Changes between Initial Version and Version 1 of JoeSandbox/OpenFlowNATTremaExample/Execute


Ignore:
Timestamp:
08/13/14 18:30:59 (10 years ago)
Author:
zwang@bbn.com
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • JoeSandbox/OpenFlowNATTremaExample/Execute

    v1 v1  
     1= [wiki:JoeSandbox/OpenFlowNATTremaExample OpenFlow NAT using Trema Example] =
     2{{{
     3#!html
     4<table border="0">
     5   
     6      <tr>
     7         <td>
     8         <a href="http://groups.geni.net/geni/wiki/JoeSandbox/OpenFlowNATTremaExample/DesignSetup"> <img border="0" src="http://groups.geni.net/geni/attachment/wiki/GENIExperimenter/Tutorials/Graphics/design.2.png?format=raw" alt="Hello GENI index"  height="90" title="Hello GENI Web server" />  </a>
     9       </td>
     10       <td>
     11         <a href="http://groups.geni.net/geni/wiki/JoeSandbox/OpenFlowNATTremaExample/Execute"> <img border="0" src="http://groups.geni.net/geni/attachment/wiki/GENIExperimenter/Tutorials/Graphics/execute_on.2.png?format=raw" alt="Hello GENI index"  height="90" title="Hello GENI Web server" />  </a>
     12       </td>
     13       <td>
     14         <a href="http://groups.geni.net/geni/wiki/JoeSandbox/OpenFlowNATTremaExample/Finish"> <img border="0" src="http://groups.geni.net/geni/attachment/wiki/GENIExperimenter/Tutorials/Graphics/finish.2.png?format=raw" alt="Hello GENI index"  height="90" title="Hello GENI Web server" />  </a>
     15       </td>
     16     </tr>
     17 </table>
     18}}}
     19
     20= STEPS FOR EXECUTING EXAMPLE =
     21
     22In this section, we are going to build a router for a private address space that needs one-to-many NAT (IP Masquerade) for some reason (e.g. short on public IP or security) using OpenFlow. As shown in the figure below, hosts `inside1` and `inside2` are inside the LAN, while host `outside` is outside. The LAN has only one public IP — '''128.128.129.1'''. (The external IPs we use, 128.128.128.0/24 and 128.128.129.0/24, are just an example. If your public IP happens to be in this subnet, change them to others.)
     23
     24[[Image(openflow-nat.png, 50%, nolink)]] 
     25== 1 Test reachability before starting controller ==
     26=== 1.1 Login to your hosts ===
     27
     28To 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.
     29
     30=== 1.2 Test reachability ===
     31
     32a. First we start a ping from `inside1` to `inside2`, which should also work since they are inside the same LAN.
     33{{{
     34inside1:~$ ping 192.168.0.3 -c 10
     35}}}
     36
     37b. Then we start a ping from `outside` to `inside1`, which should timeout as no according routing information in its routing table. You can use `route -n` to verify that.
     38{{{
     39outside:~$ ping 192.168.0.2 -c 10
     40}}}
     41
     42c. Similarly, we cannot ping from `insideX` to `outside`.
     43
     44d. You can also use Netcat(nc) to test reachability of TCP and UDP. The behavior should be the same.
     45
     46== 2 Start controller to enable NAT ==
     47
     48=== 2.1 Inside source ===
     49'''We definitely need a better naming for this one'''
     50
     51You can try to write your own controller to implement NAT. However, we've provided you a functional controller, which is a file called nat.rb under /tmp/ .
     52
     53a. Start the controller on `switch` host:
     54{{{
     55switch:~$ trema run /tmp/nat.rb
     56}}}
     57You should see following log after the switch is connected to the controller
     58{{{
     59rule added to switch for arp and ipv6 pkt: send normally
     60}}}
     61which means we ask the switch to forward ARP and Ipv6 packets normally, and only perform NAT for TCP, UDP and ICMP.
     62
     63b. On `outside`, we start a nc server:
     64{{{
     65outside:~$ nc -l 6666
     66}}}
     67and we start a nc client on `inside1` to connect it:
     68{{{
     69inside1:~$ nc 128.128.128.2 6666
     70}}}
     71
     72c. Now send message between each other and try the same thing between `outside` and `inside2`.
     73
     74d. On the terminal of `switch`, in which you started your controller, you should see a log similar to:
     75{{{
     76Created mapping 192.168.0.3 31596 to 128.128.129.1 59997
     77}}}
     78Note that there should be only one log per connection, because the rest of the communication will re-use the mapping.
     79
     80=== 2.2 Outside source ===
     81
     82'''I know you hate this part. I'm just putting it here because this example is too short.'''
     83
     84You 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.
     85
     86However, it will work if we can access the translation table on the switch.
     87
     88a. Look back into the log we got previously:
     89{{{
     90Created mapping 192.168.0.3 31596 to 128.128.129.1 59997
     91}}}
     92Now we know there is mapping between these two pairs.
     93
     94b. Now we start a nc server on `inside2` (`inside1` if your mapping shows 192.168.0.2) on the according port:
     95{{{
     96inside2:~$ nc -l 31596
     97}}}
     98
     99c. Then on `outside`, we start a nc client:
     100{{{
     101outside:~$ nc 128.128.128.1 59997
     102}}}
     103
     104d. `outside` and `inside2` should be able to send messages to each other.
     105
     106e. 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.
     107
     108== 3 Handle ARP and ICMP ==
     109One 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.
     110
     111=== 3.1 ARP ===
     112As we mentioned before, we should insert rules into the OF switch that allow ARP packets to go through, probably after the switch is connected (see event handler '''switch_ready''').
     113
     114=== 3.2 ICMP ===
     115Handling 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.
     116
     117a. On `inside1`, start a ping to `outside`.
     118{{{
     119inside1:~$ ping 128.128.128.2
     120}}}
     121
     122b. Do the same thing on `inside2`.
     123{{{
     124inside2:~$ ping 128.128.128.2
     125}}}
     126
     127You should see both pinging are working.
     128
     129c. On `outside`, use `tcpdump` to check the packets it receives.
     130{{{
     131outside:~$ sudo tcpdump -i eth1
     132}}}
     133
     134You should see it's receiving two groups of icmp packets, differentiated by icmp_id.
     135
     136d.
     137Note that, again, you cannot start the ping from the outside, similar to TCP/UDP. The common solution is to manually map the ping destination to a specific inside IP in advance. We will leave it as an exercise for you to implement it, as well.
     138
     139
     140
     141
     142
     143
     144
     145
     146= [wiki:JoeSandbox/OpenFlowNATTremaExample/Finish Next: Teardown Experiment] =