Experimenting with Mininet

Mininet enables you to quickly create, customize, interact with, and share an OpenFlow prototype. Mininet's command line can be used to create a network (hosts and switches). Its CLI allows you to control and manage your entire virtual network from a single console. Furthermore, Mininet's API allows you to develop custom network applications with a few lines of Python script. Once a prototype works on Mininet, it can be deployed on a real network.

In this sample experiment, we will use the default topology of Mininet (by running $ sudo mn). This topology includes one OpenFlow switch connected to two hosts, plus the OpenFlow reference controller. This topology can also be specified on the command line with --topo=minimal. Other topologies are also available out of the box in Mininet; refer to the --topo section in the output of mn -h. You can display nodes, links, and dump information about all nodes in the setup using the following commands, respectively:

    $ sudo mn
mininet> nodes result: available nodes are: c0 h1 h2 s1 mininet> net result: h1 h1-eth0:s1-eth1 h2 h2-eth0:s1-eth2 s1 lo: s1-eth1:h1-eth0 s1-eth2:h2-eth0 c0 mininet> dump result: <Host h1: h1-eth0:10.0.0.1 pid=5066> <Host h2: h2-eth0:10.0.0.2 pid=5068> <OVSSwitch s1: lo:127.0.0.1,s1-eth1:None,s1-eth2:None pid=5073> <Controller c0: 127.0.0.1:6653 pid=5059>

Upon execution of the Mininet emulation environment with the default topology, the OpenFlow controller and switch initiate the OpenFlow protocol, which can be captured and viewed in the Wireshark capturing window. The following screenshot shows the captured traffic, which shows the Hello message, feature request/reply and several packet-in messages. This confirms that the OpenFlow switch in this setup is connected to the OpenFlow controller:

OpenFlow traffic, which is captured in Wireshark

If the first string typed into the Mininet CLI (mininet>) is a host, switch, or controller name, the command is executed on that node. For example, you can see the Ethernet and loopback interface of the first host (h1) using the following command:

    mininet> h1 ifconfig -a

Now we can check the connectivity of each host with a simple ping command:

    mininet> h1 ping -c 1 h2  

This command sends a single ping packet from h1 to h2. The first host (h1) ARP for the MAC address of the second (h2) causes a packet_in message to go to the OpenFlow controller. The controller then sends a packet_out message to flood the broadcast packet to other ports on the switch (in this example, the only other data port). The second host observes the ARP request and sends a broadcast reply. This reply goes to the controller, which sends it to the first host and pushes down a flow entry to the flow table of s1 (OpenFlow switch):

The captured traffic after issuing an h1 ping -c 1 h2 command in Mininet

Now the first host knows the IP address of the second and can send its ping via an Internet Control Message Protocol (ICMP) echo request. This request and its corresponding reply from the second host both go to the controller and result in a flow entry pushed down. The actual packets are sent out too. In our setup, the reported ping time is 3.93 ms. We repeat the same ping command one more time:

    mininet> h1 ping -c 1 h2  

The ping time for the second ping command is decreased to just 0.25 ms. A flow entry covering ICMP ping traffic was previously installed in the switch, so no control traffic was generated and the packets immediately pass through the switch.

An easier way to run this test is to use the Mininet CLI built-in pingall command, which does an all-pairs ping. Another useful test is a self-contained regression test. The following command created a minimal topology, started up the OpenFlow reference controller, ran an all-pairs-ping test, and tore down both the topology and the controller:

    $ sudo mn --test pingpair  

Another useful test is the performance evaluation using iperf:

    $ sudo mn --test iperf  

This command needs a few seconds to complete. It creates the same Mininet topology (one controller, one switch, and two hosts) and runs an iperf server on one host, an iperf client on the second host, and reports the TCP bandwidth between these two hosts.

Using Mininet's Python API, it is possible to define custom topologies for experiments. A built-in example is provided in ~/mininet/custom/topo-2sw-2host.py. This example connects two switches directly, with a single host connected to each switch:

"""Custom topology example 
Two directly connected switches plus a host for each switch: 
   host --- switch --- switch --- host 
  h1 <-> s3 <-> s4 <-> h2 
Adding the 'topos' dict with a key/value pair to generate our newly defined 
topology enables one to pass in '--topo=mytopo' from the command line. 
""" 
from mininet.topo import Topo 
class MyTopo( Topo ): 
    "Simple topology example." 
    def __init__( self ): 
        "Create custom topo." 
        # Initialize topology 
        Topo.__init__( self ) 
        # Add hosts and switches 
        leftHost = self.addHost( 'h1' ) 
        rightHost = self.addHost( 'h2' ) 
        leftSwitch = self.addSwitch( 's3' ) 
        rightSwitch = self.addSwitch( 's4' ) 
        # Add links 
        self.addLink( leftHost, leftSwitch ) 
        self.addLink( leftSwitch, rightSwitch ) 
        self.addLink( rightSwitch, rightHost ) 
        topos = { 'mytopo': ( lambda: MyTopo() ) } 

This Python script can be passed as a command-line parameter to the Mininet. When a custom Mininet file is provided, it can add new topologies, switch types, and tests to the command line. For instance, a pingall test can be executed using the mentioned topology with the following invocation of Mininet:

$ sudo mn --custom ~/mininet/custom/topo-2sw-2host.py --topo mytopo 
--test pingall

For more complex debugging and to have access to the console of hosts, switch(es), or controller(s), you can start Mininet with the -x command-line parameter (that is, sudo mn -x). The xterms, which will pop up, are useful for running interactive commands. For instance, in the xterm labeled, switch: s1 (root), you can run this:

# dpctl dump-flows tcp:127.0.0.1:6634  

Since the flow table of the switch s1 is empty, nothing will print out. Now in the xterm of host 1 (h1), you can ping the other host (h2) using a normal ping command (# ping 10.0.0.2). If you go back to the xterm of switch s1 and dump the flow table, you should see multiple flow entries now. You can also use the dpctl built-in command in Mininet.

This was just a brief introduction to Mininet. In next chapters, we will use Mininet as part of our setup for experimenting with OpenFlow controllers and for the development of network applications. Those of you interested can find more details on the Mininet website at http://mininet.org/.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset