FAUCET SDN Controller Documentation

FAUCET's design relies on several core assumptions to guarantee a consistent switch state and support high availability without state sharing between controllers:

• Single Controller Ownership: FAUCET is assumed to be the only controller for the switch capable of adding or removing flows.
• OpenFlow Uniformity: All supported dataplanes (hardware or software) must implement a functionally identical subset of OpenFlow 1.3. There is no switch-specific driver or TTP layer; the same messages are sent to OVS or hardware.
• Default Deny Policy: FAUCET provisions default deny flows, meaning all traffic not explicitly programmed is dropped.
• Minimized Packet-In: FAUCET minimizes the use of packet in messages to reduce competition for the OpenFlow control channel and protect the switch CPU. It achieves this by programming the dataplane to handle flooding where configured. Users are encouraged to use policy-based forwarding (e.g., ACLs) rather than relying on packet in.

Faucet uses an OpenFlow 1.3 multi-table pipeline to process packets. The pipeline is modular: tables are only provisioned if the corresponding functionality (like routing) is configured. While table IDs are typically allocated sequentially, you should refer to them by their functional names.

Key stages of the pipeline include:

• L2/VLAN Processing: PORT_ACL (port-based ACLs), VLAN (VLAN tagging/untagging and L2 protocol filtering), and VLAN_ACL (VLAN-based ACLs).
• L2 Learning & Switching: ETH_SRC (handles source MAC learning and routing decisions), ETH_DST_HAIRPIN (handles hairpinning/routing between VLANs on the same port), ETH_DST (standard L2 switching), and FLOOD (broadcast/multicast).
• L3 Routing: IPV4_FIB and IPV6_FIB (handle IPv4/IPv6 routing, TTL decrement, and MAC rewriting).
• Specialized Handling: Coprocessor (allows external NFV processors to intercept traffic) and VIP (handles traffic destined for Faucet Virtual IPs, including ARP/ND).

Faucet is designed for horizontal scaling and high availability through the following principles:

• Statelessness/Independence: Faucet controllers are not interdependent. You achieve "hot/hot" high availability by provisioning multiple Faucets with the same configuration.
• Distributed Deployment: A large network can run many Faucet instances spread across multiple machines. Controllers can be deployed as discrete functional units (e.g., one controller per rack) to reduce control plane complexity and latency.
• Offloaded Forwarding: Faucet offloads all forwarding to the OpenFlow switch, including flooding. It programs the switch pre-emptively to minimize packet processing needs.
• Multi-table Pipeline: Faucet uses a multi-table packet processing pipeline. This allows for complex flow-based logic while maintaining a smaller number of total flows and improving scalability by using dedicated tables with narrow match fields (e.g., IPv4 or IPv6 FIB tables).

To enable stacking, you must configure two main components in your faucet.yaml:

1. Stack Priority: Define a stack block with a priority value for each datapath (DP). The datapath with the lowest priority value becomes the root switch of the stack.
2. Stack Interfaces: For each interface acting as a link between switches, define a stack block specifying the remote datapath (dp) and the remote port (port).

When configured, Faucet uses LLDP beacons to discover and connect the stack ports automatically.

dps:
    br0:
        dp_id: 0x1
        hardware: "Open vSwitch"
        stack:
            priority: 1
        interfaces:
            1:
                description: "host1 network namespace"
                native_vlan: hosts
            2:
                description: "br0 stack link to br1"
                stack:
                    dp: br1
                    port: 2
    br1:
        dp_id: 0x2
        hardware: "Open vSwitch"
        interfaces:
            1:
                description: "host2 network namespace"
                native_vlan: hosts
            2:
                description: "br1 stack link to br0"
                stack:
                   dp: br0
                   port: 2

Faucet can manage stack topologies that contain loops (e.g., a ring topology) without requiring a traditional Spanning Tree Protocol (STP). When Faucet detects a topology change or brings up a stack for the first time, it calculates a spanning tree internally to prevent broadcast loops. This allows for fault-tolerant architectures where the network can survive single link or switch failures.

To configure a ring topology, define the stack links for each switch in faucet.yaml so that they form a closed loop. Faucet will automatically manage the spanning tree to ensure connectivity while preventing loops.

# /etc/faucet/faucet.yaml

vlans:
    hosts:
       vid: 100
dps:
    br0:
        dp_id: 0x1
        hardware: "Open vSwitch"
        stack:
            priority: 1
        interfaces:
            1:
                description: "host1 network namespace"
                native_vlan: hosts
            2:
                description: "br0 stack link to br1"
                stack:
                    dp: br1
                    port: 2
            3:
                description: "br0 stack link to br2"
                stack:
                    dp: br2
                    port: 2
    br1:
        dp_id: 0x2
        hardware: "Open vSwitch"
        interfaces:
            1:
                description: "host2 network namespace"
                native_vlan: hosts
            2:
                description: "br1 stack link to br0"
                stack:
                   dp: br0
                   port: 2
            3:
                description: "br1 stack link to br2"
                stack:
                   dp: br2
                   port: 3
    br2:
        dp_id: 0x3
        hardware: "Open vSwitch"
        interfaces:
            1:
                description: "host3 network namespace"
                native_vlan: hosts
            2:
                description: "br2 stack link to br0"
                stack:
                   dp: br0
                   port: 3
            3:
                description: "br2 stack link to br1"
                stack:
                   dp: br1
                   port: 3