On Fri, Jun 9, 2017 at 11:26 PM, José Miguel Guzmán <jmguz...@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.ja...@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 <alo...@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>
>>>
>>> jmguz...@whitestack.com
>>>
>>> jmguzmanc
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users@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>
> jmguz...@whitestack.com
> jmguzmanc
>
_______________________________________________
Users mailing list
Users@openoverlayrouter.org
http://mail.openoverlayrouter.org/cgi-bin/mailman/listinfo/users
