Changes between Initial Version and Version 1 of GENIExperimenter/Tutorials/OpenFlowOVS-Floodlight/Execute

Timestamp:

10/30/16 00:58:21 (7 years ago)

Author:

pjayanth@bbn.com

Comment:

--

GENIExperimenter/Tutorials/OpenFlowOVS-Floodlight/Execute

@@ +1 @@
+= [wiki:GENIExperimenter/Tutorials/OpenFlowOVS Intro to OpenFlow Tutorial] =
+{{{
+#!html
+
+<div style="text-align:center; width:495px; margin-left:auto; margin-right:auto;">
+<img id="Image-Maps_5201305222028436" src="http://groups.geni.net/geni/attachment/wiki/GENIExperimenter/Tutorials/Graphics/Execute.jpg?format=raw" usemap="#Image-Maps_5201305222028436" border="0" width="495" height="138" alt="" />
+<map id="_Image-Maps_5201305222028436" name="Image-Maps_5201305222028436">
+<area shape="rect" coords="18,18,135,110" href="http://groups.geni.net/geni/wiki/GENIExperimenter/Tutorials/OpenFlowOVS-Floodlight/DesignSetup" alt="" title=""    />
+<area shape="rect" coords="180,18,297,111" href="http://groups.geni.net/geni/wiki/GENIExperimenter/Tutorials/OpenFlowOVS-Floodlight/Execute" alt="" title=""    />
+<area shape="rect" coords="344,17,460,110" href="http://groups.geni.net/geni/wiki/GENIExperimenter/Tutorials/OpenFlowOVS-Floodlight/Finish" alt="" title=""    />
+<area shape="rect" coords="493,136,495,138" href="http://www.image-maps.com/index.php?aff=mapped_users_5201305222028436" alt="Image Map" title="Image Map" />
+</map>
+<!-- Image map text links - End - -->
+
+</div>
+}}}
+[[PageOutline]]
+== Step 3. Execute Experiment ==
+
+Now that the switch is up and running we are ready to start working on the controller. For this tutorial we are going to use the [http://www.noxrepo.org/pox/about-pox/ POX controller]. The software is already installed in the controller host for running POX and can also be found [http://www.gpolab.bbn.com/experiment-support/OpenFlowOVS/of-ovs.tar.gz here]. 
+
+=== 3a. Login to your hosts ===
+
+To start our experiment we need to ssh all of our hosts. 
+
+To get ready for the tutorial you will need to have the following windows open:
+  * one window with ssh into the controller
+  * four windows with ssh into OVS
+  * one window with ssh into host1 
+  * two windows with ssh into host2 
+  * one window with ssh into host3 
+
+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 [wiki:HowTo/LoginToNodes how to login.] Once you have logged in follow the rest of the instructions. 
+
+=== 3b. Use a Learning Switch Controller ===
+
+In this example we are going to run a very simple learning switch controller to forward traffic between `host1` and `host2`.
+ 
+  1. First start a ping from  `host1` to `host2`, which should timeout, since there is no controller running. 
+
+{{{
+ping host2 -c 10
+}}}
+
+  2. We have installed the POX controller under `/tmp/pox` on the controller 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.  Start the learning switch controller which is already available by running the following two commands:
+
+
+{{{
+#!html
+
+<table id="Table_01" border="0" cellpadding="5" cellspacing="0">
+    <tr>
+        <td>
+            <img src="http://trac.gpolab.bbn.com/gcf/raw-attachment/wiki/Graphics/4NotesIcon_512x512.png" width="50" height="50" alt="Note">
+               </td>
+<td>If you want to run your controller in a different port other than the default one (6633) then every time you invoke pox you should include: <code>openflow.of_01 --port=<custom_port> </code> e.g. pox.py  openflow.of_01 --port=443 --verbose forwarding.l2_learning
+</td>
+        </tr>
+</table>
+}}}
+
+{{{
+#!html
+
+<table id="Table_01" border="0" cellpadding="5" cellspacing="0">
+    <tr>
+        <td>
+            <img src="http://trac.gpolab.bbn.com/gcf/raw-attachment/wiki/Graphics/4NotesIcon_512x512.png" width="50" height="50" alt="Note">
+               </td>
+<td>"l2" below uses the letter `l` as in level and is not the number one. And you should wait for the '''INFO ... connected''' line to ensure that the switch and the controller are communicating.
+</td>
+        </tr>
+</table>
+}}}
+ 
+{{{
+cd /tmp/pox
+./pox.py --verbose forwarding.l2_learning
+}}}
+
+The output should look like this:
+{{{
+POX 0.1.0 (betta) / Copyright 2011-2013 James McCauley, et al.
+DEBUG:core:POX 0.1.0 (betta) going up...
+DEBUG:core:Running on CPython (2.7.3/Apr 20 2012 22:39:59)
+DEBUG:core:Platform is Linux-3.2.0-56-generic-x86_64-with-Ubuntu-12.04-precise
+INFO:core:POX 0.1.0 (betta) is up.
+DEBUG:openflow.of_01:Listening on 0.0.0.0:6633
+INFO:openflow.of_01:[9e-38-3e-8d-42-42 1] connected
+DEBUG:forwarding.l2_learning:Connection [9e-38-3e-8d-42-42 1]
+}}}
+
+
+{{{
+#!html
+
+<table id="Table_01" border="0" cellpadding="5" cellspacing="0">
+    <tr>
+        <td>
+            <img src="http://trac.gpolab.bbn.com/gcf/raw-attachment/wiki/Graphics/4NotesIcon_512x512.png" width="50" height="50" alt="Note">
+               </td>
+<td>In the event that you need to move the port of your controller, this is the command - 
+<pre>
+sudo ./pox.py --verbose openflow.of_01 --port=443 forwarding.l2_learning
+</pre>
+  Do not forget to tell the ovs switch that the controller will be listening on this new port, i.e change 6633 to 443 in Step 2c.
+</td>
+        </tr>
+</table>
+}}} 
+
+ 3. In the terminal of `host1`, 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. 
+
+  4. Go to your controller 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.  
+
+{{{
+#!html
+
+<table id="Table_01" border="0" cellpadding="5" cellspacing="0">
+    <tr>
+        <td>
+            <img src="http://trac.gpolab.bbn.com/gcf/raw-attachment/wiki/Graphics/4NotesIcon_512x512.png" width="50" height="50" alt="Note">
+               </td>
+<td>There is no way to get this information from the OpenFlow-capable hardware switch.
+</td>
+        </tr>
+</table>
+}}}
+
+=== 3b. Look around your OVS switch  ===
+
+  1. If you are using OVS, to see the flow table entries on your OVS switch:
+{{{
+sudo ovs-ofctl dump-flows br0
+}}}
+    You should see at least two table entries: One for ICMP Echo (icmp_type=8) messages from host1 to host2 and one for ICMP Echo Reply (icmp_type=0) messages from host2 to host1.  You may also see flow entries for arp packets.
+
+  2. To see messages go between your switch and your controller, open a new ssh window to your controller node and run tcpdump on the `eth0` interface and on the tcp port that your controller is listening on usually 6633.  (You can also run `tcpdump` on the `OVS` control interface if you desire.)
+{{{
+sudo tcpdump -i eth0 tcp port 6633
+}}}
+  You will see (1) periodic keepalive messages being exchanged by the switch and the controller, (2) messages from the switch to the controller (e.g. when there is a table miss) and an ICMP Echo message in, and (3) messages from the controller to the switch (e.g. to install new flow entries).
+
+  3. 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
+INFO:core:Going down...
+INFO:openflow.of_01:[3a-51-a1-ab-c3-43 1] disconnected
+INFO:core:Down.
+}}}
+
+  4. Notice what happens to your ping on host1.
+
+  5. If you are using OVS, check the flow table entries on your switch:
+{{{
+sudo ovs-ofctl dump-flows br0
+}}}
+  Since you set your switch to "secure" mode, i.e. don't forward packets if the controller fails, you will not see flow table entries.  If you see flow table entries, try again after 10 seconds to give the entries time to expire.
+
+
+==== Soft vs Hard Timeouts ====
+
+All rules on the switch have two different timeouts:
+
+  * '''Soft Timeout''': This determines for how long the flow will remain in the forwarding table of the switch if there are 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?
+
+=== 3d. Download the pox apps ===
+To help you get started with your controller writing, we will provide: 
+  * skeleton files for the controllers where you only need to complete some missing functionality
+  * the solution: fully implemented controllers
+  * a utility library that makes some of the pox messages easier to write
+
+'''In the controller terminal execute''':
+{{{
+  cd /tmp/pox/ext
+  wget http://www.gpolab.bbn.com/experiment-support/NFVApps/pox-intro-ctrlapps.tar.gz
+  tar xvfz pox-intro-ctrlapps.tar.gz
+}}}
+==== Useful Tips for writing your controller ====
+
+In order to make this first experience of writing a controller easier, we wrote some helpful functions that will abstract some of the particularities of POX away. 
+These functions are located in `/tmp/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
+
+=== 3e. Debugging your Controller ===
+While you are developing your controller, some useful debugging tools are:
+
+==== i. Print messages ====
+Run your controller in verbose mode (add --verbose) and add print messages at various places to see what your controller is seeing. 
+
+==== ii. Check the status in the switch ====
+If you are using an OVS switch, you can dump information from your switch.  For example, to dump the flows:
+{{{
+sudo ovs-ofctl dump-flows br0
+}}}
+Two other useful commands show you the status of your switch:
+{{{
+sudo ovs-vsctl show 
+sudo ovs-ofctl show br0
+}}}
+
+==== iii. Use Wireshark to see the OpenFlow messages ====
+Many times it is useful to see the OpenFlow messages being exchanged between your controller and the switch. This will tell you whether the messages that are created by your controller are correct and will allow you to see the details of any errors you might be seeing from the switch. You can use wireshark on both ends of the connection, in hardware switches you have to rely only on the controller view. 
+
+The controller host and OVS has wireshark installed, including the openflow dissector. For more information on wireshark you can take a look at the [http://wiki.wireshark.org/ wireshark wiki]. 
+
+Here we have a simple case of how to use the OpenFlow dissector for wireshark.
+
+If you are on a Linux friendly machine (this includes MACs) open a terminal and ssh to your controller machine using the -Y command line argument, i.e.
+{{{
+ssh -Y <username>@<controller>
+}}}
+
+Assuming that the public IP address on the controller is eth0, run wireshark by typing: 
+{{{
+sudo wireshark -i eth0&
+}}}
+
+When the wireshark window pops up, you might still have to choose eth0 for a live capture.  And you will want to use a filter to cut down on the chatter in the wireshark window.   One such filter might be just seeing what shows up on port 6633. To do that type ''tcp.port eq 6633'' in the filter window, assuming that 6633 is the port that the controller is
+listening on.   And once you have lines, you can choose one of the lines and choose "Decode as ...." and choose the ''OFP protocol''. 
+
+=== 3f. Run a traffic duplication controller ===
+
+In the above example we ran a very simple learning switch controller. [[BR]]
+[[Image(GENIExperimenter/Tutorials/Graphics:4NotesIcon_512x512.png, 5%, nolink)]]
+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 `tcpdump`  on two ports on the OVS switch. 
+
+  1. '''Use the interfaces that are connected to `host2` and  `host3`. '''
+    * Software Switch (OVS): If you have not noted them down you can use the manifest and the MAC address of the interfaces (ovs:if1 and ovs:if2) to figure this out. But you should have noted down the interfaces in Section 2 when you were configuring the software switch. Run tcpdump on these interfaces; one in each of the two ovs terminals you opened. This will allow you to see all traffic going out the interfaces.
+    [[BR]]
+   
+  To see that duplication is happening, on the ovs host, run:  
+{{{
+sudo tcpdump -i <data_interface_name>  [data_interface to host2]
+sudo tcpdump -i <data_interface_name>  [data_interface to host3]
+}}}
+
+  You should see traffic from host1 to host2 showing up in the tcpdump window for host3.  As a comparison, you will notice that no traffic shows up in that window when the controller is running the learning switch.
+  2. '''In the controller host directory `/tmp/pox/ext` you should see two files:'''
+
+       i. '''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. 
+       ii. '''!DuplicateTraffic.py''' : This has the actual solution. You can just run this if you don't want to bother with writing a controller. 
+
+  3. Run your newly written controller on the <data_interface_name> that corresponds to ''OVS:if2'' (which is connected to `host3`):  
+{{{
+cd /tmp/pox
+./pox.py --verbose DuplicateTraffic --duplicate_port=?
+}}}
+
+  For example, if ''OVS:if2'' corresponds to "eth1", enter
+
+  {{{
+  ./pox.py --verbose myDuplicateTraffic --duplicate_port=eth1
+  }}}
+   
+  4. 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. 
+
+  5. Stop the POX controller:
+{{{
+DEBUG:DuplicateTraffic: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]
+
+INFO:core:Going down...
+INFO:openflow.of_01:[3a-51-a1-ab-c3-43 1] disconnected
+INFO:core:Down.
+}}}
+
+=== 3g. 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 `/tmp/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.
+
+  2. 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
+}}}
+
+  3. Now, start the simple layer 2 forwarding controller. We are doing this to see what happens with a simple controller.
+{{{
+cd /tmp/pox
+./pox.py --verbose forwarding.l2_learning
+}}}
+
+  4. Go to the terminal of host1 and connect to host2 at port 5000:
+{{{
+nc 10.10.1.2 5000
+}}}
+   
+  5. Type something and you should see it at the the terminal of host2 at port 5000. 
+
+  6. 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
+
+INFO:core:Going down...
+INFO:openflow.of_01:[36-63-8b-d7-16-4b 1] disconnected
+INFO:core:Down.
+}}}
+
+  7. And start your port forwarding controller (if you have written your controller then use myPortForwarding in the following command):
+{{{
+./pox.py --verbose PortForwarding
+}}}
+
+  8. Repeat the netcat scenario described above. Now, your text should appear on the other terminal of host2 which is listening to port 6000. 
+
+
+  9. Stop your port forwarding controller:
+{{{
+DEBUG:myPortForwarding:Got a packet : [02:aa:a3:e8:6c:db>33:33:ff:e8:6c:db IPV6]
+
+INFO:core:Going down...
+INFO:openflow.of_01:[36-63-8b-d7-16-4b 1] disconnected
+INFO:core:Down.
+}}}
+
+=== 3h. Run a Server Proxy Controller ===
+
+As our last exercise, instead of diverting the traffic to a different server running on the same host, we will divert the traffic to a server running on a different host and on a different port. 
+
+  1. Under the `/tmp/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.
+
+  2. On the terminal of `host3` run a netcat server:
+{{{
+nc -l 7000
+}}}
+
+  3. On your controller host, open the /tmp/pox/ext/myProxy.py file, and edit it to implement a controller that will divert traffic destined for `host2` to `host3`. Before you start implementing think about what are the side effects of diverting 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 /tmp/pox/ext/Proxy.py file.  
+  
+  4. To test your proxy controller run  (if you have written your controller then use myProxy in the following command):: 
+{{{
+cd /tmp/pox
+./pox.py --verbose Proxy
+}}}
+
+
+  5. Go back to the terminal of `host1` and try to connect netcat to `host2` port 5000
+{{{
+nc 10.10.1.2 5000
+}}}
+
+  6. If your controller works correctly, you should see your text showing up on the terminal of `host3`.
+
+=== 3i. Delete your bridge ===
+Before moving to the next step make sure you delete the bridge you have created, especially if you are using the same reservation for a different exercise:
+{{{
+  sudo ovs-vsctl del-br br0
+}}}
+
+{{{
+#!comment
+== 4. Moving to a Hardware Switch ==
+To try your controller with a GENI Hardware !OpenFlow switch:
+       * Delete the sliver with your experiment topology.  '''Do not''' delete your controller. 
+       * Follow the instructions at [wiki:GENIExperimenter/Tutorials/OpenFlowOVS/HW/DesignSetup OpenFlow Design and Setup for Hardware Switch]
+
+If you do not want to do the Hardware !OpenFlow portion of the tutorial, proceed to [wiki:GENIExperimenter/Tutorials/OpenFlowOVS/Finish Finish]
+}}}
+----
+
+= [wiki:GENIExperimenter/Tutorials/OpenFlowOVS-Floodlight/DesignSetup Prev: Design and Setup for OVS] =
+
+{{{
+#!comment
+= [wiki:GENIExperimenter/Tutorials/OpenFlowOVS/NATExecute Next: Make your switch to act as a NAT server] = 
+= [wiki:GENIExperimenter/Tutorials/OpenFlowOVS/FirewallExecute Next: Make your switch to act as a Firewall] =
+}}}
+= [wiki:GENIExperimenter/Tutorials/OpenFlowOVS-Floodlight/Finish Next:  Finish] =