Thanks to open source software, we can now take control over and modify the behavior of almost every component in an IT system. We can modify everything from the networking stack in the kernel all the way down to web server code in user space to make improvements or implement new features.
The final hurdle to having complete control over our hardware and software stack is the physical network hardware. These devices are usually built from the open source tools we love, but they are presented as black boxes that can't easily be modified by network operators.
Open standards such as OpenFlow and P4 promised to improve the landscape by opening access to these devices via a programmable API, but they still require someone to write a controller to re-implement normal switch functionality, such as forwarding and routing, in a multi-vendor, standards-compliant way. This led our group to write the Faucet software-defined network (SDN) controller, which allows anyone to fully realize the dream of programmable networks.
How Faucet works
Faucet is a compact, open source OpenFlow controller that enables users to run their networks the same way they run server clusters. Faucet makes networking approachable to all by bringing the DevOps workflow to networking. It does this by making network functions (like routing protocols, neighbor discovery, and switching algorithms) easy to manage, test, and extend by moving them to regular software that runs on a server, versus the traditional approach of embedding these functions in the firmware of a switch or router. Faucet works by ingesting a YAML configuration file that represents the network topology and required network functionality, and it does the work to program every device on the network with OpenFlow.
The Faucet story began in September 2015 when REANNZ wrote the first version of Faucet based on prototype code by the WAND Network Research Group at the University of Waikato. Since then, these groups and many others in New Zealand and further afield have partnered to write and maintain a functional OpenFlow controller that can be used by the masses. We have been committed to being an open source project since day one, as we feel this is the best way we can make our contributions available to help the community, and we are happy to have received code changes from over 40 different developers to date.
Brad Cowie. CC BY-SA 4.0
Testing and cross-vendor compatibility
When writing network controllers, it is crucial to deliver working code with each release that won't break production deployments when they're upgraded. As a result, testability is one of Faucet's important guiding principles. We have a comprehensive test suite that not only tests for code quality with linting and static analysis, but we also test a large number of network topologies with different Faucet features enabled. This testing is automatically performed on every code change.
Our test suite also allows us to qualify the hardware devices that support all of Faucet's features. This has made cross-vendor SDN compatibility a real possibility, as a number of vendors run the Faucet test suite as part of their QA process to validate that their firmware supports Faucet. This also allows us to avoid writing additional drivers or vendor extensions to program new devices, which has the added benefit of keeping our codebase small and consistent.
Faucet in the real world
Faucet has been deployed in many different networks all over the world. Most recently, we partnered with the ACM/IEEE Supercomputing Conference 2018 (SC18) conference to deploy a large Faucet network as part of the SCinet network that delivers terabits per second of internet to the booths on the show floor. The network we built featured hardware from Allied Telesis, Cisco, and NoviFlow, and we managed to exceed 9 terabits per second of capacity.
Faucet SC18 group photo in front of SCinet network.
A NoviFlow device running a Barefoot Tofino P4 Application-Specific Integrated Circuit (ASIC) was the network's core router. NoviFlow wrote OpenFlow as a P4 application, which enabled Faucet to use OpenFlow as a runtime API on top of P4. We wrote some Ansible automation code to integrate with the SC18 customer connection database and generate Faucet configuration on the fly. The database allocated each booth a VLAN and subnet information.
Faucet's job was to do inter-VLAN routing on the core router and Border Gateway Protocol (BGP) peer with the two core SCinet routers to allow booths to route to the internet. The Link Aggregation Control Protocol (LACP) implementation inside Faucet enabled us to bundle 2x100G links to each upstream router to allow for resilience (in case there was a fiber issue). Each booth was supplied an internet connection—1Gb, 10Gb, or 100Gb—by an access switch (supplied by one of the vendors) that was also controlled by Faucet. The access switches did forwarding and implemented security policies on each access port to protect the network. Additional network security was provided by CyberReboot's Poseidon, a machine learning tool that integrates with Faucet and can identify suspicious end hosts on the network. All services on the network, such as Dynamic Host Configuration Protocol (DHCP) and BGP, were provided by open source daemons (e.g., dhcpd and BIRD) that were running as network functions virtualization (NFV) services on a Linux server.
We believe the SC18 deployment demonstrates the maturity of Faucet and OpenFlow for running real, large-scale production networks. We also hope to see others taking up the challenge of taking control over their networks by deploying SDN. To find out more about faucet and how to deploy it, please visit our website, which has links to tutorials, documentation, and mailing lists for user discussions. For those interesting in being involved with our open source project, we have a developer guide to help first-time contributors. Finally, to keep track of our progress and announcements of future conferences, tutorials or deployments similar to SC18, follow us on Twitter.
Brad Cowie will present Using an open source SDN controller to deploy a high-speed production network at linux.conf.au, January 21-25 in Christchurch, New Zealand.
Comments are closed.