Wednesday, November 15, 2017

OVS17: FAUCET and Enterprise SDN

At OVS17 in San Jose:

Google has been developing solutions for enterprise networking using
SDN, including contributing to the open-source FAUCET project. This talk
discusses how the FAUCET approach enables security, development
velocity, and other innovation.

Wednesday, October 25, 2017

LINK022 reference implementation

LINK022, a gNMI controlled WiFi AP reference implementation which was demonstrated at FAUCET con, is available on github.

Tuesday, October 24, 2017

FAUCET OVS tutorial

Thanks Ben!

FAUCET con #1 - slides and videos

Our first conference on FAUCET at LBL was last week, and videos and slides from the talks are available - has the links and we are collecting all the slides (which will be referenced from github).

Wednesday, September 13, 2017

FAUCET Foundation established

To: "" <>
From: Richard Nelson <>
Subject: Faucet Foundation Established
Date: Thu, 14 Sep 2017 10:38:45 +1200

We are please to announce the Faucet Foundation has been established and 
registered as an Incorporated Society.  The Foundation has been 
established with the following aims:
  - To curate the Faucet platform as a production quality reference 
implementation of an SDN system,
  - To host the infrastructure for a Faucet community, and
  - To ensure that the Faucet platform and the benefits of using it are 
available to the widest possible community.

The Foundation has a board representing industry, R&E networks and 
universities, all of which have contributed to the development of 
Faucet.   The board are still establishing plans for the Foundation, we 
encourage you to provide suggestions or feedback via  Board members will be at the Faucet 
Conference to talk to users and developers.

As part of the move to a Faucet Foundation the GitHub repository will 
soon be moving from reannz/faucet to faucetsdn/faucet. Further details 
will be posted before this happens.

Tuesday, August 8, 2017

FAUCET 1.5.7 with policy based and inter VLAN routing

From Brad Cowie:


Hi again,

Happy to announce v1.5.7 has just been released on github, docker hub and

This is our first release to include stable Inter-VLAN Routing (IVR) and Policy Based Routing (PBR), most of which is alive on my network at WAND now.

Here's the release highlights for 1.5.7:

 * Fix nexthop resolution for IVR.
 * Explicitly log host/port/VLAN learning association.

Since things have been moving so quickly for us at faucet attempting to ship IVR and PBR there was also an intermediary release that wasn't announced.

Here are the release highlights for 1.5.6:

 * Fix logging of DPID of VID
 * Ryu upgrade to 4.16
 * Security fixes for crashes in Ryu parser (severely restricted byte range)
 * Add OF meter support
 * Multiple VLANs can have the same VID
 * VLAN and drop rule tags on InfluxDB flows

Brad Cowie

Wednesday, July 26, 2017

Osaka IX FAUCET deployment

Primary production of FAUCET Umbrella w/ x930 Allied Telesis @NSPIXP-3 in Osaka Japan The SDN road for IXPs Thanks @FaucetSdn @WIDE_Project

Congratulations, Marc!

Tuesday, July 25, 2017

govhack Hamilton networked by FAUCET

FAUCET conference - save the date - October 19th/20th 2017 Berkeley, CA

FAUCET 2017 conference: save the date

FAUCET is an open source SDN/OpenFlow controller for experimental and enterprise networks, running in production at multiple sites and supported by multiple hardware vendors.

The WAND network research group at the University of Waikato in New Zealand, Google, ESnet and LBLNet, would like to announce the first FAUCET conference, to be held at LBL in Berkeley, CA, 19th and 20th of October 2017.

Main conference: 19th and 20th October 2017
PlugFest: 18th October 2017

The conference will be for FAUCET users, operators and developers - those interested in using SDN in production. It will feature an in depth workshop on building and operating production enterprise SDN networks, given by Brad Cowie from the WAND network research group, and network infrastructure for the conference will be powered by FAUCET itself.

It will include also workshops on FAUCET development, consultation on future architecture and features, including the gNMI protocol for configuration and telemetry, and network security.

The conference will be preceded by a FAUCET PlugFest on the 18th of October for vendors to test interoperability and compatibility. The PlugFest network will remain in place for the main conference, for attendees to have an opportunity to see and use different switching platforms.

