↓Skip to main content

Welcome to Mininet

·11 mins

What is Mininet? #

The thing is that while Software-Defined Networking is pretty great to look forward to, the equipment for the required infrastructure is rare to come across, and expensive to manufacture due to a lack of demand.

So, how does one attempt to run a Software-Defined Network in the first place? Well, the answer is emulation. Most researchers during their investigation, tend to test out their architecture on emulated hardware that mimics the results of real-life equipment. Networking has come pretty far and testing out the viability of a network virtually is a great way to reduce expenditure, whilst also having the freedom to experiment.

So, here comes in Mininet. A network emulation tool, that one can use to develop, share and experiment with Software-Defined Networks. Mininet is honestly the foundation upon which the research of the SDN community is built upon. I’m pretty sure that a lot of the research in this space depends entirely on the accuracy of Mininet.

Mininet is largely regarded as an industry standard and is widely accepted for network emulation. As such, it’s a good idea to test out your application via mininet. Let’s get started!

What does a basic network have? #

While your general networks consist of two components, hosts and switches/routers, SDN networks comprise of three components,

  1. Hosts

These devices essentially act as your host computers in a network. Each host is it’s own entity, and you could assume that they’re something like a Raspberry Pi, or a laptop at your house. These devices could be used to emulate traffic in your network, either by sending packets/information from them, or by directing network packets to them.

We can summon forth a CLI to “log-in” to the host itself with the xterm [host] command. This allows for us to access the command line of the machine.

  1. Switches

These devices are like your generic network switches which are responsible for directing traffic to the appropriate receiver devices, however, there is a distinction present between the ones present in a traditional network and ones present in an SDN.

That is, these switches are “OpenFlow Switches”, which means that they follow the OpenFlow protocol unlike your traditional switches. OpenFlow is a protocol made specifically for the implementation of Software-Defined Networking, where the network is managed through the switch’s packet lookup and rule-checking. These factors enable or disable the network packet from reaching the destination in a specified manner.

  1. Controller

A controller in the network is the one that is contacted when the switch does not know where to direct a network packet.

The controller has a global view of the network and is in-charge of monitoring the network. This is the one key element that sets the SDN paradigm apart from the traditional networking model. In that, the controller provides an interface for the network administrator to orchestrate a whole bunch of operations through control layer commands, rather than have to interact with every switch/router in the network to modify a certain property of the network.

Emulating a basic network with Mininet. #

There are a few instructions that are to be followed for the installation of Mininet on your computer. But, it’s rather straightforward, in most cases and depends on the operating system that you’re working with. If you wanna get into it as far as you can, I’d recommend Option 1: Mininet VM Installation.

I do recommend that you initialize a Virtual Machine to work with Mininet. The network emulation sometimes messes with your internal network configuration and doing a fresh start with your VM is a lot easier than attempting to reset your entire system.

So, now that you know what a basic network is comprised of, we can now proceed to make one. We’ll first be working with the default topology that Mininet provides us.

This architecture contains a single controller, single switch, and two hosts, and it will be connected as shown in the below figure.

flowchart LR; A[Host A]-->B[OpenFlow Switch]; B-->C[Controller]; C-->B; B-->D[Host B];

Btw, experimenting is definitely viable in Mininet, and there’s a bunch of different topologies that you can try out as well. Here’s the link to the documentation section that allows you to try out other topologies.

The 2 switch, 1 ap, 1 controller connection can be set up through a simple command.

sudo mn --topo single,2

This should set up the network and trigger the command line interface to interact with the network as well. If something goes wrong, try running a sudo mn -c. This command cleans up the network, and we can attempt to set up the network once more. If everything goes alright, you should face a prompt like below,

mininet>

You can check for the different components present in the network, through a few commands,

  1. nodes - Displays the available nodes in the network.
mininet> nodes
  1. links - Displays the links in the network.
mininet> links
  1. net - Lists out all the network connections.
mininet> net

An important part of setting up the network is to ensure that hosts can communicate with each other. If there are discrepancies in the communication process, then it’s best to restart the network and retry, or to check your topology for errors.

To check if a host can successfully ping another host, you can run the ping command,

mininet> h1 ping h2

But, what exactly happens when a host tries to ping another host? #

The following are the steps that take place in the backend when you call for a ping between the hosts.

  1. h1 sends the network packet to the switch.
  2. The switch checks it’s Flow Table Records, to see if it has an entry corresponding to the destination station.
  3. If it is unable to find the record, it contacts the controller.
  4. The controller checks the global view of the network and determines the path that needs to be traveled by the packet to reach the destination.
  5. It sends the flow table record to the switch to allow it to forward the packet to the destination station.
  6. The switch checks the flow table record for the rules, and if there are no restrictions that require the switch to drop or redirect the packet, it is forwarded to wherever the destination is supposed to be.
  7. The packet is successfully forwarded to the destination host.
  8. The initial station might wish to send another packet now, repeating the cycle.
  9. The switch no longer contacts the controller since the record is directly present in it’s flow tables.
  10. The record is looked up and the packet is forwarded at a fraction of the previous time.

This process of reducing the response time through persistent storage of flow records in the switches is what makes an SDN, an SDN!

Plugging an external controller into the equation. #

While the aspect of having a controller provisioned by Mininet itself is quite appealing since it reduces the integration effort for us, we don’t quite get enough information from the Mininet Controller at all.

