In-band Controller with Mininet – Part 2

Update: Some people are finding some interesting results when they have more than one switch in their topology.  I haven’t been able to confirm, but it seems that the controller will talk to the adjacent switch over the link, but when the controller needs to communicate with another switch, the management traffic might be going to the other switches via the root network namespace instead of going through another link.  One possible workaround would be to run an OVS instance for each switch in its own network namespace.  I haven’t been able to try this out yet, but if anyone has more details, we would be glad to hear about it.

Update 2 : I have been successful now running OVS in it’s own network namespace with the controller in-band.  You can see my progress here and conclusion here.

————-

In my previous post of setting up an In-band controller, I didn’t like the idea that you had to modify mininet classes to get it to work.  So I found a way to do it by introducing my own controller class called InbandController so that you can run an in-band controller without modifying the mininet code itself.  Below is the new version of the test script that will run without modifying mininet classes.

#!/usr/bin/python

from mininet.net import Mininet
from mininet.node import RemoteController, OVSSwitch
from mininet.cli import CLI
from mininet.log import setLogLevel, info

class InbandController( RemoteController ):

    def checkListening( self ):
        "Overridden to do nothing."
        return

def emptyNet():

    "Create an empty network and add nodes to it."

    net = Mininet( topo=None,
                   build=False)

    net.addController( 'c0',
                       controller=InbandController,
                       ip='10.0.0.1'  )

    h1 = net.addHost( 'h1', ip='10.0.0.1' )
    h2 = net.addHost( 'h2', ip='10.0.0.2' )
    h3 = net.addHost( 'h3', ip='10.0.0.3' )

    s1 = net.addSwitch( 's1', cls=OVSSwitch )

    net.addLink( h1, s1 )
    net.addLink( h2, s1 )
    net.addLink( h3, s1 )

    net.start()
    s1.cmd('ifconfig s1 10.0.0.10')

    CLI( net )
    net.stop()

if __name__ == '__main__':
    setLogLevel( 'info' )
    emptyNet()

This post ‘In-band Controller with Mininet – Part 2’ first appeared on https://gregorygee.wordpress.com/.

In-band Controller with Mininet

Update: See my followup post on an improvement to the script so that you don’t need to modify and MiniNet classes. But first read through this post to see how it works.

—-

There have been a few threads in the Mininet mailing list about people trying to connect a controller to a specific switch by creating a link between a switch and ‘c0’.  As people have discovered, this isn’t going to work.  But this got me thinking about how to test in-band management.  I found that Open vSwitch by default uses in-band.  So after some testing and changing node.py in mininet, I managed to actually build a working scenario of in-band management.

So what I did, which should work, but mininet had a bug/deficiency, is that first create a network script like this.

    net = Mininet( topo=None,  build=False)

    h1 = net.addHost( 'h1', ip='10.0.0.1' )
    h2 = net.addHost( 'h2', ip='10.0.0.2' )
    h3 = net.addHost( 'h3', ip='10.0.0.3' )

    s1 = net.addSwitch( 's1', cls=OVSSwitch )

    net.addLink( h1, s1 )
    net.addLink( h2, s1 )
    net.addLink( h3, s1 )

    net.start()
    CLI( net )
    net.stop()

Now here is the trick.  Since you can’t create a link to a controller, we are actually going to run a controller inside one of the hosts.  So for our test, we are going to run our controller inside h1.  So first, add this line into your script.

    net.addController( 'c0',
                       controller=RemoteController,
                       ip='10.0.0.1'  )

The other important thing to remember is that the switch itself needs an IP address.  So we add a command to the script to set the IP address on the switch to something in the same subnet.  We will insert a new line after the net.start() to set the s1 switch IP address to 10.0.0.10.

    s1.cmd('ifconfig s1 inet 10.0.0.10')

Once that is done, you should have been able to start up the script.  But when I did, the mininet hung.  I tracked it down to mininet calling a method checkListening().  Unfortunately, it hangs in here because the test is trying to see if the IP and port are there, but we gave it an address that wasn’t even routable.  So the test hangs.  So my quick hack was to remove the listen check.  The path to your python might be different depending on how you installed it and all this must be done as root/sudo.

First, remove the binary of node.py, called node.pyc.

cd /usr/local/lib/python2.7/dist-packages/mininet-2.1.0-py2.7.egg/mininet
rm node.pyc

Then modify the node.py.  Since I am running the Mininet 2.1.0 VM, go to line 1135.  It will be in the __init__() method.  Just comment out the line calling self.checkListening().

    def __init__( self, name, inNamespace=False, command='controller',
                  cargs='-v ptcp:%d', cdir=None, ip="127.0.0.1",
                  port=6633, **params ):
        self.command = command
        self.cargs = cargs
        self.cdir = cdir
        self.ip = ip
        self.port = port
        Node.__init__( self, name, inNamespace=inNamespace,
                       ip=ip, **params  )
        self.cmd( 'ifconfig lo up' )  # Shouldn't be necessary
        #self.checkListening()

Now that you modified the file and saved it, go ahead and start your script.  But at this point, if you try and run pingall, it will all fail.  That is because you didn’t start the controller yet.

mininet> pingall
*** Ping: testing ping reachability
h1 -> X X
h2 -> X X
h3 -> X X
*** Results: 100% dropped (0/6 received)

So start the controller.  First open an xterm to h1, which is where we said the controller would be.

mininet> xterm h1

When the xterm opens, start the controller. For this quick test, we will just start the OpenFlow Reference controller.

root@mininet-vm:~# controller -v ptcp:6633

At this point, you should see output from the controller like.

This means that the controller and switch are successfully talking to each other.  And if you do a pingall now.

mininet> pingall
*** Ping: testing ping reachability
h1 -> h2 h3
h2 -> h1 h3
h3 -> h1 h2
*** Results: 0% dropped (6/6 received)

Congratulations, you now have in-band testing.  There are certain cases where you would want to test this scenario.  So it is a good option to have.

This will also now allow you to add link bandwidth management parameters on the link between the switch and the node hosting the controller, such as delay and jitter, if you really want to do that.  For this example, we just used the OpenFlow reference controller.  You should be able to start any controller that you have installed on your Mininet VM.

Hope people find this useful.  My full script looks like this.

#!/usr/bin/python

from mininet.net import Mininet
from mininet.node import RemoteController, OVSSwitch
from mininet.cli import CLI
from mininet.log import setLogLevel, info

def emptyNet():

    "Create an empty network and add nodes to it."

    net = Mininet( topo=None,
                   build=False)

    net.addController( 'c0',
                       controller=RemoteController,
                       ip='10.0.0.1'  )

    h1 = net.addHost( 'h1', ip='10.0.0.1' )
    h2 = net.addHost( 'h2', ip='10.0.0.2' )
    h3 = net.addHost( 'h3', ip='10.0.0.3' )

    s1 = net.addSwitch( 's1', cls=OVSSwitch )

    net.addLink( h1, s1 )
    net.addLink( h2, s1 )
    net.addLink( h3, s1 )

    net.start()
    s1.cmd('ifconfig s1 inet 10.0.0.10')

    CLI( net )
    net.stop()

if __name__ == '__main__':
    setLogLevel( 'info' )
    emptyNet()

This post ‘In-band Controller with Mininet’ first appeared on https://gregorygee.wordpress.com/.