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-25 OpenFlowPlugin <p>After you start the mininet using </p> <p>1. sudo mn --topo tree,2 --controller remote,ip=10.125.136.52 --switch ovsk,protocols=OpenFlow13<br/> 2. sudo mn --topo tree,2 --controller remote,ip=10.125.136.52</p> <p>and GET <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> through REST-APIs, the topology remains unclear even after mininet goes off.</p> <p>Operating System: Windows<br/> Platform: PC</p> OPNFLWPLUG-25

Topology Manager (Builds network topology)

Improvement Resolved Done Ed Warnicke Madhusudhan Ananderi Mon, 13 Jan 2014 18:04:21 +0000 Mon, 27 Sep 2021 09:01:01 +0000 Fri, 7 Feb 2014 13:57:58 +0000 General Fri, 17 Jan 2014 00:00:00 +0000 0 3 <p>When I use </p> <p>sudo mn --topo tree,2 --controller 'remote,ip=10.0.2.2:6633' --switch ovsk,protocols=OpenFlow13</p> <p>GET <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>shows me the correct topology. When I exit mininet, it goes away.</p> <p>I think this may have been fixed by </p> <p><a href="https://git.opendaylight.org/gerrit/#/c/4410/" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/#/c/4410/</a></p> <p>Hi,</p> <p>After changing of.discoveryInterval=10 in config.ini file, I am able to see the topology. When I play for about 3-4 times, Following things are noted:</p> <p>1. When I exit mininet: sudo mn --topo tree,2 --controller 'remote,ip=10.0.2.2:6633' --switch ovsk,protocols=OpenFlow13</p> <p>switch manager(Devices,Flows,Troubleshoot - This can be seen to the left on the GUI) is cleared but the I could see the topology on the GUI.</p> <p>2. When I start the mininet again, everything is fine and could see the correct topology. GET topology is also worked.</p> <p>3. When I exit the mininet again, everything is fine and could not see the topology. And even didn't see the GET topology.</p> <p>So, mininet and GET topology works fine and sometimes it don't.</p> <p>Hi,</p> <p>Could you please make a description for "a test focus or a test topic" and then add the steps for whole scenario simulation. </p> <p>I've retested couple of scenarious:<br/> 1) get a topology for a mininet<br/> 2) get a topology for couple of mininets (4 and less) (with same OpenFlow version, with both controller comunication ports)<br/> 3) get a topology for couple of mininets (4 and less) (with mixed OF ver. 1.0 and 1.3, with both controller comunication ports)</p> <p>Sorry, but I've not seen any problems. </p> <p>(Env. debian7, Open vSwitch 2.0.0, controller build from Jan_21, postman v.0.8.4.3, all run in localhost and both controller port have tested in mix <span class="error">&#91;6633 and 6653&#93;</span>) </p> <p>Please, use full commands for a correct mininet start before send a get req by postman.</p> <p>Additional Idea:</p> <p>If your test scenario focus is realy a controller topology processing for the multiple mininet topologies, you have to thing about ID and MAC addresses (<a href="http://mininet.org/walkthrough/#id--mac" class="external-link" target="_blank" rel="nofollow noopener">http://mininet.org/walkthrough/#id--mac</a>) So sometimes you could get switches with same MAC addresses from the different mininet topologies what is not allowed and it could realy finish in some unexpectad state.</p> <p>This is working most of the time but still failing occasionally...</p> <p>This applies to both OF10 and OF13 mininet</p> <p>Please find the comments:</p> <p>1. Used mininet : sudo mn --topo tree,2 --controller remote,ip=192.168.56.1:6633 --switch ovsk,protocols=OpenFlow13</p> <p>2. OpenDayLight UI shows the correct topology</p> <p>3. Restconf GET <a href="http://192.168.56.1:8080/controller/nb/v2/topology/default" class="external-link" target="_blank" rel="nofollow noopener">http://192.168.56.1:8080/controller/nb/v2/topology/default</a> show the correct topology output</p> <p>4. When I exit mininet, the topology goes away from OpenDayLight UI and GET <a href="http://192.168.56.1:8080/controller/nb/v2/topology/default" class="external-link" target="_blank" rel="nofollow noopener">http://192.168.56.1:8080/controller/nb/v2/topology/default</a> does not return any topology details.</p> <p>5. I play for about 5-6 times, and it is working fine.</p> <p>Please confirm for the closure of the bug.</p> <p>Thanks<br/> Sachi</p> <p>Now I'm a little confused. Is the test focus realy testing only on/off topology build response for one mininet? Or is it focusing for the mininet concurrency topology build ?<br/> One mininet <br/> sudo mn --topo tree,2 --controller 'remote,ip=127.0.0.1,port=6653' --switch ovsk,protocols=OpenFlow13</p> <p>the on/off topology build works well (a confirmation for last comment from Sachi Gupta)</p> <p>Concurrency (2 mininet with same mac address in same time)</p> <p>sudo mn --mac --topo tree,2 --controller 'remote,ip=127.0.0.1,port=6653' --switch ovsk,protocols=OpenFlow13</p> <p>(OpenDayLight UI shows the correct topology, REST has correct response too)</p> <p>sudo mn --mac --topo single,3 --controller 'remote,ip=127.0.0.1,port=6633' --switch ovsk,protocols=OpenFlow13</p> <p>(OpenDayLight UI shows the correct topology, REST has strange response)</p> <p>KILL single topo.<br/> (OpenDayLight UI shows the correct topology, REST has bad response)</p> <p>I can not see a reason for the topology concurrency tests (I don't think it is a correct simulation of a switch power off)</p> <p>Described strange behavior I was not able to replicate anymore. (Again tested for 1.3 and 1.0 openflow). <br/> Madhusudhan Ananderi, if you'll see again something similar, please check the "Hello" messages for hand-shake in wireshark and please reopen this bug again. Please don't forget to add a whole controller logs.</p> Development External issue ID 289 External issue URL Rank 0|i02ylr: