There are very smart people involved in the development of Openflow. However, I suspect very few of them actively manage networks on a day-to-day basis. Now that the code is in the hands of network engineers, we can see what's needed to actually get this running in production networks.
When it comes to emerging technologies, this space between the development and actual production use - between developers and the network engineers in the trench - is something I find incredibly interesting. It's great to be involved in the development at the point you can provide substantive feedback into the actual product or technology.
And that is where we are today with Openflow. We have Openflow deployed to 4 "production" switches and have a wireless SSID in 3 buildings across campus that feeds into an Openflow switch. The cool thing is that it all pretty much works. The problem is that, when it doesn't work, it's a pretty big pain to figure out why. Yesterday I compared it to the early days of the GSRs when the tables on one of the linecards would get out of sync, but it's a bit worse because the "linecards" are spread across the whole campus and there are very few debugging tools available.
There are a number of debugging features that would be useful, but I think the most useful one would be a way to see the dataplane and control-plane packets at the same time. One way to do this would be for the switch vendors to allow you to add Openflow control-plane packets into a port-mirroring configuration. This would allow me to hook a sniffer up to a switch port and mirror both the traffic to/from a switch port and the Openflow control messages to the sniffer.
Why would this be useful ? One problem we're having right now is that some laptops take 1-2 minutes to get a DHCP lease on the Openflow network. Is the switch taking a long time to encapsulate the first DHCP message into an Openflow message and send it to the controller ? Is the controller taking a long time to send the packet-out and flow-add messages to the switch ? Are the Openflow messages getting lost along the way ? Today I have to run a tcpdump on the Openflow controller to capture control-plane packets and Wireshark on a laptop to capture the dataplane packets and then try to compare them without synchronized timestamps. This one little feature would have saved us a lot of headaches !
Subscribe to:
Post Comments (Atom)
Posts
5 comments:
Great post! I think we all suffer from a divergence of tools that we use for debugging on the workbench developing controllers/switch software and the tools that are used in live networks.
On this particular one -- is there a way to do this with a debug app on the controller, potentially mirroring the packets-under-investigation to the controller and then dumping those alongside the control messages in and out? It doesn't capture as many of the timing dynamics of your current or proposed approach, but you'd at least get to see the delays incurred on controller-side processing.
I'd actually like to see both approaches implemented. This would give you a view from both the controller and the switch. When you're debugging timing issues in particular, the view from the switch is probably more valuable, but both are necessary. The advantage of implementing this on the controller is that you can see data for all switches from one vantage point.
Hi Kyle,
Just wanted to point out that one of the common ways that we do debugging at Stanford is using flowvisor. FlowVisor can be pretty easily configured to create exactly a control plane port mirror (a "readonly" slice, in FV terms). Let's talk offline if you're interested in following up on this.
I might know the answer to this particular issue. If you're still having it send me an e-mail and I can type up some details. Cheers, Frank
Well, great post on Openflow Wish List.. Thats great idea to select few of them.. I really enjoyed reading your article. Thanks for sharing it.. Ecommerce website developers
Post a Comment