| OpenFlow Testing Framework |
| July, 2010 |
| Last updated January 2013 |
| |
| Copyright (c) 2010 The Board of Trustees of The Leland Stanford |
| Junior University |
| |
| License |
| +++++++ |
| |
| The software included with this distribution is subject to the |
| OpenFlow Switching License as given in the included file LICENSE. |
| Details are also available at: |
| |
| http://www.openflow.org/wp/legal |
| |
| Other software referenced in this distribution is subject to its |
| respective license. |
| |
| Introduction |
| ++++++++++++ |
| |
| This test framework is meant to exercise a candidate OpenFlow |
| switch (the device/switch under test, DUT or SUT). It provides a |
| connection like a controller to which the switch connects and it |
| controls data plane ports, sending and receiving packets, which |
| should be connected to the switch. |
| |
| For information on writing new tests or making improvements to |
| the test framework see the file DEVELOPING. |
| |
| Getting OFTest |
| ++++++++++++++ |
| |
| You can check out OFTest with git with the following command: |
| |
| git clone git://github.com/floodlight/oftest |
| |
| Quick Start |
| +++++++++++ |
| |
| You need to have Python and Scapy installed on your system. |
| See 'Pre-requisites' below. |
| |
| Make sure your switch is running and trying to connect to a |
| controller on the machine where you're running oft (normally port |
| 6633). See below regarding run_switch.py for a script that starts |
| up a software switch on the test host. |
| |
| Currently, switches must be running version 1.0 of OpenFlow. |
| |
| # git clone git://github.com/floodlight/oftest |
| # cd oftest |
| Make sure the switch you want to test is running -- |
| see (4) below for the reference switch example. |
| # ./oft --list |
| # sudo ./oft basic.Echo |
| # sudo ./oft --verbose --log-file="" |
| # sudo ./oft basic --platform=remote --host=... |
| |
| Longer Start |
| ++++++++++++ |
| |
| 1. Pre-requisites: |
| * An OF switch instance to test (see 4 below) |
| * Root privilege on host running oft |
| * Switch running OpenFlow 1.0 and attempting to connect |
| to a controller on the machine running oft. |
| * Python 2.5 or 2.6. You can run platforms using eth interfaces |
| with Python 2.4. Python 2.7 may work. |
| * oftest checked out (called <oftest> here) |
| * scapy installed: http://www.secdev.org/projects/scapy/ |
| 'sudo apt-get install scapy' should work on Debian. |
| * pypcap installed: http://code.google.com/p/pypcap/ (optional) |
| 'sudo apt-get install python-pypcap' should work on Debian. |
| Tests using VLAN tags may fail without pypcap. |
| * tcpdump installed (optional, but scapy will complain if it's |
| not there) |
| * Doxygen and doxypy for document generation (optional) |
| * lint for source checking (optional) |
| |
| 2. Edit configuration if necessary |
| The default (local) platform uses 4 veth interface pairs and |
| is only suitable for testing local software switches. To test |
| hardware switches you will need to create an appropriate |
| platform file. See the "Platforms" section below. |
| |
| 3. Start the switch to test |
| The switch must be running and actively attempting to |
| connect to a controller on the test host at the port number |
| used by oft (6633 by default, or specified as --port=<n> as |
| an argument to oft). |
| |
| If you're new to the test environment and want to check its |
| sanity, you can do the following. This requires that |
| your host kernel supports virtual ethernet interfaces. This |
| is best done in a window separate from where you will run oft. |
| |
| 4A. Check out openflow (preferably at the same level as oftest): |
| git clone git://openflowswitch.org/openflow.git |
| 4B. cd openflow; ./boot.sh; ./configure; make |
| 4C. cd ../oftest |
| 4D. Run the switch startup script: |
| sudo ./run_switch.py; Now you can run oft (see below). |
| 4F. Use --help to see command line switches. If you use a port |
| number other than the default, make sure you use the same |
| one for the switch as for oft. |
| 4E. Use control-C to terminate the switch daemons. |
| 4F. To clean up the virtual ethernet interfaces, use |
| sudo rmmod veth |
| |
| New tools allow you to run an OVS instance as well. See |
| oftest/tools/ovs-ctl. You will need to install a version of |
| openvswitch. See http://openvswitch.org/. |
| |
| 4. Run oft (requires sudo to control the dataplane) |
| cd <oftest> |
| sudo ./oft --help |
| |
| Important Notes |
| +++++++++++++++ |
| |
| 1. If you're running into issues with transactions, and it appears that |
| OpenFlow messages aren't quite right, start by looking at any length |
| fields in the packets. With the local platform, you can use wireshark |
| on the loopback interface as well as the dataplane veth interfaces. |
| |
| 2. If tests dealing with VLANs fail unexpectedly then try installing |
| pypcap (see Longer Start above). |
| |
| Platforms |
| +++++++++ |
| |
| The "platform" is a configuration file (written in Python) that |
| tells OFTest how to send packets to and receive packets from the |
| dataplane of the switch. The default platform uses Linux virtual |
| ethernet interfaces and is suitable only for local software switches. |
| |
| You can add your own platform, say gp104, by adding a file gp104.py to the |
| platforms directory that defines the function platform_config_update and then |
| use the parameter --platform=gp104 on the command line. You can also use the |
| --platform-dir option to change which directory is searched. |
| |
| IMPORTANT: That file should define a function platform_config_update which |
| takes a configuration dictionary as an argument and updates it for the |
| current run. In particular, it should set up config["port_map"] with |
| the proper map from OF port numbers to OF interface names. |
| |
| Helpful Note: Recovering From Crash |
| +++++++++++++++++++++++++++++++++++ |
| |
| If the test script, oft, becomes unresponsive, you may find that |
| ^C does not break out of the script. In this case you have two |
| options: |
| |
| * Use ^Z to interrupt the script and return to the shell prompt. |
| * Start another terminal window to the same machine. |
| |
| In either case, you then need to kill the process that is hung. |
| Use the following commands: |
| |
| me@host> ps aux | grep oft |
| root 4 0.0 S< Jul07 0:00 [ksoftirqd/0] |
| ... |
| root 14066 3.2 Tl 09:27 0:00 python ./oft ... |
| me 14074 0.0 R+ 09:28 0:00 grep oft |
| |
| me@host> sudo kill -9 14066 |
| |
| where 14066 is the process ID of the hung process. (Replace it |
| with the PID for your process.) |
| |
| This is still preliminary work and there are bugs in the framework |
| that need to be ironed out. Please report any issues to |
| dtalayco@stanford.edu. |
| |
| Using CentOS/RHEL |
| +++++++++++++++++ |
| |
| CentOS/RHEL have two challenges: they are very tied to Python 2.4 |
| (and Scapy requires Python 2.5 for its latest version) and they |
| require a kernel upgrade to use veth pairs for local platform |
| testing. |
| |
| If you only need to control eth interfaces for a remote platform, |
| you can use CentOS/RHEL without major disruption. The key is to |
| download scapy-1.2 from the following link: |
| |
| wget http://hg.secdev.org/scapy/raw-file/v1.2.0.2/scapy.py |
| |
| See: http://www.dirk-loss.de/scapy-doc/installation.html#installing-scapy-v1-2 |
| for more info. |
| |
| Copy scapy.py to /usr/lib/python2.4/site-packages |
| |
| If you hit an error related to importing scapy.all, you just need |
| to change the import to refer to scapy (not scapy.all). See |
| examples in parse.py for example. |