[OOR-Users] Prefix expiration dropping traffic

Mon Jun 12 10:40:40 CEST 2017

On Mon, Jun 12, 2017 at 11:11 AM, Albert López <alopez at ac.upc.edu> wrote:

> Dear all,
>
> From my point of view I think that it doesn't matter if we start the
> refresh of the mapping just when the timer expires. It will make the code
> quite more easy.
> What I would do is:
>
> We call the function "mc_entry_expiration_timer_cb" when the entry is
> going to be expired. This function should check when was the last time we
> had a packet for that map cache entry. If the time is more than X, we
> remove the entry otherwise we call a new function that will do somthing
> similar to this:
>
>     timer_arg = timer_map_req_arg_new_init(mce,src_eid);
>     timer = oor_timer_with_nonce_new(MAP_REQUEST_RETRY_TIMER,xtr,send_
> map_request_retry_cb,
>             timer_arg,(oor_timer_del_cb_arg_fn)timer_map_req_arg_free);
>
> What we does this code is to create a new timer that will send a new map
> request for the map cache entry. If we don't receive a map reply after y
> retries, it will remove the map cache entry, otherwise it will update the
> map cache entry with the information of the map reply.
>
> The part to obtain when was the last time we had a packet for that map
> cache entry is something that should be implemented in the data plane
> module. The problem here is that it has been some changes from the master
> branch to the new version we are working with. I think that in that point
> you should add a new function in the data_plane_struct to obtain this
> information but the implementation of this function will be different for
> the current master branch code and the new release code.
>

Sounds good. It is propably best then for Jose to wait for the new data
plane code to become available.

Best regards,
-Lori

>
>
> Best regards
>
> Albert
>
>
>
> El 10/06/17 a les 08:51, Lori Jakab ha escrit:
>
> On Fri, Jun 9, 2017 at 11:26 PM, José Miguel Guzmán <
> jmguzman at whitestack.com> wrote:
>
>> 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).
>>
>
> Well, if a site operator set a certain TTL, that's for a reason, and we
> need to respect that, so I think we should remove or overwrite an expired
> entry. I would suggest to do the proactive refresh BEFORE the entry
> expires. Say we have a TTL of 1000 seconds, we initiate the refresh after
> 990 seconds elapsed, so that the entry is refreshed already when it would
> have to be removed.
>
> -Lori
>
>
>>
>> JM
>>
>>
>>
>>
>>
>> El vie., 9 jun. 2017 a las 4:00, Lori Jakab (<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> 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:
>>>> [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
>>>> [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, 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
>>>> [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.
>>>> [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:
>>>> [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 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 <+16502482490>
>>>>   +56 (9) 9064-2780 <+56990642780>
>>>>
>>>>   jmguzman at whitestack.com
>>>>
>>>>   jmguzmanc
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> 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 <+16502482490>
>>   +56 (9) 9064-2780 <+56990642780>
>>
>>   jmguzman at whitestack.com
>>
>>   jmguzmanc
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openoverlayrouter.org/pipermail/users/attachments/20170612/39e5c718/attachment-0001.html>