Thanks Albert I forgot to mention I changed that timer some time ago, to deal with the fact that when one xTR changed its RLOC, it took up to 10m to get the other xTRs to notice it. But did not realize this side effect. I reverted to 10m, and I see the same behavior (though with larger interval)
[2017/6/9 16:27:28] DEBUG: Got expiration for EID 192.168.101.0/24 [2017/6/9 16:27:29] DEBUG: No map cache for EID 192.168.101.1. Sending Map-Request! [2017/6/9 16:27:29] DEBUG: The map cache entry of EID 192.168.101.0/24 will expire in 10 minutes. [2017/6/9 16:37:28] DEBUG: Got expiration for EID 192.168.101.0/24 [2017/6/9 16:37:30] DEBUG: No map cache for EID 192.168.101.1. Sending Map-Request! [2017/6/9 16:37:30] DEBUG: The map cache entry of EID 192.168.101.0/24 will expire in 10 minutes. [2017/6/9 16:47:29] DEBUG: Got expiration for EID 192.168.101.0/24 [2017/6/9 16:47:31] DEBUG: No map cache for EID 192.168.101.1. Sending Map-Request! [2017/6/9 16:47:31] DEBUG: The map cache entry of EID 192.168.101.0/24 will expire in 10 minutes. JM El vie., 9 jun. 2017 a las 3:33, Albert López (<alo...@ac.upc.edu>) escribió: > 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 > > > -- *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