In fact, we get nearly nothing. So, what do we do? Well, of course, we use a different controller that provides us with a lot more functionality!

The options for Controllers in the current day are pretty wide, and there’s quite a few options to pick from as well.

  1. Ryu
  2. OpenDaylight
  3. Floodlight
  4. Faucet SDN
  5. Beacon
  6. ZeroSDN
  7. POX
  8. NOX
  9. ONOS …etc

But, while all these SDNs are great, each of them come with their own advantages and disadvantages. For example, while Ryu is a pretty good controller to start out with due to it’s minimal configuration setup, it isn’t the best at providing a visual interface to understand the working of the network. On the other hand, ONOS is a great controller at manipulation of the network, but setting it up is painful and being as heavy of a controller as it is, it does not allow for deployment in IoT.

So, it’s perhaps imperative to decide what kind of controller you would wish to work with. Some industries decide that ODL is what they wish to work with, while others believe in the Faucet supremacy. To each their own, I say. But, in the end, they all still need to connect to the network.

We’ll be working with the Ryu Controller in most articles. In order to work with the Ryu Controller, we’ll need to add components into it, and run ryu-manager that manages these components. This can be done as follows. (navigate to the ryu/ryu/app/ directory to follow)

Syntax: ryu-manager [packages].py
$> ryu-manager simple_switch_12.py ofctl_rest.py

In order to connect to the Mininet network as an external controller, one needs to use the RemoteController class. In CLI, this could be done through flag parameters.

Syntax: sudo mn --controller=remote,ip=[ip],port=[port]
$> sudo mn --controller=remote,ip=192.168.0.25,port=6653

This allows for the mininet instance to understand that there is a controller running at a particular IP address and that it needs to use the given port to connect to it. And, just like that, we’ve connected a controller to the network!

The following is the URL to request for information on the switches that are present in the network through the Ryu Controller. We leverage the functionality of ofctl_rest.py, to inquire into the status of the network.

GET http://[controller-ip]:8080/stats/switches

In Python, this same request could be executed in a few simple lines, and iterated over to be presented in a more user readable format.

#!/usr/bin/python
"""
A simple script to retrieve the switches present in the
network.
"""
import requests

RETRIEVE_SWITCHES_QUERY = "http://localhost:8080/stats/switches"

# retrieves the switches present in the network from
# controller
switches = json.loads(requests.get(RETRIEVE_SWITCHES_QUERY).text)
print(*switches)

Upon execution, the above program should output the switches in the network. Iterating through these switches should allow for you to perform operations on every switch in the network in an automated fashion as compared to manually going to every switch and performing operations on it. (As mentioned at the start of the article)

Going from Mininet to Mininet-WiFi #

Mininet is cool and all, but the fact of the matter is that technology has advanced to a point where wired connections are only one of the mediums of network usage, and internet connectivity. Nowadays, Wi-Fi enabled systems are all the hype and this brings us to an extension of the Mininet network emulation software, Mininet-Wifi.

Mininet-Wifi is a fork of Mininet, and adds in the feature set of wireless networks through virtualized Wi-Fi Stations and Access Points to support the emulation of WiFi-enabled SDN ecosystems.

There are minute differences with regards to the notations/naming conventions for the devices.

Stations, are essentially hosts but with functionality that allows them to connect to WiFi, and the Access Points in the network area.

Access Points, or APs, are essentially switches but with a network coverage area. They function much like the WiFi modem or router in your household, integrating OpenFlow functionality like the OpenFlow switches from Mininet.

It helps to think of hosts as computers, and stations as laptops, in that one of them is stationary (to a degree) while the other one is mobile. Switches and Access Points are pretty much the difference between a wired connection in comparison to a wireless connection.

While the transition between Mininet and Mininet-Wifi in terms of functionality doesn’t differ all too much, there are issues that you might face during the installation procedure that might have you hit a roadblock. In order to hit the ground running, I would personally recommend installing the Mininet-Wifi Virtual Machine and working with that rather than performing a manual installation. Helps reduce build errors in most aspects.

Anyway! Once you’re done with the installation procedure, it’s time to get comfortable with using Mininet-Wifi, which is pretty straight forward given the similarities it shares with Mininet.

$> sudo mn -w
OR
$> sudo mn --wifi

The above command can be used to emulate a basic wireless SDN network consisting of two stations, one AP and a controller.

I suppose you can already see which Mininet topology this replicates. ;)

Displaying your architecture #

Setting up a network architecture is cool and all, but you know what’s cooler? Being able to see it.

While Mininet doesn’t quite need the topology view aspect as much since there’s no mention of mobility in wired connections, mobility is a huge feature of Mininet-Wifi. Setting up a graph to view your topology and stations migrating in real-time is a lot of fun and can be triggered simply by adding one line to your script!

net.plotGraph(max_x=1000, max_y=1000)

This allows for you to view the graph in real-time, even if you don’t have migration features, it’s still a good way to view as to whether your connections have been set up as you’ve intended them to be.

That’s about it for now! #

This article is pretty short, but that’s the point. It’s supposed to serve as an entry point into working with Software-Defined Networks.

However, that doesn’t mean that all of it ends here! I’ll be back with more articles on building SDN networks, and setting up applications in the SDN space in general soon. I’ll also be adding in references periodically to look into in order to gain a better footing in this domain.

Until next time.

↑