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-76 OpenFlowPlugin <p>Get Topology is failing all the time at our integration repo. </p> <p>Error: I could not see any links between the switches on the GUI, hence the response for GET request fails.</p> <p>Steps to replicate the issue:</p> <p>1. Start the latest controller using ./run.sh -of13<br/> 2. Bring up the mininet: sudo mn --controller=remote,ip=10.125.136.52 --topo tree,2<br/> 3. Check the GUI: 3 switches are showing up, but with no links<br/> 4. Do GET requests from RESTAPI client<br/> <a href="http://10.125.136.52:8080/controller/nb/v2/topology/default" class="external-link" target="_blank" rel="nofollow noopener">http://10.125.136.52:8080/controller/nb/v2/topology/default</a></p> <p>BR<br/> Madhusudhan</p> <p>Operating System: Windows<br/> Platform: PC</p> OPNFLWPLUG-76

Get Topology fails against CPqD switch

Bug Resolved Duplicate Madhusudhan Ananderi Madhusudhan Ananderi Thu, 6 Mar 2014 01:18:29 +0000 Mon, 27 Sep 2021 09:01:05 +0000 Tue, 12 Aug 2014 13:36:55 +0000 General 0 5 <p>This testcase is working fine. Moved the status to FIXED</p> <p>Hi Madhusudhan,<br/> I tried with cpqd (ofsoftswitch) with no success. It seems like there is no LLDP packet even sent back to controller at all - which explains missing links in topology and failing pings (controller will never get alerted regarding ping packets).</p> <p>On the other hand it all works fine with ovs (openvswitch) which by default sends all packets (not covered by any flow) up to controller. So the controller gets the topology discovered and also reacts upon ping packet by creating appropriate flows.</p> <p>Are you sure, you get ping working in cpqd and not ovs? If yes, can you attach flows on your virtual devices?</p> <p>After adding flow in order to forward all packets to controller I got links in topology and ping in --topo tree,2 looks liek this:<br/> h1 -&gt; X h3 h4 <br/> h2 -&gt; X h3 h4 <br/> h3 -&gt; h1 h2 X <br/> h4 -&gt; h1 h2 X </p> <ul> <li> <ul> <li> <ul> <li>Results: 33% dropped (4/12 lost)</li> </ul> </li> </ul> </li> </ul> <p>I never get h1 &lt;<del>&gt; h2 and h3 &lt;</del>&gt; h4 pinged.</p> <p>Hi Michal,</p> <p>Yes. I tried with cpqd (ofsoftswitch) with no success. Maybe there is no LLDP packet even sent back to controller at all. </p> <p>I used this sudo mn --topo tree,2 --mac --switch user --controller=remote,ip=127.0.0.1 for CPqD</p> <p>I am able to see the topology on the GUI and when I do pingall, I get the following:</p> <p>mininet&gt; pingall</p> <ul> <li> <ul> <li> <ul> <li>Ping: testing ping reachability<br/> h1 -&gt; h2 X X <br/> h2 -&gt; h1 X X <br/> h3 -&gt; X X h4 <br/> h4 -&gt; X X h3 </li> <li>Results: 66% dropped (8/12 lost)</li> </ul> </li> </ul> </li> </ul> <p>Using OVS, it is found to be working fine. So, the problem lies in CPqD switch.</p> <p>Note: I normally try with OVS. Guys from India will be tested against CPqD. </p> <p>However, I am going to try in both the switches going forward.</p> <p>Hi Michal,</p> <p>GET topology fails against CPqD switch.</p> <p>1. Download and start latest controller using ./run.sh -of13</p> <p>2. sudo mn --topo tree,2 --mac --switch user --controller=remote,ip=127.0.0.1</p> <p>3. Check the topology on the GUI and check whether you are able to see the links between the switches (In my case, I could not see the links)</p> <p>4. Use GET <a href="http://127.0.0.1:8080/controller/nb/v2/topology/default" class="external-link" target="_blank" rel="nofollow noopener">http://127.0.0.1:8080/controller/nb/v2/topology/default</a> and I could not see the topology. Thus the ping fails using CPqD.</p> <p><a href="https://git.opendaylight.org/gerrit/#/c/5650/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/5650/</a></p> <p>Attachment flow-f54t0.xml has been added with description: flow sending all packets up to controller</p> <p>One of the differences between cpqd and ovs is that ovs sends packets not covered by any flow up to controller by default. And cpqd drops them.</p> <p>In order to alter this behavior of cpqd I added the flow (attached - flow-f54t0.xml) to each switch (tableId=0, priority=0, all packets, action=send to controller port).</p> <p>Then the topology got discovered and ping worked (sometimes I get &lt;100% success on 1st try).</p> <p>Steps:</p> <ul class="alternate" type="square"> <li>start controller</li> <li>start cpqd</li> <li>wait till connected</li> <li>add flows to all nodes:</li> </ul> <p>for i = 1 .. x:<br/> action: POST<br/> url: <a href="http://localhost:8080/restconf/config/opendaylight-inventory:nodes/node/openflow:i/table/0" class="external-link" target="_blank" rel="nofollow noopener">http://localhost:8080/restconf/config/opendaylight-inventory:nodes/node/openflow:i/table/0</a><br/> content: attached file</p> <ol> <li>Or do it via osgi console command (change 5650 is lowering the priority of this flow to 0):<br/> osgi&gt; addMDFlow openflow:i f54 0</li> </ol> <ul class="alternate" type="square"> <li>observe packetIn in wireshark</li> <li>run pingall in mininet</li> </ul> <p>Could you replicate this, please? (the attached xml already contains priority = 0, higher priority of this flow is causing this: h1 never pings h2, h3 never pings h4)</p> <p>Exactly. Using CPqD, OF packets are not forwarded to the controller by default. It worked only after inserting a flow of action, Output=CONTROLLER to all the nodes. Eventually, ping worked!</p> <p>I think the issue is in CPqD switch and believe that, it started behaving like this recently. Maybe, we need to file a bug for CPqD people to start looking into it.</p> <p>Thanks for the resolution.</p> <p>Assuming this is cpqd specific behavior and wont be fixed on controller side.</p> <p>Reopened,<br/> since this behaviour is not CPQD specific, but may be observed on switches which<br/> faitfully implement openflow specification.</p> <p>Section 5.1 of OF 1.3 specification clearly states that packet may be forwarded to controller or dropped based on table configuration and this behaviour is left to table configuration.</p> <p>In order for controller to reliably perfom LLDP topology discovery controller must not depend on "unknown conditions" such as forwarding all packet misses to controller.</p> <p>So controller needs to install flows, which will forward LLDP packets to controller, in order to do topology discovery reliable and to not be dependent<br/> on out-of-the-band configuration of table.</p> <p>Same recommendation as in <a href="https://bugs.opendaylight.org/show_bug.cgi?id=974" class="external-link" target="_blank" rel="nofollow noopener">https://bugs.opendaylight.org/show_bug.cgi?id=974</a> to add an explicit LLDP flow to punt the LLDP packets to the controller.</p> Duplicate OPNFLWPLUG-154 Development External issue ID 480 External issue URL Priority Rank 0|i02yx3: