Does the lab need an OpenFlow switch or a licence?

No. The switch is Open vSwitch, open source and in Ubuntu’s archive, and Mininet and the controller library come from the same archive. They are installed when the student’s VM starts, and nothing of them is distributed by us.

Why does the lab ship its own controller launcher?

Ubuntu’s os-ken package is a library only, with no command to run an application. The lab adds a short launcher, ctl.py, which is readable in the definition. os-ken depends on eventlet, which is deprecated and prints a notice in the controller’s log. That is why the lab teaches ovs-ofctl and Mininet first: those parts do not depend on it.

Can students harm anything?

Only their own copy. The network between the hosts is virtual and inside the VM, which reaches Ubuntu’s archive, PyPI, npm and GitHub and nothing else. If a student breaks the lab, sdnlab reset puts both files back.

Was the lab tested in a real student VM?

The setup, the lesson’s commands and the check were run in a real Ubuntu 26.04 with the kernel’s own Open vSwitch datapath, in a container standing in for the VM. A booted student VM, which starts the lab from a systemd unit and loads Ubuntu’s own kernel module, is worth one try before a class.

Software-defined networking lab: Open vSwitch, Mininet and an OpenFlow controller on one VM

This lab gives each student a switch they can program. Open vSwitch, a real software switch, and three small hosts are built inside the student’s one Ubuntu VM, together with Mininet and a library for writing an OpenFlow controller. At the start the switch has an empty flow table, so it forwards nothing. The student writes the flows by hand, then finishes a controller that makes the switch learn.

Nothing is installed on the student’s computer and no network equipment is needed. The hosts are network namespaces, the switch is Open vSwitch with the kernel datapath, and the commands are the real ones, ovs-ofctl, ovs-vsctl and mn.

What students learn

What software-defined networking changes: the rules for forwarding are data in a flow table, written by a person or by a program. In three parts. First Mininet, a tool that builds a whole test network, with its pingall test. Then a flow table written by hand with ovs-ofctl, in OpenFlow 1.3: a match and an action for each flow, ARP as well as IP, and a flow that drops one host on purpose. Last a controller, an application on the os-ken library, finished so that it learns which port each MAC address is on and installs a flow for it, which students read back with ovs-ofctl dump-flows.

The topology

The switch br0 has three ports. The hosts h1, h2 and h3 have the addresses 10.0.0.1, 10.0.0.2 and 10.0.0.3 and the MAC addresses ending 01, 02 and 03, so a flow can be written from the README. The switch is in fail-mode secure, so with no flow it drops every packet, which an ordinary switch never does. The student’s work goes in two files, one for the flow table and one for the controller, loaded every time the lab starts.

Run it in your browser

VM labs are set as a lab task in a module, and the sample is on the lab’s page. The machine is small: one CPU, 1 GB of memory and 10 GB of disk. The switch, its database and the controller together use about a tenth of that memory.

Add the lab. In a module you teach, add a task and choose the Ubuntu VM lab card. The page shows a short description of the machine instead of a compose file.
Start from the sample. The page offers ready-made labs to start from. Choose Software-defined networking. Using a sample replaces the text, and Undo brings yours back.
Publish and start your own copy. Publish, then Start. The lab’s own setup script installs Open vSwitch, Mininet and the os-ken controller library from Ubuntu’s archive and writes the sdnlab command, the two files to edit and the README, the first time the VM starts, in a few minutes.
Open the terminal. Open its terminal and read README.md in the home folder: it says what to do in three parts and gives none of the answers.

A basic lesson on this lab

SDN Basics is a small lesson worked in this lab, which is an Ubuntu VM. It has a hook, an I can outcome, key words, a starter, a check after each idea, a common mistake and an exit check, and each step has a Run button that types its command into the machine’s terminal. A student reads the empty flow table, sees a ping fail because nothing matches, runs Mininet’s pingall, and starts the lab’s controller as it is given to see the one flow it leaves.

The lesson looks around and leaves the lab’s own task, the flows and the learning switch, to the student, so it hands out no answers.

How it is marked

The lab has a check. It runs on a copy of the saved machine after a fresh start and loads the student’s two files itself, so a flow typed by hand and never saved does not count. With the flow file alone and no controller, h1 and h2 must reach each other, h3 must reach nobody and nobody h3, and a flow that matches h3 must drop it and have been hit by h3’s packets. The action NORMAL does not pass. Then the check starts the student’s controller, gives h2 a MAC address nobody has seen, so a table written in advance is no use, and pings between every pair. The controller must have learned each address and installed a flow with the right output port, with no flooding flow. The first line of what the check printed says why.

Hand it out. Assign the lab like any task, with a due date if you want one. Each student gets a VM of their own, kept between sessions.
Run the check. On a student’s row in the class list, press Run the check. It starts a copy of their saved machine that is not saved back, runs the lab’s check script as root and shows whether it passed, what it printed and when. The student is not told the result.
Mark it. Read the first line of what the check printed: it says what is not right, such as a host that cannot reach another with the flows in the file, or a learned flow that is missing. Send the work back with a reason if it needs more.

The definition on GitHub

The file is the whole lab definition, the same text the platform runs: size, setup script, the sdnlab tool, the controller launcher, README and check. Copy it and change the flows, the hosts or the controller task to make a longer lab.

Try this lab, and what it costs

A free personal account can work through the basic lessons in this lab, with enough free credit each month to follow most lessons and no card. For a class, a school or college has its first 365 days free for up to 50 students, then pays per student a year, with every lab included and staff free.

Questions people ask

Does the lab need an OpenFlow switch or a licence?: No. The switch is Open vSwitch, open source and in Ubuntu’s archive, and Mininet and the controller library come from the same archive. They are installed when the student’s VM starts, and nothing of them is distributed by us.
Why does the lab ship its own controller launcher?: Ubuntu’s os-ken package is a library only, with no command to run an application. The lab adds a short launcher, ctl.py, which is readable in the definition. os-ken depends on eventlet, which is deprecated and prints a notice in the controller’s log. That is why the lab teaches ovs-ofctl and Mininet first: those parts do not depend on it.
Can students harm anything?: Only their own copy. The network between the hosts is virtual and inside the VM, which reaches Ubuntu’s archive, PyPI, npm and GitHub and nothing else. If a student breaks the lab, sdnlab reset puts both files back.
Was the lab tested in a real student VM?: The setup, the lesson’s commands and the check were run in a real Ubuntu 26.04 with the kernel’s own Open vSwitch datapath, in a container standing in for the VM. A booted student VM, which starts the lab from a systemd unit and loads Ubuntu’s own kernel module, is worth one try before a class.

Create a free account to run every lab.