[OOR-Users] Prefix expiration dropping traffic
Albert López
alopez at ac.upc.edu
Mon Jun 12 10:11:51 CEST 2017
Dear all,
From my point of view I think that it doesn't matter if we start the
refresh of the mapping just when the timer expires. It will make the
code quite more easy.
What I would do is:
We call the function "mc_entry_expiration_timer_cb" when the entry is
going to be expired. This function should check when was the last time
we had a packet for that map cache entry. If the time is more than X, we
remove the entry otherwise we call a new function that will do somthing
similar to this:
timer_arg = timer_map_req_arg_new_init(mce,src_eid);
timer =
oor_timer_with_nonce_new(MAP_REQUEST_RETRY_TIMER,xtr,send_map_request_retry_cb,
timer_arg,(oor_timer_del_cb_arg_fn)timer_map_req_arg_free);
What we does this code is to create a new timer that will send a new map
request for the map cache entry. If we don't receive a map reply after y
retries, it will remove the map cache entry, otherwise it will update
the map cache entry with the information of the map reply.
The part to obtain when was the last time we had a packet for that map
cache entry is something that should be implemented in the data plane
module. The problem here is that it has been some changes from the
master branch to the new version we are working with. I think that in
that point you should add a new function in the data_plane_struct to
obtain this information but the implementation of this function will be
different for the current master branch code and the new release code.
Best regards
Albert
El 10/06/17 a les 08:51, Lori Jakab ha escrit:
> On Fri, Jun 9, 2017 at 11:26 PM, José Miguel Guzmán
> <jmguzman at whitestack.com <mailto:jmguzman at 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.jakab at gmail.com <mailto:lorand.jakab at 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
> <alopez at ac.upc.edu <mailto:alopez at 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 <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
>>
>
>
> _______________________________________________
> Users mailing list
> Users at openoverlayrouter.org
> <mailto:Users at openoverlayrouter.org>
> http://mail.openoverlayrouter.org/cgi-bin/mailman/listinfo/users
> <http://mail.openoverlayrouter.org/cgi-bin/mailman/listinfo/users>
>
>
> --
>
> *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/10075851/attachment-0001.html>
More information about the Users
mailing list