noxrepo / pox

The POX network software platform
https://noxrepo.github.io/pox-doc/html/
Apache License 2.0
619 stars 470 forks source link

Pox Controller Issue (Using Pox halosaur or gar) #298

Closed paulpal closed 4 months ago

paulpal commented 4 months ago

paulpal commented 3 days ago Hi Murphy, My problem seems to be with the pox loadbalancer component which when I run as the remote controller component doesn't seem to allow either pingall or ping commands from mininet single switch with any number of hosts topology set to remote controller running on port 6633. Every other pox component seems to work just okay with any topology from another terminal. Could you please explain if the pox loadbalancer component is still active or no longer recognized in pox/mininet topologies.

mininet@mininet-vm:~$ sudo mn --topo single,4 --controller remote Creating network Adding controller Unable to contact the remote controller at 127.0.0.1:6653 Connecting to remote controller at 127.0.0.1:6633 Adding hosts: h1 h2 h3 h4 Adding switches: s1 Adding links: (h1, s1) (h2, s1) (h3, s1) (h4, s1) Configuring hosts h1 h2 h3 h4 Starting controller c0 Starting 1 switches s1 ... Starting CLI: mininet> pingall Ping: testing ping reachability h1 -> X X X h2 -> X X X h3 -> X X X h4 -> X X X *** Results: 100% dropped (0/12 received) mininet>

mininet@mininet-vm:~$ sudo ~/pox/pox.py log.level --DEBUG misc.ip_loadbalancer --ip=10.0.1.1 --servers=10.0.0.2,10.0.0.3 POX 0.7.0 (gar) / Copyright 2011-2020 James McCauley, et al. DEBUG:core:POX 0.7.0 (gar) going up... DEBUG:core:Running on CPython (3.8.5/Jul 28 2020 12:59:40) DEBUG:core:Platform is Linux-5.4.0-42-generic-x86_64-with-glibc2.29 WARNING:version:Support for Python 3 is experimental. INFO:core:POX 0.7.0 (gar) is up. DEBUG:openflow.of_01:Listening on 0.0.0.0:6633 INFO:openflow.of_01:[00-00-00-00-00-01 1] connected INFO:iplb:IP Load Balancer Ready. INFO:iplb:Load Balancing on [00-00-00-00-00-01 1] INFO:iplb.00-00-00-00-00-01:Server 10.0.0.2 up INFO:iplb.00-00-00-00-00-01:Server 10.0.0.3 up

Thanks

@paulpal paulpal commented 3 days ago The results are the same regardless of the commands I use in creating the topology. For example:

sudo mn --topo single,4 --controller =remote,port=6633 sudo mn --topo single,6 --controller=remote,port=6633 sudo mn --topo single,4 --controller remote sudo mn --topo single,6 --controller=remote, ip=127.0.0.1,port=6633

mininet@mininet-vm:~$ sudo ~/pox/pox.py log.level --DEBUG misc.ip_loadbalancer1 --ip=10.0.1.1 --servers=10.0.0.1,10.0.0.2,10.0.0.3 POX 0.8.0 (halosaur) / Copyright 2011-2022 James McCauley, et al. DEBUG:core:POX 0.8.0 (halosaur) going up... DEBUG:core:Running on CPython (3.8.5/Jul 28 2020 12:59:40) DEBUG:core:Platform is Linux-5.4.0-42-generic-x86_64-with-glibc2.29 DEBUG:openflow.of_01:Listening on 0.0.0.0:6633 INFO:core:POX 0.8.0 (halosaur) is up. INFO:openflow.of_01:[00-00-00-00-00-01 2] connected INFO:iplb:IP Load Balancer Ready. INFO:iplb:Load Balancing on [00-00-00-00-00-01 2] INFO:iplb.00-00-00-00-00-01:Server 10.0.0.1 up INFO:iplb.00-00-00-00-00-01:Server 10.0.0.2 up INFO:iplb.00-00-00-00-00-01:Server 10.0.0.3 up DEBUG:openflow.of_01:1 connection aborted

Hi Murphy, if you are still around please note that this problem persists even with the latest pox upgrade ( in my case, halosaur) and as you can see from when I started posting in this thread, it did not work with gar either. I have even opened a new issue with the same complaint under different topological scenarios in the hope I'd get a response from either you or the community to no avail. There's not so much info available on the internet and the one that I came across (https://www.cnblogs.com/gddfg/p/16807891.html) had the DEBUG:openflow.of_01:3 connection aborted which recommended setting the openflows to "protocols=OpenFlow10" when creating the topology.

What should I do to clear the connection aborting bug? Thanks in advance.

@paulpal paulpal commented 4 minutes ago mininet@mininet-vm:~$ sudo -E mn --topo=single,6 --controller=remote,ip=127.0.0.1,port=6633 --switch ovsk,protocols=OpenFlow13 Creating network Adding controller Adding hosts: h1 h2 h3 h4 h5 h6 Adding switches: s1 Adding links: (h1, s1) (h2, s1) (h3, s1) (h4, s1) (h5, s1) (h6, s1) Configuring hosts h1 h2 h3 h4 h5 h6 Starting controller c0 Starting 1 switches s1 ... *** Starting CLI: mininet> h1

mininet@mininet-vm:~$ sudo ~/pox/pox.py log.level --DEBUG misc.ip_loadbalancer1 --ip=10.0.1.1 --servers=10.0.0.1,10.0.0.2,10.0.0.3 POX 0.8.0 (halosaur) / Copyright 2011-2022 James McCauley, et al. DEBUG:core:POX 0.8.0 (halosaur) going up... DEBUG:core:Running on CPython (3.8.5/Jul 28 2020 12:59:40) DEBUG:core:Platform is Linux-5.4.0-42-generic-x86_64-with-glibc2.29 DEBUG:openflow.of_01:Listening on 0.0.0.0:6633 INFO:core:POX 0.8.0 (halosaur) is up. DEBUG:openflow.of_01:6 connections aborted DEBUG:openflow.of_01:3 connections aborted DEBUG:openflow.of_01:3 connections aborted DEBUG:openflow.of_01:3 connections aborted

These are the results when I try to change the openflow version from the default (1.0) to the latest (I used openflow 13). Would you kindly let me know which openflow version works with pox halosaur if that might be the case though I highly doubt it coz the connection aborted error happens as soon I start issuing mininet commands (pingall, ping) on the CLI upon creating the topology.

MurphyMc commented 4 months ago

There has been some work get other versions running in POX, but the main line uses OpenFlow 1.0 as documented in the manual.

As mentioned in the other issue you opened recently (#297), it seemed like your switches were connecting fine. I think OVS may actually open extra connections, perhaps because it doesn't know which version will work immediately. These don't actually cause problems.

Are you sure the aborted error happens when you start issuing Mininet commands? Looking at the code, it looks like POX coalesces aborted messages for some number of seconds. What if you just waited? Are you sure the message doesn't appear anyway.

In any case, I think you've said that components besides the ip_loadbalancer work for you, which is an indication that there isn't a problem connecting to the switches. And from the description in #297, it seemed like the problem came down to wanting the ip_loadbalancer component to do something which it doesn't do, and not with switch/controller communication.