On Fri, Jun 9, 2017 at 11:26 PM, José Miguel Guzmán
<jmguz...@whitestack.com <mailto:jmguz...@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.ja...@gmail.com <mailto:lorand.ja...@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
<alo...@ac.upc.edu <mailto:alo...@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>
jmguz...@whitestack.com <mailto:jmguz...@whitestack.com>
jmguzmanc
_______________________________________________
Users mailing list
Users@openoverlayrouter.org
<mailto:Users@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>
jmguz...@whitestack.com <mailto:jmguz...@whitestack.com>
jmguzmanc
