[OOR-Users] Prefix expiration dropping traffic
Albert López
alopez at ac.upc.edu
Tue Jun 13 12:58:33 CEST 2017
Hi José Miguel,
I have added this functionality in the branch testing-novpp. The way to
check if a mapping is active or not is done in the control plane. This
should be done in the data plane but as I will not be able to reuse this
code for the new release, I used the easiest way to do it.
I hope this feature will help you in your experiments.
Best regards
Albert
El 09/06/17 a les 22:26, José Miguel Guzmán ha escrit:
> Hi Lori, I agree with you.
> IMHO, 1) is not so bad, It would help to reduce delay for the first
> packet to a forgotten prefix that reactivates. I am assuming most
> deployments will have a few EIDs (<10 in our case)
> For 2), I found the function that handles the timer expiration
> mc_entry_expiration_timer_cb. I will need to review the code to see if
> it is safe to call handle_map_cache_miss(xtr, dst_eid, src_eid) here.
> I am confused with this
> /* If the EID is not from a iid net, try to fordward to the PeTR */
> if (lisp_addr_is_iid(dst_eid) == FALSE){
>
> I am wondering if instead of removing the entry, and then installing a
> temporary NOT_ACTIVE entry, is it not better to keep the same entry in
> NOT_ACTIVE status, and use it as it were active (as the last known
> mapping).
>
> JM
>
>
>
>
>
> El vie., 9 jun. 2017 a las 4:00, Lori Jakab (<lorand.jakab at gmail.com
> <mailto:lorand.jakab at gmail.com>>) escribió:
>
> Jose,
>
> Regardless of the TTL value, one optimization in the code that
> could be made would be to be proactive in refreshing mappings in
> the map-cache, so that active flows don't get packet drops when
> the TTL expires. This would need two things to be implemented:
>
> 1. Keeping a "last hit" timestamp for each map-cache entry, to be
> able to determine which entries have active flows. For each
> packet that is cache hit, we would update the timer.
> 2. When a cache entry's TTL expires, if it is still active (for
> that we need to define what active means, which can be a
> configurable threshold) we send out a Map-Request without
> removing it, wait for a reply, and install that into the
> map-cache.
>
> In theory we could just do 2) without 1) but we don't want to keep
> unused entries around in the map-cache.
>
> I'm pretty sure the OOR team is very busy with other high priority
> items, but I'm also pretty sure they would be happy to take
> patches implementing the above.
>
> Regards,
> -Lori
>
> On Fri, Jun 9, 2017 at 10:34 AM, Albert López <alopez at ac.upc.edu
> <mailto:alopez at ac.upc.edu>> wrote:
>
> Dear José,
>
> The expiration time is defined by TTL. This is a hard coded
> parameter that is defined by DEFAULT_DATA_CACHE_TTL (defs.h)
> and is used in mapping_record_init_hdr(lisp_message_fields.c)
> . We usually set this value to 10 (10 minutes). I don't know
> why you have 1, may be I sent to you a testing version. In a
> future we would like to add this parameter in the
> configuration file but we don't have it yet.
>
> Best regards
>
> Albert
>
>
> El 09/06/17 a les 00:08, José Miguel Guzmán ha escrit:
>> Hi All
>>
>> We realized that every minute, we are dropping traffic
>> packets due to expiration of the destination prefix, and time
>> required to update the entry form server (couple of seconds)
>>
>> *[2017/6/8 18:53:48] DEBUG: Got expiration for EID
>> 192.168.102.0/24 <http://192.168.102.0/24>*
>> *[2017/6/8 18:53:49] DEBUG: No map cache for EID
>> 192.168.102.168. Sending Map-Request!
>> *
>> [2017/6/8 18:53:49] DEBUG-2: lisp_addr_get_ip_pref_addr: Not
>> applicable to ip addressess
>> [2017/6/8 18:53:49] DEBUG: Balancing locator vector for
>> 192.168.102.168/32 <http://192.168.102.168/32>:
>> [2017/6/8 18:53:49] DEBUG: IPv4 locators vector (0 locators):
>> [2017/6/8 18:53:49] DEBUG: IPv6 locators vector (0 locators):
>> [2017/6/8 18:53:49] DEBUG: IPv4 & IPv6 locators vector (0
>> locators):
>> [2017/6/8 18:53:49] DEBUG: locators for req: 172.16.60.8
>> [2017/6/8 18:53:49] DEBUG: Map-Request->
>> flags:a=0,m=0,p=0,s=0,P=0,S=0, irc: 0 (+1), record-count: 1,
>> nonce: 78627d755, itr-rlocs:172.16.60.8, src-eid:
>> 192.168.101.1, req-eid: 192.168.102.168/32
>> <http://192.168.102.168/32>
>> [2017/6/8 18:53:49] DEBUG-2: lisp_addr_get_ip_addr: Not
>> applicable to prefixes
>> [2017/6/8 18:53:49] DEBUG: ECM -> flags:s, inner IP:
>> 192.168.101.1 -> 192.168.102.168/32
>> <http://192.168.102.168/32>, inner UDP: 4342 -> 4342
>> [2017/6/8 18:53:49] DEBUG: Sent control message IP:
>> 172.16.60.8 -> 172.16.60.194 UDP: 4342 -> 4342
>> *[2017/6/8 18:53:49] DEBUG: Received Map-Reply->
>> flags:P=0,E=0,S=0, record-count: 1, nonce: 78627d75597fe77d,
>> IP: 192.168.123.75 -> 172.16.60.8, UDP: 4342 -> 4342*
>> [2017/6/8 18:53:49] DEBUG: Mapping-record -> ttl: 1
>> loc-count: 1 action: no-action auth: 0 map-version: 0 eid:
>> 192.168.102.0/24 <http://192.168.102.0/24>
>> [2017/6/8 18:53:49] DEBUG: Locator-record -> flags:
>> L=1,p=0,R=1, p/w: 1/100 255/0, addr: 172.16.60.9
>> [2017/6/8 18:53:49] DEBUG-2: mapping_get_locators_with_afi:
>> List for OOR AFI 1 and afi 2 not yet created
>> [2017/6/8 18:53:49] DEBUG-2: mapping_add_locator: Added
>> locator 172.16.60.9 to the mapping with EID 192.168.102.0/24
>> <http://192.168.102.0/24>.
>> [2017/6/8 18:53:49] DEBUG-2: mapping_get_locators_with_afi:
>> List for OOR AFI 3 and afi 10 not yet created
>> [2017/6/8 18:53:49] DEBUG: Balancing locator vector for
>> 192.168.102.0/24 <http://192.168.102.0/24>:
>> [2017/6/8 18:53:49] DEBUG: IPv4 locators vector (1
>> locators): 172.16.60.9
>> [2017/6/8 18:53:49] DEBUG: IPv6 locators vector (0 locators):
>> [2017/6/8 18:53:49] DEBUG: IPv4 & IPv6 locators vector (0
>> locators):
>> *[2017/6/8 18:53:49] DEBUG: The map cache entry of EID
>> 192.168.102.0/24 <http://192.168.102.0/24> will expire in 1
>> minutes.*
>> [2017/6/8 18:53:49] DEBUG-2: Programming probing of EID's
>> 192.168.102.0/24 <http://192.168.102.0/24> locator
>> 172.16.60.9 (30 seconds)
>>
>> I am not sure if I am doing something wrong.. (probably :))
>>
>> Is there any way to handle this transparently? For instance,
>> have xTR refreshing prefixes 5secs before expiration, so,
>> traffic is not interrupted?
>> Are these expiration timers, configurable? I only see
>> that rloc-probing timers are tunable.
>>
>> Thanks!
>> JM
>>
>>
>>
>>
>> --
>>
>> *José Miguel Guzmán
>> *Senior Network Consultant
>> Latin America & Caribbean
>>
>> +1 (650) 248-2490 <tel:+16502482490>
>> +56 (9) 9064-2780 <tel:+56990642780>
>>
>> jmguzman at whitestack.com <mailto:jmguzman at whitestack.com>
>>
>> jmguzmanc
>>
>
>
> _______________________________________________
> Users mailing list
> Users at openoverlayrouter.org <mailto:Users at openoverlayrouter.org>
> http://mail.openoverlayrouter.org/cgi-bin/mailman/listinfo/users
>
>
> --
>
> *José Miguel Guzmán
> *Senior Network Consultant
> Latin America & Caribbean
>
> +1 (650) 248-2490 <tel:+16502482490>
> +56 (9) 9064-2780 <tel:+56990642780>
>
> jmguzman at whitestack.com <mailto:jmguzman at whitestack.com>
>
> jmguzmanc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openoverlayrouter.org/pipermail/users/attachments/20170613/85f8ff82/attachment-0001.html>
More information about the Users
mailing list