Changes between Version 3 and Version 4 of GENIExperimenter/Tutorials/GREESC13/OpenFlowWiMAX/Execute


Ignore:
Timestamp:
06/25/13 10:07:03 (8 years ago)
Author:
Ryan Izard
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • GENIExperimenter/Tutorials/GREESC13/OpenFlowWiMAX/Execute

    v3 v4  
    3434   $ ./system_setup.sh
    3535   }}}
    36    Please be patient; the script can take a minute to complete. It is bringing up the tap interface, starting OVS and
    37 
    38 creating the topology coded in the script, and configuring network access on each OVS bridge.
     36   Please be patient; the script can take a minute to complete. It is bringing up the tap interface, starting OVS and creating the topology coded in the script, and configuring network access on each OVS bridge.
    3937   2.  In the Root Terminal, execute the '''delete_route.sh''' script:
    4038   {{{
     
    4341   }}}
    4442   Verify the new routing table has a default route via the br_tap interface no routes via the br_wimax and br_wifi interfaces.
    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
     46with 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.
    5747   {{{
    5848   $ curl http://localhost:8080/wm/core/controller/switches/json | python -mjson.tool
     
    264254   ]
    265255   }}}
    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.
    274258   {{{
    275259   $ gedit gree13_switchWiFi.py
     
    398382pusher.set(flow8)
    399383   }}}
    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.
    408385   7.  Save the '''gree13_switchWiFi.py''' script.
    409    8.  Repeat and save for '''gree13_switchWiMAX.py'''. Use the port numbers noted in the json output to complete the
    410 flows needed to send packets from the br_tap interface out the br_wimax interface.
     386   8.  Repeat and save for '''gree13_switchWiMAX.py'''. Use the port numbers noted in the json output to complete the flows needed to send packets from the br_tap interface out the br_wimax interface.
    411387
    412388== 5.  Execute Experiment ==
     
    423399(200, 'OK', '{"status" : "Entry pushed"}')
    424400   }}}
    425    2.  In another unused tab in the Root Terminal, run ping to the gateway IP. The default route is set to br_tap and IP
    426 forwarding is disabled -- this forces all packets into the OVS network, where the interface switching is handled by
    427 Floodlight and the Static Flow Pusher.
     401   2.  In another unused tab in the Root Terminal, run ping to the gateway IP. The default route is set to br_tap and IP forwarding is disabled -- this forces all packets into the OVS network, where the interface switching is handled by Floodlight and the Static Flow Pusher.
    428402   {{{
    429403   $ ping 192.168.193.1
     
    444418== 6.  Analyze Experiment ==
    445419
    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.
    452422
    453423