= Tutorial on seprating traffic on SB9 =

Open flow is a very versatile standard. You can read more about it here. As an example of the capabalities of open, and a tutorial to the setup
on the orbit sandbox that was created specfically for the purposes of evaluating and testing openflow, we will run through a simple expirment.

In the Openflow model, traffic can be seperated along may diffrent boundaries. In this particular example we're going to sperate bittorrent traffic in highnumbered ports. We will run two sperate controllers. The first will handle the production traffic, and run a comodity controller, SNAC. The second controller will manage the bit-torrent traffic, and run a configured Nox controller. The data interfaces (eth0) of 4 nodes are connected to the open flow switch. The logical setup should look like:[[BR]]

[[Image(setup.jpg)]] 


== Flowvisor ==

The flowvisor tool server as an intermediary between controllers. It splits traffic based on predefined rules. For our configuration we're running
flowvisor on SB9. While it is completely possible to complie your own flowvisor from scratch and install it in your home directory, a precompiled flowvisor is located in /opt.  In order to properly steer the flowvisor tool, you must populate a flovisor-config.d directory with files that configure the flowvisor behavoir. For the purposes of this demo we'll be using these files:

{{{
bittorent.guest
default.switch
routing.guest
}}}

The defualt file primes the flowvisor and contains only the following lines:

{{{
 # For switches that do not have a their own, specific config file
 Default: 1
 # Start numbering "default" switches at 10000
 Id: 10000
}}}

The routing.guest file directs production traffic to SNAC running on port 6634, it denies high numbered IP traffic from getting to port 6634:

{{{
Name: routing
ID: 1

Host: tcp:localhost:6634

# By default, with now "FlowSpace" param, this slice has
# permissions to affect all traffic
FlowSpace: deny: tp_src: 10001
FlowSpace: deny: tp_dst: 10001
FlowSpace: deny: tp_src: 10002
FlowSpace: deny: tp_dst: 10002
FlowSpace: deny: tp_src: 10003
FlowSpace: deny: tp_dst: 10003
FlowSpace: deny: tp_src: 10004
FlowSpace: deny: tp_dst: 10004
FlowSpace: deny: tp_src: 10005
FlowSpace: deny: tp_dst: 10005

# limit 10000 == at most 10000 packet_in's per second == infinity
FlowSpace: allow:   limit: 10000
}}}

Finally the bittorent.guest directs high numbered ip port traffic to a controller on 6635:
{{{
Id: 1001
Host: tcp:localhost:6635

FlowSpace: allow: tp_src: 10001 limit: 10000
FlowSpace: allow: tp_dst: 10001 limit: 10000
FlowSpace: allow: tp_src: 10002 limit: 10000
FlowSpace: allow: tp_dst: 10002 limit: 10000
FlowSpace: allow: tp_src: 10003 limit: 10000
FlowSpace: allow: tp_dst: 10003 limit: 10000
FlowSpace: allow: tp_src: 10004 limit: 10000
FlowSpace: allow: tp_dst: 10004 limit: 10000
FlowSpace: allow: tp_src: 10005 limit: 10000
FlowSpace: allow: tp_dst: 10005 limit: 10000
}}}

== TESTS for connectivity ==

=== The SNAC controller Web interface ===

The web interface for SNAC is accessible externally at http://sb9.orbit-lab.org (default credentials). Assuming your flowvisor is passing along high priority traffic to snac,  the this:[[BR]]
[[Image(snac.jpg)]]

=== Inter-node traffic ===

==== FIXME probably this will be a script detail ====

Once the data interfaces are brought up on each of the 4 nodes, they should be discovered by SNAC. Assuming we place them all in the same IP subnet, it should be possible to ping each node from every other node. A simple test can be done as follows:
{{{
for node1-i:

ssh root@node1-i
ifconfig eth0 up
ifconfig eth0 192.168.1.i
ping 192.168.1.(i-1)

where i runs from 1 to 4.
}}}

This should be done with independent sessions, as each session will start display traffic information. Once completed SNAC should report an increase in production  traffic, and 4 discovered hosts with the specified ips. 

==