Changes between Version 14 and Version 15 of GENIExperimenter/Tutorials/WiMAXOpenFlow/Design-Setup


Ignore:
Timestamp:
10/27/13 14:47:58 (6 years ago)
Author:
Ryan Izard
Comment:

--

Legend:

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

    v14 v15  
    5050      b.  The '''module loading system''' maintains a list of the modules to be loaded at runtime. To remove the Forwarding module from this list (and thus disable it), open the '''/root/floodlight-0.90/src/main/resources/floodlightdefault.properties''' file and remove the line '''net.floodlightcontroller.forwarding.Forwarding,\'''.
    5151      c.  Browse to the root directory of the Floodlight project -- '''/root/floodlight-0.90'''. Execute '''ant''' in the terminal. '''ant''' is a Java-based build tool to build and compile Java projects. Upon success, '''ant''' will produce an updated executable jar file in the '''/root/floodlight-0.90/target''' directory named '''floodlight.jar'''.
     52
    5253   3.  In the client, determine the MAC addresses of the WiMAX and WiFi network interface cards (NICs). These will be used in OpenFlow flows and will be discussed shortly.
    5354      a.  Load the kernel modules for each of the NICs by executing '''modprobe i2400m_usb''' and '''modprobe ath5k''', respectively.
     
    7172          Interrupt:19 Base address:0x14a4
    7273   }}}
     74
    7375   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 Open vSwitch, and (5) configure Linux networking.
    74       a. Open the script with the text editor of your choice (vim, gedit, pico, nano, etc):
     76      a.  Open the script with the text editor of your choice (vim, gedit, pico, nano, etc):
    7577      {{{
    7678      $ vim gec18_setup.sh
     
    307309      ...
    308310      }}}
    309       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.
     311      i.  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.
    310312      {{{
    311313      ...
     
    314316      #################
    315317     
    316      ## Set patch ports
     318      ## Set patch ports
    317319      #echo "OVS: Patching ports $IFACE_patch_bridge_E_to_bridge_A, $IFACE_patch_bridge_A_to_bridge_E"
    318320      #ovs-vsctl set interface $IFACE_patch_bridge_E_to_bridge_A type=patch
     
    340342     
    341343      }}}
    342       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.
     344      j.  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.
    343345      {{{
    344346      ## Set Eth DPID
     
    396398      ...
    397399      }}}
    398       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 any IP addresses assigned by DHCP when the interfaces were brought up. In the case of this tutorial, we should not get an IP via DHCP for WiFi, since we're managing our own AP. It is possible that we received an IP over WiMAX though, so we need to remove it, just in case. This involves killing the running '''dhclient''' process for WiMAX. At this point, we're ready to assign our single IP to the tap OVS bridge over 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.
     400      k.  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 any IP addresses assigned by DHCP when the interfaces were brought up. In the case of this tutorial, we should not get an IP via DHCP for WiFi, since we're managing our own AP. It is possible that we received an IP over WiMAX though, so we need to remove it, just in case. This involves killing the running '''dhclient''' process for WiMAX. At this point, we're ready to assign our single IP to the tap OVS bridge over 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.
    399401      {{{
    400402      ##########################
     
    483485      exit 0
    484486      }}}
    485       o. At this point, all components of this tutorial have been configured for the client. The last thing to do is allow the flow of packets from the tap interface to the interface of our choice using Floodlight's Static Flow Pusher API. There is the variable '''FL_initial_flows_script''' that is defined as the path to the Bash script that will insert the initial flows. Now, at this point, we will insert these flows, but we need to need check to ensure they are configured correctly. For this, we will need to take note of the WiMAX MAC address determined in an earlier step.
    486       p. Save the script using your text editor and close it.
    487   5. The last thing to configure in the Client are the flows themselves. OpenFlow flows are designed to match certain types of packets, and then based on a successful match, do something to those packets -- e.g. output on port 1, rewrite to a new destination IP, etc. For this tutorial, we need to do two things -- (1) we need to output the packet to the correct port, and (2) we need to rewrite the source MAC for any outbound packets and the destination MAC for any inbound packets. Why? Well, we configured our OVS switches and linked them together as depicted in the figure at the top of this page. Each link of each switch has a port number associated with it. Any physical or tap interface has the port number 1, and any OVS patch port (a port linking two OVS bridges) has an arbitrarily assigned port number. In order to switch packets in our OVS network, we need to know the correct patch ports over which to send packets. For example, if the client wants to send a packet from the tap OVS bridge to the WiFi interface, when the packet is in the tap OVS bridge, the switch needs to know which port to send the packet out on. Well, since we are manually telling the client which interface to use, our static flows must specify the port number that leads to the physical interface of choice. In the case of our example, we would want to insert a flow to direct all packet out the patch port number leading to the WiFi OVS bridge. To determine these port numbers, we need to query Floodlight for information about connected switches. There is a script in the directory '''/root/SwitchingScripts''' called '''getJSONPorts.sh'''. This script will send an HTTP request to Floodlight's REST API, requesting information about the connected switches. It pipes this information (in JSON format) to a python JSON printer (i.e. it "pretty-prints" the JSON string for us). Based on this output, we can determine and confirm the port numbers assigned to each OVS bridge, and thus, we can correctly compose our flows such that they match on and forward packets out the correct port numbers. Since we are using the same Orbit image for each client machine in this tutorial, all the port numbers should be configured correctly as-is, but it's still worth checking just to be certain.
    488      a. The following is an example output from the client's '''/root/SwitchingScripts/getJSONPorts.sh''' script. Base on this information, note the port numbers for each port of each OVS bridge. The WiFi and WiMAX OVS bridges should have three ports -- the physical interface port, the OVS patch port to the tap OVS bridge, and the port of the OVS bridge itself. And, the tap OVS bridge should have four ports -- the "physical" tap interface port, the OVS patch ports to the WiFi and WiMAX OVS bridges, and the OVS bridge itself.
    489      b. Using your favorite text editor, open the '''/root/SwitchingScripts/gec18_switch_to_wifi.py''' script. (Do not open the '''/root/SwitchingScripts/gec18_switch_to_wifi.sh''' script. This is simply a wrapper for the python script with the flows themselves.) In the python script, browse down to were you see the definition of '''flow1'''. Right before this definition are a few variables we need to check/set. They define the MAC addresses of the physical and tap interfaces. Recall that we need to rewrite these in our flows. Why is this so? Well, WiFi and WiMAX have an association process. This process provides the AP/BS with the MAC address of the associated client. The AP/BS will filter incoming packets by associate MACs. If an ingress packet contains a source MAC that is not known to the AP/BS, it will be dropped. Thus, any packets we send from our tap interface need to have their source MAC addresses rewritten so that the AP or BS will recognize the source and thus accept the packets. Using the MAC of the WiMAX interface noted in prior steps, set the MAC address of the '''wifi_mac''' and '''wimax_mac''' to the MAC address of the WiMAX MAC. This might seem odd, but in order to simplify this tuturial and experiment, we have "spoofed" the actual MAC of the WiFi interface to that of the WiMAX interface, thus making both interfaces appear to have the same MAC. You can see this for yourselves in the '''gec18_setup.sh''' script of the client. This allows the server to address the client with a single MAC.
    490      c. Next, save the WiFi switching script and open '''/root/SwithingScripts/gec_18_switch_to_wimax.py'''. Repeat step 5b.
     487      l.  At this point, all components of the '''gec18_setup.sh''' script have been configured for the client. The last thing to do is allow the flow of packets from the tap interface to the interface of our choice using Floodlight's Static Flow Pusher API. There is the variable '''FL_initial_flows_script''' that is defined as the path to the Bash script that will insert the initial flows. Now, at this point, we will insert these flows, but we need to need check to ensure they are configured correctly. For this, we will need to take note of the WiMAX MAC address determined in an earlier step.
     488      m.  Save the script using your text editor and close it.
     489
     490  5.  The last thing to configure in the Client are the flows themselves. OpenFlow flows are designed to match certain types of packets, and then based on a successful match, do something to those packets -- e.g. output on port 1, rewrite to a new destination IP, etc. For this tutorial, we need to do two things -- (1) we need to output the packet to the correct port, and (2) we need to rewrite the source MAC for any outbound packets and the destination MAC for any inbound packets. Why? Well, we configured our OVS switches and linked them together as depicted in the figure at the top of this page. Each link of each switch has a port number associated with it. Any physical or tap interface has the port number 1, and any OVS patch port (a port linking two OVS bridges) has an arbitrarily assigned port number. In order to switch packets in our OVS network, we need to know the correct patch ports over which to send packets. For example, if the client wants to send a packet from the tap OVS bridge to the WiFi interface, when the packet is in the tap OVS bridge, the switch needs to know which port to send the packet out on. Well, since we are manually telling the client which interface to use, our static flows must specify the port number that leads to the physical interface of choice. In the case of our example, we would want to insert a flow to direct all packet out the patch port number leading to the WiFi OVS bridge. To determine these port numbers, we need to query Floodlight for information about connected switches. There is a script in the directory '''/root/SwitchingScripts''' called '''getJSONPorts.sh'''. This script will send an HTTP request to Floodlight's REST API, requesting information about the connected switches. It pipes this information (in JSON format) to a python JSON printer (i.e. it "pretty-prints" the JSON string for us). Based on this output, we can determine and confirm the port numbers assigned to each OVS bridge, and thus, we can correctly compose our flows such that they match on and forward packets out the correct port numbers. Since we are using the same Orbit image for each client machine in this tutorial, all the port numbers should be configured correctly as-is, but it's still worth checking just to be certain.
     491      a.  The following is an example output from the client's '''/root/SwitchingScripts/getJSONPorts.sh''' script. Base on this information, note the port numbers for each port of each OVS bridge. The WiFi and WiMAX OVS bridges should have three ports -- the physical interface port, the OVS patch port to the tap OVS bridge, and the port of the OVS bridge itself. And, the tap OVS bridge should have four ports -- the "physical" tap interface port, the OVS patch ports to the WiFi and WiMAX OVS bridges, and the OVS bridge itself.
     492      b.  Using your favorite text editor, open the '''/root/SwitchingScripts/gec18_switch_to_wifi.py''' script. (Do not open the '''/root/SwitchingScripts/gec18_switch_to_wifi.sh''' script. This is simply a wrapper for the python script with the flows themselves.) In the python script, browse down to were you see the definition of '''flow1'''. Right before this definition are a few variables we need to check/set. They define the MAC addresses of the physical and tap interfaces. Recall that we need to rewrite these in our flows. Why is this so? Well, WiFi and WiMAX have an association process. This process provides the AP/BS with the MAC address of the associated client. The AP/BS will filter incoming packets by associate MACs. If an ingress packet contains a source MAC that is not known to the AP/BS, it will be dropped. Thus, any packets we send from our tap interface need to have their source MAC addresses rewritten so that the AP or BS will recognize the source and thus accept the packets. Using the MAC of the WiMAX interface noted in prior steps, set the MAC address of the '''wifi_mac''' and '''wimax_mac''' to the MAC address of the WiMAX MAC. This might seem odd, but in order to simplify this tuturial and experiment, we have "spoofed" the actual MAC of the WiFi interface to that of the WiMAX interface, thus making both interfaces appear to have the same MAC. You can see this for yourselves in the '''gec18_setup.sh''' script of the client. This allows the server to address the client with a single MAC.
     493      c. Next, save the WiFi switching script and open '''/root/SwithingScripts/gec_18_switch_to_wimax.py'''. Repeat step 5b.
     494
    491495  6. The configuration of the client is now complete. The next step is to configure the server node. For the tutorial at GEC18, the server has been configured for you. Not only does this save time, but it also allows multiple clients to share the same server node. The process is nearly identical to that of the client node. The difference is that you need to assign a different IP to the tap interface and provide the IP of the client instead of the the IP of the server. Another key difference is how the flows work. On the client, the flows inserted will switch packets to the interface the client wishes to use. As a simplification to this experiment and tutorial, the server's flows are configured to always listen and send packets out its WiFi and WiMAX interfaces. In other words, no switching takes place on the server node. The flows that are inserted when the server is configured and run are the flows that will remain for the lifetime of the experiment.
     496
    492497  7. Last but not least, after the server is configured, the AP needs to be configured and brought up. This has also been done for you at GEC18, since all client nodes will share a single AP. The steps to configuring the AP are mostly related to setting up '''hostapd'''. On the AP, there is a script '''/root/gec18_setup.sh'''. This script simply inserts the kernel module for the Atheros 5000 series card ('''modprobe ath5k''') and starts hostapd. All configuration parameters related to the WiFi network (e.g. SSID, encryption, channel, etc) are located in the '''/root/hostapd.conf''' configuration file. '''hostapd''' will parse this file and read these parameters when it is executed. The AP is set by default to broadcast an open (unsecured) network on channel 11 and with SSID GENI_WiFi_AP. It is also configured by default in AP mode, not ad-hoc mode. No changes should be made to this configuration for this experiment.
    493498=== Warnings ===