Changes between Version 1 and Version 2 of GENIExperimenter/Tutorials/OpenFlowNFVFirewall


Ignore:
Timestamp:
11/20/15 14:12:29 (6 years ago)
Author:
nriga@bbn.com
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GENIExperimenter/Tutorials/OpenFlowNFVFirewall

    v1 v2  
    11= OpenFlow Firewall =
    2 
    32''This exercise is based on as assignment by [http://groups.geni.net/geni/wiki/GENIEducation/SampleAssignments/OpenFlowFirewallAssignment Sonia Famy, Ethan Blanton and Sriharsha Gangam of Purdue University].''
     3
     4!TinyUrl: [http://tinyurl.com/geni-nfv-nat]
     5
     6{{{
     7#!html
     8<table border="0" >
     9 <tr>
     10    <td width="350" valign="top">
     11<h3 align="left"> <u>Overview: </u> </h3>
     12In this tutorial you will learn <b> how to build a router for a network with a private address space that needs a one-to-many NAT </b> (IP Masquerade) using OpenFlow. We will use the following network topology for this experiment. You will also learn how to <b> take advantage of kernel L3 routing while using OVS </b>. 
     13<img border="0" src="http://www.gpolab.bbn.com/experiment-support/NFVApps/GENI-NFV-NAT.png" alt="route topology"  align="center" width="350" title="nat topology" />
     14
     15</td>
     16 <td> <pre>   </pre> </td>
     17    <td width="350" valign="top">
     18<h3 align="left"> <u>Prerequisites: </u></h3>
     19 For this tutorial you need :
     20   <ul>
     21       <li> <b> access to the <a href="https://portal.geni.net"> GENI Experimenter Portal </a></b> and be a <b> member of a GENI project </b>. <br/>Please see the <a href="http://groups.geni.net/geni/wiki/SignMeUp"> Sign Me Up page for more information. </a></li>
     22       <li> <b>be familiar with reserving resources in GENI based on an rspec</b>. <br/>If you are not familiar you should first do the <a href="http://groups.geni.net/geni/wiki/GENIExperimenter/Tutorials/RunHelloGENI"> Hello GENI </a> or <a href="http://groups.geni.net/geni/wiki/GENIEducation/SampleAssignments/LabZero/Procedure"> Lab Zero </a> </li>
     23       <li>  be familiar with <b><a href="http://groups.geni.net/geni/wiki/HowTo/LoginToNodes" > logging in to GENI resources </a> </b> </li>
     24       <li> be familiar with <b> OpenFlow concepts </b> </li>
     25   </ul>
     26
     27    </td>
     28  </tr>
     29  <tr>
     30    <td width="350" valign="top">
     31<h3 align="left"> <u>Tools: </u></h3>
     32All the tools will already be installed at your nodes. For your reference we are going to use <b>a Ryu controller</b>.
     33     </td>
     34 <td> <pre>   </pre> </td>
     35    <td width="350" valign="top">
     36    <h3 align="left"> <u>Where to get help: </u></h3>
     37      For any questions or problem with the tutorial please email <a href="mailto:geni-users@googlegroups.com?Subject=Help%20with%20HelloGENI%20tutorial"> geni-users@googlegroups.com </a>
     38    </td>
     39  </tr>
     40</table>
     41}}}
     42----
     43
     44{{{
     45#!html
     46<table  border="0" cellpadding="0" cellspacing="0">
     47  <tr>
     48     <td valign="top" align="left">
     49        <img src="http://groups.geni.net/geni/attachment/wiki/GENIExperimenter/Tutorials/Graphics/design.png?format=raw" width="150" alt="Design/Setup"></a>
     50      </td>
     51      <td>
     52         <h3> If you have already reserved the topology from a previous tutorial you can move to Execute. </h3>
     53         <h3><u>1. Verify your Environment Setup: </u></h3>
     54   This exercise assumes you have already setup your account at the GENI Portal. In particular ensure that:
     55   <ol>
     56      <li> You can login to the <a href="https://portal.geni.net"> GENI Portal </a></li>
     57      <li> You are a member of a GENI Project (there is at least one project listed under the <a href="https://portal.geni.net/secure/projects.php">''Projects''</a> tab) </li>
     58      <li> You have setup your ssh keys (there is at least one key listed under the <a href="https://portal.geni.net/secure/profile.php#ssh">''Profile->SSH Keys''</a> tab) </li>
     59    </ol>
     60<h3><u> 2. Setup the Topology: </u></h3>
     61   <ol>
     62      <li> Login to the <a href="https://portal.geni.net"> GENI Portal </a> </li>
     63       <li> Reserve:
     64           <ol type='a'>
     65            <li>  the topology from an InstaGENI rack using the <a href="http://www.gpolab.bbn.com/experiment-support/OpenFlowOVS/openflowovs-all-xen.rspec.xml"> OpenFlow OVS all XEN </a> RSpec (In Portal: "OpenFlow OVS all XEN"; URL: http://www.gpolab.bbn.com/experiment-support/OpenFlowOVS/openflowovs-all-xen.rspec.xml)</li>
     66            <li> at a <b>different InstaGENI rack</b> reserve a <a href="http://www.gpolab.bbn.com/experiment-support/OpenFlowOVS/xen-openflow-controller-rspec.xml"> XEN OpenFlow Controller</a> RSpec (In Portal: "XEN OpenFlow Controller"; URL: http://www.gpolab.bbn.com/experiment-support/OpenFlowOVS/xen-openflow-controller-rspec.xml)</li>
     67    </ol>         
     68          </td>
     69       </tr>
     70</table>
     71}}}
     72
     73[[BR]]
     74
     75{{{
     76#!html
     77<table  border="0" cellpadding="0" cellspacing="0">
     78  <tr>
     79     <td valign="top" align="left">
     80        <img src="http://groups.geni.net/geni/attachment/wiki/GENIExperimenter/Tutorials/Graphics/execute.png?format=raw" height="150" alt="Execute"></a>
     81      </td>
     82      <td>
     83 </tr>
     84</table>
     85}}}
     86== 3. Test reachability before starting controller ==
     87=== 3.1 Login to your hosts ===
     88
     89To start our experiment we need to ssh into all the hosts (controller, ovs, host1, host2, 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 take a look in [wiki:HowTo/LoginToNodes this page.] Once you have logged in, follow the rest of the instructions.
     90
     91=== 3.1a Configure OVS ===
     92 i. Write down the interface names that correspond to the connections to your hosts (use ifconfig). The correspondence is:
     93       * '''h1_if''': Interface with IP ''10.10.1.11'' to host1  - ethX
     94       * '''h2_if''': Interface with IP ''10.10.1.12'' to host2 - ethY
     95       *  '''h3_if''': Interface with IP ''10.10.1.13'' to host3 - ethZ
     96 ii. In the OVS node run:
     97 {{{
     98wget http://www.gpolab.bbn.com/experiment-support/NFVApps/ovs-nat-conf.sh ; chmod +x ovs-nat-conf.sh
     99sudo ./ovs-nat-conf.sh <h1_if> <h2_if> <h3_if> <controller_ip>
     100}}}
     101
     102=== 3.1b Configure hosts ===
     103The hosts in your topology are all in the same subnet, 10.10.1.0/24. We will move host3 to a different subnet:
     104  i. '''host3''': Assign 128.128.128.128 to host3.
     105  {{{
     106   sudo ifconfig eth1 128.128.128.128/24
     107}}}
     108
     109  ii. '''host1, host2''': Setup routes at `host1` and `host1` to 128.128.128.0/24 subnet:
     110  {{{
     111   sudo route add -net 128.128.128.0 netmask 255.255.255.0 gw 10.10.1.100
     112}}}
     113
     114=== 3.2 Test reachability ===
     115
     116a. First we start a ping from `inside1` to `inside2`, which should work since they are both inside the same LAN.
     117{{{
     118host1:~$ ping 10.10.1.2 -c 10
     119}}}
     120
     121b. Then we start a ping from `outside` to `inside1`, which should timeout as there is no routing information in its routing table. You can use `route -n` to verify that.
     122{{{
     123host3:~$ ping 10.10.1.2 -c 10
     124}}}
     125
     126c. Similarly, we cannot ping from `insideX` to `outside`.
     127
     128d. You can also use Netcat (`nc`) to test reachability of TCP and UDP. The behavior should be the same.
     129
     130== 4 Start controller to enable NAT ==
     131
     132=== 4.1 Access a server from behind the NAT ===
     133
     134You can try to write your own controller to implement NAT. However, we a provide you a functional controller.
     135  a. Download the NAT Ryu module. At your controller node run:
     136     {{{
     137cd /tmp/ryu/
     138wget http://www.gpolab.bbn.com/experiment-support/NFVApps/ryu-nat.tar.gz
     139tar xvfz ryu-nat.tar.gz
     140}}}
     141
     142  b. Start the controller on `NAT` host:
     143  {{{
     144nat:~$ cd /tmp/ryu/; ./bin/ryu-manager ryu-nat.py
     145}}}
     146You should see output similar to following log after the switch is connected to the controller
     147{{{
     148loading app ryu-nat.py
     149loading app ryu.controller.dpset
     150loading app ryu.controller.ofp_handler
     151instantiating app ryu.controller.dpset of DPSet
     152instantiating app ryu.controller.ofp_handler of OFPHandler
     153instantiating app ryu-nat.py of NAT
     154switch connected <ryu.controller.controller.Datapath object at 0x2185210>
     155}}}
     156
     157  c. On `outside`, we start a nc server:
     158{{{
     159host3:~$ nc -l 6666
     160}}}
     161and we start a nc client on `inside1` to connect it:
     162{{{
     163host1:~$ nc 128.128.128.2 6666
     164}}}
     165
     166  d. Now send message between each other and try the same thing between `host3` and `host2`.
     167
     168  e. On the terminal of `controller`, in which you started your controller, you should see a log similar to:
     169{{{
     170Created mapping 192.168.0.3 31596 to 128.128.128.100 59997
     171}}}
     172Note that there should be only one log per connection, because the rest of the communication will re-use the mapping.
     173
     174{{{
     175#!comment
     176=== 4.2 Outside source ===
     177
     178You may be wondering whether it will behave the same if we use `insideX` hosts to be the nc server. You can try it and the answer is no. That's due to the nature of dynamic NAT.
     179
     180However, it will work if we can access the translation table on the switch.
     181
     182a. Look back into the log we got previously:
     183{{{
     184Created mapping 192.168.0.3 31596 to 128.128.128.100 59997
     185}}}
     186Now we know there is mapping between these two pairs.
     187
     188b. Now we start a nc server on `inside2` (`inside1` if your mapping shows 192.168.0.2) on the according port:
     189{{{
     190inside2:~$ nc -l 31596
     191}}}
     192
     193c. Then on `outside`, we start a nc client:
     194{{{
     195outside:~$ nc 128.128.128.1 59997
     196}}}
     197
     198d. `outside` and `inside2` should be able to send messages to each other.
     199
     200e. Common solution of handling outside source is providing some way to manually create mapping in advance. We will leave it as an exercise for you to implement it.
     201}}}
     202
     203== 5 Handle ARP and ICMP ==
     204One of very common mistakes that people make, when writing OF controller, is forgetting to handle ARP and ICMP message and finding their controller does not work as expected.
     205
     206=== 5.1 ARP ===
     207As we mentioned before, we should insert rules into the OF switch that allow ARP packets to go through, probably after the switch is connected.
     208
     209=== 5.2 ICMP ===
     210Handling ARP is trivial as NAT does not involve ARP. However, it's not the case for ICMP. If you only process translation for TCP/UDP, you will find you cannot ping between `outside` and `insideX` while nc is working properly. Handling ICMP is even not as straightforward as for TCP/UDP. Because for ICMP, you cannot get port information to bind with. Our provided solution makes use of ICMP echo identifier. You may come up with different approach involves ICMP sequence number or others.
     211
     212a. On `inside1`, start a ping to `outside`.
     213{{{
     214host1:~$ ping 128.128.128.128
     215}}}
     216
     217b. Do the same thing on `host2`.
     218{{{
     219host2:~$ ping 128.128.128.128
     220}}}
     221
     222You should see both pinging are working.
     223
     224c. On `host3`, use `tcpdump` to check the packets it receives.
     225{{{
     226host3:~$ sudo tcpdump -i eth1 -n icmp
     227}}}
     228
     229You should see it's receiving two groups of icmp packets, differentiated by id.
     230[[BR]]
     231{{{
     232#!html
     233<table  border="0" cellpadding="0" cellspacing="0">
     234  <tr>
     235     <td valign="top" align="left">
     236        <img src="http://groups.geni.net/geni/attachment/wiki/GENIExperimenter/Tutorials/Graphics/finish.png?format=raw"  width="150" alt="Finish"></a>
     237      </td>
     238       <td>
     239             
     240               <h3><u> 6. Cleanup </u></h3>
     241           After you are done with the exercise and you have captured everything requested for the writeup, you should release your resources so that other experimenters can use
     242them. In order to cleanup your slice :
     243              <ol type="a">
     244                 <li>In Flack, press the <b>Delete</b> button in the bottom of your canvas </li>
     245                 <li> Select <b>Delete at used managers</b> and <b>confirm</b> your selection. </li>
     246              </ol>
     247Wait and after a few moments all the resources will have been released and you will have an empty canvas again. Notice that your slice is still there. There is no way to delete a slice, it will be removed automatically after its expiration date, but remember that a slice is just an empty container so it doesn't take up any resources.
     248                             
     249          </td>
     250       </tr>
     251</table>
     252}}}
     253----
     254
     255[[Image(GENIExperimenter/Tutorials/Graphics:tip.png, 40, left)]]
     256= Tips =
     257  * Remember that you can use “ifconfig” to determine which Ethernet interface (e.g., eth0) is bound to what IP address at each of the nodes.
     258  * In order to enable IP forwarding of packets on a node you have to execute the following command:
     259  {{{
     260sudo sh -c 'echo 1 > /proc/sys/net/ipv4/ip_forward'
     261}}}
     262
    4263
    5264For this experiment we will run an !OpenFlow Firewall.