[OOR-Users] Prefix expiration dropping traffic
Albert López
alopez at ac.upc.edu
Mon Jun 12 10:19:14 CEST 2017
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 (<alopez at ac.upc.edu
> <mailto:alopez at 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>
>>
>> jmguzman at whitestack.com <mailto:jmguzman at 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>
>
> jmguzman at whitestack.com <mailto:jmguzman at whitestack.com>
>
> jmguzmanc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openoverlayrouter.org/pipermail/users/attachments/20170612/86097b94/attachment.html>
More information about the Users
mailing list