| 19 | | = 1. Debugging an OpenFlow Controller = |
| 20 | | You will find it helpful to know what is going on inside your OpenFlow controller and its associated switch when implementing these exercises. [[BR]] |
| 21 | | This section contains a few tips that may help you out if you are using the Open vSwitch implementation provided with this tutorial. |
| 22 | | If you are using a hardware OpenFlow switch, your instructor can help you find equivalent commands. [[BR]] |
| 23 | | The Open vSwitch installation provided by the RSpec included in this tutorial is located in ''/opt/openvswitch-1.6.1-F15''. You will find Open vSwitch commands in ''/opt/openvswitch-1.6.1-F15/bin'' and ''/opt/openvswitch-1.6.1-F15/sbin''. Some of these commands may be helpful to you. If you add these paths to your shell’s ''$PATH'', you will be able to access their manual pages with man. Note that ''$PATH'' will not affect sudo, so you will still have to provide the absolute path to sudo; the absolute path is omitted from the following examples for clarity and formatting. |
| 24 | | |
| 25 | | - '''ovs-vsctl'''[[BR]] |
| 26 | | Open vSwitch switches are primarily configured using the ''ovs-vsctl'' command. For exploring, you may find the ''ovs-vsctl show'' command useful, as it dumps the status of all virtual switches on the local Open vSwitch instance. Once you have some information on the local switch configurations, ''ovs-vsctl'' provides a broad range of capabilities that you will likely find useful for expanding your network setup to more complex configurations for testing and verification. In particular, the subcommands ''add-br'', ''add-port'', and ''set-controller'' may be of interest. |
| 27 | | - '''ovs-ofctl''' [[BR]] |
| 28 | | The switch host configured by the given rspec listens for incoming OpenFlow connections on localhost port 6634. |
| 29 | | You can use this to query the switch state using the ''ovs-ofctl'' command. In particular, you may find the ''dump-tables'' and ''dump-flows'' subcommands useful. For example, ''sudo ovs-ofctl dump-flows tcp:127.0.0.1:6634'' will output lines that look like this: |
| 30 | | {{{ |
| 31 | | cookie=0x4, duration=6112.717s, table=0, n packets=1, n bytes=74, idle age=78,priority=5,tcp, |
| 32 | | nw src=10.10.10.0/24 actions=CONTROLLER:65535 |
| 33 | | }}} |
| 34 | | This indicates that any TCP segment with source IP in the 10.10.10.0/24 subnet should be sent to the OpenFlow controller for processing, that it has been 78 seconds since such a segment was last seen, that one such segment has been seen so far, and the total number of bytes in packets matching this rule is 74. The other fields are perhaps interesting, but you will probably not need them for debugging. (Unless, of course, you choose to use multiple tables — an exercise in OpenFlow 1.1 functionality left to the reader.) |
| 35 | | - '''Unix utilities'''[[BR]] |
| 36 | | You will want to use a variety of Unix utilities, in addition to the tools listed in [http://groups.geni.net/geni/wiki/GENIEducation/SampleAssignments/OpenFlowAssignment/ExerciseLayout ExerciseLayout], to test your controllers. The standard ping and ''/usr/sbin/arping'' tools are useful for debugging connectivity (but make sure your controller passes ''ICMP ECHO REQUEST'' and ''REPLY'' packets and ''ARP'' traffic, respectively!), and the command ''netstat -an'' will show all active network connections on a Unix host; the TCP connections of interest in this exercise will be at the top of the listing. The format of netstat output is out of the scope of this tutorial, but information is available online and in the manual pages. |
| 37 | | - '''Linux netem''' [[BR]] |
| 38 | | Use the ''tc'' command to enable and configure delay and lossrate constraints on the outgoing interfaces for traffic traveling from the OpenFlow switch to the Aggregator node. To configure a path with a 20 ms delay and 10% lossrate on eth2, you would issue the command: |
| 39 | | {{{ |
| 40 | | sudo tc qdisc add dev eth2 root handle 1:0 netem delay 20ms loss 2% |
| 41 | | }}} |
| 42 | | Use the "tc qdisc change" command to reconfigure existing links,instead of "tc qdisc add". [[BR]] |
| | 206 | = Tips: Debugging an OpenFlow Controller = |
| | 207 | You will find it helpful to know what is going on inside your OpenFlow controller and its associated switch when implementing these exercises. [[BR]] |
| | 208 | This section contains a few tips that may help you out if you are using the Open vSwitch implementation provided with this tutorial. |
| | 209 | If you are using a hardware OpenFlow switch, your instructor can help you find equivalent commands. [[BR]] |
| | 210 | The Open vSwitch installation provided by the RSpec included in this tutorial is located in ''/opt/openvswitch-1.6.1-F15''. You will find Open vSwitch commands in ''/opt/openvswitch-1.6.1-F15/bin'' and ''/opt/openvswitch-1.6.1-F15/sbin''. Some of these commands may be helpful to you. If you add these paths to your shell’s ''$PATH'', you will be able to access their manual pages with man. Note that ''$PATH'' will not affect sudo, so you will still have to provide the absolute path to sudo; the absolute path is omitted from the following examples for clarity and formatting. |
| | 211 | |
| | 212 | - '''ovs-vsctl'''[[BR]] |
| | 213 | Open vSwitch switches are primarily configured using the ''ovs-vsctl'' command. For exploring, you may find the ''ovs-vsctl show'' command useful, as it dumps the status of all virtual switches on the local Open vSwitch instance. Once you have some information on the local switch configurations, ''ovs-vsctl'' provides a broad range of capabilities that you will likely find useful for expanding your network setup to more complex configurations for testing and verification. In particular, the subcommands ''add-br'', ''add-port'', and ''set-controller'' may be of interest. |
| | 214 | - '''ovs-ofctl''' [[BR]] |
| | 215 | The switch host configured by the given rspec listens for incoming OpenFlow connections on localhost port 6634. |
| | 216 | You can use this to query the switch state using the ''ovs-ofctl'' command. In particular, you may find the ''dump-tables'' and ''dump-flows'' subcommands useful. For example, ''sudo ovs-ofctl dump-flows tcp:127.0.0.1:6634'' will output lines that look like this: |
| | 217 | {{{ |
| | 218 | cookie=0x4, duration=6112.717s, table=0, n packets=1, n bytes=74, idle age=78,priority=5,tcp, |
| | 219 | nw src=10.10.10.0/24 actions=CONTROLLER:65535 |
| | 220 | }}} |
| | 221 | This indicates that any TCP segment with source IP in the 10.10.10.0/24 subnet should be sent to the OpenFlow controller for processing, that it has been 78 seconds since such a segment was last seen, that one such segment has been seen so far, and the total number of bytes in packets matching this rule is 74. The other fields are perhaps interesting, but you will probably not need them for debugging. (Unless, of course, you choose to use multiple tables — an exercise in OpenFlow 1.1 functionality left to the reader.) |
| | 222 | - '''Unix utilities'''[[BR]] |
| | 223 | You will want to use a variety of Unix utilities, in addition to the tools listed in [http://groups.geni.net/geni/wiki/GENIEducation/SampleAssignments/OpenFlowAssignment/ExerciseLayout ExerciseLayout], to test your controllers. The standard ping and ''/usr/sbin/arping'' tools are useful for debugging connectivity (but make sure your controller passes ''ICMP ECHO REQUEST'' and ''REPLY'' packets and ''ARP'' traffic, respectively!), and the command ''netstat -an'' will show all active network connections on a Unix host; the TCP connections of interest in this exercise will be at the top of the listing. The format of netstat output is out of the scope of this tutorial, but information is available online and in the manual pages. |
| | 224 | - '''Linux netem''' [[BR]] |
| | 225 | Use the ''tc'' command to enable and configure delay and lossrate constraints on the outgoing interfaces for traffic traveling from the OpenFlow switch to the Aggregator node. To configure a path with a 20 ms delay and 10% lossrate on eth2, you would issue the command: |
| | 226 | {{{ |
| | 227 | sudo tc qdisc add dev eth2 root handle 1:0 netem delay 20ms loss 2% |
| | 228 | }}} |
| | 229 | Use the "tc qdisc change" command to reconfigure existing links,instead of "tc qdisc add". [[BR]] |
| | 230 | |
| | 231 | |
