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/.

Advertisements

6 Responses to In-band Controller with Mininet – Part 2

  1. Pingback: In-band Controller with Mininet | Tech and Trains

  2. Are you sure this works? Because neither h1 can ping s1, nor s1 can ping h1. In this case, how will s1 be able to connect to a TCP app running on h1?

  3. Joseph Beshay says:

    How does this line work?
    s1.cmd(‘ifconfig s1 10.0.0.10’)

    I am trying with Mininet 2.1.0+ and the switch doesn’t have an interface named s1. Only s1-eth1/2/3

    • gregorygee says:

      If you run ifconfig, you will see an interface for each switch that has the name of the switch. As an example, if I just run the basic Mininet topology `sudo mn`, I would see the following when I run ìfconfig on the system or VM that is running Mininet. These interfaces only exist while the switch and Mininet are running.

      s1        Link encap:Ethernet  HWaddr 36:db:b7:a2:5d:48
                UP BROADCAST RUNNING  MTU:1500  Metric:1
                RX packets:9 errors:0 dropped:0 overruns:0 frame:0
                TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
                collisions:0 txqueuelen:0
                RX bytes:678 (678.0 B)  TX bytes:0 (0.0 B)
      
      s1-eth1   Link encap:Ethernet  HWaddr 92:c3:8a:ab:43:a2
                UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
                RX packets:6 errors:0 dropped:0 overruns:0 frame:0
                TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
                collisions:0 txqueuelen:1000
                RX bytes:468 (468.0 B)  TX bytes:300 (300.0 B)
      
      s1-eth2   Link encap:Ethernet  HWaddr fa:f1:a4:82:10:41
                UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
                RX packets:6 errors:0 dropped:0 overruns:0 frame:0
                TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
                collisions:0 txqueuelen:1000
                RX bytes:468 (468.0 B)  TX bytes:378 (378.0 B)
      
      • Joseph Beshay says:

        Apparently something is wrong with the copy of openvswitch I had built myself. I replaced that with one from a prebuilt package for Debian and it worked fine.

        I will dig further into my build to see why it’s broken. Thanks for your response.

      • gregorygee says:

        I wrote a good post here on how to upgrade the OVS that comes with Mininet installation. I`ve used these instructions to upgrade to several different version including OVS 2.0.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: