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"
        actions:
            output:
                dl_dst: "06:06:06:06:06:06"
                vlan_vids: [123, 456]
                port: acloutport
See https://github.com/REANNZ/faucet/pull/517/commits/117ed988c8d42dab7e2ce2d154d520b1fd79810e 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 https://github.com/osrg/ryu/blob/master/doc/source/tls.rst.

To test that it works with your hardware, see the the new TLS fields in https://github.com/REANNZ/faucet/blob/master/tests/hw_switch_config.yaml.

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



Tuesday, March 21, 2017

FAUCET @ OpenStack 2017

https://www.openstack.org/summit/boston-2017/summit-schedule/events/18638/open-vswitch-lightning-talks

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.

vlans:
    100:
        faucet_vips: ["10.100.0.254/24"]
    200:
        faucet_vips: ["10.200.0.254/24"]
routers:
    router-1:
        vlans: [100, 200]
dps:
    faucet-1:
        hardware: "Open vSwitch"
        dp_id: 0x1
        interfaces:
            1:
                native_vlan: 100
            2:
                native_vlan: 200


Tuesday, February 28, 2017

FAUCET continuous integration testing with Travis

https://xkcd.com/303/

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.

https://travis-ci.org/anarkiwi/faucet

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

https://youtu.be/N0RuxM9bt-Y?list=PLeAkos2dldO5vjrg6vS0rYEPIvRs8naAA&t=694

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:

        interfaces:
            1:
                native_vlan: 100
                name: "port1.0.1"
                description: "host 1"
            2:
                native_vlan: 200
                name: "port1.0.2"
                description: "host 2"
            3:
                native_vlan: 300
                name: "port1.0.3"
                description: "host 3"
            9:
                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.

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

                allow: 1
...

        interfaces:
            1:
                tagged_vlans: [2001,2002,2003]
                name: "port1.0.1"
                description: "windscale"
            2:
                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 192.168.1.1).

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

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 (https://pypi.python.org/pypi/ryu-faucet).

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.

Thanks,

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.
            9:

                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):
    link022-faucet-1:

        dp_id: 0xb827eb608918
        hardware: "Open vSwitch"
        interfaces:
            1:
                tagged_vlans: [2002]
            2:
                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 
address 0.0.0.0

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

auto wlan0
iface wlan0 inet static
address 0.0.0.0

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
address 0.0.0.0
        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

6a4b6902-349e-4b99-b1ed-54338ca7ceac
    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

interface=wlan0

driver=nl80211
hw_mode=g
channel=6
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=2
rsn_pairwise=CCMP
bridge=wlanbr0
ssid=eduroam
auth_server_addr=<RADIUS SERVER IP>
auth_server_port=1812
auth_server_shared_secret=<SECRET>
wpa_key_mgmt=WPA-EAP
ieee8021x=1


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

Some further reading: