A lot has been said about OpenFlow in the last couple of years: what it can or cannot achieve and what it will or will not change. I believe it is a technology whose time has come. Looking at the advances that compute virtualisation and automation have wrought, people are ready to automate and control the networking side of things to gain the same type of benefits: scale, control and the massive cost savings that go with it.
Being a networking geek, I have been looking at OpenFlow for a while now and have been monitoring the progress. I decided, as a side project, to visualise OpenFlow data in HyperGlance. Being able to visualise the end-to-end flow seemed like a very useful thing to be able to do. One of the advantages of OpenFlow, I always thought, was being able to know the actual data path and therefore being able to discount everything not in the path when troubleshooting. In traditional networks, every switch and router is an island and you rarely know the complete end-to-end path without tracing it hop by hop.
I have been looking for a good candidate to bring OpenFlow data into HyperGlance for months and I finally found Floodlight. Floodlight is the Open Source side of Big Switch Networks, one of the luminaries of the Silicon Valley OpenFlow scene. They have just raised a $25 million funding round so they must be doing something right! Floodlight seems to be getting some mind share and has a nice RESTful API so it’s a good candidate to create a collector for HyperGlance. I want to show how visualisation could help monitor and manage OpenFlow networks just as it does for traditional networks. It’s all just structured data to me. So as long as I can get relationship data and then attributes and metrics to lay over the top, I am happy. Luckily, floodlight gives me everything I need.
First things first, I needed to create the data. I don’t have any OpenFlow switches hanging around so I used Mininet to emulate the switches, workstations and data flow between them.
Mininet is software that allows “rapid prototyping for software defined networks” (their words) and comes out of Stanford, where OpenFlow was born. The plan was to run both Mininet and floodlight in a VM so I could then just hook HyperGlance into it and voilà, an end-to-end monitoring and visualisation proof of concept. (Didn’t I just mention the great things compute virtualisation has enabled?)
Things went pretty smoothly. Mininet has a ready to go VM to download, floodlight is Java, like HyperGlance, so I knew how to handle that. All that was left was to create the collector to pull the data into HyperGlance. Both Mininet and Floodlight were pretty light weight resource-wise so I ran both in the same VM. Once I had them running and talking to each other, building the collector was straightforward; Floodlight’s API is nice and simple (it exports JSON). I am a pretty poor programmer and had a little help from one of our development guys, but if I can create a collector just about anyone can.
It turned out pretty well, if I do say so myself, I ramped up the collection cycle for demo purposes so the adding and deleting of the flows is very snappy as you can see from the video. In real life, I can’t see why you would need it to be any more than every minute or so (even then only when troubleshooting).
In the future, I plan to use Python with Mininet to start pushing/deleting flows to the switches using HyperGlance’s GUI command functionality to see the workflow and also to see how far I can push Mininet and floodlight scale-wise.
I am actively looking for monitoring use cases and workflows in regards to OpenFlow. So if you have a live network or have done some research around this, please get in touch.