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
-
TUXEDO Computers Unveils Linux Laptop Featuring AMD Ryzen CPU
This latest release is the first laptop to include the new CPU from Ryzen and Linux preinstalled.
-
XZ Gets the All-Clear
The back door xz vulnerability has been officially reverted for Fedora 40 and versions 38 and 39 were never affected.
-
Canonical Collaborates with Qualcomm on New Venture
This new joint effort is geared toward bringing Ubuntu and Ubuntu Core to Qualcomm-powered devices.
-
Kodi 21.0 Open-Source Entertainment Hub Released
After a year of development, the award-winning Kodi cross-platform, media center software is now available with many new additions and improvements.
-
Linux Usage Increases in Two Key Areas
If market share is your thing, you'll be happy to know that Linux is on the rise in two areas that, if they keep climbing, could have serious meaning for Linux's future.
-
Vulnerability Discovered in xz Libraries
An urgent alert for Fedora 40 has been posted and users should pay attention.
-
Canonical Bumps LTS Support to 12 years
If you're worried that your Ubuntu LTS release won't be supported long enough to last, Canonical has a surprise for you in the form of 12 years of security coverage.
-
Fedora 40 Beta Released Soon
With the official release of Fedora 40 coming in April, it's almost time to download the beta and see what's new.
-
New Pentesting Distribution to Compete with Kali Linux
SnoopGod is now available for your testing needs
-
Juno Computers Launches Another Linux Laptop
If you're looking for a powerhouse laptop that runs Ubuntu, the Juno Computers Neptune 17 v6 should be on your radar.