Operating System: Windows
Platform: PC

When I use

sudo mn --topo tree,2 --controller 'remote,ip=10.0.2.2:6633' --switch ovsk,protocols=OpenFlow13

GET http://10.125.136.52:8080/controller/nb/v2/topology/default

shows me the correct topology. When I exit mininet, it goes away.

I think this may have been fixed by

https://git.opendaylight.org/gerrit/#/c/4410/

Hi,

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:

1. When I exit mininet: sudo mn --topo tree,2 --controller 'remote,ip=10.0.2.2:6633' --switch ovsk,protocols=OpenFlow13

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.

2. When I start the mininet again, everything is fine and could see the correct topology. GET topology is also worked.

3. When I exit the mininet again, everything is fine and could not see the topology. And even didn't see the GET topology.

So, mininet and GET topology works fine and sometimes it don't.

Hi,

Could you please make a description for "a test focus or a test topic" and then add the steps for whole scenario simulation.

I've retested couple of scenarious:
1) get a topology for a mininet
2) get a topology for couple of mininets (4 and less) (with same OpenFlow version, with both controller comunication ports)
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)

Sorry, but I've not seen any problems.

(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 [6633 and 6653])

Please, use full commands for a correct mininet start before send a get req by postman.

Additional Idea:

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 (http://mininet.org/walkthrough/#id--mac) 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.

This is working most of the time but still failing occasionally...

This applies to both OF10 and OF13 mininet

Please find the comments:

1. Used mininet : sudo mn --topo tree,2 --controller remote,ip=192.168.56.1:6633 --switch ovsk,protocols=OpenFlow13

2. OpenDayLight UI shows the correct topology

3. Restconf GET http://192.168.56.1:8080/controller/nb/v2/topology/default show the correct topology output

4. When I exit mininet, the topology goes away from OpenDayLight UI and GET http://192.168.56.1:8080/controller/nb/v2/topology/default does not return any topology details.

5. I play for about 5-6 times, and it is working fine.

Please confirm for the closure of the bug.

Thanks
Sachi

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 ?
One mininet
sudo mn --topo tree,2 --controller 'remote,ip=127.0.0.1,port=6653' --switch ovsk,protocols=OpenFlow13

the on/off topology build works well (a confirmation for last comment from Sachi Gupta)

Concurrency (2 mininet with same mac address in same time)

sudo mn --mac --topo tree,2 --controller 'remote,ip=127.0.0.1,port=6653' --switch ovsk,protocols=OpenFlow13

(OpenDayLight UI shows the correct topology, REST has correct response too)

sudo mn --mac --topo single,3 --controller 'remote,ip=127.0.0.1,port=6633' --switch ovsk,protocols=OpenFlow13

(OpenDayLight UI shows the correct topology, REST has strange response)

KILL single topo.
(OpenDayLight UI shows the correct topology, REST has bad response)

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)

Described strange behavior I was not able to replicate anymore. (Again tested for 1.3 and 1.0 openflow).
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.