In our last article, we continued work on our virtual workspace by installing and using Postman with Ryu’s REST API. This time, we are going to look at creating custom Mininet topologies by writing Mininet profiles in Python. Now that we are creating and modifying code and will need some additional project organization, we will start using Atom as our base editor and IDE. We are choosing Atom here because it’s expandable, contains all the features we need for developing OpenFlow controller applications, and is available for all major platforms. This article and future articles will show screenshots and videos with interacting with Atom as the editor, but you are more than welcome to use a different editor if you like.

We’ve also added an overview video for this article:

Atom Setup

Defining Mininet Topologies

Now that we have an editor set up, let’s look at how Mininet Topologies are defined. From the previous examples, we’ve been running mininet using only command line options, like this:

This actually works pretty well for simple tests. There are even more complicated topologies that are built in to Mininet, including Tree and Torus. Let’s say we want a custom topology that might reflect a real-world network. Thankfully, Mininet provides a rich scripting environment that makes emulating custom topologies very simple.

Creating a Mininet Project

While experimenting with topologies, we will need a place to store the topology scripts. Let’s create a new directory under our workspace directory:

If you are using Atom, go ahead and add this as a project folder:

Now on to our first topology.

Simple Topology Creation

Before getting into more advanced topologies, let’s create the simplest Mininet script that will allow us to apply a topology and give us a CLI prompt like the Mininet commands we’ve been running so far. Create a new file called ‘minimal.py’ in the Mininet Topologies project directory created above.

With this script, there are a couple options to run it. First, make sure Ryu is running in a separate terminal with the OF1.3 version of simple switch and optionally the REST API:

The last line in the script provides a hook to the mn command that allows it to be imported and the custom topology to be used:

But what if we wanted a script to automatically set up the network with the options we’ve been providing the mn command all this time? We can add a bit more to the script:

The script can now be run directly and it will run the runSimpleTopo function, which sets up the global network defaults for us:

You can do a lot with scripting the creation of the Mininet network such as automated testing, automatically starting Ryu and more. For simplicity’s sake in this article, we will keep to the first form and use the mn command. We will touch on automated environments in a future article.

Building a Datacenter Topology

In this topology, we have four racks, each with four hosts and a single top-of-rack (ToR) switch. These ToR switches are connected to a central root switch. This represents a simple datacenter.

This topology isn’t all that different from a standard tree topology, but it does demonstrate how to write a topology that is closer to a real network. Ryu’s simple switch shouldn’t have any problem managing this either:

In order to keep track of which host belongs to which rack, the names of the hosts and switches are customized. All switches still start with s#, but is suffixed by the rack specified as r#. the only switch that doesn’t have a rack suffix is the root switch. Additionally, the hosts are named similar so that h3r2 means host 3 on rack 2.

Making the Topology Configurable

Our previous topology is a bit too rigid and static. Let’s add the ability to specify how many hosts we want in each rack and how many racks in our network straight from the command line.

The topology configuration is in the form of dsconfig,<numRacks>,<numHostsInRack> and can be specified as just dsconfig for the default of 4 and 4. You could also only specify the number of racks and use the default hosts-per-rack like dsconfig,6 (6 racks, 4 hosts per rack).

Adding Redundant Links

In a real datacenter, you will most often have more than one root switch linked in a ring pattern with at least two links going to each ToR switch. This allows for a failure of one of your root switches without bringing down your entire network. Implementing that is simple enough:

However, this does create a problem: loops. Just adding the topology now will cause the network to crumble because our simple switch doesn’t have any basic loop management such as STP. If you kept the original Ryu controller running, you may notice a flood of packets being reported. You may have to press Ctrl+C repeatedly in order for it to stop.

Thankfully, Ryu includes a simple switch implementation with STP. Stop the existing Ryu controller and start a new one loading the ryu.app.simple_switch_stp controller application. Note that this example STP switch app only supports OF 1.0, though the library it uses supports OF 1.0 and 1.3.

Then in the other terminal, run Mininet again with the same mn command above. You will immediately see learning entries in the log. Running a pingall right away may result in some packet loss before the entire topology is learned by the controller.

The first minute or so running the pingall command will result in packet loss while the controller is learning the network topology. Eventually, the pingall command will complete with no packet loss.

Full Redundancy

As a final addition to our datacenter topology, let’s configure it so that every rack has two ToR switches, each connected with a single link to the root switches and provide every host with a connection to both ToR switches in that rack.

Run the topology:

After a few moments (look for FORWARD log entries in Ryu), run the pingall command and it should pass with no packet loss.

While we have pingall passing here, it is important to note that we did not go into each host and configured some sort of link aggregation to actually prepare for a switch or link failure. This will be covered in future topics. This does demonstrate, however, that you can emulate nearly any network L2 topology fairly easily. In a real-world environment, STP is probably not the best protocol for HA networks and more advanced switch control would be needed in the controller or from the controller’s base libraries. For example, the ryu.app.simple_switch_stp example app uses an STP library provided by Ryu’s internals.

Automated Testing

Included in the downloadable content for this article is the full source for all the examples above and an automated test script that will test each of those examples. It will even start and stop Ryu with the appropriate controller applications loaded! We’ll be touching more on automated testing with Mininet in a later article, but take a look at the datacenterTests.py file for an example.

To run the tests, assuming you extracted the archive in ~/ofworkspace/, run:

At the end, you should see all tests pass:

You may notice that a couple of the tests (specifically the ones using STP) drop some packets. This is normal and the test allows 15 packets to drop to accommodate the learning period required. Feel free to play around with the test code and see if you can make it so the ping test always passes with zero packet loss. It is possible! =)

We’ve hoped you enjoyed this topic and that you will visit us for the next in the series where we start building our own pluggable Ryu controller app. Make sure to sign up to our mailing list to be notified when these articles are published. Also, please feel free to ask questions and leave comments below. We are always welcome to feedback so we can provide the best content possible.

As always, Happy Coding! =)