<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jun 9, 2017 at 11:26 PM, José Miguel Guzmán <span dir="ltr"><<a href="mailto:jmguzman@whitestack.com" target="_blank">jmguzman@whitestack.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Lori, I agree with you.<div>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)</div><div>For 2), I found the function that handles the timer expiration <font face="monospace">mc_entry_<wbr>expiration_timer_cb</font>. I will need to review the code to see if it is safe to call <font face="monospace">handle_map_cache_miss(<wbr>xtr, dst_eid, src_eid)</font> here. I am confused with this</div><div><div><font face="monospace">/* If the EID is not from a iid net, try to fordward to the PeTR */</font></div><div><font face="monospace">if (lisp_addr_is_iid(dst_eid) == FALSE){</font></div></div><div><br></div><div>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).</div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>-Lori</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class="HOEnZb"><font color="#888888"><div><br></div><div>JM</div></font></span><div><div class="h5"><div><br></div><div><br></div><div><br></div><div><br><br><div class="gmail_quote"><div dir="ltr">El vie., 9 jun. 2017 a las 4:00, Lori Jakab (<<a href="mailto:lorand.jakab@gmail.com" target="_blank">lorand.jakab@gmail.com</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Jose,<div><br></div><div>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:</div><div><ol><li>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.</li><li>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.</li></ol><div>In theory we could just do 2) without 1) but we don't want to keep unused entries around in the map-cache.</div><div><br></div><div>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.</div></div><div><br></div><div>Regards,</div><div>-Lori</div></div><div class="gmail_extra"><br><div class="gmail_quote"></div></div><div class="gmail_extra"><div class="gmail_quote">On Fri, Jun 9, 2017 at 10:34 AM, Albert López <span dir="ltr"><<a href="mailto:alopez@ac.upc.edu" target="_blank">alopez@ac.upc.edu</a>></span> wrote:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<div class="m_1430977790609434764m_-2318041939853115081m_-6660769542085780350moz-cite-prefix">Dear José,<br>
<br>
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_<wbr>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.<br>
<br>
Best regards<br>
<br>
Albert<br>
<br>
<br>
El 09/06/17 a les 00:08, José Miguel Guzmán ha escrit:<br>
</div><div><div class="m_1430977790609434764m_-2318041939853115081h5">
<blockquote type="cite">
<div dir="ltr">Hi All
<div><br>
</div>
<div>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)</div>
<div><br>
</div>
<div>
<div><font face="monospace"><b>[2017/6/8 18:53:48] DEBUG: Got
expiration for EID <a href="http://192.168.102.0/24" target="_blank">192.168.102.0/24</a></b></font></div>
<div><b><span style="font-family:monospace">[2017/6/8
18:53:49] DEBUG: No map cache for EID 192.168.102.168.
Sending Map-Request!</span><br>
</b></div>
<div><font face="monospace">[2017/6/8 18:53:49] DEBUG-2:
lisp_addr_get_ip_pref_addr: Not applicable to ip
addressess</font></div>
<div><font face="monospace">[2017/6/8 18:53:49] DEBUG:
Balancing locator vector for <a href="http://192.168.102.168/32" target="_blank">192.168.102.168/32</a>:</font></div>
<div><font face="monospace">[2017/6/8 18:53:49] DEBUG: IPv4
locators vector (0 locators):</font></div>
<div><font face="monospace">[2017/6/8 18:53:49] DEBUG: IPv6
locators vector (0 locators):</font></div>
<div><font face="monospace">[2017/6/8 18:53:49] DEBUG: IPv4
& IPv6 locators vector (0 locators):</font></div>
<div><font face="monospace">[2017/6/8 18:53:49] DEBUG:
locators for req: 172.16.60.8</font></div>
<div><font face="monospace">[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: <a href="http://192.168.102.168/32" target="_blank">192.168.102.168/32</a></font></div>
<div><font face="monospace">[2017/6/8 18:53:49] DEBUG-2:
lisp_addr_get_ip_addr: Not applicable to prefixes</font></div>
<div><font face="monospace">[2017/6/8 18:53:49] DEBUG: ECM
-> flags:s, inner IP: 192.168.101.1 -> <a href="http://192.168.102.168/32" target="_blank">192.168.102.168/32</a>,
inner UDP: 4342 -> 4342</font></div>
<div><font face="monospace">[2017/6/8 18:53:49] DEBUG: Sent
control message IP: 172.16.60.8 -> 172.16.60.194 UDP:
4342 -> 4342</font></div>
<div><font face="monospace"><b>[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</b></font></div>
<div><font face="monospace">[2017/6/8 18:53:49] DEBUG:
Mapping-record -> ttl: 1 loc-count: 1 action: no-action
auth: 0 map-version: 0 eid: <a href="http://192.168.102.0/24" target="_blank">192.168.102.0/24</a></font></div>
<div><font face="monospace">[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</font></div>
<div><font face="monospace">[2017/6/8 18:53:49] DEBUG-2:
mapping_get_locators_with_afi: List for OOR AFI 1 and afi
2 not yet created</font></div>
<div><font face="monospace">[2017/6/8 18:53:49] DEBUG-2:
mapping_add_locator: Added locator 172.16.60.9 to the
mapping with EID <a href="http://192.168.102.0/24" target="_blank">192.168.102.0/24</a>.</font></div>
<div><font face="monospace">[2017/6/8 18:53:49] DEBUG-2:
mapping_get_locators_with_afi: List for OOR AFI 3 and afi
10 not yet created</font></div>
<div><font face="monospace">[2017/6/8 18:53:49] DEBUG:
Balancing locator vector for <a href="http://192.168.102.0/24" target="_blank">192.168.102.0/24</a>:</font></div>
<div><font face="monospace">[2017/6/8 18:53:49] DEBUG: IPv4
locators vector (1 locators): 172.16.60.9</font></div>
<div><font face="monospace">[2017/6/8 18:53:49] DEBUG: IPv6
locators vector (0 locators):</font></div>
<div><font face="monospace">[2017/6/8 18:53:49] DEBUG: IPv4
& IPv6 locators vector (0 locators):</font></div>
<div><font face="monospace"><b>[2017/6/8 18:53:49] DEBUG: The
map cache entry of EID <a href="http://192.168.102.0/24" target="_blank">192.168.102.0/24</a>
will expire in 1 minutes.</b></font></div>
<div><font face="monospace">[2017/6/8 18:53:49] DEBUG-2:
Programming probing of EID's <a href="http://192.168.102.0/24" target="_blank">192.168.102.0/24</a>
locator 172.16.60.9 (30 seconds)</font></div>
</div>
<div><br>
</div>
<div>I am not sure if I am doing something wrong.. (probably
:)) </div>
<div><br>
</div>
<div>Is there any way to handle this transparently? For
instance, have xTR refreshing prefixes 5secs before
expiration, so, traffic is not interrupted?<br>
</div>
<div>Are these expiration timers, configurable? I only see
that rloc-probing timers are tunable.</div>
<div><br>
</div>
<div>Thanks!</div>
<div>JM</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div dir="ltr">-- <br>
</div>
<div data-smartmail="gmail_signature">
<div dir="ltr">
<table cellspacing="0" cellpadding="0">
<tbody>
<tr>
<td colspan="3"><img src="http://www.whitestack.com/static/whitestack_signature.png"></td>
</tr>
<tr>
<td width="31px"><br>
</td>
<td colspan="3"><b>José Miguel Guzmán<br>
</b>Senior Network Consultant<br>
Latin America & Caribbean<br>
</td>
</tr>
<tr>
<td><br>
</td>
<td class="m_1430977790609434764m_-2318041939853115081m_-6660769542085780350inbox-inbox-icon" valign="top"><img src="http://www.whitestack.com/static/phone-icon.png"></td>
<td class="m_1430977790609434764m_-2318041939853115081m_-6660769542085780350inbox-inbox-info" valign="top"> <a href="tel:+16502482490" target="_blank">+1
(650) 248-2490</a><br>
<a href="tel:+56990642780" target="_blank">+56
(9) 9064-2780</a></td>
</tr>
<tr>
<td><br>
</td>
<td class="m_1430977790609434764m_-2318041939853115081m_-6660769542085780350inbox-inbox-icon" valign="top"><img src="http://www.whitestack.com/static/email-icon.png"></td>
<td class="m_1430977790609434764m_-2318041939853115081m_-6660769542085780350inbox-inbox-info" valign="top"> <a href="mailto:jmguzman@whitestack.com" target="_blank">jmguzman@whitestack.com</a></td>
</tr>
<tr>
<td><br>
</td>
<td class="m_1430977790609434764m_-2318041939853115081m_-6660769542085780350inbox-inbox-icon" valign="top"><img src="http://www.whitestack.com/static/skype-icon.png"></td>
<td class="m_1430977790609434764m_-2318041939853115081m_-6660769542085780350inbox-inbox-info" valign="top"> <a>jmguzmanc</a></td>
</tr>
</tbody>
</table>
</div>
</div>
</blockquote>
<br>
</div></div></div>
<br></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">______________________________<wbr>_________________<br>
Users mailing list<br>
<a href="mailto:Users@openoverlayrouter.org" target="_blank">Users@openoverlayrouter.org</a><br>
<a href="http://mail.openoverlayrouter.org/cgi-bin/mailman/listinfo/users" rel="noreferrer" target="_blank">http://mail.openoverlayrouter.<wbr>org/cgi-bin/mailman/listinfo/<wbr>users</a><br>
<br></blockquote></div><br></div>
</blockquote></div></div></div></div></div><div class="HOEnZb"><div class="h5"><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr"><table cellpadding="0" cellspacing="0" style="font-family:'trebuchet ms',arial,sans-serif;font-size:11px"><tbody><tr><td colspan="3"><img src="http://www.whitestack.com/static/whitestack_signature.png"></td></tr><tr><td width="31px"></td><td colspan="3"><b>José Miguel Guzmán<br></b>Senior Network Consultant<br>Latin America & Caribbean<br></td></tr><tr><td></td><td class="m_1430977790609434764inbox-inbox-icon" valign="top"><img src="http://www.whitestack.com/static/phone-icon.png"></td><td class="m_1430977790609434764inbox-inbox-info" valign="top"> <a href="tel:+16502482490" target="_blank">+1 (650) 248-2490</a><br> <a href="tel:+56990642780" target="_blank">+56 (9) 9064-2780</a></td></tr><tr><td></td><td class="m_1430977790609434764inbox-inbox-icon" valign="top"><img src="http://www.whitestack.com/static/email-icon.png"></td><td class="m_1430977790609434764inbox-inbox-info" valign="top"> <a href="mailto:jmguzman@whitestack.com" target="_blank">jmguzman@whitestack.com</a></td></tr><tr><td></td><td class="m_1430977790609434764inbox-inbox-icon" valign="top"><img src="http://www.whitestack.com/static/skype-icon.png"></td><td class="m_1430977790609434764inbox-inbox-info" valign="top"> <a>jmguzmanc</a></td></tr></tbody></table></div></div>
</div></div></blockquote></div><br></div></div>