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

 

Advertisements

7 Responses to Running Open vSwitch in Network Namespace

  1. Pingback: Running Open vSwitch in Network Namespace with In-Band Controller | Tech and Trains

  2. Fari says:

    Hi,

    Thanks a lot for your contribution. it is a greatful help.
    Actually I am new to bash script.
    would you mind tell me where should I save the bash file?

    Cheers,
    Fari

    • gregorygee says:

      The bash files can be saved anywhere on the PC or VM that is running Mininet. The mininet hosts all have access to the same host filesystem.

      • Fari says:

        Hi,

        Thanks for your reply. It’s soloved but I have another problem.

        when I made the topology and run it after opening Xterm for switches, I tried to make an OVSDB on one of the switches (by ./startOvsDb s2)that this error comes to screen.

        root@ubuntu:~/mininet# ./startOvsDb s2
        Strating OVSDB for s2
        Creating OVSDB
        Aug 21 07:49:41|00001| lockfile|INFO|/tmp/mininet-s2/.conf.db.~lock:lock file does not exist, creating
        ovsdb-server: processing “console:emer”:unknown faciliy “emer”
        Aug 21 07:49:41|00002| stream-unix|ERR|/tmp/stream-unix.2939.0: connection to /tmp/mininet-s2/db.sock failed: No such file or directory
        Aug 21 07:49:41|00003| reconnect|WARN|unix: /tmp/mininet-s2/db.sock: connection at tempt failed (No such file or directory)
        Aug 21 07:49:42|00004| stream-unix|ERR|/tmp/stream-unix.2939.1: connection to /tmp/mininet-s2/db.sock failed: No such file or directory
        Aug 21 07:49:42|00005| reconnect|WARN|unix: /tmp/mininet-s2/db.sock: connection at tempt failed (No such file or directory)
        ….

        I can’t find proper solution to solve that. would you mind help me in it?

      • gregorygee says:

        This is a little tricky to debug what happened. You could add a few print/echo commands in the script to at least find out which command it is failing at. The error message about console:emer is interesting. The command line option might not be valid for certain versions of OVS. What version are you using?

        One thing you could look at, is that when you installed OVS, a copy should already be running. Try running a ‘ps -ef | grep ovsdb’ and see how different the parameters are compared to what the script runs. My scripts were just using the same command line parameters that my current system already did. You might have to tailor the script to match you system. Just use the same parameters, but anywhere that a file or directory is passed, just provide the alternate location like the script is doing.

  3. Fari says:

    Hi, thanks again for your reply.

    The version of OVS is as follow:

    ” ovs-vswitchd (Open vSwitch) 1.4.6
    Compiled Jan 10 2014 01:45:48
    OpenFlow versions 0x1:0x1 ”

    I also ran “ps -ef | grep ovsdb” then the result is :

    root 1246 1 0 07:32 ? 00:00:08 ovs-vswitchd: monitoring pid 1247 (healthy)
    root 1247 1246 0 07:32 ? 00:00:01 ovs-vswitchd unix:/var/run/openvswitch/db.sock -vANY:CONSOLE:EMER -vANY:SYSLOG:ERR -vANY:FILE:INFO –mlockall –no-chdir –log-file=/var/log/openvswitch/ovs-vswitchd.log –pidfile=/var/run/openvswitch/ovs-vswitchd.pid –detach –monitor

    As u told me the parameters are different, so I changed the part of startOvsDb &startOvs script to :

    -vANY:CONSOLE:EMER \
    -vANY:SYSLOG:ERR \
    -vANY:FILE:INFO \

    my problem is solved, but not compeletly. Actually, I got this error after updating the script and runnig again.

    root@ubuntu:~/mininet# ./startOvsDb s1
    Strating OVSDB for s1
    DB already exists
    ovsdb-server: “db:Open-vSwitch,SSL,certificate”: table “Open-vSwitch” has no column “SSL”
    Aug 27 15:32:55|00002| stream-unix|ERR|/tmp/stream-unix.3639.0: connection to /tmp/mininet-s1/db.sock failed: No such file or directory
    Aug 27 15:32:55|00003| reconnect|WARN|unix: /tmp/mininet-s1/db.sock: connection attempt failed (No such file or directory)
    Aug 27 15:32:56|00004| stream-unix|ERR|/tmp/stream-unix.3639.1: connection to /tmp/mininet-s1/db.sock failed: No such file or directory
    Aug 27 15:32:57|00005| reconnect|WARN|unix: /tmp/mininet-s1/db.sock: connection attempt failed (No such file or directory)

    would you mind help me with that?

    Thanks a lot,
    Fari

    • Fari says:

      I did ‘ps -ef | grep ovsdb-server’ on my PC, the result was as below:

      ovsdb-server /etc/openvswitch/conf.db
      -vANY:CONSOLE:EMER
      -vANY:SYSLOG:ERR
      -vANY:FILE:INFO
      –remote=punix:/var/run/openvswitch/db.sock
      –remote=db:Open_vSwitch,manager_options
      –private-key=db:SSL,private_key
      –certificate=db:SSL,certificate
      –bootstrap-ca-cert=db:SSL,ca_cert
      –no-chdir
      –log-file=/var/log/openvswitch/ovsdb-server.log
      –pidfile=/var/run/openvswitch/ovsdb-server.pid
      –detach
      –monitor

      So I updated “startOvsDb” and “startOvs” Script on my PC according to the above parameters.But l left the directory references in the script to stay the same as your script and not the same as the default OVS.

      So it works for me…Thanks a million for your help.

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: