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.