The date and location are set, and registration will be open August 2017. We will announce further details on the faucet-users group - please stay tuned there for updates.

Hope to see you there,

Saturday, June 17, 2017

Experimental Docker FAUCET image for Pi

Docker makes it easy to manage installations that can have a lot of dependencies (like Ryu, which FAUCET depends on). There are Docker images for FAUCET for x86 already, but there is now an experimental Docker build for Pi as well.

If you're running Raspbian, you probably need to upgrade Docker itself before you can use the image.

Thursday, June 8, 2017


V1.5.0 has just been released (and a new pip package is available).

This release is a significant advance over V1.4.0, benefiting from experience gained at the recent FAUCET PlugFest at LBL, and the deployment at WAND a the University of Waikato.

Among the many changes (including performance and reliability improvements to existing basic/policy based switching, and the test suite which now runs in Docker and supports python3), FAUCET now supports Prometheus, and both IPv4 and IPv6 routing are improved (the latter now supporting RAs).

It is strongly recommended that you upgrade to this release.

While V1.5.0 passes all systems tests under python3, testing under python3 is still not complete. You may prefer to stay python2 for now. V1.5.1 will move to python3 and drop python2 support.

Monday, May 22, 2017

FAUCET @ WAND: inside a live enterprise FAUCET deployment

Our friends and colleagues at the WAND group, at the University of Waikato in NZ, have deployed an enterprise SDN network controlled by FAUCET, supporting two different vendor hardware switches and OVS with DPDK. It peers with BGP, and switches and routes both IPv4 and IPv6 for wired and WiFi access.

The system is managed with Ansible - configuration changes are checked (and checked in), and then pushed to NFV services and FAUCET controllers. Even upgrades of the controller software are automatically checked and pushed out.

This means all configuration changes to the network - ACLs, BGP, etc are made through Ansible. There is no reason to log in to a switch directly once FAUCET has assumed control of it with OpenFlow.

Sunday, May 14, 2017

Using Prometheus with FAUCET

Here is a quick example of configuring and using Prometheus with FAUCET.

First, enable access to Prometheus to FAUCET (the Docker instructions in show how to enable access to port 9244).

Then install Prometheus. Under Ubuntu 16.0.4, this is as simple as:

apt-get install prometheus

Then configure Prometheus to scrape FAUCET. Under Ubuntu, edit /etc/prometheus/prometheus.yml, and under scrape_configs add a job for FAUCET:

  - job_name: 'faucet'


       - targets: ['']

Restart Prometheus.

service prometheus restart

You should now be able to browse port 9090 on your Prometheus server, and draw graphs (for example, packet in rate):

Wednesday, May 10, 2017

TouSIX, Umbrella and FAUCET

Marc Bruyere describes his proof of concept TouSIX SDX, and plans for a FAUCET controlled exchange using Umbrella encoding, which eliminates unwanted broadcast traffic from a distributed layer 2 network.

Installing, testing and routing with FAUCET and OVS in less than 5m

Joe Stringer walks through installing FAUCET and configuring it as a router step by step, in less than 5m.

If you want to get FAUCET routing and switching and have only 5m to learn how, this might be the reference for you.

FAUCET controlling OVS + DPDK

DPDK enables high performance packet processing on PC type platforms with certain supported NICs. In particular OVS has DPDK support, and can offload work to DPDK NICs.

While this is beyond the scope of what FAUCET does (it works at the OpenFlow level), getting up and running quickly with OVS + DPDK is useful. Hopefully as DPDK packaging continues to include the process will become less complex.

Sunday, May 7, 2017

It's good to have access port control

Once you know about a security vulnerability, you can add firewall rules to protect yourself against attacks from outside the firewall.

But what about the inside? If you have someone scanning for a vulnerable machine (or an infected machine scanning its neighbors) inside your network, your firewall may not be of much use - it probably won't be in the forwarding path of the traffic.

FAUCET gives you very low level port level control, and makes it safe it easy to deploy a port level ACL (in this example, by blocking AMT access with a few TCP destination port matches).

