Version 42 (modified by 10 years ago) (diff) | ,
---|
Intro to OpenFlow Tutorial (OVS)?
Step 1. Obtain resources
This tutorial can use compute resources from any InstaGENI rack. For a list of available InstaGENI racks see the GENI Production Resources page. If doing this outside a tutorial, use Utah DDC InstaGENI. The experiment will need:
- 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
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 other three hosts can only communicate through the OVS switch.
If you are attending a Tutorial, the resources might have been reserved for you, check with your instructor and skip this step. You can use any reservation tool you want to reserve this topology. We will need two slices for this tutorial:
- A slice with a single VM that runs your OpenFlow controller
- A slice with your compute resources including a VM with OVS installed.
To reserve resources use your favorite resource reservation tool (Omni, Portal, jFed):
- In your slice that will run the OpenFlow controller: Reserve a VM running the controller using the request RSpec http://www.gpolab.bbn.com/exp/OpenFlowOVS/pox-controller.rspec. This RSpec is available in the Portal and is called XEN VM POX Ctrl
- In the slice that will run your hosts: Reserve the topology using the request rspec http://www.gpolab.bbn.com/experiment-support/OpenFlowOVS/openflowovs-all-xen.rspec.xml. This RSpec is available in the Portal and is called OpenFlow OVS all XEN
Step 2. Configure and Initialize
Although OVS is installed and initialized on the host that is meant to act as a software switch, it has not been configured yet. There are two main things that need to be configured: (1) configure your software switch with the interfaces as ports and (2) point the switch to an OpenFlow controller.
In order to configure the OVS switch, we first login to the host that will be used as an OpenFlow switch.
Depending on which tool and OS you are using there is a slightly different process for logging in. If you don't know how to SSH to your reserved hosts learn how to login.
2a. Configure the Software Switch (OVS Window)
Now that you are logged in, we need first to configure OVS. To save time in this tutorial, we have already started OVS and we have added an Ethernet bridge that will act as our software switch. Try the following to show the configured bridge:
sudo ovs-vsctl list-br
You should see only one bridge br0
. Now we need to add the interfaces to this bridge that will act as the ports of the software switch.
|
eth0
and l0
, remove the IP from the interfaces (your interface names may vary): -
sudo ifconfig ethX 0
-
sudo ifconfig ethY 0
-
sudo ifconfig ethZ 0
-
sudo ovs-vsctl add-port br0 ethX
-
sudo ovs-vsctl add-port br0 ethY
-
sudo ovs-vsctl add-port br0 ethZ
Congratulations! You have configured your software switch. To verify the three ports configured run:
sudo ovs-vsctl list-ports br0
2c. Point your switch to a controller
In the controller window, find the control interface IP of your controller, use ifconfig and note down the IP address of eth0
.
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.
In order to point our software OpenFlow switch to the controller, in the ovs window, run:
sudo ovs-vsctl set-controller br0 tcp:<controller_ip>:6633
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 a 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 failssecure
: 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 falls back 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. Run:
sudo ovs-vsctl set-fail-mode br0 secure
You can verify your OVS settings by issuing the following:
sudo ovs-vsctl show