Changes between Version 110 and Version 111 of GENIExperimenter/Tutorials/OpenFlowOVS/Execute


Ignore:
Timestamp:
02/27/15 14:24:37 (9 years ago)
Author:
rrhain@bbn.com
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • GENIExperimenter/Tutorials/OpenFlowOVS/Execute

    v110 v111  
    1 = [wiki:GENIExperimenter/Tutorials/OpenFlowOVS Intro to OpenFlow using OVS] =
     1= [wiki:GENIExperimenter/Tutorials/OpenFlowIntro Intro to OpenFlow Tutorial] =
    22{{{
    33#!html
    … …  
    1616}}}
    1717[[PageOutline]]
    18 
    19 == Step 2.  Configure and Initialize ==
    20 
    21 Although OVS is installed and initialized on the host that is meant to act as a software switch, it has not been configured yet.
    22 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''.
    23 
    24 In order to configure our switch, we first need to login to the host that will be used as an !OpenFlow switch.
     18== Step 3. Execute Experiment ==
     19
     20Now 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].
     21
     22=== 3a. Login to your hosts ===
     23
     24To start our experiment we need to ssh all of our hosts.
    2525
    2626To get ready for the tutorial you will need to have the following windows open:
    … …  
    3131  * one window with ssh into host3
    3232
    33 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 [wiki:HowTo/LoginToNodes this page.]
    34 
    35 === 2a. Configure  the Software Switch (OVS Window) ===
    36 
    37 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:
    38 {{{
    39 sudo ovs-vsctl list-br
    40 }}}
    41 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.
    42 
    43 {{{
    44 #!html
    45 <table border="0">
    46       <tr >
    47        <td width = "500">
    48          <ol>
    49            <li>List all the interfaces of the node
    50             <ul> <li> <code>ifconfig</code> </ul><br/>
    51             Write down the interface names that correspond to the connections to your hosts. The correspondence is:
    52             <ul>
    53                 <li> Interface with IP 10.10.1.11 to host1  - ethX</li>
    54                 <li> Interface with IP 10.10.1.12 to host2 - ethY</li>
    55                 <li> Interface with IP 10.10.1.13 to host3 - ethZ</li>
    56            </ul></li>
    57            </li> <br/>
    58            <li> Be careful <b> not to bring down eth0</b>. This is your control interface, if you bring that interface down you <b> won't be able to login</b> to your host!. For all interfaces other than <code>eth0</code> and <code> l0</code>, remove the IP from the interfaces (your interface names may vary): <br/>
    59                               <ul><li> <code> sudo ifconfig ethX 0 </code> </li></ul>
    60                               <ul><li> <code> sudo ifconfig ethY 0 </code> </li></ul>
    61                               <ul><li> <code> sudo ifconfig ethZ 0 </code> </li></ul>
    62              <li> Add all the data interfaces to your switch (bridge):Be careful <b> not to add interface eth0</b>. 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.)
    63                 <ul><li> <code> sudo  ovs-vsctl add-port br0 ethX </code> </li></ul>
    64                 <ul><li> <code> sudo  ovs-vsctl add-port br0 ethY </code> </li></ul>
    65                 <ul><li> <code> sudo  ovs-vsctl add-port br0 ethZ </code> </li></ul>
    66              </li>
    67           </ol>
    68        </td>
    69         <td>
    70         <img border="0" src="http://groups.geni.net/geni/attachment/wiki/GENIExperimenter/Tutorials/OpenflowOVS/Graphics/ovs-interfaces.jpg?format=raw" alt="Login information for a VM"  height="250" title="Login information for a VM" /> </a>
    71        </td>
    72     </tr>
    73  </table>
    74 }}}
     33Depending 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.
     34
     35=== 3b. Use a Learning Switch Controller ===
     36
     37In this example we are going to run a very simple learning switch controller to forward traffic between `host1` and `host2`.
    7538 
    76 Congratulations! You have configured your software switch. To verify the three ports configured run:
    77 {{{
    78 sudo ovs-vsctl list-ports br0
    79 }}}
    80 
    81 === 2c. Point your switch to a controller ===
    82 
    83 In the controller window, find the control interface IP of your controller, use ifconfig and note down the IP of `eth0`.
    84 
    85 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.
    86 
    87 In order to point our software !OpenFlow switch to the controller, in the ovs window, run:
    88 {{{
    89 sudo ovs-vsctl set-controller br0 tcp:<controller_ip>:6633
    90 }}}
    91 
    92 ==== `standalone` vs `secure` mode ====
    93 
    94 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:
    95   * `standalone` [default]: in which case OVS will take responsibility for forwarding the packets if the controller fails
    96   * `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.
    97 
    98 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:
    99 {{{
    100 sudo ovs-vsctl set-fail-mode br0 secure
    101 }}}
    102 You can verify your OVS settings by issuing the following:
    103 
    104 {{{
    105 sudo ovs-vsctl show
    106 }}}
    107 
    108 == Step 3. Execute Experiment ==
    109 
    110 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 [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].
    111 
    112 === 3a. Login to your hosts ===
    113 
    114 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 [wiki:HowTo/LoginToNodes this page.] Once you have logged in follow the rest of the instructions.
    115 
    116 === 3b. Use a Learning Switch Controller ===
    117 
    118 In this example we going to run a very simple learning switch controller to forward traffic between host1 and host2.
    119  
    120   1. First we are going to start a ping from  `host1` to `host2`, which should timeout, since there is no controller running.
    121   {{{
    122   ping host2 -c 10
    123   }}}
    124 
    125   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.  Let's start the learning switch controller which is already available:
    126   {{{
    127   cd /tmp/pox
    128   ./pox.py --verbose forwarding.l2_learning
    129 
     39  1. First start a ping from  `host1` to `host2`, which should timeout, since there is no controller running.
     40
     41{{{
     42ping host2 -c 10
     43}}}
     44
     45  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:
     46
     47{{{
     48cd /tmp/pox
     49./pox.py --verbose forwarding.l2_learning
     50}}}
     51
     52The output should look like this:
     53{{{
    13054  POX 0.1.0 (betta) / Copyright 2011-2013 James McCauley, et al.
    13155  DEBUG:core:POX 0.1.0 (betta) going up...
    … …  
    13963  }}}
    14064
    141    '' Note: "l2" above 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.''[[BR]]
    142 
    143    '' Note:  In the event that you need to move the port of your controller, this is the command - sudo ./pox.py --verbose openflow.of_01 --port=443 forwarding.l2_learning -  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.''
    144 
    145  3. Now go to terminal of `host1` and ping `host2`:
     65{{{
     66#!html
     67
     68<table id="Table_01" border="0" cellpadding="5" cellspacing="0">
     69    <tr>
     70        <td>
     71            <img src="http://trac.gpolab.bbn.com/gcf/raw-attachment/wiki/Graphics/4NotesIcon_512x512.png" width="50" height="50" alt="Note">
     72               </td>
     73<td>"l2" above 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.
     74</td>
     75        </tr>
     76</table>
     77}}}
     78 
     79
     80{{{
     81#!html
     82
     83<table id="Table_01" border="0" cellpadding="5" cellspacing="0">
     84    <tr>
     85        <td>
     86            <img src="http://trac.gpolab.bbn.com/gcf/raw-attachment/wiki/Graphics/4NotesIcon_512x512.png" width="50" height="50" alt="Note">
     87               </td>
     88<td>In the event that you need to move the port of your controller, this is the command -
     89<pre>
     90sudo ./pox.py --verbose openflow.of_01 --port=443 forwarding.l2_learning
     91</pre>
     92  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.
     93</td>
     94        </tr>
     95</table>
     96}}}
     97
     98 3. In the terminal of `host1`, ping `host2`:
    14699  {{{
    147100  [experimenter@host1 ~]$ ping host2
    … …  
    159112  Now the ping should work.
    160113
    161   4. 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.
    162 
    163   5. To see the flow table entries on your OVS switch:
    164   {{{
    165   sudo ovs-ofctl dump-flows br0
     114  4. If you are using OVS, 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. 
     115
     116{{{
     117#!html
     118
     119<table id="Table_01" border="0" cellpadding="5" cellspacing="0">
     120    <tr>
     121        <td>
     122            <img src="http://trac.gpolab.bbn.com/gcf/raw-attachment/wiki/Graphics/4NotesIcon_512x512.png" width="50" height="50" alt="Note">
     123               </td>
     124<td>There is no way to get this information from the OpenFlow-capable hardware switch.
     125</td>
     126        </tr>
     127</table>
     128}}}
     129
     130  5. If you are using OVS, to see the flow table entries on your OVS switch:
     131  {{{
     132sudo ovs-ofctl dump-flows br0
    166133  }}}
    167134  You should see at least two table entries: One for ICMP Echo (icmp_code=8) messages from host1 to host2 and one for ICMP Echo Reply (icmp_code=0) messages from host2 to host1.  You may also see flow entries for arp packets.
    168135
    169   6. 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:
    170   {{{
    171   sudo tcpdump -i eth0 tcp port 6633
     136  6. 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.  However, when using the hardware switch, you can only do the `tcpdump` on your controller host.)
     137  {{{
     138sudo tcpdump -i eth0 tcp port 6633
    172139  }}}
    173140  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).
    … …  
    184151  8. Notice what happens to your ping on host1.
    185152
    186   9. Check the flow table entries on your switch:
     153  9. If you are using OVS, check the flow table entries on your switch:
    187154   {{{
    188   sudo ovs-ofctl dump-flows br0
     155sudo ovs-ofctl dump-flows br0
    189156  }}}
    190157  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.
    … …  
    195162All rules on the switch have two different timeouts:
    196163
    197   * '''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.
     164  * '''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.
    198165  * '''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.
    199166
    … …  
    202169=== Useful Tips for writing your controller ===
    203170
    204 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.
     171In 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.
    205172These functions are located in `/tmp/pox/ext/utils.py`, so while you write your controller consult this file for details.
    206173
    … …  
    257224}}}
    258225
    259 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, so to do that type ''tcp.port eq 6633'' in the filter window, assuming that 6633 is the port that the controller is
    260 listening on.   And once you have lines, you can choose one of the lines and choose "Decode as ...." and choose the OFP protocol.
     226When 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
     227listening on.   And once you have lines, you can choose one of the lines and choose "Decode as ...." and choose the ''OFP protocol''.
    261228
    262229=== 3d. Run a traffic duplication controller ===
    … …  
    265232
    266233  1. Use the interfaces that are connected to `host2` and  `host3`.
    267     * Software Switch (OVS): If you haven't note them down you can use the manifest and the MAC address of the interfaces (ovs:if1 and ovs:if2) to figure this out.  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.
    268     * Hardware Switch:   Refer to this Section to figure out ports: [http://groups.geni.net/geni/wiki/GENIExperimenter/Tutorials/OpenFlowOVS/Appendix#Usefultips UsefulTips].  If you are using a hardware switch, you may not see the traffic on host3, but if you observe your controller output, you will notice that flows are being installed for forwarding to host2 and host3.[[BR]]
    269    To see that duplication is happening, on host3, run: 
    270   {{{
    271   sudo tcpdump -i <data_interface_name>
     234    * 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.
     235    * Hardware Switch:   Refer to this Section to figure out ports: [http://groups.geni.net/geni/wiki/GENIExperimenter/Tutorials/OpenFlowHW/DesignSetup#a2a.ConfiguretheControllerfortheHardwareSwitch:UsefulTips UsefulTips].  If you are using a hardware switch, you may not see the traffic on host3, but if you observe your controller output, you will notice that flows are being installed for forwarding to host2 and host3.[[BR]]
     236   
     237  To see that duplication is happening, on host3, run: 
     238  {{{
     239sudo tcpdump -i <data_interface_name>
    272240  }}}
    273241
    274242  You should see ICMP echo and ICMP reply lines from host1 to host2 showing up in the host3 tcpdump window.
    275   2. In the controller host directory `/tmp/pox/ext` you would see two files:
    276 
    277        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.
    278        ii. !DuplicateTraffic.py : this has the actual solution you can just run this if you don't want to bother with writing a controller.
     243  2. In the controller host directory `/tmp/pox/ext` you should see two files:
     244
     245       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.
     246       ii. !DuplicateTraffic.py : This has the actual solution. You can just run this if you don't want to bother with writing a controller.
    279247
    280248  3. Run your newly written controller on the <data_interface_name> that corresponds to ''OVS:if2'' (which is connected to `host3`): 
    281249  {{{
    282   cd /tmp/pox
    283   ./pox.py --verbose myDuplicateTraffic --duplicate_port=<data_interface_name>
     250cd /tmp/pox
     251./pox.py --verbose myDuplicateTraffic --duplicate_port=<data_interface_name>
    284252  }}}
    285253   
    286254  4. To test it go to the terminal of host1 and try to ping host2:
    287255  {{{
    288   ping 10.10.1.2
     256ping 10.10.1.2
    289257  }}}
    290258  If your controller is working, your packets will register in both terminals running tcpdump.
    … …  
    309277  2. To test your controller we are going to use netcat. Go to the two terminals of host2. In one terminal run:
    310278  {{{
    311   nc -l 5000
     279nc -l 5000
    312280  }}}
    313281
    314282  and in the other terminal run
    315283  {{{
    316   nc -l 6000
     284nc -l 6000
    317285  }}}
    318286
    319287  3. Now, start the simple layer 2 forwarding controller. We are doing this to see what happens with a simple controller.
    320288  {{{
    321   cd /tmp/pox
    322   ./pox.py --verbose forwarding.l2_learning
     289cd /tmp/pox
     290./pox.py --verbose forwarding.l2_learning
    323291  }}}
    324292
    325293  4. Go to the terminal of host1 and connect to host2 at port 5000:
    326294  {{{
    327   nc 10.10.1.2 5000
     295nc 10.10.1.2 5000
    328296  }}}
    329297   
    … …  
    342310  7. And start your port forwarding controller:
    343311  {{{
    344   ./pox.py --verbose myPortForwarding
     312./pox.py --verbose myPortForwarding
    345313  }}}
    346314
    … …  
    359327=== 3e. Run a Server Proxy Controller ===
    360328
    361 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.
     329As 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.
    362330
    363331  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.
    … …  
    365333  2. On the terminal of `host3` run a netcat server:
    366334  {{{
    367   nc -l 7000
    368   }}}
    369 
    370   3. On your controller host, open the /tmp/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.
     335nc -l 7000
     336  }}}
     337
     338  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.
    371339     * Is it enough to just change the IP address?
    372340     * Is it enough to just modify the TCP packets?
    … …  
    376344  4. To test your proxy controller run:
    377345  {{{
    378   cd /tmp/pox
    379   ./pox.py --verbose myProxy
     346cd /tmp/pox
     347./pox.py --verbose myProxy
    380348  }}}
    381349
    … …  
    383351  5. Go back to the terminal of `host1` and try to connect netcat to `host2` port 5000
    384352  {{{
    385   nc 10.10.1.2 5000
     353nc 10.10.1.2 5000
    386354  }}}
    387355
    … …  
    391359To try your controller with a GENI Hardware !OpenFlow switch:
    392360       * Delete resources in your slice with the compute resources.  '''Do not''' delete resources in your slice with the controller.
    393        * Follow the instructions at [wiki:GENIExperimenter/Tutorials/OpenFlowOVS/Appendix]
    394 
    395 If you do not want to do the Hardware !OpenFlow portion of the tutorial, proceed to [wiki:GENIExperimenter/Tutorials/OpenFlowOVS/Finish]
     361       * Follow the instructions at [wiki:GENIExperimenter/Tutorials/OpenFlowHW/DesignSetup]
     362
     363If you do not want to do the Hardware !OpenFlow portion of the tutorial, proceed to [wiki:GENIExperimenter/Tutorials/OpenFlowShared/Finish]
    396364----
    397365
    398 = [wiki:GENIExperimenter/Tutorials/OpenFlowOVS Introduction] =
    399 = [wiki:GENIExperimenter/Tutorials/OpenFlowOVS/Finish Next:  Finish] =
     366= [wiki:GENIExperimenter/Tutorials/OpenFlowSW/DesignSetup Design and Setup for OVS] =
     367= [wiki:GENIExperimenter/Tutorials/OpenFlowHW/DesignSetup Design and Setup for Hardware Switch] =
     368= [wiki:GENIExperimenter/Tutorials/OpenFlowShared/Finish Next:  Finish] =