On Mon, Jun 12, 2017 at 11:11 AM, Albert López <[email protected]> wrote:
> 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. > Sounds good. It is propably best then for Jose to wait for the new data plane code to become available. Best regards, -Lori > > > 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 < > [email protected]> 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 (<[email protected]>) >> 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 <[email protected]> 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> >>>> >>>> [email protected] >>>> >>>> jmguzmanc >>>> >>>> >>>> >>>> _______________________________________________ >>>> Users mailing list >>>> [email protected] >>>> http://mail.openoverlayrouter.org/cgi-bin/mailman/listinfo/users >>>> >>>> >>> -- >> >> >> *José Miguel Guzmán *Senior Network Consultant >> Latin America & Caribbean >> >> +1 (650) 248-2490 <+16502482490> >> +56 (9) 9064-2780 <+56990642780> >> >> [email protected] >> >> jmguzmanc >> > > >
_______________________________________________ Users mailing list [email protected] http://mail.openoverlayrouter.org/cgi-bin/mailman/listinfo/users
