POX as an OpenFlow Switch

June 1, 2013 in News, POX

POX is now an OpenFlow switch as well as an OpenFlow controller. Most of the code for this has actually been in the repository for a while and has been used along with the STS SDN Troubleshooting Simulator, but we’ve never had all the pieces assembled in the repository to actually let you run POX as a standalone switch until now. It’s definitely not the best switch, but it might do in a pinch and someone may find some use for it. We’re hoping to improve its spec conformance some in the next couple of weeks. As for performance… I wouldn’t hold your breath for big improvements. :)

The switch uses pcap to interface with the networking hardware, and it does this through POX’s own pcap module — pxpcap. This is a C Python extension, so it doesn’t work with PyPy and you need to actually compile it. Hopefully this is relatively easy. You need libpcap and a C compiler, but hopefully that’s it. There are shell/batch scripts in pox/lib/pxpcap/pxpcap_c for building under Mac OS, Linux, and Windows. I originally wrote this stuff like two years ago, so it was probably 32 bits then, and I just compiled it today on 64 bit Linux and Mac OS, so we should be good. I probably haven’t built the Windows version since I originally wrote it, so let me know if you run into problems.

Along with it came some new IOWorker subclasses which will hopefully make IOWorker more attractive. Actually, they’re from a different project from last year and have now been hacked around a bit to work with POX (hopefully — they’re not all tested).

Anyway, if you want to play with the switch, grab the carp branch and modify this quick example for your own purposes. To create a switch using ports eth0, eth1, and eth2 that connects to a controller at (–port defaults to 6633):
./pox.py --no-openflow datapaths.pcap_switch --address= --ports=eth0,eth1,eth2
You can also run a “plain” software switch. It takes all the same arguments except for ports:
./pox.py --no-openflow datapaths:softwareswitch --address=
The data plane on the “plain” subclass isn’t connected to anything, though, so it’s not clear how useful it is. ;)

2 responses to POX as an OpenFlow Switch

  1. The “plain” software switch can be used as proxy to non-OpenFlow devices. I have looked for some code which implements OpenFlow protocol and all required protocol logic on switch side which could be easily extended.

    There is one solution: https://www.codebasin.net/redmine/projects/xdpd/wiki (I have plans to use it) but I would like also to use OF datapath endpoint implementation in Python which would be much more easier to implement interactions with various network devices management interfaces and where nasty translations of OpenFlow logic (at least in some part) to specific non-OF hardware functionalities will be easiest as possible. Performance is no factor here.

    • Pretty cool!

      I’ve been hoping to add support in POX for … I don’t know what to call it … basically, remote Linux networking configuration. The idea is that you’d run a POX-based agent on a Linux box, which would connect to a POX-based controller. This wouldn’t be OpenFlow — it’d be a custom protocol (probably JSON based on top of the messenger component), with commands and notifications specific to Linux networking. For example, it’d allow remote control of netfilter, interfaces, network namespaces, etc.

      So in the vein of your idea, it’d be easy enough to take some of that functionality and put the softswitch on top of it to give some level of OpenFlow compatibility, so non-POX controllers could leverage it. For example, they could use OpenFlow to see the interfaces and their MAC addresses and monitor their up/down state as port status messages. Might be interesting.

Leave a reply

You must be logged in to post a comment.

Sign in using...