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


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

--

Legend:

Unmodified
Added
Removed
Modified
  • GENIExperimenter/Tutorials/OpenFlowNFVFirewall

    v2 v3  
    11= OpenFlow Firewall =
     2!TinyUrl: [http://tinyurl.com/geni-nfv-firewall]
    23''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]
    54
    65{{{
     
    109    <td width="350" valign="top">
    1110<h3 align="left"> <u>Overview: </u> </h3>
    12 In 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>. 
     11In this tutorial you will learn <b> how to build a Firewall for a network 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>. 
    1312<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" />
    1413
     
    8483</table>
    8584}}}
    86 == 3. Test reachability before starting controller ==
    87 === 3.1 Login to your hosts ===
    88 
    89 To 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  {{{
    98 wget http://www.gpolab.bbn.com/experiment-support/NFVApps/ovs-nat-conf.sh ; chmod +x ovs-nat-conf.sh
    99 sudo ./ovs-nat-conf.sh <h1_if> <h2_if> <h3_if> <controller_ip>
    100 }}}
    101 
    102 === 3.1b Configure hosts ===
    103 The 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 
    116 a. First we start a ping from `inside1` to `inside2`, which should work since they are both inside the same LAN.
    117 {{{
    118 host1:~$ ping 10.10.1.2 -c 10
    119 }}}
    120 
    121 b. 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 {{{
    123 host3:~$ ping 10.10.1.2 -c 10
    124 }}}
    125 
    126 c. Similarly, we cannot ping from `insideX` to `outside`.
    127 
    128 d. 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 
    134 You 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      {{{
    137 cd /tmp/ryu/
    138 wget http://www.gpolab.bbn.com/experiment-support/NFVApps/ryu-nat.tar.gz
    139 tar xvfz ryu-nat.tar.gz
    140 }}}
    141 
    142   b. Start the controller on `NAT` host:
    143   {{{
    144 nat:~$ cd /tmp/ryu/; ./bin/ryu-manager ryu-nat.py
    145 }}}
    146 You should see output similar to following log after the switch is connected to the controller
    147 {{{
    148 loading app ryu-nat.py
    149 loading app ryu.controller.dpset
    150 loading app ryu.controller.ofp_handler
    151 instantiating app ryu.controller.dpset of DPSet
    152 instantiating app ryu.controller.ofp_handler of OFPHandler
    153 instantiating app ryu-nat.py of NAT
    154 switch connected <ryu.controller.controller.Datapath object at 0x2185210>
    155 }}}
    156 
    157   c. On `outside`, we start a nc server:
    158 {{{
    159 host3:~$ nc -l 6666
    160 }}}
    161 and we start a nc client on `inside1` to connect it:
    162 {{{
    163 host1:~$ 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 {{{
    170 Created mapping 192.168.0.3 31596 to 128.128.128.100 59997
    171 }}}
    172 Note 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 
    178 You 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 
    180 However, it will work if we can access the translation table on the switch.
    181 
    182 a. Look back into the log we got previously:
    183 {{{
    184 Created mapping 192.168.0.3 31596 to 128.128.128.100 59997
    185 }}}
    186 Now we know there is mapping between these two pairs.
    187 
    188 b. Now we start a nc server on `inside2` (`inside1` if your mapping shows 192.168.0.2) on the according port:
    189 {{{
    190 inside2:~$ nc -l 31596
    191 }}}
    192 
    193 c. Then on `outside`, we start a nc client:
    194 {{{
    195 outside:~$ nc 128.128.128.1 59997
    196 }}}
    197 
    198 d. `outside` and `inside2` should be able to send messages to each other.
    199 
    200 e. 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 ==
    204 One 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 ===
    207 As 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 ===
    210 Handling 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 
    212 a. On `inside1`, start a ping to `outside`.
    213 {{{
    214 host1:~$ ping 128.128.128.128
    215 }}}
    216 
    217 b. Do the same thing on `host2`.
    218 {{{
    219 host2:~$ ping 128.128.128.128
    220 }}}
    221 
    222 You should see both pinging are working.
    223 
    224 c. On `host3`, use `tcpdump` to check the packets it receives.
    225 {{{
    226 host3:~$ sudo tcpdump -i eth1 -n icmp
    227 }}}
    228 
    229 You should see it's receiving two groups of icmp packets, differentiated by id.
     85{{{
     86#!html
     87
     88
     89
     90
     91            <table border="0">
     92              <tr>
     93                <td >
     94                 <ol type="a">
     95            <li>Log into <tt>switch</tt> and run the following commands to download and run the firewall controller:
     96<pre>
     97sudo apt-get install python-pip python-dev libxml2-dev libxslt-dev zlib1g-dev
     98sudo pip install oslo.config
     99</pre>
     100</li>
     101<li>
     102Run a simple learning switch controller:
     103<pre>
     104cd /tmp/ryu
     105./bin/ryu-manager --verbose ryu/app/simple_switch.py
     106</pre>
     107</li>
     108<li> Verify simple connectivity by logging into <tt>right</tt> ping <tt>left</tt>
     109<pre>
     110ping left
     111</pre>
     112Notice the printouts of the ryu simple switch controller.
     113</li>
     114<li>
     115   Stop your controller by Ctrl-c and remove all your flows
     116<pre>
     117sudo ovs-ofctl del-flows br0
     118</pre>
     119<li> Make your switch into a firewall by downloading and running the appropriate Ryu controller:
     120<pre>
     121wget http://www.gpolab.bbn.com/exp/OpenFlowExampleExperiment/ryu/gpo-ryu-firewall.tar.gz
     122tar xvfz gpo-ryu-firewall.tar.gz
     123cd gpo-ryu-firewall/
     124/tmp/ryu/bin/ryu-manager simple_firewall.py
     125</pre>
     126<b> WARNING </b> If at some point your controller prints an error, kill it (ctrc-c) and start it again.
     127 </li>
     128            <li>Log into <tt>right</tt> and run a <tt>nc</tt> server:
     129<pre>
     130nc -l 5001
     131</pre>
     132</li>
     133            <li>Log into <tt>left</tt> and run a <tt>nc</tt> client:
     134<pre>
     135nc 10.10.11.1 5001
     136</pre></li>
     137            <li>Type some text in <tt>left</tt> and it should appear in <tt>right</tt> and vise versa.</li>
     138            <li>In the terminal for <tt>switch</tt> you should see messages about the flow being passed or not:
     139<pre>
     140Extracted rule {'sport': '57430', 'dport': '5001', 'sip': '10.10.10.1', 'dip': '10.10.11.1'}
     141Allow Connection rule {'dport': '5001', 'dip': '10.10.11.1', 'sip': '10.10.10.1', 'sport': 'any'}
     142</pre>
     143</li>
     144            <li><tt>CTRL-C</tt> to kill <tt>nc</tt> in each terminal. </li>
     145            <li>Run a <tt>nc</tt> server on port 5002, then 5003.
     146       <ul>
     147         <li> Compare the observed behavior to the contents of <tt>~/gpo-ryu-firewall/fw.conf</tt>.  <i>Does the behavior match the configuration file?</i>
     148         <li> Stop the Firewall controller and run a simple switch controller. Is there any traffic being blocked now? Don't forget to delete the flows after you stop the controller</li>
     149         <li>  Feel free to modify the configuration file to allow more traffic.</li>
     150      </ul>
     151
     152           </ol>
     153}}}
    230154[[BR]]
    231155{{{