FAUCET can also block layer 2 only traffic that a firewall can't see at layer 3.

Monday, May 1, 2017

FAUCET now supports Prometheus

FAUCET now supports Prometheus monitoring (set the FAUCET_PROMETHEUS_PORT environment variable, and FAUCET will export internal statistics via HTTP).

Over time, FAUCET will expose more state (for example, which host has been learned on what port in what VLAN).

For more details, see the patch at

For more on what Prometheus can do, see

Sunday, April 30, 2017

FAUCET conference 10/18 to 10/20 2017 survey

We are looking at planning the first FAUCET conference, focusing on building and running FAUCET enterprise networks. If you're interested in attending, please let us know!

Tuesday, April 25, 2017

design pattern - labels as metadata

FAUCET now allows you to push, via the ACL language, multiple VLAN headers.

    - rule:
        dl_dst: "01:02:03:04:05:06"
                dl_dst: "06:06:06:06:06:06"
                vlan_vids: [123, 456]
                port: acloutport
See for caveats.

Why is this useful? Apart from being a tunneling mechanism, it also allows you add metadata to a packet for a downstream NFV application. For example, you might push an additional VLAN header onto a packet, based on an ACL entry that identifies a particular user or application known to match the ACL conditions.

In particular, you could also push a VLAN representing the input port number, on top of another header that tells you the input VLAN. For example, an ACL could tag a packet on untagged VLAN 100, on port 2, with VLAN 100, then VLAN 2 (so that a "mirroring" application can know what VLAN and port the packet came from).

In the future, FAUCET will make more use of this design pattern as an alternative to packet in. It will be able to alternatively use PBB or MPLS labels in a similar way.

Testing the CPN (and TLS support)

Unit testing the dataplane is important, but so is testing control plane connectivity.

FAUCET now supports, when testing hardware, that TLS can be used by FAUCET to secure the OpenFlow connection to the switch.

To configure FAUCET for TLS, follow the Ryu instructions at

To test that it works with your hardware, see the the new TLS fields in

There will be additional control plane testing added to the FAUCET test suite over time.

Tuesday, March 21, 2017

FAUCET @ OpenStack 2017

Joe Stringer will present "Deploying an OVS-based feature switch in 5 minutes or less", a demo showing how to quickly deploy the Faucet open source OpenFlow controller as a drop-in replacement for a network switch.

Joe Stringer will present "Cyber RFP!" about the strategy that the Faucet open source OpenFlow controller uses to validate a switch's OpenFlow support using a comprehensive, easy to use testsuite.

Monday, March 13, 2017

Inter VLAN routing

FAUCET now supports routing between VLANs, in a way similar to non-SDN switch/routers

In this example, hosts in VLAN 100 can reach hosts in VLAN 200, using FAUCET as a gateway (FAUCET of course presents a gateway in each VLAN).

In the future, FAUCET will allow you to configure routing between just the VLANs you specify, rather than all or none.

        faucet_vips: [""]
        faucet_vips: [""]
        vlans: [100, 200]
        hardware: "Open vSwitch"
        dp_id: 0x1
                native_vlan: 100
                native_vlan: 200

Tuesday, February 28, 2017

FAUCET continuous integration testing with Travis

You've added a new feature to FAUCET and the tests pass; that's great! But how can you be confident that they pass in an environment that has been cleanly set up from scratch?

With Travis CI you can. Travis automatically runs tests for you in a dynamically created VM and tracks various code metrics so you can see things improve over time.

If you clone FAUCET to your own repo, you can have Travis do this checking for you easily.

Friday, February 24, 2017

Reporting on the FAUCET pipeline

It's useful to know, when implementing a feature and while testing it, what impact it might have in terms of match or action resources on the switch.

The FAUCET unit tests now produce a report on what match, instructions, and actions are used by each table.

The following example is when running the FaucetUntaggedTest only. As you can see, there are operations on VLAN/VID, and some mask matching on eth_dst (the rest being exact match).

FAUCET's pipeline changes occasionally to accommodate new features, so it's handy to be able to run this report at any time.

