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
[email protected]
http://mail.openoverlayrouter.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://mail.openoverlayrouter.org/cgi-bin/mailman/listinfo/users
