User Tools

Site Tools


soft:ofx

OpenFlow eXperimental facility (OFX)

The OpenFlow eXperimental facility (OFX) within Community-Lab allows users/researchers to carry out Software Defined Networking (SDN) experiments based on the OpenFlow standard. With the OFX extension, Community-Lab is, to our knowledge, the first wireless testbed which enables OpenFlow experiments within a large scale production network. OFX makes possible focused experiments on all OpenFlow key aspects: the switch, the controller, and the controller applications (i.e. switching rules). A researcher can deploy and test off-the-shelf or novel OpenFlow switches, controllers and controller applications. And to simplify the realization of focused experiments, the researcher has available a pre-installed OFX-toolkit formed by: an OpenFlow switch (i.e. Open vSwitch) per virtual machine; an instance of an OpenFlow controller on a dedicated server of the Community-Lab; and a set of default controller applications, like L2/L3 Learning etc. The different items of the toolkit can be used or not, depending on the specific focus of the experiment.

Please see also: http://wiki.confine-project.eu/experiments:opencall2#confine_extension_towards_openflow_experimentationinfrastructure_software_and_demonstrations_conflate_cnit_unidata

OFX diagram

CONFLATE topology builder

OpenFlow requires a layer 2 network and OFX provides a topology builder / “L2 Virtual Topology Deployer“ tool, which automatically deploys an arbitrary layer 2 topology among the virtual machines of the researcher. Obviously, this tool is also re-usable by other experimenters contributing to extend the Community-Lab experimental facility towards different kinds of layer 2 experiments, beyond OpenFlow.

The layer 2 topology is formed by Ethernet tunnels. The tunneling approach makes possible a pervasive introduction of the OFX facility in Community-Lab, since it makes the OFX platform independent from the specific deployment of Research Devices (i.e., directly connected or connected through non-CONFINE devices) and from the underlying IP routing protocol used in the Community Networks (e. g. OLSR, BGP, etc.). Indeed, Community-Lab is rather heterogeneous with respect to these two aspects, therefore being the new facility independent from them avoids deployment issues.

We planned to use the emerging network virtualization technology Virtual Extensive LAN (VXLAN) for this task. At the time of this writing, VXLAN is not supported in the firmware running on deployed research devices, but upcoming firmware releases (based on OpenWrt Barrier Breaker) will add support.

Therefore we provide two versions of the OFX topology builder: one based on VXLAN and one based on the well-known Generic Routing Encapsulation (GRE) protocol, supported by all the CONFINE firmware versions.

All the OFX source code has been published here: http://redmine.confine-project.eu/projects/ofx/repository

VXLAN-based CONFLATE topology builder

The python script vxlan_topology_builder.py automates the creation of VXLAN-based distributed L2 topologies by exploiting the following components:

  1. VXLAN linux kernel module, to create VXLAN tunnels between stations and switches
  2. Virtual switch module and tools Openvswitch, to create virtual switches supporting Openflow
  3. paramiko SSH python library, for remote node configuration

The script connects via SSH to the nodes, creates tunnels between them and adds the virtual interfaces associated to the tunnels to local OpenFlow bridges.

Figure 1 shows an example of a distributed VXLAN L2 topology along with the relevant nomenclature that will be used in this document.

Figure 1

The script vxlan_topology_builder.py has the following usage:

vxlan_topology_builder.py [-h] [--clean] conf_file

where conf_file is a path to a JSON configuration file describing a given topology. If the —clean switch is specified, the script will destroy all network devices and remove any configuration command.

A “topology” JSON object consists of the following fields:

