Changes between Version 8 and Version 9 of GENIExperimenter/Tutorials/GREESC13/OpenFlowWiMAX/Design-Setup


Ignore:
Timestamp:
03/19/14 15:31:02 (8 years ago)
Author:
Ryan Izard
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GENIExperimenter/Tutorials/GREESC13/OpenFlowWiMAX/Design-Setup

    v8 v9  
    9696      $ gedit system_setup.sh
    9797      }}}
    98       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).
     98      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). Note that you might not need to change anything depending on what virtualization software you are using and how you set up your VM's network preferences.
    9999      {{{
    100100      ###################
     
    112112      IFACE_wimax=eth2
    113113      }}}
    114       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.
     114      f.  Next, we need to create our tap interface. This is the network interface that will accept all packets routed from the userspace on our VM and send them into our OpenVswitch network.
    115115      {{{
    116116      ###############
     
    121121      openvpn --mktun --dev $IFACE_tap --lladdr 12:51:16:90:8f:ee
    122122      }}}
    123       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:
     123      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. Make sure the following lines of the '''system_setup.sh''' script are commented out:
    124124      {{{
    125125      ##################
     
    131131      echo "FL: Finished!"
    132132      }}}
    133       h.  Next, we need to insert the OpenVswitch kernel module:
     133      h.  Next, we need to insert the Open vSwitch kernel module. The this kernel module is an OpenFlow-enabled replacement for the Linux bridge kernel module. You cannot run both simultaneously.
    134134      {{{
    135135      ###################
     
    149149      fi
    150150      }}}
    151       i.  After that, we need to initialize OpenVswitch and its database:
     151      i.  After that, we need to initialize Open vSwitch and its database. This is where OVS stores information about configured bridges and ports.
    152152      {{{
    153153      echo "OVS: Creating database"
     
    163163      ovs-vswitchd --pidfile --detach
    164164      }}}
    165       j.  Now, we need to take down any pre-existing OVS bridges:
     165      j.  Now, we need to take down any pre-existing OVS bridges. The OVS database is persistent between OVS executions. This is great if you want to retain your previous OVS configuration; however, if you want to start fresh or redo a particular aspect of your topology, you will want to remove the necessary bridge(s).
    166166      {{{
    167167      echo "OVS: Removing any existing bridge, $IFACE_bridge_eth $IFACE_bridge_wlan0"
     
    226226      ovs-vsctl add-port $IFACE_bridge_int $IFACE_patch_tap_to_wimax -- set Interface $IFACE_patch_tap_to_wimax ofport=$port_tap_to_wimax
    227227      }}}
    228       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.
     228      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. A physical analogy to patch ports is an Ethernet cable interconnecting two OpenFlow-enabled switches.
    229229      {{{
    230230      #################
     
    246246      ovs-vsctl set interface $IFACE_patch_wimax_to_tap options:peer=$IFACE_patch_tap_to_wimax
    247247      }}}
    248       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'''.
     248      l.  Now, we need to assign each OVS bridge a unique ID (DPID or Datapath Identifier) and point them to the address of the Floodlight controller. Floodlight will be run on the localhost (i.e. on our VM), so the loopback address is used and defined within the variable '''OVS_controllerIP'''.
    249249      {{{
    250250      ##########
     
    283283      echo "OVS: Finished!"
    284284      }}}
    285       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.
     285      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 interface. This will allow us to inject data/packets into and out of our OVS network. We also need to configure our OVS tap bridge with 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 IP forwarding.
    286286      {{{
    287287      ##########################
     
    323323      #tc qdisc add dev br_wimax root netem delay 100ms
    324324      }}}
    325       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.
     325      The '''tc''' command allows us 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. Make sure this line is ''uncommented'' in order to enable the delay.
    326326      o.  Save '''system_setup.sh''' and close your text editor.
    327327   4.  Examine the kernel routing table, and create a script to automate adding and removing of IP routes.
     
    369369      exit 0
    370370      }}}
    371       Configure the script to remove all routes except a single default route via the br_tap interface. Note, until the '''system_setup.sh''' is executed, there will be no OVS bridge interfaces present. As such, this script will not be run until after '''system_setup.sh'''. (There is no harm in running it now, though. If an attempt is made to add or remove a non-existent route, a error message will be displayed and the script will continue.)
     371      Configure the script to remove all routes except a single default route via the br_tap interface. We can only control the interface packets use if they are sent into our OVS network. When a user application sends a packet, Linux will send it to the appropriate network interface according to the routing table. As such, we need to make sure the default route and route for each handoff-participating interface is via the tap OVS bridge, not via the physical interfaces. Note, until the '''system_setup.sh''' is executed, there will be no OVS bridge interfaces present. As such, this script should not be run until after '''system_setup.sh'''. (There is no harm in running it now, though. If an attempt is made to add or remove a non-existent route, a error message will be displayed and the script will continue.)
    372372      d.  Save the '''delete_route.sh''' script and exit the text editor.
    373373