= VLAN stitching on the (Tunneling) NetFPGA !OpenFlow Switch = This page describes how VLAN stitching can be implemented on a NetFPGA running the Tunneling !OpenFlow bitfile (of1). == Topology == The NetFPGA bridges two VLANs, 5 and 3733. The connections are as follows: * of1:nf2c1 <---- VLAN 5 ---> sw-top:geth0/15 * of1:nf2c2 <-- VLAN 3733 --> sw-outside:geth0/34 These VLANs were stitched together by pushing flow rules to of1 from `kvm-big`, running the Big Switch controller. == Configurations == `of1` shows up as DPID 00:00:00:23:20:08:0f:f7 on `kvm-big`. On `of1`, this is the MAC address of interface tap0. [[BR]] This is done from the CLI, in config-switch mode. {{{ kvm-big> en kvm-big# conf kvm-big(config)# switch 00:00:00:23:20:08:0f:f7 kvm-big(config-switch)# }}} From the config-switch context, two flow entries are created for `of1`'s DPID on `kvm-big`: one for switching VLAN tags from 3733 to 5 on nf2c2, and the other, from 5 to 3733 on nf2c1. {{{ flow-entry port-c1 active True ingress-port 2 vlan-id 5 actions set-vlan-id=3733,output=3 flow-entry port-c2 active True ingress-port 3 vlan-id 3733 actions set-vlan-id=5,output=2 }}} If using the REST API, the exact same keyword=value pairs can be placed in a HTTP PUT using a script, or a tool such as `curl`: {{{ % curl -d '{"switch": "00:00:00:23:20:08:0f:f7", "name": "port-c1", "active": "true" ... }' http://:8080/wm/staticflowentrypusher/json }}} Setting flow entries from the `config-switch` context is a matter of copy/pasting each line above, and exiting contexts between different flow entries. Key points are: * The four ports of the NetFPGA are designated 1,2,3,4, not 0,1,2,3 as the nf2cx numbering might suggest. * 'active True' must be specified to enable the flow policy since the default for any newly created flow is 'active False' * at least one layer 2 or lower constraint e.g. ingress/egress port or src/dst MAC must be specified * there should be no white-spaces between the actions list. === sanity checks === The NetFPGA host implements !OpenFlow features via the following processes: {{{ root 1374 1 0 10:55 ? 00:00:00 /opt/netfpga2.1.1/openflow/udatapath/ofdatapath -D punix:/var/run/test -d 002320080ff7 -i nf2c0 nf2c1 nf2c2 nf2c3 root 1452 1 0 10:55 ? 00:00:00 /opt/netfpga2.1.1/openflow/secchan/ofprotocol -D unix:/var/run/test tcp:nox.orbit-lab.org:6633 --out-of-band }}} To check for flows on the host itself, `dpctl` should be used. The commands to pull the switch's status and current flows (e.g. traces) are: {{{ dpctl show unix:/var/run/test dpctl status unix:/var/run/test dpctl montior unix:/var/run/test }}} This is similar to the commands `show [DPID] status` and `show [DPID] trace detail` on the controller CLI. An external test involved IP address assignments to the VLAN interfaces for VLANs 5 and 3733 on sw-top and sw-outside, respectively. The IP addresses were pinged from each side; Pings pass between the two VLAN interfaces when stitched correctly.