table: 0
  matches: ['in_port']
  table_instructions: ['OFPInstructionGotoTable']
  table_actions: []
table: 1
  matches: ['eth_dst', 'eth_src', 'eth_type', 'in_port', 'vlan_vid']
  table_instructions: ['OFPInstructionGotoTable']
  table_actions: ['OFPActionPushVlan', 'OFPActionSetField_vlan_vid']
table: 2
  matches: ['in_port']
  table_instructions: []
  table_actions: []
table: 3
  matches: ['eth_src', 'in_port', 'vlan_vid']
  table_instructions: ['OFPInstructionGotoTable']
  table_actions: ['OFPActionOutput']
table: 4
  matches: ['vlan_vid']
  table_instructions: []
  table_actions: []
table: 5
  matches: ['vlan_vid']
  table_instructions: []
  table_actions: []
table: 6
  matches: ['eth_dst', 'vlan_vid']
  table_instructions: ['OFPInstructionGotoTable']
  table_actions: ['OFPActionOutput', 'OFPActionPopVlan']
table: 7
  matches: ['eth_dst', 'eth_dst/ff:ff:00:00:00:00', 'eth_dst/ff:ff:ff:00:00:00', 'in_port', 'vlan_vid']
  table_instructions: []

  table_actions: ['OFPActionOutput', 'OFPActionPopVlan']

Tuesday, February 14, 2017

Running NZNOG 2017 on FAUCET

In this video, Brad Cowie describes how the NZNOG 2017 conference was run on FAUCET (see slides, using Ansible to manage and push configuration).

We used hardware switches (AT x930s) together with OVS + DPDK, and we provided IPv4, IPv6, both wired and WiFi and connected to the ISP using BGP. The talk itself was streamed live and recorded over FAUCET.

We plan to make this network a permanent installation at WAND and continue to add features.

Monday, February 6, 2017

FAUCET, VLANs, tagged and untagged

VLANs (virtual LANs) are extensively supported in non-SDN networks (Cisco have a helpful reference) and are used, in general, to provide the illusion of separate networks that are sharing the same physical infrastructure. Cisco helpfully explain in detail why this is useful, but in summary, it allows you to easily and selectively control connectivity between devices on a network (eg you can say, hosts 1 and 2 can see each other, and hosts 3 and 4 can see each other, but hosts 1 and 2 cannot talk to hosts 3 and 4). It also allows you to carry traffic from multiple VLANs on the same physical cable, a concept called "trunking".

In configuring conventional VLANs, you configure a given switch port to be one of two modes - an access port (generally connected to a host), and a trunk port (generally connected to another switch). Hosts connected to access ports generally expect packets without VLAN headers (ie. untagged). Switches (or special hosts) connected to trunk ports, generally expect packets with VLAN headers (tagged), so that they know which VLAN packets belong to.

This tagging of traffic is what enables traffic from several different VLANs to coexist on the same physical cable - "trunking". Trunking allows you then, to connect a special host - an NFV host - to a "trunk" port, which the NFV host can then use to provide services (like DNS and firewalling) to other hosts on the network.

FAUCET supports "trunking." It does it in a different (and less complex) way than a conventional switch - you configure the VLANs in the FAUCET config file, and NOT on the switches. You don't specify a port as a "trunk". Instead, you say which VLANs the port participates in and which ones to tag (you can even receive untagged traffic for one VLAN as well as tagged traffic for other VLANs on a port, should you want to).

Here's an example. In this network there are three hosts, connected to ports 1, 2, 3, and an NFV host on port 9. We want each host to be able to talk to the NFV host, but we don't want the hosts to be able to talk to each other. We are putting host 1 in VLAN 100, host 2 in VLAN 200, and host 3 in VLAN 300, and we are allowing the NFV host to access all the VLANs.

+---------+   +---------+   +---------+    +---------+
|         |   |         |   |         |    |         |
| Host 1  |   | Host 2  |   | Host 3  |    | NFV Host|
|         |   |         |   |         |    |         |
|   +-+   |   |   +-+   |   |   +-+   |    |   +-+   |
|   | |   |   |   | |   |   |   | |   |    |   | |   |
|   +-+   |   |   +-+   |   |   +-+   |    |   +-+   |
+---------+   +---------+   +---------+    +---------+
     |             |             |              |
     |             |             |              |
     |             |             |              |
