The final Open Source Software Defined Networking (SDN) Controller to be compared in this series is Faucet. Built on top of Ryu, Faucet is a lightweight SDN Controller adding a critical northbound function for operations teams.
Faucet is a compact open source OpenFlow controller, which enables network operators to run their networks the same way they do server clusters. Faucet moves network control functions (like routing protocols, neighbor discovery, and switching algorithms) to vendor independent server-based software, versus traditional router or switch embedded firmware, where those functions are easy to manage, test, and extend with modern systems management best practices and tools.
As shown in the figure below, architecturally, each Faucet instance has two connections to the underlying switches. One for control and configuration updates, the other (Gauge) is a read-only connection specifically for gathering, collating and transmitting state information for processing elsewhere using Influxdb or Prometheus.
Modularity and Extensibility
Python based controllers provide a well-defined API for developers to change the way components are managed and configured.
Adding functionality to Faucet is achieved through modifying the systems that make use of its Northbound interfaces. This provides the added flexibility of using different tools and languages depending on the problem being solved. Additionally, increasing the complexity of northbound interactions does not negatively impact the SDN directly.
Faucet is designed to be deployed at scale such that each instance is close to the subset of switches under its control. Each instance of Faucet is self-contained and can be deployed directly to server hardware or through containers, moving the administration back into well understood areas of automation.
Due to the lightweight nature of the code and the smaller control space for each instance, no clustering is required – each instance is completely idempotent and concerns itself with only what it is configured to control.
- Faucet contains no intrinsic clustering capability and requires external tools such as Zookeeper to distribute state if this is desired. Extra instances of the controller can be started independently as long as the backing configuration remains identical.
- PCE functionality for these controllers could be pushed down to the instance in the form of modules, or implemented in a similar manner to OpenKilda, backed by a processing cluster of choice.
- It does not yet support a cooperative cluster of controllers.
- Southbound: It supports multiple southbound protocols for managing devices, such as OpenFlow, VLANs, IPv4, IPv6, static and BGP routing, port mirroring, policy-based forwarding and ACLs matching.
- Northbound: YAML configuration files track the intended system state instead of instantaneous API calls, requiring external tools for dynamically applying configuration. However, it does open the SDN to administration by well-understood CI/CD pipelines and testing apparatus.
Faucet can export telemetry into Influxdb, Prometheus or flat text log files. While Prometheus saves data locally, it can also be federated, allowing centralised event aggregation and processing, while maintaining a local cache to handle upstream processing outages and maintenance.
Resilience and Fault Tolerance
Faucet has no inbuilt clustering mechanism, instead relying on external tools to maintain availability. High availability is achieved by running multiple, identically configured instances, or a single instance controlled by an external framework that detects and restarts failed nodes.
For Faucet in particular, which is designed to sit in a distributed, shared SDN and be controlled by static configuration files, restarting a controller is a quick, stable exercise that has no reliance on upstream infrastructure once the configuration is written.
Faucet is written in Python.
Faucet has an active community developing the framework and it is well supported.