https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/OPNFLWPLUG-477 OpenFlowPlugin <p>1) Start karaf<br/> 2) Enable below features<br/> feature:install odl-openflowplugin-flow-services-ui<br/> feature:install odl-l2switch-loopremover</p> <p>3) Now connect a topology of two switches in linear and no hosts</p> <p>mn --controller=remote,ip=10.11.200.3 --topo linear,2,0 --switch ovsk,protocols=OpenFlow13</p> <p>3) Check the number of links discovered. It is 2. One in each direction.<br/> 4) Now type exit in mininet<br/> 5) Repeat step 3 one more time.<br/> 6) Check the number of links discovered. I see only one link.<br/> 7) Packet captures revealed that controller did not send lldp discovery on one of the switches.<br/> 8) If I connect a linear topology of 2 switches with one host each I dont see this problem.<br/> mn --controller=remote,ip=10.11.200.3 --topo linear,2,1 --switch ovsk,protocols=OpenFlow13</p> <p>Attaching the packet captures for step 3 and 5.</p> <p>Operating System: All<br/> Platform: All</p> OPNFLWPLUG-477

He plugin: LLDP speaker does not start/stop sending LLDP packets on port up/down events

Bug Resolved Done Anil Vishnoi SANDEEP GANGADHARAN Tue, 2 Jun 2015 21:38:47 +0000 Mon, 27 Sep 2021 09:01:33 +0000 Tue, 12 Dec 2017 00:39:17 +0000 Boron General Fri, 18 Dec 2015 00:00:00 +0000 0 8 <p>Attachment captures.zip has been added with description: captures of before and after network restart</p> <p>Hi Sandeep,</p> <p>Can you reproduce the issue with odl-openflowplugin-flow-services-ui feature only? If not I think we should submit this bug to l2switch folks.</p> <p>BR/Luis</p> <p>(In reply to Luis Gomez from comment #1)<br/> &gt; Hi Sandeep,<br/> &gt; <br/> &gt; Can you reproduce the issue with odl-openflowplugin-flow-services-ui feature<br/> &gt; only? If not I think we should submit this bug to l2switch folks.<br/> &gt; <br/> &gt; BR/Luis</p> <p>Hi Luis<br/> Links are not learned until odl-l2switch-loopremover is installed. This is the behavior in Lithium and Helium.</p> <p>Regards<br/> Sandeep</p> <p>(In reply to SANDEEP GANGADHARAN from comment #2)<br/> &gt; (In reply to Luis Gomez from comment #1)<br/> &gt; &gt; Hi Sandeep,<br/> &gt; &gt; <br/> &gt; &gt; Can you reproduce the issue with odl-openflowplugin-flow-services-ui feature<br/> &gt; &gt; only? If not I think we should submit this bug to l2switch folks.<br/> &gt; &gt; <br/> &gt; &gt; BR/Luis<br/> &gt; <br/> &gt; Hi Luis<br/> &gt; Links are not learned until odl-l2switch-loopremover is installed.<br/> &gt; This is the behavior in Lithium and Helium.<br/> &gt; <br/> &gt; Regards<br/> &gt; Sandeep</p> <p>Sandeep,</p> <p>I didn't follow all the way. Are you saying that your environment doesn't learn links at all until you install loopremover? If so, I think something is wrong as we should be getting link learning with just ofp-flow-services-ui</p> <p>Thanks,<br/> JamO</p> <p>(In reply to Jamo Luhrsen from comment #3)<br/> &gt; (In reply to SANDEEP GANGADHARAN from comment #2)<br/> &gt; &gt; (In reply to Luis Gomez from comment #1)<br/> &gt; &gt; &gt; Hi Sandeep,<br/> &gt; &gt; &gt; <br/> &gt; &gt; &gt; Can you reproduce the issue with odl-openflowplugin-flow-services-ui feature<br/> &gt; &gt; &gt; only? If not I think we should submit this bug to l2switch folks.<br/> &gt; &gt; &gt; <br/> &gt; &gt; &gt; BR/Luis<br/> &gt; &gt; <br/> &gt; &gt; Hi Luis<br/> &gt; &gt; Links are not learned until odl-l2switch-loopremover is installed.<br/> &gt; &gt; This is the behavior in Lithium and Helium.<br/> &gt; &gt; <br/> &gt; &gt; Regards<br/> &gt; &gt; Sandeep<br/> &gt; <br/> &gt; <br/> &gt; Sandeep,<br/> &gt; <br/> &gt; I didn't follow all the way. Are you saying that your environment doesn't<br/> &gt; learn links at all until you install loopremover? If so, I think something<br/> &gt; is wrong as we should be getting link learning with just ofp-flow-services-ui<br/> &gt; <br/> &gt; Thanks,<br/> &gt; JamO</p> <p>Jamo/Luis<br/> Yes. With only ofp-flow-services-ui enabled controller does not learn links. Should this be another defect?</p> <p>Regards<br/> Sandeep</p> <p>so after further investigation with Sandeep, we have narrowed things down a little more.</p> <p>the first point is that this problem is coming if you only install odl-openflowplugin-flow-services-ui. The confusion between us is that with <br/> just that feature I was seeing links being learned and Sandeep was not.<br/> The reason is that my ovs v2.0 was punting packets (so lldp's) to the <br/> controller. By default, Sandeeps v2.3 ovs was dropping those so no <br/> links are learned. If you use v2.3 ovs you can then program a catchall<br/> flow to punt packets to the controller in order to have lldp's sent <br/> there and links learned.</p> <p>so, with just ofp-flow-services-ui installed, the basic steps of starting<br/> mininet with a linear,2,0 topo, stopping then restarting will show that<br/> the expected 2 links are not learned. just one.</p> <p>to be clear, we wanted to rule out that l2switch-loopremover was getting<br/> in the way. it does not appear to be the case.</p> <p>Cool, then we can say this is an ofplugin bug and I personally would like to see this fix in Lithium as even if a configuration with no hosts is unusual, this bug could uncover some design problem.</p> <p>So Jamo and I were concerned this small issue was hiding something big and it actually does. After more analysis and test here are my conclusions:</p> <p>1) LLDP speaker does not start/stop sending LLDP packets on port up/down events (similar to current l2switch not reacting to port events)</p> <p>2) However when a switch connects for the first time to ODL, the LLDP speaker ONLY sends LLDP packets to those ports that report up during registration. This would be right if 1) was working.</p> <p>So, the combination of 1) and 2) behaviors makes topology to fail to update any new connection you create between switches after initial registration.</p> <p>BR/Luis</p> <p>Adding Anil to this one.</p> <p>Anil fixed similar issue when a switch adds/removes an openflow port. This is a similar case where the port goes up/down.</p> <p>Hi, here is the experimental fix. I pushed it on master. Please test it whenever you have spared cycles.<br/> <a href="https://git.opendaylight.org/gerrit/#/c/22811/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/22811/</a></p> <p>What is this to do with l2switch? the issue is in openflowplugin helium code at least (I have not tested with Li code).</p> <p>(In reply to Luis Gomez from comment #11)<br/> &gt; What is this to do with l2switch? the issue is in openflowplugin helium code<br/> &gt; at least (I have not tested with Li code).</p> <p>To reinforce Luis' point, see comment #5. The issue detailed in this <br/> bug does not involve l2switch (those features are not even installed)</p> <p>OK, I see the point now, this issue is not happening with Li redesign, only with He code.</p> <p>Since all projects in Li are based in He code we need a workaround and here is my suggest: if the port event notifications are difficult to address in He code, lets change the LLDP speaker to send LLDP packets at connection time to all ports regarless whether they are up or down. This should be easy to achieve in code and will alleviate very much this bug.</p> <p>BR/Luis</p> <p>(In reply to Luis Gomez from comment #13)<br/> &gt; OK, I see the point now, this issue is not happening with Li redesign, only<br/> &gt; with He code.<br/> &gt; <br/> &gt; Since all projects in Li are based in He code we need a workaround and here<br/> &gt; is my suggest: if the port event notifications are difficult to address in<br/> &gt; He code, lets change the LLDP speaker to send LLDP packets at connection<br/> &gt; time to all ports regarless whether they are up or down. This should be easy<br/> &gt; to achieve in code and will alleviate very much this bug.<br/> &gt; <br/> &gt; BR/Luis</p> <p>This could produce a lot of useless noise in the mgmt network. Imagine a few high port density switches. The controller will be sending LLDP packet outs on the wire a lot.</p> <p>but if it's determined to be the only way for now, it's better to do that, than lose a link in the topology.</p> <p>I understand Jamo. My workaround is in case nothing can be done or too much effort to fix. Better too chatty protocol than not working right?</p> <p>(In reply to Luis Gomez from comment #15)<br/> &gt; I understand Jamo. My workaround is in case nothing can be done or too much<br/> &gt; effort to fix. Better too chatty protocol than not working right?</p> <p>Probably not too chatty - if the ports are not up nothing will come on the wire - right?</p> <p>(In reply to Abhijit Kumbhare from comment #16)<br/> &gt; (In reply to Luis Gomez from comment #15)<br/> &gt; &gt; I understand Jamo. My workaround is in case nothing can be done or too much<br/> &gt; &gt; effort to fix. Better too chatty protocol than not working right?<br/> &gt; <br/> &gt; Probably not too chatty - if the ports are not up nothing will come on the<br/> &gt; wire - right?</p> <p>No, the suggestion is that if we cannot send LLDP packet-out based on ports being UP (via notifications) then we just send LLDP on <b>all</b> ports that the switch advertises, even if they are down. So, packet-out on a down port is the chatty part.</p> <p>I agree with Luis. Chatty is better than broken.</p> <p>More reasons to fix: this works in Helium so it could be seen as regression</p> <p>I was asked by Michal Rehak to continue with his remarks.<br/> As he identified, the probable place for change shoud be in class<br/> org.opendaylight.openflowplugin.applications.lldpspeaker.NodeConnectorInventoryEventTranslator</p> <p>I prepared this patch <br/> <a href="https://git.opendaylight.org/gerrit/#/c/22882/1" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/22882/1</a></p> <p>I have tested it aproximately 10 times (mininet up-down, with 2 switches with no hosts) and in logs I have seen both links.<br/> I installed only <br/> &gt;&gt;&gt;&gt;feature:install odl-openflowplugin-flow-services-ui</p> <p>and debugging was set as following<br/> &gt;&gt;&gt;&gt;&gt;&gt;log:set TRACE org.opendaylight.openflowplugin.applications.lldpspeaker.LLDPSpeaker<br/> &gt;&gt;&gt;&gt;&gt;&gt;log:set TRACE org.opendaylight.openflowplugin.applications.lldpspeaker.NodeConnectorInventoryEventTranslator</p> <p>Luis: I pushed a fix to stable/helium branch as well</p> <p><a href="https://git.opendaylight.org/gerrit/23795" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/23795</a></p> <p>Can you please verify it.</p> <p>Anil, your patch actually fixes:</p> <p><a href="https://bugs.opendaylight.org/show_bug.cgi?id=3233" class="external-link" target="_blank" rel="nofollow noopener">https://bugs.opendaylight.org/show_bug.cgi?id=3233</a></p> <p>which is a different issue <img class="emoticon" src="https://jira.opendaylight.org/images/icons/emoticons/smile.png" height="16" width="16" align="absmiddle" alt="" border="0"/></p> <p>This was actually fixed before we released Lithium.</p> <p>Actually it is not, I just checked with latest stable/lithium.</p> <p>This bug is still pending for resolution...</p> <p>This one is tricky to reproduce with mininet becasue you need a switch with a port in state DOWN when it connects to controller and then bring the port UP. I just did with a HW switch and the issue is still there.</p> <p>Adding Kamal for a quick check of this.</p> <p>Adding Anil for a quick check of this. Apparently this is happening only with the He design.</p> <p>Just tested and LLDP speaker works good in the case of port UP. For the port DOWN the issue is still there but it is not that critical so lowering the priority.</p> <p>BR/Luis</p> <p>I tried to reproduce this problem on latest master branch (carbon) and it is working perfectly fine (at least when I tried to reproduce it with steps described in original description, but + added table miss entries, because otherwise links are just not showing)</p> <p>1. Start mininet with linear topo with 2 switches and no hosts<br/> 2. Check topology<br/> &#8212; NODES <span class="error">&#91;2&#93;</span>---<br/> <span class="error">&#91;openflow:1&#93;</span><br/> openflow:1:1<br/> openflow:1:LOCAL<br/> <span class="error">&#91;openflow:2&#93;</span><br/> openflow:2:LOCAL<br/> openflow:2:1<br/> &#8212; LINKS <span class="error">&#91;2&#93;</span>---<br/> openflow:2:1 --&gt; openflow:1:1<br/> openflow:1:1 --&gt; openflow:2:1<br/> 3. Exit mininet and check topology<br/> &#8212; NODES <span class="error">&#91;2&#93;</span>---<br/> <span class="error">&#91;openflow:1&#93;</span><br/> openflow:1:1<br/> openflow:1:LOCAL<br/> <span class="error">&#91;openflow:2&#93;</span><br/> openflow:2:LOCAL<br/> openflow:2:1<br/> &#8212; LINKS <span class="error">&#91;0&#93;</span>---<br/> 4. Start mininet again, and check topology (result should be same as in step 2)<br/> 5. Set port 1 of switch 1 DOWN and check topology (result should be same as in step 3)<br/> 6. Set port 1 of switch 1 UP and check topology (result should be same as in step 2)</p> <p>Attached also pcap from Wireshark.</p> <p>Attachment lldp.pcapng has been added with description: Switch port UP/DOWN capture</p> <p>I do not see PORT STATUS events in the capture, normally to verify this bug with wireshark we should see a port DOWN event and after controller should not be sending any LLDP packet-out to that port.</p> <p>Adding capture also with PORT_STATUS messages, with these steps</p> <p>1. Start mininet<br/> 2. Set port 1 on switch s1 DOWN<br/> 3. Set port 1 on switch s1 UP<br/> 4. Stop mininet<br/> 5. Repeat steps 1 - 4</p> <p>PORT_STATUS is correctly send on DOWN event, but I think, even when we received this DOWN event, PACKET_OUTS are still sent to port.</p> <p>Attachment lldp.pcapng has been added with description: PORT_STATUS+ LLDP capture</p> <p>I believe this bug was fixed in helium plugin. Given that helium plugin is now deprecated, please re-open the bug if you see this issue with carbon/nitrogen/oxygen branch.</p> Development External issue ID 3548 External issue URL Rank 0|i031e7: