Mininet Provides the Virtual Network Structure

To test OpenDaylight, you need a number of switches and hosts. Mininet [1] gives you a flexible approach for simulating these devices to create a virtual network infrastructure of OpenFlow-capable nodes. Further steps involve installing OpenDaylight as the control plane and then configuring it.

Mininet is available as a prebuilt virtual machine in OFV format and can thus be launched on any popular virtualization host. To illustrate the example, I will be launching the file, which weighs in at around 1GB, on VMware Workstation. It is important to use a Mininet installation from August 2014 or later, because this version will support OpenFlow 1.3 out of the box.

To start, you'll need to install Maven, JRE, and JDK. OpenDaylight needs these packages to operate. Then, download the OpenDaylight Karaf distribution [2]. This is a packetized release that provides the full feature scope. You now have everything you need for your SDN lab. Next, you'll need to create a small network topology with three clients and a switch. To be able to do so, launch Mininet at the command line as follows:

sudo mn --topo single,3 --controller remote

The --topo parameter defines the topology with three individual computers. The --controller remote parameter states that the control plane is external to Mininet. Otherwise, Mininet will provide both the data plane and control plane in its own environment. Now, your test lab for commissioning OpenDaylight is ready and simulating a small network without a control plane.

Adding Features as Modules

Mininet will notify you of the missing controller when launched, outputting a message reading Unable to contact the remote controller at 127.0.0.1:6633 . In other words, the control plane is missing. Just to confirm this, try to ping host h3 from host h1. You will see a message telling you that the host is not reachable. The reason for this is that switch S1 does not have a control plane. As I mentioned previously, the control plane handles the routing of the data packets. Because this is still missing, the data plane – represented by switch S1 – has no idea how to distribute the packets.

In this example, I'm launching OpenDaylight on the same virtual machine as Mininet. In production, you will want to run OpenDaylight on a dedicated computer. At this point, OpenDaylight does not perform any other tasks because the system features need to be loaded individually. Each feature is a module written in Java; you can also program your own features to extend the system. As of this writing, OpenDaylight comes with 158 features. I will be configuring OpenDaylight at the command line; this means installing and loading the required features as follows:

feature:install odl-base-all odl-aaa-authn odl-restconf \
  odl-nsf-all odl-adsal-northbound odl-mdsal-apidocs \
  odl-l2switch-switch odl-dlux-all

It can take awhile for the system to provide this functionality. To check whether the control plane is connected with the data plane, you can ping host h3 from h1 again.

Network Analysis with OpenFlow

For a more comprehensive test and to evaluate OpenDaylight's capabilities, you can build a more extensive Mininet as follows:

sudo mn --topo tree,3 --controller remote

The tree parameter lets you create a topology with three trees consisting of a total of eight hosts and seven switches. Again, you need to install the required features to manage all seven switches, with OpenDaylight acting as the control plane. You can then use the pingall command in Mininet to ping each host from each host. The first return packet takes about 800ms; all subsequent packets are returned far more quickly (<20ms). This is because it initially takes some time for OpenDaylight to analyze the network with OpenFlow, discover the paths between the hosts, and store them in its network plan.