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 > >
_______________________________________________ Users mailing list Users@openoverlayrouter.org http://mail.openoverlayrouter.org/cgi-bin/mailman/listinfo/users
