Changes between Version 6 and Version 7 of GENIExperimenter/Tutorials/WiMAXOpenFlow/Design-Setup
- Timestamp:
- 10/27/13 10:04:46 (10 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
GENIExperimenter/Tutorials/WiMAXOpenFlow/Design-Setup
v6 v7 55 55 {{{ 56 56 $ ifconfig wmx0 57 wmx0 Link encap:Ethernet HWaddr 00:0c:29:04:5c:4157 wmx0 Link encap:Ethernet HWaddr '''00:0c:29:04:5c:41''' 58 58 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 59 59 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 60 60 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 61 61 collisions:0 txqueuelen:1000 62 RX bytes:0 ( 8.3 KiB) TX bytes:0 (6.1KiB)62 RX bytes:0 (0 KiB) TX bytes:0 (0 KiB) 63 63 Interrupt:18 Base address:0x1424 64 64 $ ifconfig wlan1 65 wlan1 Link encap:Ethernet HWaddr 00:0c:29:04:5c:4b65 wlan1 Link encap:Ethernet HWaddr '''00:0c:29:04:5c:4b''' 66 66 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 67 67 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 68 68 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 69 69 collisions:0 txqueuelen:1000 70 RX bytes:0 ( 31.0 KiB) TX bytes:0 (5.1KiB)70 RX bytes:0 (0 KiB) TX bytes:0 (0 KiB) 71 71 Interrupt:19 Base address:0x14a4 72 72 }}} 73 73 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. 88 79 {{{ 89 80 ################### 90 81 #USR DEF VARIABLES# 91 82 ################### 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. 104 86 {{{ 105 87 ############### … … 110 92 openvpn --mktun --dev $IFACE_tap --lladdr 12:51:16:90:8f:ee 111 93 }}} 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. 113 95 {{{ 114 96 ################## … … 120 102 echo "FL: Finished!" 121 103 }}} 122 h. Next, we need to insert the OpenVswitch kernel module:104 i. Next, we need to insert the Open vSwitch kernel module: 123 105 {{{ 124 106 ################### … … 138 120 fi 139 121 }}} 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: 141 123 {{{ 142 124 echo "OVS: Creating database" … … 152 134 ovs-vswitchd --pidfile --detach 153 135 }}} 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: 155 137 {{{ 156 138 echo "OVS: Removing any existing bridge, $IFACE_bridge_eth $IFACE_bridge_wlan0" … … 215 197 ovs-vsctl add-port $IFACE_bridge_int $IFACE_patch_tap_to_wimax -- set Interface $IFACE_patch_tap_to_wimax ofport=$port_tap_to_wimax 216 198 }}} 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. 218 200 {{{ 219 201 ################# … … 235 217 ovs-vsctl set interface $IFACE_patch_wimax_to_tap options:peer=$IFACE_patch_tap_to_wimax 236 218 }}} 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. 238 220 {{{ 239 221 ########## … … 272 254 echo "OVS: Finished!" 273 255 }}} 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. 275 257 {{{ 276 258 ########################## … … 307 289 308 290 }}} 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 315 292 o. Save '''system_setup.sh''' and close your text editor. 316 293