The controller FAUCET: Why OpenFlow is not dead

2019年12月19日 木曜日


【この記事を書いた人】
Bruyere Marc

My career started in 1996, with the ISP Club-Internet.fr, Cisco, Vivendi-Universal, Credit Suisse, Airbus/Dimension Data, Force10 Networks, and Dell. I obtain my Ph.D. with the CNRS in France, and a 2-year PostDoc at the University of Tokyo. My research topics are SDN and Internet Measurement.

「The controller FAUCET: Why OpenFlow is not dead」のイメージ
IIJ Engineers blog読者プレゼントキャンペーン

Twitterフォロー&条件付きツイートで「バリーくんぬいぐるみ」を抽選で20名にプレゼント!
応募期間は2019/11/29~2019/12/31まで。詳細はこちらをご覧ください。
今すぐツイートするならこちら→ フォローもお忘れなく!

IIJ 2019 TECHアドベントカレンダー 12/19(木)の記事です】

※本記事の日本語訳はこちら

It is now more than a decade “OpenFlow: Enabling Innovation in Campus Networks” has been published. It founded the paradigm change of Software Defined Networking in computer networking.
To remember here, the main benefits of this ongoing conceptual shift:

Programmability

  • Enable innovation/differentiation
  • Accelerate new features and services introduction

Centralized Intelligence

  • Simplify provisioning
  • Optimize performance
  • Granular policy management

Abstraction

  • Decoupling of Hardware & Software, Control plane & forwarding, and Physical & logical config
  • Open up full automation stack
  • Open up multi-vendor architecture

Why did we not see more fully native Openflow network deployment?

Introducing hardware innovation is a slow and gradual process that could be very expensive. Single-table OpenFlow was a natural first option for hardware vendors because of its straightforward implementation, in particular for vendors using Broadcom chipset. But a single-table OpenFlow implementation has a huge flaw as it does not scale. The Open Networking Foundation (ONF), who established the OpenFlow standard, has introduced multi-table for significantly increase the scalability but at a more expensive cost for the hardware vendors. Furthermore, on the data-plane side, the OF-DPA from Broadcom diverted the real benefits of true multi-table OpenFlow DataPlane. The ONF has marked the multi-table support as optional in the standard version 1.3. Then vendors can have OpenFlow v1.3 switches certified but without multi-table — this lack of scalability situation has also conducted to limit interest in full OpenFlow architecture.

Moreover, in the northbound, the well-known OpenFlow controllers, ONOS and OpenDaylight, remain too complex and big software frameworks to develop controller applications. They can not be turned on quickly in production. Enterprise and Campus Networks Operators are not the target of such big software projects.

Faucet came up in this empty gap and proposed a rich set of layer2 and layer3 features ready to be used without software development.

Faucet a compact ready to use, multi-table controller.
Faucet is an OpenFlow controller designed to be compact, easy to install and operate. It can execute various switching and routing mechanisms needed for network functions through virtualization methods in the controller or the OpenFlow switch tables in the data-plane. Faucet is built on top of Ryu, a Python-based SDN framework, and uses Ryu’s event procedures and packet processing Application Programming Interface (API) functions.
Faucet uses a multi-table packet processing pipeline as shown in the figure below. Using multiple flow tables over a single table allows Faucet to implement more complicated flow-based logic while maintaining a smaller number of total flows. Using dedicated flow tables with a narrow number of match fields, or limiting a table to exact match only, such as the IPv4 or IPv6 FIB tables allows us to achieve greater scalability over the number of flow entries we can install on a datapath.

Give it a try

An extensive tutorial can be found here if you want to try Faucet on your computer, and Open vSwitch has another tutorial.

Installing Faucet

  1. Using APT
  2. With Docker
  3. With Pip
  4. On Raspberry Pi
  5. With Virtual Machine image

Configuring Faucet

YAML is a simple human and machine-readable data-serialization format that is used by a user to describe to Faucet the network plan and functions wanted. The YAML configuration file is one of the reasons Faucet is so easy to configure.
In the below sample configuration file, we can find three sections. The Virtual Local Area Network (VLAN), the router section, describes the inter-VLAN and the Datapath (DP) section, which defines the DPs connected to Faucet and how each of the associated switches ports are configured.

Visualizing your network in action

For monitoring, Faucet differs from the typical Non-SDN network management system in that it does not use the Simple Network Management Protocol (SNMP). Instead, the Faucet pushes statistics (bytes, packets, in and out from each port) to the Gauge monitoring controller. Gauge is running in parallel with Faucet and supports Prometheus and InfluxDB, which are open-source time-series databases. Faucet interacts with the open-source visualization system, Grafana, where it is possible to create dashboards and run inquiries on current and historical data, as shown in figure below.

Hardware switches vendors love Faucet project

The faucet control plane is just a part of the ecosystems. In the past years, notable vendors join the project and get full supportability of Faucet multi-table data-plane pipeline. On the day of this blog post, the list of supported vendors is Allied Telesis, Cisco, HPE Aruba, Noviflow, ZodiacFX, ZodiacGX, Lagopus, and Open vSwitch. A newcomer joins Faucet; we will discuss it in the FaucetCon section below.

An Open Source Community growing is always giving satisfaction.

After our first FaucetCon in 2017, the number of attendees more than double and operator’s projects too at the FaucetCon2. The conference took place inside the Silicon Valley Google Campus. We started with our traditional PlugFest, and all vendors interoperated under Faucet control with no issues at all. The big news is Arista joins the gang.

The variety of use cases is also a surprisingly good presage. Here is below, just my selection.

With Faucet at the Sandria Nation Lab, they are building no-overlayed multiple isolated cloud environments without physically re-wiring or managing a switch CLI.

Google has presented a couple of Faucet IoT projects: Taming the IoT: Operationalized Testing to Secure Connected Devices and Network for IoT Powered by Faucet

IP ArchiTechs Managed Services is a network consulting firm that focuses on white-box, and open networking integration has talked about SDN Traffic Engineering for Wireless ISPs

Bob Lantz had a light talk introduced faucetagent.py: a very simple gNMI agent for configuring FAUCET.

Cybersecurity remains a top problem. The InQtel CyberReboot Lab has chosen Faucet for is long terms SDN strategy, and its two talks, which included demos, were awe-inspiring. Making Thousands of Automated Configuration Changes at Home and in Production with FAUCET and Friends and Finding Aram Fingal: Using Poseidon and Faucet to Identify and Monitor Insider Threats.

As a researcher of IIJ-II, I have presented my ongoing research project with Faucet for IXP operators on how to operate their dedicated switching fabric through a visual web interface exclusively.

To Sum Up, the Faucet’s community delightful is ramping up. In this period of data-plane programming language like P4, OpenFlow SDN has still a significant role to play.

Bruyere Marc

2019年12月19日 木曜日

My career started in 1996, with the ISP Club-Internet.fr, Cisco, Vivendi-Universal, Credit Suisse, Airbus/Dimension Data, Force10 Networks, and Dell. I obtain my Ph.D. with the CNRS in France, and a 2-year PostDoc at the University of Tokyo. My research topics are SDN and Internet Measurement.

Related
関連記事