<div dir="ltr">Thanks for the reply. <div>I figured out that my SMR was malformed. </div><div>Now, everything is working fine.</div><div>Nice!!</div><div>Thanks. </div><div><br></div><div>/Yoonseon Han </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 29, 2016 at 8:11 PM, YoonSeon Han <span dir="ltr"><<a href="mailto:yoonseon@onlab.us" target="_blank">yoonseon@onlab.us</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">Dear OOR users, <div><br></div><div><div style="font-size:12.8px">Hi. My name is yoonseon han, and I just started to support dynamic configuration using YANG/NetConf. </div></div><div><br></div><div>I did successfully configured OOR as my testbed LISP data plane. </div><div>Also, it well supports dynamic local db configuration and resolver modifications through NetConf.</div><div><br></div><div>However, I have a problem. </div><div>After OOR local-db is changed through NetConf, OOR doesn't send SMR to xTRs on it's map cache. </div><div>Moreover, there are no function to process SMR when OOR receives SMR. </div><div>Am I misconfigured OOR? or is still in development?</div><div><br></div><div>Second question is that when local cache mapping is expired, it continues send map request to the xTR where the EID was supported. </div><div>For example, xTR A was provided 1.1.1.1 EID. </div><div>But, it removed from local-db of xTR A. </div><div>In this case, xTR B (client) noticed that xTR A not support 1.1.1.1 EID by xTR A.</div><div>But, xTR B continuously send map-request to xTR A, and the xTR B's cache recored never expired. </div><div>The map-cache record should removed form xTR B, and it should get new mapping info. from mapping system. </div><div>I attached my log in the last part of this mail. </div><div><br></div><div>As summary, </div><div><br></div><div>1. OOR not send SMR when configured through NetConf</div><div>2. OOR not process SMR when receive SMR as ITR</div><div>3. OOR map cache never not expired. </div><div><br></div><div>Sincerely, </div><div><br></div><div>/Yoonseon Han</div><div><br></div><div>EID - 11.11.11.11</div><div>ITR - 141.223.92.125</div><div>ETR - 141.223.92.127</div><div>Now, 141.223.92.127 not support 11.11.11.11 EID anymore. </div><div><br></div><div><div>[2016/11/30 12:57:26] DEBUG-3: Forwarding native to destination 11.11.11.11</div><div>[2016/11/30 12:57:27] DEBUG: Sent control message IP: 141.223.92.125 -> 141.223.92.127 UDP: 4342 -> 4342</div><div>[2016/11/30 12:57:27] DEBUG: Map-Request Probe for locator 141.223.92.127 and EID: <a href="http://11.11.11.11/32" target="_blank">11.11.11.11/32</a></div><div>[2016/11/30 12:57:27] DEBUG-3: OUTPUT: Received EID 2.2.2.2 -> 11.11.11.11, Proto: 1, Port: 0 -> 0</div><div>[2016/11/30 12:57:27] DEBUG-3: Forwarding native to destination 11.11.11.11</div><div>[2016/11/30 12:57:28] DEBUG: Sent control message IP: 141.223.92.125 -> 141.223.92.127 UDP: 4342 -> 4342</div><div>[2016/11/30 12:57:28] DEBUG: Retry Map-Request Probe for locator 141.223.92.127 and EID: <a href="http://11.11.11.11/32" target="_blank">11.11.11.11/32</a> (1 retries)</div><div>[2016/11/30 12:57:29] DEBUG-3: OUTPUT: Received EID 2.2.2.2 -> 11.11.11.11, Proto: 1, Port: 0 -> 0</div><div>[2016/11/30 12:57:29] DEBUG-3: Forwarding native to destination 11.11.11.11</div><div>[2016/11/30 12:57:29] DEBUG-2: Reprogramed RLOC probing of the locator 141.223.92.127 of the EID <a href="http://11.11.11.11/32" target="_blank">11.11.11.11/32</a> in 1 seconds</div><div>[2016/11/30 12:57:30] DEBUG-3: OUTPUT: Received EID 2.2.2.2 -> 11.11.11.11, Proto: 1, Port: 0 -> 0</div><div>[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</div><div>IID|VNI: 0</div></div><div><br></div></div>
</blockquote></div><br></div>