How to connect OpenFlow switches to multiple controllers (Mininet)

Original post is here.


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

def myNet():

    #OpenDayLight controller

    #Floodlight controller

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

    # Create nodes
    h1 = net.addHost( 'h1', mac='01:00:00:00:01:00', ip='' )
    h2 = net.addHost( 'h2', mac='01:00:00:00:02:00', ip='' )

    # Create switches
    s1 = net.addSwitch( 's1', listenPort=6634, mac='00:00:00:00:00:01' )
    s2 = net.addSwitch( 's2', listenPort=6634, mac='00:00:00:00:00:02' )

    print "*** Creating links"
    net.addLink(h1, s1, )
    net.addLink(h2, s2, )   
    net.addLink(s1, s2, )  

    # Add Controllers
    odl_ctrl = net.addController( 'c0', controller=RemoteController, ip=ODL_CONTROLLER_IP, port=6633)

    fl_ctrl = net.addController( 'c1', controller=RemoteController, ip=FL_CONTROLLER_IP, port=6633)

    # Connect each switch to a different controller
    s1.start( [odl_ctrl] )
    s2.start( [fl_ctrl] )

    s1.cmdPrint('ovs-vsctl show')

    CLI( net )

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

Openvswitch Module

If you’re getting kernel module installation errors, probably the module is not compiled for the current kernel or its dependencies are not loaded.

# insmod datapath/linux/openvswitch.ko


datapath/linux/openvswitch.ko: Unknown symbol in module

By using the command modinfo, you can take clues about the module, such as its dependencies and kernel version that was used to compile.

If the problem is dependencies, instead of using insmod to install openvswitch.ko module, you can first type the command in the OVS root directory (after compiling):

# make install

This will install all compiled modules in the Linux system. Then, type:

# modprobe openvswitch

The command should automatically load openvswitch module and its dependencies.

Read line-by-line in bash

From the original post:

The following (save as reads a file passed as an argument line by line:

while IFS='' read -r line || [[ -n "$line" ]]; do
    echo "Text read from file: $line"
done < "$1"


  • IFS='' (or IFS=) prevents leading/trailing whitespace from being trimmed.
  • -r prevents backslash escapes from being interpreted.
  • || [[ -n $line ]] prevents the last line from being ignored if it doesn’t end with a \n (since read returns a non-zero exit code when it encounters EOF).

Run the script as follows:

chmod +x
./ filename.txt

OVS kernel’s table entry timeout

How long a kernel’s table entry can be inactive? The OVS kernel’s table can inactive, by default, during a time interval less than 5 seconds. After 5 seconds being inactive, the flow entry is removed from the table. This time is dictated by ovs-vswitchd.

From the original post:

”ovs-vswitchd determines how long the flow should stay in the kernel flow table. By default, it expires a flow after five seconds of inactivity. It can be more aggressive if the flow table becomes large.”

ovs-dpctl: description ‘used=never’

Original post here.

When using ovs-dpctl, there are flow descriptions with “used=never”. What does it mean? It means that a packet went up to the userspace (ovs-vswitchd), a match was found and it was copied to the kernel space. However, there were no more following packets that matched the rule cached in the kernel’s table.


Differences between ovs-ofctl and ovs-dpctl

Basically, ovs-ofctl is used to look up for the actual flow table entries. And, ovs-dpctl can be used to see what is inside of the OVS’s kernel table, which can be considered as flow table, but OVS kernel module actually does not speak OpenFlow, i.e., it doesn’t handle OpenFlow messages.

The number of entries retrieved by ovs-ofctl and ovs-dpctl can be different. That is because only the matched entries in user-space are copied to the kernel-space. More details may be found in the OVS official website.

From the original post.
ovs-ofctl dump-flows” prints OpenFlow flow table entries.

ovs-dpctl dump-flows” is different.

As the manpage says:

This command is primarily useful for debugging Open vSwitch. The flow table entries that it displays are not OpenFlow flow entries. Instead, they are different and considerably simpler flows maintained by the Open vSwitch kernel module.

In a little more detail, the flows that ovs-dpctl prints are always exact-match. They reflect packets that have actually passed through the system in the last 5 seconds or so.

If you want to know what OpenFlow sees, use ovs-ofctl. If you want to verify that the OpenFlow flows are being implemented in the way you expect, ovs-dpctl is the right tool.

JMX connector error

If you’re running ONOS, you might have seen the following error:

Exception in thread "JMX Connector Thread 
java.lang.RuntimeException: Could not start JMX connector server

I got this issue once, and I solved by replacing ‘‘ with a meaningful IP address, such as ‘‘. All I had to do, was to edit the file  ‘ ‘

$ cd apache-karaf-3.0.3/etc
$ vim

That’s all,