Changes between Version 27 and Version 28 of GENIExperimenter/Tutorials/WiMAXOpenFlow/Design-Setup


Ignore:
Timestamp:
05/23/17 18:42:52 (7 years ago)
Author:
Vic Thomas
Comment:

--

Legend:

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

    v27 v28  
    7373   }}}
    7474
    75    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.
     75   4.  Also in the client, customize the setup script '''gec20_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.
    7676      a.  Open the script with the text editor of your choice (vim, gedit, pico, nano, etc):
    7777      {{{
    78       $ vim gec18_setup.sh
    79       }}}
    80       b.  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 and IP address of the server node as defined in '''SERVER_IP''' and '''SERVER_MAC'''. These will provide information for a static ARP entry to the server to simplify the tutorial. For the GEC18 tutorial, the server IP will be '''10.41.117.11''' and the server MAC will be '''00:1d:e1:36:ff:51'''. 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. 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. Some other variables that need to be configured in the client are the MAC address, SSID, and channel of the AP node, denoted as '''IFACE_B_AP_...''' in the script. 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. For the tutorial, the AP's SSID is '''GENI_WiFi_AP''', the channel is '''11''', and assuming the AP is loaded on '''node11-11.grid.orbit-lab.org''', the MAC will be '''00:60:b3:ac:a2:44'''.
     78      $ vim gec20_setup.sh
     79      }}}
     80      b.  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 and IP address of the server node as defined in '''SERVER_IP''' and '''SERVER_MAC'''. These will provide information for a static ARP entry to the server to simplify the tutorial. For this tutorial, the server IP will be '''10.41.4.1''' and the server MAC will be '''00:1d:e1:3b:4e:ba'''. 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. 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. Some other variables that need to be configured in the client are the MAC address, SSID, and channel of the AP node, denoted as '''IFACE_B_AP_...''' in the script. 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. For the tutorial, the AP's SSID is '''GENI_WiFi_AP''', the channel is '''11''', and assuming the AP is loaded on '''node10-11.grid.orbit-lab.org''', the MAC will be '''00:60:b3:ac:2c:63'''.
    8181      {{{
    8282      ###################
     
    130130      FL_log=/root/floodlight-output
    131131      FL_clear_flows_script=/root/SwitchingScripts/clear_flows.sh
    132       FL_initial_flows_script=/root/SwitchingScripts/gec18_switch_to_wifi.sh
     132      FL_initial_flows_script=/root/SwitchingScripts/gec20_switch_to_wifi.sh
    133133      ...
    134134      }}}
     
    485485      exit 0
    486486      }}}
    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.
     487      l.  At this point, all components of the '''gec20_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.
    488488      m.  Save the script using your text editor and close it.
    489489
     
    701701      ]
    702702      }}}
    703       c.  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.
    704       d. Next, save the !WiFi switching script and open '''/root/SwithingScripts/gec_18_switch_to_wimax.py'''. Repeat step 5b.
    705 
    706    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.
    707 
    708    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.
     703      c.  Using your favorite text editor, open the '''/root/SwitchingScripts/gec20_switch_to_wifi.py''' script. (Do not open the '''/root/SwitchingScripts/gec20_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 '''gec20_setup.sh''' script of the client. This allows the server to address the client with a single MAC.
     704      d. Next, save the !WiFi switching script and open '''/root/SwithingScripts/gec_20_switch_to_wimax.py'''. Repeat step 5b.
     705
     706   6. The configuration of the client is now complete. The next step is to configure the server node. For this tutorial 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.
     707
     708   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 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/gec20_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.
    709709=== Warnings ===
    710710{{{