Changes between Version 6 and Version 7 of GENIExperimenter/Tutorials/WiMAXOpenFlow/Design-Setup


Ignore:
Timestamp:
10/27/13 10:04:46 (8 years ago)
Author:
Ryan Izard
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GENIExperimenter/Tutorials/WiMAXOpenFlow/Design-Setup

    v6 v7  
    5555   {{{
    5656   $ ifconfig wmx0
    57       wmx0      Link encap:Ethernet  HWaddr 00:0c:29:04:5c:41 
     57      wmx0      Link encap:Ethernet  HWaddr '''00:0c:29:04:5c:41''' 
    5858          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
    5959          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
    6060          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
    6161          collisions:0 txqueuelen:1000
    62           RX bytes:0 (8.3 KiB)  TX bytes:0 (6.1 KiB)
     62          RX bytes:0 (0 KiB)  TX bytes:0 (0 KiB)
    6363          Interrupt:18 Base address:0x1424
    6464   $ ifconfig wlan1
    65       wlan1      Link encap:Ethernet  HWaddr 00:0c:29:04:5c:4b 
     65      wlan1      Link encap:Ethernet  HWaddr '''00:0c:29:04:5c:4b''' 
    6666          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
    6767          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
    6868          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
    6969          collisions:0 txqueuelen:1000
    70           RX bytes:0 (31.0 KiB)  TX bytes:0 (5.1 KiB)
     70          RX bytes:0 (0 KiB)  TX bytes:0 (0 KiB)
    7171          Interrupt:19 Base address:0x14a4
    7272   }}}
    7373   4. Also in the client, customize the setup script '''gec18_setup.sh''' in /root/StartupScripts. This script is designed to (1) define user variables, (2) configure the tap interface with OpenVPN, (3) start Floodlight, (4) initialize and start OpenVswitch, and (5) configure Linux networking.
    74 
    75      
    76       Note the subnets and names given to each of the network interfaces. Recall, when the VM was initialized, we configured 1 NAT interface and 2 host-only interfaces. The two interfaces on the same subnet are the host-only interfaces. Make notes of each interface name and its IP and subnet mask.
    77       c.  With this information, to the setup script directory:
    78       {{{
    79       $ cd /root/06-03-13
    80       $ ls
    81       ... system_setup.sh ...
    82       }}}
    83       d.  Open the script with the text editor of your choice (vi, gedit, pico, nano, etc):
    84       {{{
    85       $ gedit system_setup.sh
    86       }}}
    87       e.  There are numerous user defined variables at the top of the script. These are placeholders for commonly used system and configuration specific information throughout the script. We need to change a few of them to suit our needs for this tutorial. Modify the physical interface names for '''IFACE_wlan0''' and '''IFACE_wimax''' to match those names of the host-only interfaces noted from '''ifconfig'''. Also, modify the '''IFACE_tap_IP''' variable to be an IP in the same subnet of the host-only interfaces (e.g. 192.168.193.155 would work for the host-only subnet 192.168.193/24).
     74      a. Open the script with the text editor of your choice (vim, gedit, pico, nano, etc):
     75      {{{
     76      $ gedit gec18_setup.sh
     77      }}}
     78      e.  There are numerous user defined variables at the top of the script. These are placeholders for commonly used system and configuration specific information throughout the script. We need to change a few of them to suit our needs for this tutorial. Modify the MAC address for '''IFACE_D_MAC''' to match that of the WiMAX interface noted from '''ifconfig wmx0'''. Also, modify the '''IFACE_bridge_E_IP''' variable to be an IP in the same subnet as the server node (yet to be configured). For the tutorial at GEC18, the server node will be configured for you and you will be assigned an IP to give your client node. Assign the IP you have been provided with to the '''IFACE_bridge_E_IP''' variable. Another variable that needs to be configured in the client is the MAC address, SSID, and channel of the AP node. The client needs these pieces of information in order to successfully associate with the AP. For this tutorial, the AP will also be pre-configured. Use the information about the AP that is provided.
    8879      {{{
    8980      ###################
    9081      #USR DEF VARIABLES#
    9182      ###################
    92       IFACE_bridge_eth=br_eth
    93       IFACE_bridge_wlan0=br_wifi0
    94       IFACE_bridge_wimax=br_wimax
    95       IFACE_bridge_int=br_tap
    96      
    97       IFACE_tap=tap0
    98       IFACE_tap_IP=192.168.193.110
    99       IFACE_ethernet=eth0
    100       IFACE_wlan0=eth1
    101       IFACE_wimax=eth2
    102       }}}
    103       f.  Next, we need to create our tap interface. This is the network interface that will funnel all outbound packets from the userspace on our VM and send them into our OpenVswitch network.
     83      }}}
     84      f. Next, we need to remove any running instances of Floodlight and OVS. We do not want more than one instance of these processes running, otherwise chaos might ensue. So, a simple loop and kill works to terminate all running processes.
     85      g. Next, we need to create our tap interface. This is the network interface that will funnel all outbound packets from the applications on our client and send them into our OpenVswitch network.
    10486      {{{
    10587      ###############
     
    11092      openvpn --mktun --dev $IFACE_tap --lladdr 12:51:16:90:8f:ee
    11193      }}}
    112       g.  Now, it is sometimes desirable to automate the start of Floodlight; however, for the purposes of this tutorial, we will launch it from within Eclipse. Comment out the following lines of the '''system_setup.sh''' script:
     94      h. After the tap interface, we need to start the Floodlight controller. The path to the controller executable generated by '''ant''' previosly is defined as the variable '''FL_path'''. Once Floodlight starts, it will not be connected to anything -- we haven't configured our OVS network yet. Once we do this, Floodlight will automatically detect and begin talking to the OVS bridges.
    11395      {{{
    11496      ##################
     
    120102      echo "FL: Finished!"
    121103      }}}
    122       h.  Next, we need to insert the OpenVswitch kernel module:
     104      i.  Next, we need to insert the Open vSwitch kernel module:
    123105      {{{
    124106      ###################
     
    138120      fi
    139121      }}}
    140       i.  After that, we need to initialize OpenVswitch and its database:
     122      j. After that, we need to initialize Open vSwitch and its database:
    141123      {{{
    142124      echo "OVS: Creating database"
     
    152134      ovs-vswitchd --pidfile --detach
    153135      }}}
    154       j.  Now, we need to take down any pre-existing OVS bridges:
     136      k. Now, we need to take down any pre-existing OVS bridges and create new ones. If we later try to create bridges with the same names, OVS will produce an error. There are options called '''--if-exists''' and '''--may-exists''' that are supposed to allow the creation of an OVS bridge/port under the condition it does not exist already. I have not been able to get these options to work, so we will use Bash scripting instead:
    155137      {{{
    156138      echo "OVS: Removing any existing bridge, $IFACE_bridge_eth $IFACE_bridge_wlan0"
     
    215197      ovs-vsctl add-port $IFACE_bridge_int $IFACE_patch_tap_to_wimax -- set Interface $IFACE_patch_tap_to_wimax ofport=$port_tap_to_wimax
    216198      }}}
    217       k.  At this point, we're ready to set the patch ports between the OVS bridges. These create links between the OVS tap bridge and the OVS WiFi and WiMAX bridges in order to facilitate the flow of packets from the tap bridge to the physical interface of choice.
     199      l.  At this point, we're ready to set the patch ports between the OVS bridges. These create links between the OVS tap bridge and the OVS WiFi and WiMAX bridges in order to facilitate the flow of packets from the tap bridge to the physical interface of choice -- WiFi or WiMAX.
    218200      {{{
    219201      #################
     
    235217      ovs-vsctl set interface $IFACE_patch_wimax_to_tap options:peer=$IFACE_patch_tap_to_wimax
    236218      }}}
    237       l.  Now, we need to assign each OVS bridge a unique ID (DPID) and point them to the address of the Floodlight controller. Floodlight will be run on the localhost, so the loopback address is defined within a the variable '''OVS_controllerIP'''.
     219      m.  Now, we need to assign each OVS bridge a unique ID (DPID) and point them to the address of the Floodlight controller. Floodlight will be run on the localhost, so the loopback address is defined within a the variable '''OVS_controllerIP''' and is set as the loopback address '''127.0.0.1:6633'''. Port '''6633''' is the default OpenFlow port. As long as Floodlight and OVS are configured to use the same port number, any available port will suffice. We also need to tell the OVS bridges what to do if and when they lose connection to the Floodlight controller. The '''standalone''' mode allows them to default to a learning switch state if the link between the controller and the bridge is broken.
    238220      {{{
    239221      ##########
     
    272254      echo "OVS: Finished!"
    273255      }}}
    274       m.  Now, the second-to-last thing to do in the setup script is to configure our network connections. We need to revoke the IPs from our physical interfaces and assign them to the OVS bridge interfaces corresponding to each inferface. This will allow us to inject data/packets into our OVS network. We also need to configure our OVS tap bridge as an available IP address in the same subnet as our VM's host-only network (noted earlier with '''ifconfig'''). And finally, we need to disable kernel IP forwarding.
     256      n.  Now that we have OVS and Floodlight running, the next thing to do in the setup script is to configure our network connections. We first need to disable IP forwarding, so that the kernel does not try to route packets around our OVS network. We then need to establish a link on each of the interface we would like to participate in the handoff -- WiFi and WiMAX. Note that WiFi is assigned to '''IFACE_B''' and WiMAX is assigned to '''IFACE_D'''. Also note the use of the WiFi AP variables we set in the first step of configuring this script. After WiFi and WiMAX each connect to their respective networks, we need to remove We also need to revoke the IPs from our physical interfaces (if any are present). What we want to do instead is have a single IP assigned to the tap OVS bridge on which applications can send and receive data. This will allow us to inject data/packets into our OVS network as well as pull packets destined for an application out of our OVS network.
    275257      {{{
    276258      ##########################
     
    307289
    308290      }}}
    309       n.  Finally, look towards the bottom of '''system_setup.sh''' script. Notice the lines:
    310       {{{
    311       #To add 100ms to all outbound traffic on br_wimax
    312       #tc qdisc add dev br_wimax root netem delay 100ms
    313       }}}
    314       This command allows you to add a simulated delay on a particular interface. So we can see the handoff when it occurs, we will add a 100ms delay to the '''br_wimax''' interface. Uncomment this line to do so.
     291     
    315292      o.  Save '''system_setup.sh''' and close your text editor.
    316293