Changes between Initial Version and Version 1 of GENIExperimenter/Tutorials/NFV/Pox/Design


Ignore:
Timestamp:
05/31/17 14:15:10 (7 years ago)
Author:
Nabeel Akhtar
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GENIExperimenter/Tutorials/NFV/Pox/Design

    v1 v1  
     1= [http://groups.geni.net/geni/wiki/GENIExperimenter/Tutorials/NFV NFV Tutorial: Managing a Virtual Network Function using SDN and Control Theory] =
     2
     3{{{
     4#!html
     5
     6<div style="text-align:center; width:495px; margin-left:auto; margin-right:auto;">
     7<img id="Image-Maps_5201305222028436" src="http://groups.geni.net/geni/attachment/wiki/GENIExperimenter/Tutorials/Graphics/Setup.jpg?format=raw" usemap="#Image-Maps_5201305222028436" border="0" width="495" height="138" alt="" />
     8<map id="_Image-Maps_5201305222028436" name="Image-Maps_5201305222028436">
     9<area shape="rect" coords="18,18,135,110" href="http://groups.geni.net/geni/wiki/GENIExperimenter/Tutorials/NFV/DesignSetup" alt="" title=""    />
     10<area shape="rect" coords="180,18,297,111" href="http://groups.geni.net/geni/wiki/GENIExperimenter/Tutorials/NFV/Execute" alt="" title=""    />
     11<area shape="rect" coords="344,17,460,110" href="http://groups.geni.net/geni/wiki/GENIExperimenter/Tutorials/NFV/Finish" alt="" title=""    />
     12<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" />
     13</map>
     14<!-- Image map text links - End - -->
     15
     16</div>
     17}}}
     18
     19= Part I: !Design/Setup =
     20
     21== 1.  Design the Experiment ==
     22 [[Image(http://csr.bu.edu/rina/grw-bu2016/tutorial_files/image012.gif)]] [[BR]]
     23The basic topology of the tutorial is shown above. We have two ''sources'' that will communicate with the ''destination'' via an OVS switch. We have two VMs (VNF1 and VNF2) running instances of the Snort Intrusion Detection System (IDS), representing the Virtual Network Function (VNF). In this tutorial, we will install forwarding rules in the OVS using a ''controller'' such that whenever a ''source'' sends packets to the ''destination'', a copy of each packet is also sent to one of the IDS for intrusion detection analysis.
     24
     25''Iperf'' will be run as an application and we will observe the operation and impact of different strategies for load balancing across the IDS instances.
     26
     27Though in this tutorial, we will be using Snort IDS as an example VNF, one can consider other  network functions, e.g., a firewall, a caching (proxy) server, etc.
     28
     29== 2.  Establish the environment ==
     30'''2.1. Pre-work:''' (Skip this section if you have already established your environment for your project.)
     31
     32  -      Ensure SSH keys are setup. If your SSH keys are not setup before, do the following steps: [[BR]]
     33   -      Generate an SSH Private Key on the ''Profile'' page on the GENI portal  [[BR]]
     34   -      ''Download the Private Key to ~/Downloads'' [[BR]]
     35   -      ''Open terminal and execute''  [[BR]]
     36    ''$ mv ~/Downloads/id_geni_ssh_rsa ~/.ssh/. '' [[BR]]
     37    ''$ chmod 0600 ~/.ssh/id_geni_ssh_rsa''  [[BR]]
     38    ''$ ssh-add ~/.ssh/id_geni_ssh_rsa''  [[BR]]
     39 
     40
     41  -      Ensure you are part of a project. [[BR]]
     42 
     43== 3.  Obtain Resources  ==
     44For this tutorial, you can use resources from any aggregate in GENI, but preferably an instaGENI aggregate (e.g., CENIC IG or Cornell IG). The experiment will need the following:
     45
     46-      1 Xen VM for the !OpenFlow controller with a public IP (''controller'') [[BR]]
     47-      1 Xen VM for the !OpenFlow virtual switch (''OVS'') [[BR]]
     48-      3 Xen VMs, two Sources and one Destination (''S1'', ''S2'' and ''destination'') [[BR]]
     49-      2 Xen VMs for two Virtual Network Function instances (VNF1 and VNF2) [[BR]]
     50 
     51We will need two slices for this tutorial: [[BR]]
     52
     531. A Slice for the !OpenFlow controller. [[BR]]
     542. A Slice for the Network consisting of sources, destination, IDSes and OVS. [[BR]]
     55
     56To reserve resources, use the GENI portal.
     57
     58
     59'''3.1. Controller'''
     60  -      Open the slice that will run the !OpenFlow controller. You may call it 'Controller-xx', with xx replaced with your initials or last name. Select a VM  running the controller using the RSpec that is available in the portal called '''XEN !OpenFlow Controller'''. This is shown in the picture below.
     61 
     62{{{
     63#!html
     64<img src="http://csr.bu.edu/rina/grw-bu2016/tutorial_files/image016.gif" hspace=100>
     65}}}
     66
     67  -      Choose any InstaGENI aggregate (e.g. CENIC or Cornell IG) and reserve resources for the ''controller''. You will see the controller VM as shown below.
     68
     69{{{
     70#!html
     71<img src="http://csr.bu.edu/rina/grw-bu2016/tutorial_files/image018.gif" hspace=100>
     72}}}
     73
     74
     75'''3.2. Network'''
     76  Create a new slice 'Network-xx', with xx replaced by your initials or last name, for a network whose topology will consist of two sources, a destination, an OVS and two VNFs. Use [http://csr.bu.edu/rina/grw-bu2016/nfv/Network_with_NFVimage.xml this given Rspec] to reserve resources for this Network slice.
     77
     78
     79  Although you can choose any InstaGENI aggregate to reserve resources for the Network slice, for this tutorial, it is simpler (and more effective!) to just use the same IG aggregate as the one used for your Controller slice. You will have a network of 6 VMs as shown below. This may take a while!
     80
     81{{{
     82#!html
     83<img src="http://csr.bu.edu/rina/grw-bu2016/tutorial_files/image020.gif" hspace=100>
     84}}}
     85
     86'''3.3. Configure and Initialize '''
     87
     88  Although OVS is installed on the host and is meant to act as a software switch, it still needs to be configured. There are two things that need to be configured:
     89
     90   ''(1) configure your software switch with the interfaces as ports'' and [[BR]]
     91   ''(2) point the switch to the OpenFlow controller.''
     92
     93'''3.3.1. Configure the Software Switch (OVS Window): '''
     94  1.     Login to the OVS host (on the Network slice)
     95  2.     Create an Ethernet bridge that will act as our software switch: [[BR]]
     96      {{{
     97#!html
     98  <span style="background:#c0c0c0; font-size: 9pt"><b>sudo ovs-vsctl add-br br0 </b>
     99 </span>
     100}}}
     101  3.     Prepare the interfaces to be added as ports to the OVS switch [[BR]]
     102  Your OVS bridge will be a Layer 2 switch and your ports do not need IP addresses. Before we remove them let's keep some information
     103   -      Run
     104   {{{
     105#!html 
     106  <span style="background:#c0c0c0; font-size: 9pt" ><b> ifconfig </b>
     107  </span>  on ovs node
     108}}}   
     109   -      Write down the interface names that correspond to the connections to your VNF1 and VNF2 hosts. The correspondence is
     110     *   Interface with IP 10.10.1.13 to VNF1 - eth'''X'''
     111     *   Interface with IP 10.10.1.14 to VNF2 – eth'''Y'''
     112
     113       {{{
     114#!html
     115<table id="Table_02" width = "1150" border="0" cellpadding="0" cellspacing="10" align="center" >
     116 <tr>
     117<td> <img src = "http://csr.bu.edu/rina/grw-bu2016/tutorial_files/image022.gif"> </td>
     118<td> <i>Make sure you have noted the names of the interfaces before you proceed. We will need the interface names to run experiments. (Otherwise, you have to figure out later which OVS interface is connected to each host by pinging from, say, one source to each VNF, after running "sudo tcpdump -i ethX" on each OVS interface.)</i> </td> </tr></table>
     119}}}
     120 
     121  4.     Prepare the interfaces to be added as ports to the OVS switch.
     122   -      Your OVS bridge will be a Layer 2 switch and your ports do not need IP addresses. Remove the IP from your data interfaces. [[BR]]
     123           {{{
     124#!html
     125    &nbsp;&nbsp;&nbsp;<span style="background:#c0c0c0; font-size: 9pt"><b>sudo ifconfig eth1 0 <br></b> </span>
     126    &nbsp;&nbsp;&nbsp;<span style="background:#c0c0c0; font-size: 9pt"><b>sudo ifconfig eth2 0 <br></b> </span>
     127    &nbsp;&nbsp;&nbsp;<span style="background:#c0c0c0; font-size: 9pt"><b>sudo ifconfig eth3 0 <br></b> </span>
     128    &nbsp;&nbsp;&nbsp;<span style="background:#c0c0c0; font-size: 9pt"><b>sudo ifconfig eth4 0 <br></b> </span>
     129    &nbsp;&nbsp;&nbsp;<span style="background:#c0c0c0; font-size: 9pt"><b>sudo ifconfig eth5 0 <br></b> </span>
     130}}}
     131
     132      {{{
     133#!html
     134<table id="Table_02" width = "1100" border="0" cellpadding="0" cellspacing="10" align="center">
     135 <tr>
     136<td> <img src = "http://csr.bu.edu/rina/grw-bu2016/tutorial_files/image022.gif"> </td>
     137<td> <i><B>Be careful not to bring down eth0.</b> 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, remove the IP from the interfaces (your interface names may vary).
     138
     139</i> </td> </tr></table>
     140}}}
     141
     142  Add all the data interfaces to your switch (bridge): Be careful not to add interface eth0. This is the control interface. The other four interfaces are your data interfaces. (Use the same interfaces as you used in the previous step).
     143          {{{
     144#!html
     145    &nbsp;&nbsp;&nbsp;<span style="background:#c0c0c0; font-size: 9pt"><b>sudo ovs-vsctl add-port br0 eth1 <br></b> </span>
     146    &nbsp;&nbsp;&nbsp;<span style="background:#c0c0c0; font-size: 9pt"><b>sudo ovs-vsctl add-port br0 eth2  <br></b> </span>
     147    &nbsp;&nbsp;&nbsp;<span style="background:#c0c0c0; font-size: 9pt"><b>sudo ovs-vsctl add-port br0 eth3  <br></b> </span>
     148    &nbsp;&nbsp;&nbsp;<span style="background:#c0c0c0; font-size: 9pt"><b>sudo ovs-vsctl add-port br0 eth4  <br></b> </span>
     149    &nbsp;&nbsp;&nbsp;<span style="background:#c0c0c0; font-size: 9pt"><b>sudo ovs-vsctl add-port br0 eth5  <br></b> </span>
     150}}}
     151  Now the software switch is configured! To verify that the five ports are configured, run the following command to see all five ports listed:
     152
     153     {{{
     154#!html
     155    &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="background:#c0c0c0; font-size: 9pt"><b>sudo ovs-vsctl list-ports br0 <br></b> </span>
     156
     157}}}
     158
     159'''3.3.2. Point your switch to a controller'''
     160      {{{
     161#!html
     162<table id="Table_02" width = "1100" border="0" cellpadding="0" cellspacing="10" align="center">
     163 <tr>
     164<td> <img src = "http://csr.bu.edu/rina/grw-bu2016/tutorial_files/image026.gif"> </td>
     165<td> <i>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.
     166
     167</i> </td> </tr></table>
     168}}}
     169
     170 1.     Login to your controller
     171 2.     Find the control interface IP of your controller, use ''ifconfig'' and note down the IP address of eth0.
     172 3.     In order to point our software !OpenFlow switch to the controller, in the ''ovs'' terminal window, run:
     173
     174 {{{
     175#!html 
     176  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="background:#c0c0c0; font-size: 9pt" ><b> sudo ovs-vsctl set-controller br0 tcp:&lt;controller_ip &gt;:6633 </b>
     177  </span> 
     178 }}}   
     179
     180 4.     Set your switch's fail-safe-mode to secure. For more info read the [wiki:GENIExperimenter/Tutorials/OpenFlowOVS/DesignSetup#standalonevssecuremode standalone vs secure mode section]. Run:
     181
     182 {{{
     183#!html 
     184  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="background:#c0c0c0; font-size: 9pt" ><b> sudo ovs-vsctl set-fail-mode br0 secure </b>
     185  </span> 
     186 }}}
     187
     188 5.     Trust but verify. You can verify your OVS settings by issuing the following:
     189
     190 {{{
     191#!html 
     192  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="background:#c0c0c0; font-size: 9pt" ><b> sudo ovs-vsctl show </b>
     193  </span> 
     194 }}}
     195
     196    {{{
     197#!html
     198<table id="Table_02" width = "1100" border="0" cellpadding="10" cellspacing="0" align="center" style="margin:0" >
     199 <tr>
     200<td> <img src = "http://csr.bu.edu/rina/grw-bu2016/tutorial_files/image026.gif"> </td>
     201<td> <i><b> Standalone vs Secure mode </b><br>
     202
     203The 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:
     204
     205</i> </td> </tr>
     206</table>
     207<ul style="list-style-type:circle; margin-left:50px">
     208 <li> standalone <i>[default]: in this case OVS will take responsibility for forwarding the packets if the controller fails</i></li>
     209<li> secure: <i> in this case only the controller is responsible for forwarding packets, and if the controller is down all packets are dropped.</i></li>
     210</ul>
     211}}}
     212 ''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.''
     213
     214== [wiki:GENIExperimenter/Tutorials/NFV/Execute Next: Execute] ==
     215
     216
     217
     218----
     219Author: Nabeel Akhtar
     220
     221Supervised by: Ibrahim Matta
     222
     223Boston University