| 45 | | 3. In Eclipse, run Floodlight by browsing to '''Run-->Run'''. Note the console output shown toward the bottom of the |
| 46 | | Eclipse window. Since OVS is running, and the '''system_setup.sh''' script pointed each OVS bridge to the Floodlight |
| 47 | | controller, you should see where each switch DPID connects to Floodlight. |
| 48 | | 4. In the Root Terminal, open an new tab (File-->Open Tab) or switch to an unused tab. Browse to the '''/root/06-03- |
| 49 | | 13/eth_control''' directory. |
| 50 | | 5. In this directory are some Python scripts to manually add and remove flows in the OVS bridges. These scripts |
| 51 | | leverage the Static Flow Pusher REST API present in the Floodlight controller. Since we have previously disabled |
| 52 | | Forwarding, flows added by the Static Flow Pusher will be the only flows present on the switches, and thus only traffic |
| 53 | | permitted by these flows will traverse the OVS network. These flows essentially take packets from a particular ingress |
| 54 | | port and send them out a destination port. To do this, we need to determine the port numbers Floodlight has associated |
| 55 | | with the ports of our OVS bridges. The Floodlight REST API is a means of obtaining data from the Floodlight controller. We |
| 56 | | need to send a query to Floodlight asking for what it knows about any connected switches. |
| | 43 | 3. In Eclipse, run Floodlight by browsing to '''Run-->Run'''. Note the console output shown toward the bottom of the Eclipse window. Since OVS is running, and the '''system_setup.sh''' script pointed each OVS bridge to the Floodlight controller, you should see where each switch DPID connects to Floodlight. |
| | 44 | 4. In the Root Terminal, open an new tab (File-->Open Tab) or switch to an unused tab. Browse to the '''/root/06-03-13/eth_control''' directory. |
| | 45 | 5. In this directory are some Python scripts to manually add and remove flows in the OVS bridges. These scripts leverage the Static Flow Pusher REST API present in the Floodlight controller. Since we have previously disabled Forwarding, flows added by the Static Flow Pusher will be the only flows present on the switches, and thus only traffic permitted by these flows will traverse the OVS network. These flows essentially take packets from a particular ingress port and send them out a destination port. To do this, we need to determine the port numbers Floodlight has associated |
| | 46 | with the ports of our OVS bridges. The Floodlight REST API is a means of obtaining data from the Floodlight controller. We need to send a query to Floodlight asking for what it knows about any connected switches. |
| 266 | | Above is sample output from the query issued. The output is organized by switch -- there should be three -- br_tap, |
| 267 | | br_wifi, and br_wimax. On each of these switches, you can see the ports and the names of the ports as they were given in |
| 268 | | '''system_setup.sh'''. Take note of the port numbers for the patch ports on each switch, as well as the port numbers for |
| 269 | | the interface port on each switch. |
| 270 | | 6. Armed with this information, we can now create the flows we want to insert on each switch. Namely, we can specify |
| 271 | | and ingress and output port on br_tap, br_wifi, and br_wimax for packets traveling in each direction. In the Root |
| 272 | | Terminal, open the Python script '''gree13_switchWiFi.py''' with your favorite text editor. This script is designed to |
| 273 | | switch to the WiFi interface. |
| | 256 | Above is sample output from the query issued. The output is organized by switch -- there should be three -- br_tap, br_wifi, and br_wimax. On each of these switches, you can see the ports and the names of the ports as they were given in '''system_setup.sh'''. Take note of the port numbers for the patch ports on each switch, as well as the port numbers for the interface port on each switch. |
| | 257 | 6. Armed with this information, we can now create the flows we want to insert on each switch. Namely, we can specify and ingress and output port on br_tap, br_wifi, and br_wimax for packets traveling in each direction. In the Root Terminal, open the Python script '''gree13_switchWiFi.py''' with your favorite text editor. This script is designed to switch to the WiFi interface. |
| 400 | | In this script, there are four flows for each OVS bridge -- two for outgoing packets and two for incoming packets. Why |
| 401 | | two? OpenFlow filters packets by not only data like MAC and IP addresses, but also by the type of packet (its |
| 402 | | '''ethertype'''). We need to forward all IP (ethertype=0x800) and all ARP (ethertype=0x806) packets in each direction in |
| 403 | | order to achieve IP connectivity between the tap interface and the outside world. What we want to do is look for packets |
| 404 | | from the port br_tap is assigned to, then send them out the tap-wifi port number (the patch port connected to the br_wifi |
| 405 | | OVS bridge), then when they arrive at br_wifi, look for them on the wifi-tap port number and send them out the br_wifi |
| 406 | | port number. Then we want to implement the same for the opposite direction. Examine the script and modify it as necessary |
| 407 | | to allow packets to travel from the br_tap interface, to the br_wifi interface, and out to the host-only network. |
| | 384 | In this script, there are four flows for each OVS bridge -- two for outgoing packets and two for incoming packets. Why two? OpenFlow filters packets by not only data like MAC and IP addresses, but also by the type of packet (its '''ethertype'''). We need to forward all IP (ethertype=0x800) and all ARP (ethertype=0x806) packets in each direction in order to achieve IP connectivity between the tap interface and the outside world. What we want to do is look for packets from the port br_tap is assigned to, then send them out the tap-wifi port number (the patch port connected to the br_wifi OVS bridge), then when they arrive at br_wifi, look for them on the wifi-tap port number and send them out the br_wifi port number. Then we want to implement the same for the opposite direction. Examine the script and modify it as necessary to allow packets to travel from the br_tap interface, to the br_wifi interface, and out to the host-only network. |
| 446 | | 1. Notice the delay introduced in the ping responses. When we configured and ran the '''system_setup.sh''' script, we |
| 447 | | introduced a simulated delay to the "WiMAX" interface. This confirms the switch is occuring. Before and after the switch, |
| 448 | | the source IP remains the br_tap IP, and the destination IP remains the gateway IP. |
| 449 | | 2. Congratuations! You have just completed a simulated vertical Layer-2 handoff! This project is being developed and |
| 450 | | tested using actual GENI WiFi and WiMAX testbed at Clemson University. You can give it a try yourself outside the VM using |
| 451 | | whatever physical interfaces you have available. |
| | 420 | 1. Notice the delay introduced in the ping responses. When we configured and ran the '''system_setup.sh''' script, we introduced a simulated delay to the "WiMAX" interface. This confirms the switch is occuring. Before and after the switch, the source IP remains the br_tap IP, and the destination IP remains the gateway IP. |
| | 421 | 2. Congratuations! You have just completed a simulated vertical Layer-2 handoff! This project is being developed and tested using actual GENI WiFi and WiMAX testbed at Clemson University. You can give it a try yourself outside the VM using whatever physical interfaces you have available. |
