| 32 | | The end-user will use the virtual tap interface (created by OpenVPN) for network connections, while the handoff execution |
| 33 | | |
| 34 | | will handle which physical interface to use. The Static Flow Pusher feature of Floodlight allows for flows to be inserted |
| 35 | | |
| 36 | | manually, as determined by the handoff decision. A Python script leverages the Static Flow Pusher API to add and remove |
| 37 | | |
| 38 | | flows. The detail instructions are as follows. It should be noted that these instructions are executed inside the VM |
| 39 | | |
| 40 | | image. |
| | 32 | The end-user will use the virtual tap interface (created by OpenVPN) for network connections, while the handoff execution will handle which physical interface to use. The Static Flow Pusher API in Floodlight allows for flows to be inserted manually, as determined by the handoff decision. A Python script leverages the Static Flow Pusher API to add and remove flows. Detailed instructions are as follows. ''It should be noted that these instructions are executed inside the VM image with the exception of the very first instruction below.'' |
| 44 | | 1. Remove the Forwarding module from the Floodlight OpenFlow controller. Floodlight uses what it calls a '''module |
| 45 | | |
| 46 | | loading system''', where the user can write modules to perform a certain task or set of tasks. Each module can register |
| 47 | | |
| 48 | | for certain events. For example, the Forwarding module registers for PACKET_IN events where the controller is sent a |
| 49 | | |
| 50 | | packet from a connected switch. Upon such an event, the Forwarding module will send the packet out the correct port(s) |
| 51 | | |
| 52 | | depending on the destination. This module essentially implements a standard '''learning switch''' function where the |
| 53 | | |
| 54 | | OpenFlow-enabled switch behaves as if it were a standard network switch. We do not want this functionality, since we would |
| 55 | | |
| 56 | | like to have control over which port(s) our packets get forwarded. |
| 57 | | a. Open the Root Terminal by browsing to Applications-->Accessories-->Root Terminal. The password is |
| 58 | | |
| 59 | | '''password'''. |
| | 36 | 1. Before booting into the VM, create three network interfaces -- two host-only interfaces and one control NAT interface. If you are using VirtualBox, you must also enable '''promiscuous mode''' for each of the two host-only interfaces. |
| | 37 | |
| | 38 | 2. Remove the Forwarding module from the Floodlight OpenFlow controller. Floodlight uses what it calls a '''module loading system''', where the user can write modules to perform a certain task or set of tasks. Each module can register for certain events. For example, the Forwarding module registers for PACKET_IN events where the controller is sent a packet from a connected switch. Upon such an event, the Forwarding module will send the packet out the correct port(s) depending on the destination. This module essentially implements a standard '''learning switch''' function where the OpenFlow-enabled switch behaves as if it were a standard network switch. We do not want this functionality, since we would like to have control over which port(s) our packets get forwarded. |
| | 39 | a. Open the Root Terminal by browsing to Applications-->Accessories-->Root Terminal. The password is '''password'''. |
| 61 | | c. The '''module loading system''' maintains a list of the modules to be loaded at runtime. To remove the |
| 62 | | |
| 63 | | Forwarding module from this list (and thus disable it), open the |
| 64 | | |
| 65 | | '''floodlight/src/main/resources/floodlightdefault.properties''' file and remove the line |
| 66 | | |
| 67 | | '''net.floodlightcontroller.forwarding.Forwarding,\'''. |
| | 41 | c. 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 '''floodlight/src/main/resources/floodlightdefault.properties''' file and remove the line '''net.floodlightcontroller.forwarding.Forwarding,\'''. |
| 130 | | e. There are numerous user defined variables at the top of the script. These are placeholders for commonly used |
| 131 | | |
| 132 | | system and configuration specific information throughout the script. We need to change a few of them to suit our needs for |
| 133 | | |
| 134 | | this tutorial. Modify the physical interface names for '''IFACE_wlan0''' and '''IFACE_wimax''' to match those names of the |
| 135 | | |
| 136 | | host-only interfaces noted from '''ifconfig'''. Also, modify the '''IFACE_tap_IP''' variable to be an IP in the same |
| 137 | | |
| 138 | | 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). |
| 278 | | ovs-vsctl add-port $IFACE_bridge_int $IFACE_patch_tap_to_wimax -- set Interface $IFACE_patch_tap_to_wimax ofport= |
| 279 | | |
| 280 | | $port_tap_to_wimax |
| 281 | | }}} |
| 282 | | k. At this point, we're ready to set the patch ports between the OVS bridges. These create links between the OVS |
| 283 | | |
| 284 | | tap bridge and the OVS WiFi and WiMAX bridges in order to facilitate the flow of packets from the tap bridge to the |
| 285 | | |
| 286 | | physical interface of choice. |
| | 226 | ovs-vsctl add-port $IFACE_bridge_int $IFACE_patch_tap_to_wimax -- set Interface $IFACE_patch_tap_to_wimax ofport=$port_tap_to_wimax |
| | 227 | }}} |
| | 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. |
| 347 | | 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 |
| 348 | | |
| 349 | | from our physical interfaces and assign them to the OVS bridge interfaces corresponding to each inferface. This will allow |
| 350 | | |
| 351 | | us to inject data/packets into our OVS network. We also need to configure our OVS tap bridge as an available IP address in |
| 352 | | |
| 353 | | the same subnet as our VM's host-only network (noted earlier with '''ifconfig'''). And finally, we need to disable kernel |
| 354 | | |
| 355 | | 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 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. |
| 441 | | Configure the script to remove all routes except a single default route via the br_tap interface. Note, until the |
| 442 | | |
| 443 | | '''system_setup.sh''' is executed, there will be no OVS bridge interfaces present. As such, this script will not be run |
| 444 | | |
| 445 | | until after '''system_setup.sh'''. (There is no harm in running it now, though. If an attempt is made to add or remove a |
| 446 | | |
| 447 | | 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. 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.) |
