Faucet: Enterprise OpenFlow in production
Remember OpenFlow? It was the media and marketing darling for the better part of 5 years as “the machine” conflated OpenFlow with SDN and SDN with - almost literally - everything. “Still Does Nothing” was a common phrase uttered around those of us that had run large scale, complex networks for a long time. Quietly, and mostly, out of the fickle media and blogosphere eye, a scrappy little SDN project called faucet has been diligently plugging away – making easy to use, production quality, well documented, and very stable code that runs OpenFlow networks quite happily in production and at scale. Oh, did I mention that it’s also got a very small footprint? Did I also mention that we’ve built a multi-terabit network that scales, transiting IPv4, IPv6, L2/L3 switching as well as routing? Or that faucet can control switches from multiple vendors, including P4 vendors who provide a P4-to-OF bridge, and interoperates with non-SDN networks? Or (and possibly most importantly) that faucet provides automated integration tests, allowing many bugs to be caught early (sometimes even by the switch vendor) before shipping new releases? Well, I should probably mention those things. I’ve been lucky enough to have been involved in SDN off and on since around 2009, and I can emphatically say that of the production SDN and OpenFlow networks that I have been intimately involved in, this combination of hardware, software and people has been, hands down, the most rewarding and most supportable. In fact, this has been so supportable and great to work with, we migrated our production branch office over to a set of faucet controlled SDN switches, and will soon migrate first hop routing over to our robust faucet system. “However did you do this?!?!” you might be inclined to say. Well, I’m glad you asked, because I am going to tell you. First, though, there should be some design goals. As many of the naysayers of SDN will happy point out, “what problem are you trying to solve?” to that end, here is what our design goals were:
- Run all layer 2 in via faucet
- Remove need to log into any network elements after deployment (other than firmware updates)
- Centralize management
- Stretch goal to NFV BGP, do first hop L3
buraglio@faucet:~ $ /usr/bin/fctl –help usage: MACs learned on a DP. /usr/bin/fctl -n –endpoints=http://172.17.0.1:9302 –metrics=learned_macs –labels=dp_id:0xb827eb608918 Status of all DPs /usr/bin/fctl -n –endpoints=http://172.17.0.1:9302 –metrics=dp_status Retrieve FAUCET/Gauge state using Prometheus variables. optional arguments: -h, –help show this help message and exit -n, –nonzero nonzero results only -e ENDPOINTS, –endpoints ENDPOINTS list of endpoint URLs to query -m METRICS, –metrics METRICS list of metrics to query -l LABELS, –labels LABELS list of labels that must be present –display-labels DISPLAY_LABELS list of labels to filter display by (default all)Monitoring is also taken into account in the form of the gauge interface, which provides a nearly-real-time telemetry stream of important and useful information. Leveraging both the wealth of topological information that the controller has at its disposal and a familiar prometheus / grafana back / front end interface, the oft-touted notion of streaming telemetry is fully - and quite capably - realized. From the perspective of a networking monitoring and statistics geek, this is the cat’s meow. Very, very data rich.
A simple diagram of our office network pretty well explains the decoupled control plane architecture. Keep it simple, architect for success. Fundamentally SDN networks should be designed like other networks, redundant systems, good monitoring, out of band access. A good design principle is that if you wouldn’t do it on a traditional network, you probably shouldn’t do it for an SDN based network. 
Don’t trust me? Fair enough, check out the University of Waikato interface here. For more interface on the deployment at WAND, check this link. You won’t be disappointed.