Testing SDN behavior with Mininet
Sandbox Games

Mininet lets you test new controller features for your software-defined network in a sandbox before releasing them onto your production network.
With a simple software update for the OpenFlow controller, a network admin can often change the entire behavior of an OpenFlow-based network [1]. You can even write the update yourself – after all, most controllers are available under open source licenses – but how do you find out whether your controller extension harmonizes with the topology of the production network? It would be too bad if you enabled your changes and the routing or the firewall went rogue. If you want to test the update extensively in a controlled environment first, you will turn to Mininet [2] sooner or later.
Sandbox for Network Admins
Mininet describes itself as "An instant virtual network on your laptop (or other PC)." With Mininet, you only need a single Linux system to emulate a network that deploys hundreds of virtual switches and hosts. Mininet can thus emulate a complete network with connected computers on a single machine; the host hardware decides the maximum number of switches and virtual hosts you can use. With an OpenFlow controller, you can then control this test network at will, and the emulated hosts will run any unmodified Linux program. Therefore, you can use Mininet to check whether and how the changed network affects individual programs running on it.
Mininet doesn't just test routing and forwarding rules. If you want to change the topology of a real network, you can simulate the consequences in advance using Mininet, or you can use Mininet to evaluate new networks in the planning phase.
Bag of Tricks
For Mininet to simulate a large number of virtual switches and hosts on a physical computer, it uses some sophisticated technologies that have been part of the Linux kernel for some time. For example, Mininet does without full virtualization and emulates virtual switches and hosts as simple processes on a shared host system.
Because these processes are to act like individual, networked devices, the kernel must separate them. The network namespaces [3] first introduced with Linux 2.2.24 are useful in this case. They allow you to equip processes with individual network interfaces, as well their own routing and ARP tables. Each process has its own network context; communication between two processes is handled by the virtual network interfaces assigned to them.
Processes, however, only talk to each other directly if a kind of virtual cable exists between their network interfaces. Mininet uses virtual Ethernet (veth) pairs to support the exchange of packets between two interfaces.
Figure 1 illustrates how the kernel uses network namespaces to equip the individual processes with their own network contexts. In this example, the two virtual hosts, H1 and H2, are connected to a common switch, S1. Bash processes emulate H1 and H2, the switch S1 runs in the root namespace in which the Linux kernel also operates. H1 and H2 use their own network namespaces and private network interfaces, h1-eth0
and h2-eth0
.

The switch S1 only has two ports, s1-eth0
and s1-eth1
, which use a veth pair to connect them to the corresponding host interfaces. Communication between H1 and H2 is thus exclusively via S1.
Packet forwarding between s1-eth0 and s1-eth1 is done by a software switch. It runs in the root namespace, which uses the physical interface eth0
, and waits for commands from the OpenFlow controller. The controller typically runs outside of the Mininet host, often on another machine on the network.
Mininet also includes some controllers that can be installed using the installation script: Nox [4], the Open vSwitch controller [5], and the OpenFlow 1.0 reference controller [6]. The three run on the same physical machine as Mininet and talk to the switch via the local loopback device; they can be launched via the Mininet command line.
To assign specific properties to the emulated cables, Mininet talks to the Linux kernel's traffic-shaping tool tc
(Traffic Control) [7]. In addition to the maximum data rate of each emulated link, the tool manages the packet error rate and latency. Additionally, you can use tc
to define the buffering behavior of the network interfaces. This determines how the interfaces deal with packets in an overload situation. Besides a simple first-in, first-out (FIFO) method, more complex techniques such as Random Early Detection (RED) can be used here.
OpenFlow Versions
Generally speaking, Mininet can cope with various software switches, which in turn are compatible with different versions of OpenFlow. The current Mininet version 2.1 by default provides native support for the OpenFlow 1.0 reference switch [6], the Indigo Virtual Switch [8], and Open vSwitch [9]. The reference implementation is a pure userspace program, whereas the other two run as kernel modules and therefore achieve much better performance with a lower forwarding delay (Table 1).
Table 1
Supported Switches
Software Switch | OpenFlow Version | Mode |
---|---|---|
Reference implementation |
1.0 |
Userspace |
Indigo Virtual Switch |
1.0 |
Kernel space |
Open vSwitch |
1.0 |
Kernel space |
Ofsoftswitch 13 |
1.3 |
Userspace |
All three switches implement OpenFlow 1.0. If you want to experiment with the new version, OpenFlow 1.3.x [10], you can replace the reference switch with the version from OpenFlow 1.3 (ofsoftswitch13
). This is easiest to do if you install Mininet using
# mininet/util/install.sh -n3fx
Thanks to the -n3fx
option, the network emulator provides an OpenFlow 1.3-compatible version of Nox.
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.
News
-
Red Hat Migrates RHEL from Xorg to Wayland
If you've been wondering when Xorg will finally be a thing of the past, wonder no more, as Red Hat has made it clear.
-
PipeWire 1.0 Officially Released
PipeWire was created to take the place of the oft-troubled PulseAudio and has finally reached the 1.0 status as a major update with plenty of improvements and the usual bug fixes.
-
Rocky Linux 9.3 Available for Download
The latest version of the RHEL alternative is now available and brings back cloud and container images for ppc64le along with plenty of new features and fixes.
-
Ubuntu Budgie Shifts How to Tackle Wayland
Ubuntu Budgie has yet to make the switch to Wayland but with a change in approaches, they're finally on track to making it happen.
-
TUXEDO's New Ultraportable Linux Workstation Released
The TUXEDO Pulse 14 blends portability with power, thanks to the AMD Ryzen 7 7840HS CPU.
-
AlmaLinux Will No Longer Be "Just Another RHEL Clone"
With the release of AlmaLinux 9.3, the distribution will be built entirely from upstream sources.
-
elementary OS 8 Has a Big Surprise in Store
When elementary OS 8 finally arrives, it will not only be based on Ubuntu 24.04 but it will also default to Wayland for better performance and security.
-
OpenELA Releases Enterprise Linux Source Code
With Red Hat restricting the source for RHEL, it was only a matter of time before those who depended on that source struck out on their own.
-
StripedFly Malware Hiding in Plain Sight as a Cryptocurrency Miner
A rather deceptive piece of malware has infected 1 million Windows and Linux hosts since 2017.
-
Experimental Wayland Support Planned for Linux Mint 21.3
As with most Linux distributions, the migration to Wayland is in full force. While some distributions have already made the move, Linux Mint has been a bit slower to do so.