|   +-+           +-+           +-+            +-+   |
|   |1|           |2|           |3|            |9|   |
|   +-+           +-+           +-+            +-+   |
|                                                    |
| native        native         native       tagged   |
| VLAN 100      VLAN 200       VLAN 300     VLANs    |
|                                           100      |
|                                           200      |
|                                           300      |
| FAUCET controlled OF switch                        |
|                                                    |


You configure this in FAUCET's configuration file:

                native_vlan: 100
                name: "port1.0.1"
                description: "host 1"
                native_vlan: 200
                name: "port1.0.2"
                description: "host 2"
                native_vlan: 300
                name: "port1.0.3"
                description: "host 3"
                tagged_vlans: [100,200,300]
                name: "port1.0.9"
                description: "nfv host"

On the NFV host, you need to configure the port to expect the tagged traffic and split it out to the right virtual interface. Let's say you connected the switch port 9, to eth0 on the NFV host. In Ubuntu, /etc/network/interfaces would have a section like this (you may also have to install the "vlan" package):

auto eth0
iface eth0 inet manual
  pre-up /sbin/ethtool -K $IFACE tso off gso off
  up ip link set $IFACE up
  down ip link set $IFACE down

auto eth0.100
iface eth0.100 inet manual
  up ip link set $IFACE up
  down ip link set $IFACE down

auto eth0.200
iface eth0.200 inet manual
  up ip link set $IFACE up
  down ip link set $IFACE down

auto eth0.300
iface eth0.300 inet manual
  up ip link set $IFACE up
  down ip link set $IFACE down

You could also of course assign IP addresses, etc to eth0.300, etc. You could even bridge those interfaces in turn to other bridges (using Linux bridges or OVS). Linux will untag the traffic for you (so for example, traffic from host 1, will appear on eth0.100, with no tag).

You can of course have multiple hosts in the same VLAN. For example, you could put hosts 1 and 2 both in VLAN 100, in which case they could see each other and the NFV host.

NB. Some FAUCET controlled switches need to be configured to expect a VLAN tag, even though the VLAN isn't configured on the switch (eg Allied Telesis switches require you to add VLAN numbers to the switch's VLAN database - see the quickstart article).

Thursday, January 5, 2017

enforcing DNSSEC client validation with FAUCET

DNSSEC is considered very important, because it provides a way for a DNS client to validate results.

However, not all DNS servers, will perform this validation on behalf of their clients (or the clients may be configured to use the wrong resolvers).

Using FAUCET with some NFV, though, you can force clients to use a validating DNS server.

First, you'll need to provide an NFV'd DNS server that performs validation. There is a guide for BIND - it boils down to a couple of extra configuration settings.

Then, you'll need to configure FAUCET to intercept DNS requests, and output them to the NFV port where the DNS server is. Here is a FAUCET config snippet that does that:

In this example, we force DNS requests, UDP and TCP, to go out port 1, VLAN 2001, which is where the NFV'd DNS server is running.

    # Force DNS
        - rule:
            dl_type: 0x800
            nw_proto: 17
            tp_dst: 53
                    vlan_vid: 2001
                    port: 1
        - rule:
            dl_type: 0x800
            nw_proto: 6
            tp_dst: 53
                    vlan_vid: 2001
                    port: 1
        - rule:

                allow: 1

                tagged_vlans: [2001,2002,2003]
                name: "port1.0.1"
                description: "windscale"
                native_vlan: 2001
                name: "port1.0.2"
                description: "vek-x"
                acl_in: 2001

