[OOR-Users] A Question about map cache expire and SMR.

[Albert López]

Hi YoonSeon,

I reply in-line

On 30/11/16 05:11, YoonSeon Han wrote:
> Dear OOR users,
>
> Hi. My name is yoonseon han, and I just started to support dynamic 
> configuration using YANG/NetConf.
>
> I did successfully configured OOR as my testbed LISP data plane.
> Also, it well supports dynamic local db configuration and resolver 
> modifications through NetConf.
>
> However, I have a problem.
> After OOR local-db is changed through NetConf, OOR doesn't send SMR to 
> xTRs on it's map cache.
We have updated the code on master to fix this problem. It is configured 
to only send an SMR of the existing entries that have been modified.
It doesn't sent SMR for new entries, not modified entries or removed 
entries.
> Moreover, there are no function to process SMR when OOR receives SMR.
> Am I misconfigured OOR? or is still in development?
We have checked and we process correctly the SMR. The function is 
tr_reply_to_smr() which is call in tr_recv_map_request(). Have you 
checked the logs when receiving an SMR?
>
> Second question is that when local cache mapping is expired, it 
> continues send map request to the xTR where the EID was supported.
> For example, xTR A was provided 1.1.1.1 EID.
> But, it removed from local-db of xTR A.
> In this case, xTR B (client) noticed that xTR A not support 1.1.1.1 
> EID by xTR A.
> But, xTR B continuously send map-request to xTR A, and the xTR B's 
> cache recored never expired.
> The map-cache record should removed form xTR B, and it should get new 
> mapping info. from mapping system.
> I attached my log in the last part of this mail.
I don't understand this point. Do you refer when we remove a local eid 
prefix using netconf? Could you give me more details? From logs I see 
that the the control messages are related to RLOC probing.

Best regards

Albert
>
> As summary,
>
> 1. OOR not send SMR when configured through NetConf
> 2. OOR not process SMR when receive SMR as ITR
> 3. OOR map cache never not expired.
>
> Sincerely,
>
> /Yoonseon Han
>
> EID - 11.11.11.11
> ITR - 141.223.92.125
> ETR - 141.223.92.127
> Now, 141.223.92.127 not support 11.11.11.11 EID anymore.
>
> [2016/11/30 12:57:26] DEBUG-3: Forwarding native to destination 
> 11.11.11.11
> [2016/11/30 12:57:27] DEBUG: Sent control message IP: 141.223.92.125 
> -> 141.223.92.127 UDP: 4342 -> 4342
> [2016/11/30 12:57:27] DEBUG: Map-Request Probe for locator 
> 141.223.92.127 and EID: 11.11.11.11/32 <http://11.11.11.11/32>
> [2016/11/30 12:57:27] DEBUG-3: OUTPUT: Received EID 2.2.2.2 -> 
> 11.11.11.11, Proto: 1, Port: 0 -> 0
> [2016/11/30 12:57:27] DEBUG-3: Forwarding native to destination 
> 11.11.11.11
> [2016/11/30 12:57:28] DEBUG: Sent control message IP: 141.223.92.125 
> -> 141.223.92.127 UDP: 4342 -> 4342
> [2016/11/30 12:57:28] DEBUG: Retry Map-Request Probe for locator 
> 141.223.92.127 and EID: 11.11.11.11/32 <http://11.11.11.11/32> (1 retries)
> [2016/11/30 12:57:29] DEBUG-3: OUTPUT: Received EID 2.2.2.2 -> 
> 11.11.11.11, Proto: 1, Port: 0 -> 0
> [2016/11/30 12:57:29] DEBUG-3: Forwarding native to destination 
> 11.11.11.11
> [2016/11/30 12:57:29] DEBUG-2: Reprogramed RLOC probing of the locator 
> 141.223.92.127 of the EID 11.11.11.11/32 <http://11.11.11.11/32> in 1 
> seconds
> [2016/11/30 12:57:30] DEBUG-3: OUTPUT: Received EID 2.2.2.2 -> 
> 11.11.11.11, Proto: 1, Port: 0 -> 0
> [2016/11/30 12:57:30] DEBUG-3: ttable_remove_with_khiter: Remove 
> tupla: Src_addr: 2.2.2.2, Dst addr: 11.11.11.11, Proto: ICMP, Src 
> Port: 0, Dst Port: 0
> IID|VNI: 0
>
>
>
> _______________________________________________
> Users mailing list
> Users at openoverlayrouter.org
> http://mail.openoverlayrouter.org/cgi-bin/mailman/listinfo/users


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openoverlayrouter.org/pipermail/users/attachments/20161130/d41df90c/attachment.html>