Changes between Version 2 and Version 3 of JoeSandbox/OpenFlowNATExample/Execute


Ignore:
Timestamp:
08/27/14 13:41:55 (10 years ago)
Author:
zwang@bbn.com
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • JoeSandbox/OpenFlowNATExample/Execute

    v2 v3  
    2020= STEPS FOR EXECUTING EXAMPLE =
    2121
    22 In 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.)
     22In this section, we are going to build a router for a network with a private address space that needs a one-to-many NAT (IP Masquerade) for some reason (e.g. short on public IP space or security) using OpenFlow. As shown in the figure below, hosts `inside1` and `inside2` are part of the private network, 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.)
    2323
    2424[[Image(openflow-nat.png, 50%, nolink)]] 
     
    2626=== 1.1 Login to your hosts ===
    2727
    28 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.
     28To start our experiment we need to ssh into 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.
    2929
    3030=== 1.2 Test reachability ===
    3131
    32 a. First we start a ping from `inside1` to `inside2`, which should also work since they are inside the same LAN.
     32a. First we start a ping from `inside1` to `inside2`, which should work since they are both inside the same LAN.
    3333{{{
    3434inside1:~$ ping 192.168.0.3 -c 10
    3535}}}
    3636
    37 b. 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.
     37b. 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.
    3838{{{
    3939outside:~$ ping 192.168.0.2 -c 10
     
    4242c. Similarly, we cannot ping from `insideX` to `outside`.
    4343
    44 d. You can also use Netcat(nc) to test reachability of TCP and UDP. The behavior should be the same.
     44d. You can also use Netcat (`nc`) to test reachability of TCP and UDP. The behavior should be the same.
    4545
    4646== 2 Start controller to enable NAT ==
    4747
    48 === 2.1 Inside source ===
    49 '''We definitely need a better naming for this one'''
     48=== 2.1 Access a server from behind the NAT ===
    5049
    51 You can try to write your own controller to implement NAT. However, we've provided you a functional controller, which is a file called nat.py under /tmp/ryu/ .
     50You can try to write your own controller to implement NAT. However, we've provided you a functional controller, which is a file called `nat.py` under `/tmp/ryu/` .
    5251
    53 a. Start the controller on `switch` host:
     52a. Start the controller on `NAT` host:
    5453{{{
    55 switch:~$ cd /tmp/ryu/
    56 switch:~$ PYTHONPATH=. ./bin/ryu-manager nat.py
     54nat:~$ cd /tmp/ryu/
     55nat:~$ ./bin/ryu-manager nat.py
    5756}}}
    5857You should see output similar to following log after the switch is connected to the controller
     
    6665switch connected <ryu.controller.controller.Datapath object at 0x2185210>
    6766}}}
    68 which means we ask the switch to forward ARP and Ipv6 packets normally, and only perform NAT for TCP, UDP and ICMP.
     67
    6968
    7069b. On `outside`, we start a nc server:
     
    8584Note that there should be only one log per connection, because the rest of the communication will re-use the mapping.
    8685
     86{{{
     87#!comment
    8788=== 2.2 Outside source ===
    88 
    89 '''I know you hate this part. I'm just putting it here because this example is too short.'''
    9089
    9190You 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.
     
    112111
    113112e. 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.
     113}}}
    114114
    115 == 3 Handle ARP and ICMP ==
     115== 2 Handle ARP and ICMP ==
    116116One 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.
    117117
    118 === 3.1 ARP ===
     118=== 2.1 ARP ===
    119119As we mentioned before, we should insert rules into the OF switch that allow ARP packets to go through, probably after the switch is connected.
    120120
    121 === 3.2 ICMP ===
     121=== 2.2 ICMP ===
    122122Handling 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.
    123123
     
    141141You should see it's receiving two groups of icmp packets, differentiated by icmp_id.
    142142
     143{{{
     144#!comment
    143145d.
    144146Note 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.
    145 
     147}}}
    146148
    147149