Next, we configure the NFV host to intercept those DNS requests. This can be done with iptables - for example (the NFV host's IP, is

-A PREROUTING -i br1 -p tcp --dport 53 -j DNAT --to-destination
-A PREROUTING -i br1 -p udp --dport 53 -j DNAT --to-destination

Any client on port 2 is now compelled to use that DNS server (and only that DNS server). For example, they can visit a test site which will verify that DNSSEC is being used.

You might imagine using the same technique to force proxy other protocols, such HTTP, etc.

V1.3 released

To: faucet-dev, faucet-users

Hi all;

We have just pushed another stable release, V1.3, including new pip packages (

This release most notably makes a change to the pipeline (ACL table now comes first), and removes support for the old V1 config file format - only version V2 is supported.

There are a number of other changes to improve test reliability and some IP routing fixes.


Wednesday, January 4, 2017

LINK022 - OF controlled WiFi

In this post, I'll describe LINK022 - an experimental WiFi AP, powered by PoE, and controlled by OpenFlow (and FAUCET in particular). LINK022 can be used for practical use cases like eduroam, which is a global roaming WiFi service for research and education - which I'll describe as a working example.

Because OpenFlow is used to control WiFi traffic, you can dynamically filter, mirror, etc traffic as soon as it enters the network (rather than by the time it reaches a firewall), perhaps based on user ID - an external process can update and signal FAUCET to apply the appropriate policy.

At the moment, non-OpenFlow configuration is manually specified (eg, SSID). In the future, OpenConfig will be used.

LINK022 is based on Raspberry Pi 3. While the 3 does have onboard WiFi, it's suggested you use a separate WiFi adaptor (eg, you might want one with better/multiple antennas).

LINK022 requires a host switch that can provide PoE, and also runs OpenFlow (so both can be controlled by FAUCET).

The key software components of LINK022 are:
  • hostapd (manages the WiFi radio, and implements 802.1x authentication via RADIUS)
  • OVS (switches packets from WiFi, and implements security controls, like FAUCET ACLs)
  • FAUCET (controls OVS, and the host wired switch - runs on a separate host)
In the following diagram, LINK022 is on the left; the host switch is on the right, and the controller/NFV host (where FAUCET runs) is top right. 

FAUCET is used to implement VLAN 100 between AP and host switch, for  OpenFlow, RADIUS, and management traffic.

FAUCET also implements VLAN 2002, which WiFi clients are bridged onto, and the NFV host provides DHCP, DNS, etc, via the host wired switch.

To implement the eduroam use case, you will need to do the following (including obtain RADIUS credentials; if you don't have eduroam, you could use your own RADIUS server):

  • Set up a host OpenFlow wired switch with controller/NFV host, as above, running FAUCET.
  • Set up FAUCET config for the port, where you will connect LINK022.

                tagged_vlans: [100,2002]
                name: "port1.0.9"
                description: "link022 WiFi AP"
  • Set up FAUCET config to control LINK022 (OVS controls only the user traffic):

        dp_id: 0xb827eb608918
        hardware: "Open vSwitch"
                tagged_vlans: [2002]
                native_vlan: 2002
  • On LINK022, set up wired interface to use VLAN 100 by default, and set up a Linux bridge with veth pair (for OVS to connect to the WiFi radio). This is accomplished by using the following for /etc/network/interfaces:
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static 

auto eth0.100
iface eth0.100 inet dhcp
        vlan-raw-device eth0

auto wlan0
iface wlan0 inet static

auto wlanbr0
iface wlanbr0 inet static
        pre-up ip link add veth1 type veth peer name veth2
        up ifconfig veth1 up
        up ifconfig veth2 up
        bridge_ports veth1
  • Install OVS on the Pi (I used 2.6.1). The Pi isn't very powerful, so it will take a while to compile.
  • Configure OVS to be controlled by FAUCET, and add eth0 and veth2 to br0. Your br0 should look like this:
root@link022:/home/pi# ovs-vsctl show

    Bridge "br0"
        Controller "tcp:<FAUCET IP>:6636"
            is_connected: true
        Port "veth2"
            Interface "veth2"
        Port "br0"
            Interface "br0"
                type: internal
        Port "eth0"
            Interface "eth0"
    ovs_version: "2.6.1"

  • Install hostapd, with the following config as /etc/hostapd/hostapd.conf


auth_server_addr=<RADIUS SERVER IP>

That's it! From now on, if you have eduroam credentials, you will be able to authenticate and browse the network.

Some further reading: