University of Evry / University of Paris Saclay

M2 CNS –SDN
Lab 1: Mininet, OpenFlow.

Objective:
Understand virtual switchs, openvswitch architecture, openflow, SDN controller.
Work to do:
a) Write a report indicating every step you have performed and the obtained results
experimenting Openvswitch configuration and OpenFlow protocol.
b) You should use ShareLatex to write your report (or any other Latex editor).
c) You should have a clear plan for your document as well as a reference list.
d) You should create a zip file containing the report document (pdf), the programs and
the following excel file:
e) You should also fill an excel file to indicate whether you were successful in responsible
to each part of the lab (Part A, Part B1-8).
f) You should upload the zip file with the pdf report, the programs and the excel file on
you ecampus account.

Part A: Setting up the VM

Download the lastest version of Mininet VM from one of the following links (user: mininet, password:
mininet):

a. https://github.com/mininet/mininet/releases

Install a newer version of Wireshark:

$ sudo apt-get remove wireshark
$ sudo apt-get install software-properties-common python-software-properties
$ sudo add-apt-repository ppa:wireshark-dev/stable
$ sudo apt-get update && sudo apt-get install wireshark wireshark-gtk

To use Wireshark from the command line:

1/9
$ ssh -X [user]@[Guest IP Here]

$ xterm

$ sudo wireshark (or sudo wireshark-gtk)

Instead of running Wireshark from the command line, you can install a desktop:
$ sudo apt-get update && sudo apt-get upgrade

$ sudo apt-get install xinit lxde virtualbox-guest-dkms

$ startx

Part B. Experimenting with Mininet

Type the following command to display a help message describing Mininet’s startup options:
$ sudo mn -h

To view control traffic using the OpenFlow Wireshark dissector, first open Wireshark in the background:
$ sudo wireshark &

In the Wireshark filter box, enter the filter “of” or “openflow”, then click Apply. For now, there should be
no OpenFlow packets displayed in the main window.

Part B.1 Interact with Hosts and Switches

Start a minimal topology and enter the CLI:
$ sudo mn

Exit the CLI:

mininet> exit

Cleanup. If Mininet crashes for some reason, clean it up:

$ sudo mn -c

The default topology is the minimal topology, which includes one OpenFlow kernel switch connected to
two hosts, plus the OpenFlow reference controller. This topology could also be specified on the command
line with --topo=minimal. Other topologies are also available out of the box; see the --topo section in the
output of mn -h.

All four entities (2 host processes, 1 switch process, 1 basic controller) are now running in the VM. The
controller can be outside the VM, and instructions for that are at the bottom.

2/9
Display Mininet CLI commands:
mininet> help

Display nodes:
mininet> nodes

Display links:
mininet> net

Dump information about all nodes:

mininet> dump

You should see the switch and two hosts listed.

If the first string typed into the Mininet CLI is a host, switch or controller name, the command is executed
on that node. Run a command on a host process:
mininet> h1 ifconfig -a

You should see the host’s h1-eth0 and loopback (lo) interfaces. Note that this interface (h1-eth0) is not
seen by the primary Linux system when ifconfig is run, because it is specific to the network namespace
of the host process.

In contrast, the switch by default runs in the root network namespace, so running a command on the
“switch” is the same as running it from a regular terminal:
mininet> s1 ifconfig -a

This will show the switch interfaces, plus the VM’s connection out (eth0).

For other examples highlighting that the hosts have isolated network states, run arp and route on both
s1 and h1.

Note that only the network is virtualized; each host process sees the same set of processes and directories.
For example, print the process list from a host process:
mininet> h1 ps -a

This should be the exact same as that seen by the root network namespace:
mininet> s1 ps -a

Now, verify that you can ping from host 0 to host 1:

mininet> h1 ping -c 1 h2

3/9
You should see OpenFlow control traffic. The first host ARPs for the MAC address of the second, which
causes a packet_in message to go to the controller. The controller then sends a packet_out message to
flood the broadcast packet to other ports on the switch (in this example, the only other data port). The
second host sees the ARP request and sends a reply. This reply goes to the controller, which sends it to
the first host and pushes down a flow entry.

Now the first host knows the MAC address of the second, and can send its ping via an ICMP Echo Request.
This request, along with its corresponding reply from the second host, both go the controller and results
in a flow entry pushed down (along with the actual packets getting sent out).

Repeat the last ping:

mininet> h1 ping -c 1 h2

You should see a much lower ping time for the second try (< 100us). A flow entry covering ICMP ping
traffic was previously installed in the switch, so no control traffic was generated, and the packets
immediately pass through the switch.

An easier way to run this test is to use the Mininet CLI built-in pingall command, which does an all-pairs
ping:
mininet> pingall

Remember that ping isn’t the only command you can run on a host! Mininet hosts can run any command
or application that is available to the underlying Linux system (or VM) and its file system. You can also
enter any bash command, including job control (&, jobs, kill, etc.)

Next, try starting a simple HTTP server on h1, making a request from h2, then shutting down the web
server:
mininet> h1 python -m SimpleHTTPServer 80 &

mininet> h2 wget -O - h1

mininet> h1 kill %python

Part B.2 Changing Topology Size and Type

The default topology is a single switch connected to two hosts. You could change this to a different topo
with --topo, and pass parameters for that topology’s creation. For example, to verify all-pairs ping
connectivity with one switch and three hosts:

Run a regression test:

$ sudo mn --test pingall --topo single,3

1. How does this topology look like?

4/9
Another example, with a linear topology (where each switch has one host, and all switches connect in a
line):
$ sudo mn --test pingall --topo linear,4

2. How does this topology look like?

3. What are the different types of possible topologies in Mininet?

Parametrized topologies are one of Mininet’s most useful and powerful features.

Part B.3 Custom Topologies

Custom topologies can be easily defined as well, using a simple Python API, and an example is provided in
custom/topo-2sw-2host.py. This example connects two switches directly, with a single host off each
switch:

simple topology example (topo-2sw-2host.py): https://github.com/mininet/mininet/tree/master/custom

When a custom Mininet file is provided, it can add new topologies, switch types, and tests to the
command-line. For example:
$ sudo mn --custom ~/mininet/custom/topo-2sw-2host.py --topo mytopo --test pingall

Write a script to create this topology (join the script to your report):

Figure 2.

Useful APIs: http://mininet.org/api/annotated.html

5/9
Part B.4 ID = MAC
By default, hosts start with randomly assigned MAC addresses. This can make debugging tough, because
every time the Mininet is created, the MACs change, so correlating control traffic with specific hosts is
tough.

The --mac option is super-useful, and sets the host MAC and IP addresses to small, unique, easy-to-read
IDs.

Before:
$ sudo mn

...

mininet> h1 ifconfig

h1-eth0 Link encap:Ethernet HWaddr f6:9d:5a:7f:41:42

inet addr:10.0.0.1 Bcast:10.255.255.255 Mask:255.0.0.0

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:6 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:392 (392.0 B) TX bytes:392 (392.0 B)

mininet> exit

After:
$ sudo mn --mac

...

mininet> h1 ifconfig

h1-eth0 Link encap:Ethernet HWaddr 00:00:00:00:00:01

inet addr:10.0.0.1 Bcast:10.255.255.255 Mask:255.0.0.0

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:0 errors:0 dropped:0 overruns:0 frame:0

TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

mininet> exit

6/9
Part B.5 Links Variation
Mininet 2.0 allows you to set link parameters, and these can even be set automatically from the command
line:
$ sudo mn --link tc,bw=10,delay=10ms

mininet> iperf
...
mininet> h1 ping -c10 h2

If the delay for each link is 10 ms, the round-trip time (RTT) should be about 40 ms, since the ICMP request
traverses two links (one to the switch, one to the destination) and the ICMP reply traverses two links
coming back.

You can customize each link using Mininet’s Python API.

Use the python API to create the following topology (Figure 3):

Figure 3.

Part B.6 Adjustable Verbosity

The default verbosity level is info, which prints what Mininet is doing during startup and teardown.
Compare this with the full debug output with the -v parameter:
$ sudo mn -v debug
mininet> exit

Lots of extra detail will print out. Now try output, a setting that prints CLI output and little else:
$ sudo mn -v output
mininet> exit

7/9
Outside the CLI, other verbosity levels can be used, such as warning, which is used with the regression
tests to hide unneeded function output. For more complex debugging, you can start Mininet so that it
spawns one or more xterms. To start an xterm for every host and switch, pass the -x option:
$ sudo mn -x

After a second, the xterms will pop up, with automatically set window names. Alternately, you can bring
up additional xterms as shown below.

By default, only the hosts are put in a separate namespace; the window for each switch is unnecessary
(that is, equivalent to a regular terminal), but can be a convenient place to run and leave up switch debug
commands, such as flow counter dumps.

Xterms are also useful for running interactive commands that you may need to cancel, for which you’d
like to see the output. For example:

In the xterm labeled “switch: s1 (root)”, run:

# dpctl dump-flows tcp:127.0.0.1:6634

Nothing will print out; the switch has no flows added. To use dpctl with other switches, startup Mininet
in verbose mode and look at the passive listening ports for the switches when they’re created.

Now, in the xterm labeled “host: h1”, run:

# ping 10.0.0.2

Go back to s1 and dump the flows:

# dpctl dump-flows tcp:127.0.0.1:6634

You should see multiple flow entries now. Alternately (and generally more convenient), you could use the
dpctl command built into the Mininet CLI without needing any xterms or manually specifying the IP and
port of the switch.

You can tell whether an xterm is in the root namespace by checking ifconfig; if all interfaces are shown
(including eth0), it’s in the root namespace. Additionally, its title should contain “(root)”. Close the setup,
from the Mininet CLI:
mininet> exit

The xterms should automatically close.

8/9
Part B.7 Python Interpreter
If the first phrase on the Mininet command line is py, then that command is executed with Python. This
might be useful for extending Mininet, as well as probing its inner workings. Each host, switch, and
controller have an associated Node object.

At the Mininet CLI, run:

mininet> py 'hello ' + 'world'

Print the accessible local variables:

mininet> py locals()

Next, see the methods and properties available for a node, using the dir() function:
mininet> py dir(s1)

You can read the on-line documentation for methods available on a node by using the help() function:
mininet> py help(h1)

(Press "q" to quit reading the documentation.)

You can also evaluate methods of variables:

mininet> py h1.IP()

Part B.8 Link Up/Down

For fault tolerance testing, it can be helpful to bring links up and down. To disable both halves of a virtual
ethernet pair:
mininet> link s1 h1 down

You should see an OpenFlow Port Status Change notification get generated. To bring the link back up:
mininet> link s1 h1 up

9/9