wiki:GENIExperimenter/Tutorials/OpenFlowOVS/Execute

Version 48 (modified by nriga@bbn.com, 10 years ago) (diff)

--

Intro to OpenFlow using OVS

Image Map

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 our switch, we first need to login to the host that will be used as an OpenFlow switch.

2a. Login to OVS host

The first thing we need to do is ssh in to the OVS host so that we can configure it. 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 take a look in this page.

2b. Configure the Software Switch

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 configure bridge:

sudo ovs-vsctl list-br

You should see only on bridge br0. Now we need to add the interfaces to this bridge that will act as ports of our software switch.

  1. List all the interfaces of the node
    • ifconfig

  • Be careful not to bring down eth0. This is your 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, remove the IP from the interfaces (your interface names may vary):
    • sudo ifconfig eth1 0
    • sudo ifconfig eth2 0
    • sudo ifconfig eth3 0
  • Add all the data interfaces to your switch (bridge):Be careful not to add interface eth0. This is your control interface. You should see three interfaces that start with VLAN, these are your data interfaces. (Use the same interfaces as you used in the previous step.)
    • sudo ovs-vsctl add-port br0 eth1
    • sudo ovs-vsctl add-port br0 eth2
    • sudo ovs-vsctl add-port br0 eth3
  • Login information for a VM

    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

    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. For the purpose of this tutorial and in order to minimize the resources we have reserved we are going to run OpenFlow controller at the same host as the OVS switch. This is merely for convenience reasons, the controller could have been anywhere on the Internet.

    In order to point our software OpenFlow switch to the controller run:

    sudo ovs-vsctl set-controller br0 tcp:127.0.0.1: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 in 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 which case OVS will take responsibility for forwarding the packets if the controller fails
    • secure: in which case only the controller is responsible for forwarding packets, and if the controller is down all packets are going to be 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
    

    3. Execute Experiment

    Now that our switch is up and running we are ready to start working on our controller. For this tutorial we are going to use the POX controller. The software is already installed in the OVS host for running POX and can also be found here.

    3a. Login to your hosts

    To start our experiment we need to ssh all of our hosts. 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 take a look in this page. Once you have logged in follow the rest of the instructions.

    3b. Use a Learning Switch Controller

    In this example we going to run a very simple learning switch controller to forward traffic between host1 and host2.

    1. First we are going to start a ping from host1 to host2, which should timeout, since there is no controller running. Leave this ping running.
      ping host2 -c 10
      
    1. We have installed the POX controller under /local/pox on the OVS host. POX comes with a set of example modules that you can use out of the box. One of the modules is a learning switch. Let's start the learning switch controller which is already available:
      cd /local/pox
      ./pox.py --verbose forwarding.l2_learning
      
    1. Now go to terminal of host1 and ping host2:
      [experimenter@host1 ~]$ ping host2 
      PING host2-lan1 (10.10.1.2) 56(84) bytes of data.
      From host1-lan0 (10.10.1.1) icmp_seq=2 Destination Host Unreachable
      From host1-lan0 (10.10.1.1) icmp_seq=3 Destination Host Unreachable
      From host1-lan0 (10.10.1.1) icmp_seq=4 Destination Host Unreachable
      64 bytes from host2-lan1 (10.10.1.2): icmp_req=5 ttl=64 time=23.9 ms
      64 bytes from host2-lan1 (10.10.1.2): icmp_req=6 ttl=64 time=0.717 ms
      64 bytes from host2-lan1 (10.10.1.2): icmp_req=7 ttl=64 time=0.654 ms
      64 bytes from host2-lan1 (10.10.1.2): icmp_req=8 ttl=64 time=0.723 ms
      64 bytes from host2-lan1 (10.10.1.2): icmp_req=9 ttl=64 time=0.596 ms
      

    Now the ping should work.

    1. Go back to your OVS host and take a look at the print outs. You should see that your controller installed flows based on the mac addresses of your packets.
    1. Kill your POX controller by pressing Ctrl-C:
      DEBUG:forwarding.l2_learning:installing flow for 02:c7:e8:a7:40:65.1 -> 02:f1:ae:bb:e3:a8.2
      ^C
      INFO:core:Going down...
      INFO:openflow.of_01:[3a-51-a1-ab-c3-43 1] disconnected
      INFO:core:Down.
      ovs:/local/pox% 
      
    1. Notice what will happen to your ping on host1.

    Soft vs Hard Timeouts

    All rules on the switch have two different timeouts:

    • Soft Timeout: This determines for how long the flow will remain at the forwarding table of the switch, if there no packets received that match the specific flow. As long as packets from that flow are received the flow remains on the flow table.
    • Hard Timeout: This determines the total time that a flow will remain at the forwarding table, independent of whether packets that match the flow are received; i.e. the flow will be removed after the hard timeout expires.

    Can you tell now why there were packets flowing even after you killed your controller?

    Useful Tips for writing your controller

    In order to make this first experience of writing controller easier, we wrote some helpful functions that will abstract some of the particularities of POX away. These functions are locates at /local/pox/ext/utils.py, so while you write your controller consult this file for details.

    Functions that are implemented include:

    • packetIsIP : Test if the packet is IP
    • packetIsARP : Test if the packet is ARP
    • packetIsRequestARP : Test if this is an ARP Request packet
    • packetIsReplyARP : Test if this is an ARP Reply packet
    • packetArpDstIp : Test what is the destination IP in an ARP packet
    • packetArpSrcIp : Test what is the sources IP in an ARP packet
    • packetIsTCP : Test if a packet is TCP
    • packetDstIp : Test the destination IP of a packet
    • packetSrcIp : Test the source IP of a packet
    • packetDstTCPPort : Test the destination TCP port of a packet
    • packetSrcTCPPort : Test the source TCP port of a packet
    • createOFAction : Create one OpenFlow action
    • getFullMatch : get the full match out of a packet
    • createFlowMod : create a flow mod
    • createArpRequest : Create an Arp Request for a different destination IP
    • createArpReply : Create an Arp Reply for a different source IP

    3c. Run a traffic duplication controller

    In the above example we ran a very simple learning switch controller. The power of OpenFlow comes from the fact that you can decide to forward the packet anyway you want based on the supported OpenFlow actions. A very simple but powerful modification you can do, is to duplicate all the traffic of the switch out a specific port. This is very useful for application and network analysis. You can imagine that at the port where you duplicate traffic you connect a device that does analysis. For this tutorial we are going to verify the duplication by doing a tcpdump on a port on the OVS switch.

    1. Open two new terminals to the OVS host.
    2. Look at the slice Details page in the portal and see what interfaces are bound to OVS:if1 and OVS:if2, use the MAC address of the interface to figure this out. Run tcpdump on these interfaces; one in each of the new terminals you opened. This will allow you to see all traffic going out the interfaces.
      sudo tcpdump -i <data_interface_name>
      
    1. In the other OVS host directory /local/pox/ext you would see two files:
    1. myDuplicateTraffic.py : this is the file that has instructions about how to complete the missing information, go ahead and try to implement your first controller.
    2. DuplicateTraffic.py : this has the actual solution you can just run this if you don't want to bother with writing a controller.
    1. Run your newly written controller on the <data_interface_name> that corresponds to OVS:if2:
      cd /local/pox
      ./pox.py --verbose myDuplicateTraffic --duplicate_port=<data_interface_name>
      

    1. To test it go to the terminal of host1 and try to ping host2:
      ping 10.10.1.2
      
      If your controller is working, your packets will register in both terminals running tcpdump.
    1. Stop the POX controller:
      DEBUG:myDuplicateTraffic:Got a packet : [02:f1:ae:bb:e3:a8>02:c7:e8:a7:40:65 IP]
      DEBUG:SimpleL2Learning:installing flow for 02:f1:ae:bb:e3:a8.2 -> 02:c7:e8:a7:40:65.[1, 2]
      ^C
      INFO:core:Going down...
      INFO:openflow.of_01:[3a-51-a1-ab-c3-43 1] disconnected
      INFO:core:Down.
      ovs:/local/pox% 
      

    3d. Run a port forward Controller

    Now let's do a slightly more complicated controller. OpenFlow gives you the power to overwrite fields of your packets at the switch, for example the TCP source or destination port and do port forwarding. You can have clients trying to contact a server at port 5000, and the OpenFlow switch can redirect your traffic to a service listening on port 6000.

    1. Under the /local/pox/ext directory there are two files PortForwarding.py and myPortForwarding.py that are similar like the previous exercise. Both of these controller are configured by a configuration file at ext/port_forward.config. Use myPortForwarding.py to write your own port forwarding controller.
    1. To test your controller we are going to use netcat. Go to the two terminals of host2. In one terminal run:
      nc -l 5000
      

    and in the other terminal run

    nc -l 6000
    
    1. Now, start the simple layer 2 forwarding controller. We are doing this to seen what happens with a simple controller.
      cd /local/pox
      ./pox.py --verbose forwarding.l2_learning
      
    1. Go to the terminal of host1 and connect to host2 at port 5000:
      nc 10.10.1.2 5000
      

    1. Type something and you should see it at the the terminal of host2 at port 5000.
    1. Now, stop the simple layer 2 forwarding controller:
      DEBUG:forwarding.l2_learning:installing flow for 02:d4:15:ed:07:4e.3 -> 02:ff:be:1d:19:ea.2
      ^C
      INFO:core:Going down...
      INFO:openflow.of_01:[36-63-8b-d7-16-4b 1] disconnected
      INFO:core:Down.
      ovs:/local/pox% 
      
    1. And start your port forwarding controller:
      ./pox.py --verbose myPortForwarding
      
    1. Repeat the netcat scenario described above. Now, your text should appear on the other terminal of host2 which is listenign to port 6000.
    1. Stop your port forwarding controller:
      DEBUG:myPortForwarding:Got a packet : [02:aa:a3:e8:6c:db>33:33:ff:e8:6c:db IPV6]
      ^C
      INFO:core:Going down...
      INFO:openflow.of_01:[36-63-8b-d7-16-4b 1] disconnected
      INFO:core:Down.
      ovs:/local/pox% 
      

    3e. Run a Server Proxy Controller

    As our last exercise, instead of diverging the traffic to a different server running on the same host, we will diverge the traffic to a server running on a different host and on a different port.

    1. Under the /loca/pox/ext directory there are two files Proxy.py and myProxy.py that are similar like the previous exercise. Both of these controllers are configured by the configuration file proxy.config. Use myProxy.py to write your own proxy controller.
    1. On the terminal of host3 run a netcat server:
      nc -l 7000
      
    1. On your OVS host open the /local/pox/ext/myProxy.py file, and edit it to implement a controller that will diverge traffic destined for host2 to host3. Before you start implementing think about what are the side effects of diverging traffic to a different host.
      • Is it enough to just change the IP address?
      • Is it enough to just modify the TCP packets?

    If you want to see the solution, it's available in file /local/pox/ext/Proxy.py file.

    1. To test your proxy controller run:
      cd /local/pox
      ./pox.py --verbose myProxy
      
    1. Go back to the terminal of host1 and try to connect netcat to host2 port 5000
      nc 10.10.1.2 5000
      
    1. If your controller works correctly, you should see your text showing up on the terminal of host3.

    Introduction

    Next: Finish