{
	"topology" : {
		"id" : "example",
		"switches" : [
			{ 
			"id":"sw1",
			"IpAddr":"192.168.0.167",
			"MgmtAddr":"fdf5:5351:1dfd:cafe:1001:0000:0000:babe",
			"SSHPubKey":"path_to_ssh_key",
			"SSHPassword":"root",
			"SSHUser":"root",
			"ports":[
				{"ConnectedTo":"h1", "RealTunNIC":"pub0"}, 
				{"ConnectedTo":"h2", "RealTunNIC":"pub0"}
			],
			"OFControllerIP:Port":"192.168.0.254:6633"
			}
		],
		"hosts" : [
			{ 
			"id":"h1",
			"IpAddr":"192.168.0.168",
			"MgmtAddr":"fdf5:5351:1dfd:beef:1001:0000:0000:babe",
			"VIpAddrAndMask":"10.0.0.1/24",
			"SSHUser":"root",
			"SSHPassword":"root",
			"SSHPubKey":"path_to_ssh_key",
			"RealTunNIC":"pub0"
			},
			{
			"id":"h2",
			"IpAddr":"192.168.0.169",
			"MgmtAddr":"fdf5:5351:1dfd:baba:1001:0000:0000:babe",
			"VIpAddrAndMask":"10.0.0.2/24",
			"SSHUser":"root",
			"SSHPassword":"root",
			"SSHPubKey":"path_to_ssh_key",
			"RealTunNIC":"pub0"
			}
		]
	}
}

where:

  1. id is a simple string that identifies the given topology
  2. switches is an array containing a number of switch descriptions
  3. hosts is an array containing a number of station descriptions

The JSON object describing a switch consists of the following fields:

  1. id: a string that identifies the virtual switch
  2. IpAddr: the community public IPv4 address of the machine hosting the switch
  3. MgmtAddr: the management address of the machine hosting the switch
  4. SSHUser, SSHPassword and SSHPubKey: the SSH user password and public key for remote connection to the switch. Please note that if a public key is specified, a SSH password is not required (and viceversa)
  5. OFControllerIP:Port: the IPaddress:port pair of an external Openflow controller
  6. ports: is an array describing a set of stations and/or switches attached to the given switch ports.

Each port object consists of the following fields:

  1. ConnectedTo: the id of the station/switch connected
  2. RealTunNIC: the real network interface to which the VXLAN tunnel is bound

The JSON object describing a host consists of the following fields:

  1. id: a string that identifies the host
  2. IpAddr: the community public IPv4 address of the host
  3. MgmtAddr: the management address of the host
  4. SSHUser, SSHPassword and SSHPubKey: the SSH user password and public key for remote connection to the host. Please note that if a public key is specified, a SSH password is not required (and viceversa)
  5. VIpAddrAndMask: is the IP address and netmask in the overlay network address space attached to a VXLAN device. If this is specified, all packets routed toward this network will automatically delivered to the VXLAN driver
  6. RealTunNIC: the real network interface to which the VXLAN tunnel is bound

The difference between a switch and a host is that a switch runs an openvswitch bridge which contains two or more tunnel endpoints, while a host has only one tunnel interface that is connected to a switch.

To successfully run a Openflow experiment on a distributed L2 topology built with vxlan_topology_builder.py we need whatever Openflow controller running on a (which can be the same machine running this script, or a sliver). We have chosen the RYU Openflow controller.

In the OFX git repository sample topologies (3 of which are depicted in Figure 2) are provided.

Figure 2

The steps to run an Openflow experiment are:

  1. write a RYU Openflow application. RYU distribution has several sample applications in the directory “ryu/app/”. In this example we choose “simple_switch.py” which is a simple Openflow application emulating 802.1 MAC learning operations. To start the controller run from the ryu root directory:
# ./bin/ryu-manager --verbose ryu/app/simple_switch.py 
  1. run the CONFLATE topology builder with a given JSON configuration file:
# python vxlan_topology_builder.py app-1sw-openflow.json
  1. use ping to test the topology deployment. Please note that the machine running the Openflow controller and vxlan_topology_builder.py can be the same machine.

GRE-based CONFLATE topology builder

The GRE (Generic Routing Encapsulation) based CONFLATE topology builder has been implemented in the gre_topology_builder.py script in the OFX repository. It uses Layer 2 GRE tunnels (a.k.a. gretap) to build an overlay topology on which OpenFlow tests can be ran.

The JSON configuration file format is the same used by the VXLAN topology builder described above.

Invocation example:

python gre_topology_builder.py app-3sw-management.json
soft/ofx.txt · Last modified: 2015/03/23 13:48 by clauz