OpenFlow Overlay Network

Introduction

The Makefile contained on the git repository can be used by an experimenter to dynamically create an overlay network in a PlanetLab slice, using the sliver-openvswitch distribution.

The overlay network supported by the Makefile may consist of:

  • at most one Open vSwitch bridge per sliver;
  • at most a pair of tunnels between each pair of slivers.

(Please note that these limitations are due to the simple naming scheme adopted by the Makefile, and are not limitations of sliver-openvswitch.)

Each bridge is connected to a tap device in the sliver. The tap device has an IP address chosen by the experimenter. The idea is to connect all the tap devices through the overlay network made up of Open vSwitch bridges and tunnels among them.

Please note that the tap device IP address is required for technical reasons, even if you do not plan to use it.

Installation

In new slices, sliver-openvswitch comes preinstalled together with the vsys scripts it needs. All you have to do is contact the PlanetLab Support team and ask for a private IP subnet for your slice.

On older slices you may have to install sliver-openvswitch on each sliver and obtain the following tags: 

NAME		VALUE
vsys		fd_tuntap
vsys		vif_up
vsys		vif_down
vsys		promisc
vsys_net	(some subnet)

On the experimenter box we need:

  • GNU make
  • the openssh client
  • the host program (usually distributed in bind-tools)
  • (optionally) the dot program from the graphviz distribution

Then, we can simply copy the Makefile in a working directory on the experimenter box 

$ mkdir work
$ cp /path/to/Makefile work
$ cd work
$ make init

The last command creates some subdirectories that are later used by the Makefile.

Example usage

Assume we have a PlanetLab slice called 'example_slice' which contains four nodes:

1) onelab7.iet.unipi.it
2) planet2.elte.hu
3) planetlab2.ics.forth.gr
4) planetlab2.urv.cat

Assume we have obtained subnet 10.0.9.0/24 for our slice. We are going to build the following overlay network: 

   10.0.9.1/24   10.0.9.2/24   10.0.9.3/24
	1 ----------- 2 ------------ 3
	              |
	              |
                      |
		      4 
		  10.0.9.4/24

In the same directory were we have put the Makefile we create a 'conf.mk' file containing the following variables: 

----------
SLICE=example_slice
HOST_1=onelab7.iet.unipi.it
IP_1=10.0.9.1/24
HOST_2=planet2.elte.hu
IP_2=10.0.9.2/24
HOST_3=planetlab2.ics.forth.gr
IP_3=10.0.9.3/24
HOST_4=planetlab2.urv.cat
IP_4=10.0.9.4/24

LINKS :=
LINKS += 1-2
LINKS += 2-3
LINKS += 2-4
----------

NOTE In this example we have chosen to use numbers (1,2,3,4) as ids for nodes, you can use any other name that is convenient for you.
See the example files in this directory for an example of this.

Then, we can just type: 

$ make -j

Assuming everything has been setup correctly, this command Will start the Open vSwitch servers, create the bridges and setup the tunnels. We can test that network is up by logging into a node and pinging some other node using the private subnet addresses: 

$ ssh -l example_slice onelab7.iet.unipi.it ping 10.0.9.4

Links can be destroyed and created dynamically. Assume we now want the the topology to match the following one: 

   10.0.9.1/24   10.0.9.2/24 
	1 ----------- 2 
	              |
	              |
                      |
                      4 ----------- 3 
		  10.0.9.4/24  10.0.9.3/24

We can issue the following commands: 

$ make -j U/2-3      # unlink nodes 2 and 3
$ make -j L/4-3      # link nodes 4 and 3

The current state of the links is represented as a set of files in the 'L' directory. If dot is installed, we can obtain a graphical representation of the topology by typing: 

$ make graph.ps

The current state of the nodes and links can be obtained by typing 

$ make snapshot > snapshot.mk

The snapshot.mk file follows the same format as conf.mk and can be used to recreate the topology at a later time: 

$ make CONF=snapshot.mk

Command reference

All targets can be issued with the '-j' flag to (greatly) speed up operations (*)
It may also be useful to use the '-k' flag, so that errors on some nodes do not stop the setup on the other nodes. 


all:        	do wathever is needed to setup all the links in the 'links' file.

clean:		tear down all existing links

L/N1-N2:    	setup a link between nodes $HOST_N1 and $HOST_N2

U/N1-N2:	tear down the link (if it exists) between nodes $HOST_N1
		and $HOST_N2

del-bridge.N:	delete the bridge running on node $HOST_N (this also tears down
	        all links that have an endpoint in $HOST_N)

graph.ps	create a postscript file containing a (simple) graphical
		representation of the current topology

(*) To get the greatest speedup from make -j you should also enable connection reuse in your ssh setup, e.g., by having the following lines in your .ssh/config: 

host *
	ControlMaster auto
	ControlPath ~/.ssh/ssh_mux_%h_%p_%r
	ControlPersist 4h

Please note, however, that maximum concurrent per-node reuse is usually set to something low (typically 10), and this is a problem if some node in your topology has many links. In this case you should raise that limit on the slivers, or limit makefile concurrency (e.g., by using make -j10).

Useful Resources: