Running Open vSwitch in Network Namespace

Update: Look at the followup post on how I figured out getting scenario 3 to work for in-band controller.

———-

If you’ve seen some of my previous posts, you will know that I have been battling with getting in-band control working.  My first attempt was actually a failure trying to use Open vSwitch because it appeared that the packets going between two switches traversed the global routing space and didn’t actually traverse the ‘link’ that was between them.  My second attempt, which it appears I didn’t post about, but you can find a message in the MiniNet Discuss mailing list,  was a bit more promising because each switch was running in a Linux network namespace.  In Mininet, switching in network namespaces are only supported by the UserSwitch and not Open vSwitch.  This worked better, but I really wanted to get Open vSwitch working in a network namespace.

I looked in many old forum and mailing list posts looking for how to run OVS in a network namespace.  I eventually found a post saying that you will probably have to run an OVSDB and OVS in each namespace.  So, I thought I’d give it a try.  So the following is what I have been able to get working so far.  There are three stages to this attempt.

1. OVS in each network namespace running in standalone mode (standard L2 learning switch not under SDN control).
2. OVS in each network namespace running in secure mode with a local SDN controller for each switch
3. OVS in each network namespace running in secure mode with a remote in-band SDN controller

What I’ll show below is #1 and #2.  I haven’t been able to get #3 working quite yet, but this is progress.  First, the following is the MiniNet script I use for the testing.  The topology is a simple h1-s1-s2-h2 linear topology.  But to do my test, s1 and s2 are created as hosts instead of switches, which will automatically create the network namespaces and a shell to run OVS in.

#!/usr/bin/python

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

def ovsns():

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

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

    h1 = net.addHost( 'h1', ip='10.0.0.1' )
    s1 = net.addHost( 's1', ip='0.0.0.0' )
    s2 = net.addHost( 's2', ip='0.0.0.0' )
    h2 = net.addHost( 'h2', ip='10.0.0.2' )

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

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

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

The next part is to figure out the commands to run OVS. So I made up the following few scripts to make it a bit easier.

• Script to start OVSDB
• Script to start OVS daemon
• Script to create the bridge in standalone mode and attach the ports.
• Script to create the bridge in secure mode and attach the ports.

I had to make sure each OVS instance was using its own communications channel and its own DB file, logs, etc.

This first script(startOvsDb) will create the unique OVSDB instance.

#!/bin/bash

echo Starting OVSDB for $1
mkdir -p /tmp/mininet-$1

if [ -e /tmp/mininet-$1/conf.db ]; then
   echo DB already exists
else
   echo Createing OVSDB
   ovsdb-tool create /tmp/mininet-$1/conf.db /usr/share/openvswitch/vswitch.ovsschema
fi

ovsdb-server /tmp/mininet-$1/conf.db \
-vconsole:emer \
-vsyslog:err \
-vfile:info \
--remote=punix:/tmp/mininet-$1/db.sock \
--private-key=db:Open_vSwitch,SSL,private_key \
--certificate=db:Open_vSwitch,SSL,certificate \
--bootstrap-ca-cert=db:Open_vSwitch,SSL,ca_cert \
--no-chdir \
--log-file=/tmp/mininet-$1/ovsdb-server.log \
--pidfile=/tmp/mininet-$1/ovsdb-server.pid \
--detach \
--monitor

ovs-vsctl --db=unix:/tmp/mininet-$1/db.sock --no-wait init

The next script(startOvs) will start the OVS daemon.

#!/bin/bash

echo Starting OVS for $1
ovs-vswitchd unix:/tmp/mininet-$1/db.sock \
-vconsole:emer \
-vsyslog:err \
-vfile:info \
--mlockall \
--no-chdir \
--log-file=/tmp/mininet-$1/ovs-vswitchd.log \
--pidfile=/tmp/mininet-$1/ovs-vswitchd.pid \
--detach \
--monitor

This script(createBr) creates the bridge in standalone mode and adds the ports.

#!/bin/bash

echo Configure OVS for $1
ovs-vsctl --db=unix:/tmp/mininet-$1/db.sock add-br $1
ovs-vsctl --db=unix:/tmp/mininet-$1/db.sock add-port $1 $1-eth0
ovs-vsctl --db=unix:/tmp/mininet-$1/db.sock add-port $1 $1-eth1
ovs-vsctl --db=unix:/tmp/mininet-$1/db.sock set-fail-mode $1 standalone
ovs-vsctl --db=unix:/tmp/mininet-$1/db.sock show

This script(createBrSdn) creates the bridge in secure mode and adds the ports.

#!/bin/bash

echo Configure OVS for $1
ovs-vsctl --db=unix:/tmp/mininet-$1/db.sock add-br $1
ovs-vsctl --db=unix:/tmp/mininet-$1/db.sock add-port $1 $1-eth0
ovs-vsctl --db=unix:/tmp/mininet-$1/db.sock add-port $1 $1-eth1
ovs-vsctl --db=unix:/tmp/mininet-$1/db.sock set-fail-mode $1 secure
ovs-vsctl --db=unix:/tmp/mininet-$1/db.sock set-controller $1 tcp:127.0.0.1:6633
ovs-vsctl --db=unix:/tmp/mininet-$1/db.sock show

To test the standalone mode, I run the MiniNet script at the top of the post to create the network and the start an xterm to both switches (s1 and s2).  In each xterm I run the three scripts to start OVS up.  Open vSwitch in standalone mode is just running OVS as a regular L2 learning switch that is not under an SDN controller.

In the xterm for S1:

startOvsDb s1
startOvs s1
createBr s1

In the xterm for S2:

startOvsDb s2
startOvs s2
createBr s2

Then, from an xterm to the host h1, I run a ping to h2 and all worked great.  I’m feeling good at this point. One note here, I haven’t done the script to cleanup. I seems that quiting MiniNet does not kill off OVS in each namespace.  So I eventually will need to write a script that will do the following in each network namespace.

• Delete the bridge
• Stop OVS daemon
• Stop OVSDB

So with it all cleaned up, I do the same test but having each switch running a controller in its network namespace.   This will prove that SDN control and that each controller is listening an the same port but  in different network namespace.

In the xterm for S1:

startOvsDb s1
startOvs s1
createBrSdn s1
controller -v ptcp:6633

In the xterm for S2:

startOvsDb s2
startOvs s2
createBrSdn s2
controller -v ptcp:6633

Now, each switch is listening to its own controller.  I run the ping test again and all is good.

So to be anticlimactic, this is where it ends for now.  I haven’t been able to get scenario #3 working yet where all of the switches are talking to the same SDN controller that is running on a remote host and not locally on each switch.  I did get this working using the UserSwitch, so I must have missed a step or OVS is doing something to get in the way.  Hopefully I’ll figure it out.  Hopefully, this post will give some people some ideas.

This post ‘Running Open vSwitch in Network Namespace’ first appeared on https://gregorygee.wordpress.com/.