Hi,
This is something really strange. When an RLOC of an xTR is modified,
OOR should start the SMR procedure. The SMR should notify all the xTRs
that were talking with our xTR (entries of the map cache) that have had
a change with our EID. It doesn't appear anything related to SMR in the
logs when you modify the RLOC?
Best regards
Albert
El 09/06/17 a les 22:03, José Miguel Guzmán ha escrit:
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
<http://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
<http://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
<http://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
<http://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
<http://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
<http://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
<mailto: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 <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>
jmguz...@whitestack.com <mailto:jmguz...@whitestack.com>
jmguzmanc
--
*José Miguel Guzmán
*Senior Network Consultant
Latin America & Caribbean
+1 (650) 248-2490 <tel:+16502482490>
+56 (9) 9064-2780 <tel:+56990642780>
jmguz...@whitestack.com <mailto:jmguz...@whitestack.com>
jmguzmanc
_______________________________________________
Users mailing list
Users@openoverlayrouter.org
http://mail.openoverlayrouter.org/cgi-bin/mailman/listinfo/users
