NOX

NOX (www.noxrepo.org) was the first OpenFlow controller written in C++ and provides API for Python too. It has been the basis for many research and development projects in the early exploration of OpenFlow and SDN space. NOX has two separate lines of development:

• NOX-Classic

• NOX, also known as new NOX

The former is the well-known line of development, which contains support for Python and C++ along with a bunch of network applications. However, this line of development is deprecated and there is no plan for further development on NOX-Classic. New NOX only supports C++. It has fewer network applications compared to NOX-Classic, but is much faster and has a much cleaner codebase.

POX is Python-only version of NOX. It can be considered as a general, open source OpenFlow controller written in Python, and a platform for rapid development and prototyping of network applications. The primary target of POX is research. Since many of the research projects are short-lived by nature, the focus of the developers of POX is on right interfaces rather than maintaining a stable API. NOX (and POX) are managed in Git source code repositories on GitHub.

Cloning the Git repository is the preferred way to get NOX and POX. POX branches fall into two categories: active and released. Active branches are branches that are being actively developed. Released branches are branches, which at some point were selected as being a new version. The most recently released branch may continue to get worked on, but only in the form of bug fixes—new features always go into the active branch. You can get the latest version of NOX and POX with the following commands:

$ git clone http://noxrepo.org/git/nox
    
    $ git clone http://www.github.com/noxrepo/pox

Implementing the OpenFlow Switch, we set up the OpenFlow laboratory using Mininet emulation environment. In this section, we start with a Net App, which behaves as a simple Ethernet hub. You can change it to a learning Ethernet L2 switch as a homework. In this application, the switch will examine each packet and learn the source-port mapping. Thereafter, the source MAC address will be associated with the port. If the destination of the packet is already associated with some port, the packet will be sent to the given port, else it will be flooded on all ports of the switch. The first step is to start your OpenFlow VM. Then you need to download the POX into your VM:

$ git clone http://github.com/noxrepo/pox
    $ cd pox

Running a POX application

After getting the POX controller, you can try running a basic hub example in POX as follows:

$`./pox.py log.level --DEBUG misc.of_tutorial`

This command line tells POX to enable verbose logging and to start the of_tutorial
component, which you will be using. This of_tutorial component acts as an Ethernet
hub. Now you can start the Mininet OpenFlow laboratory using the following
command line:

    $ sudo mn --topo single,3 --mac --switch ovsk --controller remote

The switches may take a little bit of time to connect. When an OpenFlow switch loses its connection to a controller, it will generally increase the period between which it attempts to contact the controller, up to a maximum of 15 seconds. This timer is implementation specific and can be defined by the user. Since the OpenFlow switch has not connected yet, this delay may be anything between 0 and 15 seconds. If this is too long to wait, the switch can be configured to wait no more than N seconds using the --max-backoff parameter. Wait until the application indicates that the OpenFlow switch has connected. When the switch connects, POX will print something like the following:

INFO:openflow.of_01:[Con 1/1] Connected to 00-00-00-00-00-01
DEBUG:samples.of_tutorial:Controlling [Con 1/1]

The first line is from the portion of POX that handles OpenFlow connections. The second line is from the tutorial component itself. Now, we verify that the hosts can ping each other, and that all the hosts see the exact same traffic: the behavior of a hub. To do this, we will create xterms for each host and view the traffic in each. In the Mininet console, start up three xterms: mininet> xterm h1 h2 h3

Arrange each xterm so that they're all on the screen at once. This may require reducing the height to fit on a cramped laptop screen. In the xterms for h2 and h3, run tcpdump, a utility to print the packets seen by a host:

# tcpdump -XX -n -i h2-eth0

And respectively:

# tcpdump -XX -n -i h3-eth0

In the xterm for h1, issue a ping command:

# ping -c1 10.0.0.2

The ping packets are now going up to the controller, which then floods them out of all interfaces except the sending one. You should see identical ARP and ICMP packets corresponding to the ping in both xterms running tcpdump. This is how a hub works; it sends all packets to every port on the network. Now, see what happens when a non-existent host doesn't reply. From h1 xterm:

# ping -c1 10.0.0.5

You should see three unanswered ARP requests in the tcpdump xterms. If your code is off later, three unanswered ARP requests is a signal that you might be accidentally dropping packets. You can close the xterms now.

In order to change the behavior of the hub to a learning switch, you have to add the learning switch functionality to of_tutorial.py. Go to your SSH terminal and stop the tutorial hub controller by pressing Ctrl + C. The file you'll modify is pox/ misc/of_tutorial.py. Open pox/misc/of_tutorial.py in your favorite editor. The current code calls act_like_hub() from the handler for packet_in messages to implement the switch behavior. You will want to switch to using the act_like_ switch() function, which contains a sketch of what your final learning switch code should look like. Each time you change and save this file, make sure to restart POX, then use pings to verify the behavior of the combination of switch and controller as a:

1. Hub.

2. Controller-based Ethernet learning switch.

3. Flow-accelerated learning switch.