'''[wiki:GENIExperimenter/Tutorials/OpenFlowOVS Intro to OpenFlow Tutorial (OVS) with Floodlight]''' {{{ #!html
Image Map
}}} [[PageOutline]] {{{ #!html
Overview
In this tutorial we are going to use Open vSwitch (OVS) as an OpenFlow switch connected to three hosts. OVS is a software switch running on a compute resource. The three hosts can only communicate through the OVS switch. The experiment will need (the RSpecs for this exercise are provided later in this section):
  • 1 Xen VM with a public IP to run an OpenFlow controller
  • 1 Xen VM to be the OpenFlow switch
  • 3 Xen VMs as hosts
Experiment Topology
}}} == Step 1. Obtain resources == This experiment requires two slices; one slice for the !OpenFlow Controller reservation and a second slice for the network topology that includes the compute resource for the OVS host plus the endpoint hosts. {{{ #!html
Note You can request compute resources from any InstaGENI aggregate and use any reservation tool (Portal, jFed, Omni, etc). For a list of available InstaGENI rack aggregates see the GENI Production Resources page or see the GENI Network Monitoring Aggregate Status page to get availability and usage levels for each rack.
}}} a) '' '''Create the controller slice and reserve a VM that runs your !OpenFlow controller.''' '' The Request Specification (RSpec) is available at: [https://raw.githubusercontent.com/GENI-NSF/geni-tutorials/master/OVSFloodLight/ControllerCustom_request_rspec.xml] b)'' '''Create the slice to reserve your network,''' '' which includes a VM with OVS installed and the endpoint hosts. RSpec is available at: [https://raw.githubusercontent.com/GENI-NSF/geni-tutorials/master/OVSFloodLight/OVS_TPOLOGY_request_rspec.xml] {{{ #!comment sudo /local/install-script-wireshark.sh http://www.gpolab.bbn.com/experiment-support/OpenFlowOVS/wireshark.tar.gz MOVED TO : https://github.com/GENI-NSF/geni-tutorials/raw/master/OVSFloodLight/Floodlight-install-script.tar.gz }}} {{{ #!html
Note In the GENI Portal, select ''Add Resources'' and then scroll down to the "Choose RSpec" section to enter the RSpec URLs above. Additionally, you can choose the InstaGENI aggregate where to reserve your resources by clicking on the node that says '''Site 1''' and selecting any InstaGENI rack from the menu on the left, as shown in the figure below:
}}} [[Image(GENIExperimenter/Tutorials/SystematicExprCaseStudy/InstallSoftware:SelectSite.jpg, 50%)]] {{{ #!html
Note SSH access to your nodes is set up as part of the resource reservation. For info on how to SSH to your reserved hosts see the How to Login page
}}} == Step 2. Configure the Open vSwitch == '''Overview ''' ''Although OVS is installed and initialized on the host that acts as a software switch, it has not been configured yet. There are two configuration operations that need to be executed: 1) configure the software switch with the interfaces as ports'' and 2) point the OVS switch to an !OpenFlow controller''. '' === 2a. Configure the Software Switch (OVS Window) === i. Login to the OVS host ii. Create an Ethernet bridge that will act as our software switch: {{{ sudo ovs-vsctl add-br br0 }}} iii. Prepare the interfaces to be added as ports to the OVS switch * Your OVS bridge will be a Layer 2 switch and your ports do not need IP addresses. Before we remove them let's keep track of some information * Run {{{ ifconfig }}} * Write down the interface names that correspond to the connections to your hosts. You will see three interfaces with IP's '''10.10.*.*''', one for each host. These are the data plane interfaces. * Remove the IP from your data interfaces. [[BR]] [[Image(GENIExperimenter/Tutorials/Graphics:warning-icon-hi.png, 2%)]] Be careful '''not to bring down eth0'''. This is the control interface, if you bring that interface down you ''' won't be able to login''' to your host. For all interfaces other than `eth0` and ` l0` (your interface names may vary) run : {{{ sudo ifconfig ethX 0 sudo ifconfig ethY 0 sudo ifconfig ethZ 0 }}} iv. Add all the data interfaces to your switch (bridge). [[BR]] [[Image(GENIExperimenter/Tutorials/Graphics:warning-icon-hi.png, 2%)]] Be careful ''' not to add interface eth0'''. This is the control interface. So now that we know the names of our three '''10.10.*.*''' interfaces, we can add them as ports to our bridge. These three interfaces are your data interfaces. {{{ sudo ovs-vsctl add-port br0 ethX sudo ovs-vsctl add-port br0 ethY sudo ovs-vsctl add-port br0 ethZ }}} v. Trust but verify. Congratulations! You have configured your software switch. To verify the three ports are configured run: {{{ sudo ovs-vsctl list-ports br0 }}} === 2b. Point your switch to a controller === {{{ #!html
Note An OpenFlow switch will not forward any packet unless instructed by a controller. Basically the forwarding table is empty, until an external controller inserts forwarding rules. The OpenFlow controller communicates with the switch over the control network and it can be anywhere in the Internet as long as it is reachable by the OVS host.
}}} i. Login to your controller ii. Find the '''control interface IP''' of your controller, use ''ifconfig'' and note down the IP address of `eth0`. iii. In order to point our software !OpenFlow switch to the controller, in the ''ovs'' terminal window, run: {{{ sudo ovs-vsctl set-controller br0 tcp::6633 }}} i. Set your switch to `fail-safe-mode`. For more info read the [#standalonevssecuremode standalone vs secure mode section]. Run: {{{ sudo ovs-vsctl set-fail-mode br0 secure }}} vi. Trust but verify. You can verify your OVS settings by issuing the following: {{{ sudo ovs-vsctl show }}} === 2c. `standalone` vs `secure` mode === The !OpenFlow controller is responsible for setting up all flows on the switch, which means that when the controller is not running there should be no packet switching at all. Depending on the setup of your network, such behavior might not be desired. It might be best that when the controller is down, the switch should default back to being a learning layer 2 switch. In other circumstances however this might be undesirable. In OVS this is a tunable parameter, called `fail-safe-mode` which can be set to the following parameters: * `standalone` ''[default]: in this case OVS will take responsibility for forwarding the packets if the controller fails'' * `secure`: ''in this case only the controller is responsible for forwarding packets, and if the controller is down all packets are dropped. '' In OVS when the parameter is not set it defaults to the `standalone` mode. For the purpose of this tutorial we will set the `fail-safe-mode` to `secure`, since we want to be the ones controlling the forwarding. ---- ''' [wiki:GENIExperimenter/Tutorials/OpenFlowOVS-Floodlight Prev: Introduction] ''' ''' [wiki:GENIExperimenter/Tutorials/OpenFlowOVS-Floodlight/Execute Next: Execute] '''