Project Software Defined Networks - Hochschule Bonn-Rhein-Sieg

Project Software Defined Networks - Hochschule Bonn-Rhein-Sieg



University of Applied Sciences

Fachbereich Informatik

Department of Computer Science

Master of Science in Computer Science

- Wintersemester 2014 -


Software Defined Networking


Florian Siebertz

Betreuung: Prof. Dr. Karl Jonas

Project: Software Defined Networking ii


1 Introduction

2 Software Defined Networking

3 OpenFlow


4 OpenFlow Software Switches



Stanford Reference Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . .



Pantou . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .



Open vSwitch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .



OFSoftswitch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


5 OpenFlow Controller



Pox/Nox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .



Beacon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .



Floodlight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .



OpenDaylight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .



Ryu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .



FlowVisor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .




6 OpenFlow on Virtual Machines



Hardware/Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .



Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .



Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .



Test Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .



In-Band vs. Out-of-Band

. . . . . . . . . . . . . . . . . . . . . . . . . . . .


7 OpenFlow on Raspberry Pi



Hardware/Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .



Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .



Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .



Test Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


8 OpenFlow on OpenWRT



Hardware/Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .



Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .



Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .



Test Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .



Wireless Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


9 Conclusion


Project: Software Defined Networking iii

List of Figures

1 SDN architecture (IRTF)

. . . . . . . . . . . . . . . . . . . . . . . . . . . .


2 OpenFlow Architecture

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .


3 Flowtable Entry with v1.0 Match Fields . . . . . . . . . . . . . . . . . . . .


4 Configuration of the Open vSwitch . . . . . . . . . . . . . . . . . . . . . . .


5 Virtual Test Setup with Out-of-Band Controller . . . . . . . . . . . . . . . .


6 Virtual Test Setup with In-Band Controller . . . . . . . . . . . . . . . . . .


7 OpenFlow enabled Raspberry Pi with additional USB to LAN interfaces . .


8 Internal architecture of the TP-Link WDR3600 internal switch . . . . . . .


9 Testing environment with two WDR3600 OpenFlow-enabled devices and

Raspberry Pi controller

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .


10 OpenFlow on OpenWrt testbed with WDR3600 routers

. . . . . . . . . . .


11 Wiring of the OpenFlow on OpenWRT testbed . . . . . . . . . . . . . . . .


Project: Software Defined Networking 1

1 Introduction

Software defined networking (SDN) is a relatively new technology emerging from the principle of programmable networks. It tries to fulfil a need to configure network devices more flexible and dynamically. This is achieved by taking away the process of making decisions about packet handling from every single device. A logically centralised controller entity is deployed instead, that can take these decisions for all devices in the entire network.

The most prominent implementation of SDN is OpenFlow. It was developed 2009 at

Stanford University with the goal of enabling network experiments in a fast and flexible manner. Soon, the Open Networking Foundation was founded as an industry consortium backing the development of OpenFlow. Known vendors of networking devices and members of the Open Networking Foundation started to implement the OpenFlow protocol in their enterprise networking hardware.

The benefits and research opportunities of using this technology in academic or industrial use cases are praised in a large number of papers and articles. However, starting to experiment with software defined networking and OpenFlow is not as trivial as picking

the standard hardware and software components and start deploying. To gain a thorough knowledge base, this document describes the know-how aquired through a project with the goal to discover the properties and possibilities of this technology, and can be used as reference for how it can be deployed for academic experiments in the future.

To this end, chapter 2 describes the architecture of SDN and the principles behind it’s

composition. Chapter 3 covers the OpenFlow architecture and protocol that is used in

the later experiments. To make use of OpenFlow controlled devices, two requirements

are necessary: A OpenFlow capable switch (chapter 4) and a controller that handles the

traffic between them (chapter 5).

With the knowlegde from the first chapters, three test environments are created. First, the Open vSwitch, a OpenFlow enabled software switch, is deployed in a virtual environ-

ment in chapter 6. Second, the possibility of running the Open vSwitch on a Raspberry

Pi is examined in chapter 7. And third, TP-Link consumer devices running OpenWRT

are turned into OpenFlow capable switches in chapter 8.

Project: Software Defined Networking 2

2 Software Defined Networking

When starting to work with Software Defined Networking (SDN) or OpenFlow, the first question that arises is what is SDN and where can a standardized description be found.

The answer is that there exists no definite standard that can be relied on at the moment, as it is a relatively recent technology. Three organizations have published approaches in

2014 to fill this gap: The Open Networking Foundation (ONF) [1], the Internet Research

Task Force (IRTF) [2] and the International Telecommunications Union (ITU) [3].

The ONF attributes the following central principles to SDN, summing up the different

definitions concisely [1]:

• Decoupling of controller and data planes

• Logically centralized control

• Exposure of abstract network resources and state to external applications

One possible architecture view is presented in figure 1 from a recently published draft [2]

by the IRTF. The terminology has been adapted to match existing work at the Internet

Engineering Task Force (IETF).

Figure 1: SDN architecture (IRTF) [4]

The network device is divided into a forwarding plane and an operational plane. The operational plane manages the operational state and configuration of the device. This contains providing general information, such as the number of ports or the capabilities of the device, but also actual state information like the status of each port, available memory, or statistics about the forwarding plane.

This information is mostly accessed by the management plane via the Management

Plane Southbound Interface (MPSI), which is responsible for monitoring and configuring the network devices via the operational plane, as well as fault management. It ensures that the network is operational as a whole. In some cases the management plane can interact with the forwarding plane, for example to implement a initial set of forwarding rules on a device.

Project: Software Defined Networking 3

The forwarding plane’s only responsibility is the handling of packets in the datapath.

This is done based on instructions from the control plane, received via the Control Plane

Southbound Interface (CPSI) and stored in forwarding tables on the device. The control plane takes decisions on how connected network devices should forward packets on a detailed level. To do so, it may also communicate with the operational plane for device state information. In this case, it would benefit from a controller entity that combines the control plane and the management plane.

Through the separation of control and management plane from forwarding and operational plane, the first principle of decoupling the controller and data plane is fulfilled. A logically centralized control is given in the possibility to manage multiple network devices through one instance of the control/management plane. The concept of a controller is not mentioned explicitly, although the combination of control plane and management plane into one entity is suggested.

The Control Abstraction Layer (CAL), Management Abstraction Layer (MAL) and De-

vice Abstraction Layer (DAL) enable the introduction of abstraction between the different planes as needed, by representing interfaces that form a common language (protocol) and data structure for communication. In addition, they aid in keeping the architecture flexible as they obliterate fixed communication paths between planes. The service abstraction

layer makes the functionalities of control and management plane accessible to applications, in order to programmatically influence network behaviour. This also corresponds to the third SDN principle mentioned above.

In the application plane reside the applications that define the network behaviour. It is noteworthy that applications are not limited to the application plane. For example, applications that primarily control basic routing behaviour or topology discovery through the control plane are not seen as part of the application plane, but the control plane.

Applications may be modular and can even span multiple planes. The concept of services hints at applications that offer functionality for upper level applications to use. These services are more integrated into the respective plane than applications. Examples for the control plane are topology discovery and path computation.

Although not shown explicitly, this architecture also allows for a hierarchical arrangement of arbitrary planes, enabling any level of abstraction or virtualization of resources

(e.g. FlowVisor). The communication in figure 1 also concentrates on vertically aligned

relations, not showing that horizontal communication between planes is in fact not prohibited but encouraged (e.g. distributed control plane).

Project: Software Defined Networking 4

3 OpenFlow

OpenFlow is the most well-established technology in connection with SDN. The latest

specification is issued as version 1.4.0 by the ONF [5]. When discussing OpenFlow, there

is a need to differentiate, as the term can be used to describe the protocol that is used in order to communicate between an OpenFlow switch and a controller, as well as the entire architecture, that consists of all components involved with OpenFlow.

The OpenFlow architecture, as described in the specification, is mainly composed of three major components: An OpenFlow switch, a controller and the OpenFlow protocol.

It is not defined how each of the components are implemented. They may be in the form of hardware, software or virtualized components, as long as they meet all requirements in

the specification. The basic composition of OpenFlow is illustrated in figure 2.

Figure 2: OpenFlow Architecture [6]

An OpenFlow switch includes a channel, multiple flow tables and a group table. Using the channel, the switch can communicate with a controller and the controller can manage the switch through pushed down rules. Sometimes, the channel is referred to as a secure

channel, indicating the possibility to encrypt the incurring communication using the SSL protocol.

Flow tables hold sets of rules that determine how a packet is handled upon arrival. These rules can be added, modified or deleted by the controller and are called flow entries. A

flow entry (fig. 3) consists of three parts: Match fields represent a number of header fields

of the network packets, which allow a classification of network traffic into distinct flows.

Actions are sets of instructions that are applied to packets identified by the match fields.

These actions can, for example, define a port to send the packet, drop the packet, or even modifiy the packet header itself. Counters are increased every time a packet is matched successfully against the match fields of the respective flow.

Packets are matched against flow entries in a priority order that is given to each flow by the controller. The first matching entry is used. Alternatively, packets may be forwarded to a subsequent flow table. This is either determined by the action part of a flow entry or

Project: Software Defined Networking 5

Figure 3: Flowtable Entry with v1.0 Match Fields [6]

can be configured as a default action, the table-miss entry, in case no flow entry matches.

This process is called pipelining and stops if there is no next table specified. At this point the packet is typically forwarded.

Noteworthy is the scope of header fields that can be matched against. They not only include ethernet and IP source and destination addresses, but even VLAN tags and MPLS labels. Additionally, TCP and UDP ports can be examined, spanning the ISO-OSI layers

2 - 4. The complete list of match fields for OpenFlow specification 1.4 is listed in table 1.

The group table is a special kind of flow table. It contains groups that represent a number of aggregated actions, the action buckets. These sets of instructions can be used to share the same actions between different flow entries. An example in the specification hints at the usefulness of such shared actions in the context of IP forwarding, where packets from different flows can be sent to a common next hop. In this case, the output action of multiple flows can be changed at a single point.

A controller is the last part of the OpenFlow architecture. It connects to one or more switches through the channel and the OpenFlow protocol. It can passively receive requests in form of packet headers from a switch (via table-miss entries), and answer with an instruction on how to handle this single packet, or it can actively push flows onto the switch, which are saved in the flow or group table. Another important feature is the ability to pull management information from switches. This includes the general capabilities, like the number of ports and (OpenFlow) status information, but also the values from the flow counters.

OpenFlow has experienced a widespread deployment. In addition to the vendor specific, proprietary implementations by NEC, Juniper or HP, a large number of open source implementations appeared. As they are mainly software switch implementations, they are

usable on a variety of devices. Examples are the Open vSwitch, OFSoftswitch (Chapter 4).

Controllers are being developed even more widely. Projects like nox, beacon, ryu or open

daylight are some of the most well-known examples (Chapter 5). All of them implement

the OpenFlow protocol, but offer different ways for programming network behaviour to

the operator. [7]

Project: Software Defined Networking

Table 1: Match Fields in OpenFlow v1.4 [5]


Content No.


01 Switch input port

02 Switch physical input port

21 ARP opcode

22 ARP source IPv4 address

03 Metadata passed between tables 23 ARP target IPv4 address

04 Ethernet destination address 24 ARP source hardware address

05 Ethernet source address

06 Ethernet frame type

07 VLAN id

25 ARP target hardware address

26 IPv6 source address

27 IPv6 destination address

08 VLAN priority

09 IP DSCP (6 bits in ToS field)

10 IP ECN (2 bits in ToS field)

11 IP protocol

12 IPv4 source address

13 IPv4 destination address

14 TCP source port

15 TCP destination port

16 UDP source port

17 UDP destination port

18 SCTP source port

19 ICMP type

20 ICMP code











IPv6 Flow Label

ICMPv6 type

ICMPv6 code

Target address for ND

Source link-layer for ND

Target link-layer for ND

MPLS label


36 MPLS BoS bit


38 Logical Port Metadata

IPv6 Extension Header pseudo-field

PBB UCA header field


Project: Software Defined Networking 7

4 OpenFlow Software Switches

As an alternative to buying an expensive hardware switch with OpenFlow enabled firmware, a large number of different devices can be turned into an OpenFlow capable switch through software implementations. This section gives a short overview over the different implementations available and contains recommendations for use.

4.1 Stanford Reference Switch

The Stanford reference switch [8] is the oldest implementation of OpenFlow. It dates back

to 2009 when OpenFlow was first developed at Stanford and can be found in a number of

(older) research papers. OpenFlow version 1.0 was supported by the original switch, and version 1.1 after an update. In 2015, the use of this implementation is not recommended, because it has not been maintained since 2011. Compilation on a recent Ubuntu (14.04) is not documented.

4.2 Pantou

Pantou [9] is an adaption of the Stanford reference switch for OpenWRT. The supported

OpenFlow version is 1.0. Like the reference switch, the use is not recommended, as there has been no development since 2011, with the exception that this is the only implementation with confirmed wireless support.

4.3 Open vSwitch

The Open vSwitch [10] is a multipurpose, open source virtual software switch that is also

OpenFlow capable. It is very actively developed by the community and supports up to

OpenFlow version 1.3 at this time. Support for OpenFlow 1.4 is under developement.

Table 2 shows the OpenFlow capability of different Open vSwitch versions for reference,

as all versions are still available for download. Installation is possible under most linux distributions, including OpenWRT, and possibly even under Windows according to the

developers FAQ [11]. A kernel-module is available in addition to running the switch in

user-space for increased performance. The use of this switch is highly recommended and it has been tested on Ubuntu 14.04 and OpenWRT’s trunk “Chaos Calmer”.

Table 2: Supported OpenFlow versions in the

Open vSwitch [11]

OpenFlow Version

Open vSwitch 1.0











• • •


• • •






• • • ∗ •


• •

X: Supported

•: Supported, with missing features

∗: Experimental

Project: Software Defined Networking 8

4.4 OFSoftswitch

OFSoftswitch [12] is an OpenFlow software switch developed by the CPqD research in-

stitute. It is based on an implementation from the Ericsson TrafficLab called Softswitch, which is in turn based on the Stanford reference switch. The supported OpenFlow version is 1.3. There exists a version for linux in general and one for OpenWRT specifically. The project is still actively developed, but use is not fully recommended because there is very little documentation available and none of the reviewed papers actually uses this switch.

Project: Software Defined Networking 9

5 OpenFlow Controller

The centerpiece to create an OpenFlow network is a controller to push down flows to the switches. The choice of which controller to run is mostly up to personal preference or

circumstantial requirements, as all controllers offer the same basic functionality. Tab. 3

shows a list of often mentioned controllers and the northbound interfaces they offer. In

Table 3: List of controllers, their northbound interfaces, and supported OpenFlow version

Name Interfaces OpenFlow Versions








REST, Java




1.0, 1.3

OpenDaylight REST, OSGi

Ryu Pyhton, REST, RPC

1.0, 1.3

1.0, 1.2, 1.3, 1.4

FlowVisor OpenFlow 1.0

the scope of these experiments we use the POX controller for easy and fast testing of the environments as the python code just has to be downloaded and can immediately be executed on most Linux-based operating system distributions without installing additional software. A downside to all controllers available is the varying programming approach, that is different for all controllers. Controllers can not be switched easily, because all developed applications have to be translated to the new controllers northbound interface.

5.1 Pox/Nox

Nox[13](Now called Nox classic) was the first OpenFlow controller developed at Stanford

University when OpenFlow came to life. It was written in C++ and Python, and was later replaced by two separate controllers called Nox (C++ only controller) and Pox (Python only controller). Nearly every paper dating a few years back used to rely on these controllers, but in recent years there has been no active development in the projects besides minor bugfixes, leading to no support of newer OpenFlow versions at all. Despite that, the Pox controller is still a quick and simple tool for running experiments that do not require the extra header fields of newer OpenFlow versions.

To install the POX controller, the latest version can be obtained by copying it from

Github [14].

Since it runs on python, there is no further compilation or installation required. The controller can be run as soon as the download is complete.

u s e r @ c o n t r o l l e r :~ $ git c l o n e h t t p s :// g i t h u b . com / n o x r e p o / pox u s e r @ c o n t r o l l e r :~ $ cd pox u s e r @ c o n t r o l l e r :~/ p o x $ ./ pox . py

POX 0 . 2 . 0 ( c a r p ) / C o p y r i g h t 2 0 1 1 - 2 0 1 3 J a m e s M c C a u l e y , et al .

I N F O : c o r e : POX 0 . 2 . 0 ( c a r p ) is up .

The use of the debug log-level is strongly recommended to enable more feedback on the status of the running controller. As a start, a simple MAC-learning application that comes with Pox can be run. If a switch has already been installed, configured and provided with

Project: Software Defined Networking 10

the right IP address for the controller (section 6.3), the controller receives the connection

attempt as soon as he is up.

u s e r @ c o n t r o l l e r :~/ p o x $ ./ pox . py log . l e v e l - - D E B U G f o r w a r d i n g . l 2 _ l e a r n i n g

POX 0 . 2 . 0 ( c a r p ) / C o p y r i g h t 2 0 1 1 - 2 0 1 3 J a m e s M c C a u l e y , et al .

D E B U G : c o r e : POX 0 . 2 . 0 ( c a r p ) g o i n g up ...

D E B U G : c o r e : R u n n i n g on C P y t h o n ( 2 . 7 . 6 / Mar 22 2 0 1 4 2 2 : 5 9 : 5 6 )

D E B U G : c o r e : P l a t f o r m Linux - 3. 13 .0 - 32 - generic - x86_64 - Ubuntu -14.04 - t r u s t y

I N F O : c o r e : POX 0 . 2 . 0 ( c a r p ) is up .

D E B U G : o p e n f l o w . o f _ 0 1 : L i s t e n i n g on 0 . 0 . 0 . 0 : 6 6 3 3

I N F O : o p e n f l o w . o f _ 0 1 :[00 -50 -56 -98 -1 a - ab 1] c o n n e c t e d

5.2 Beacon

Beacon[15] is a Java based controller that is closely connected to the Eclipse development

environment (meaning it is required to develop applications). It is actively developed by

Stanford University and a community and offers basic modules for topology discovery, learning switch, or routing. Being written in Java and well integrated into Eclipse, the

Controller and it’s applications are by no means lightweight.

5.3 Floodlight

Floodlight [16] is a fork of the Beacon controller by BigSwitch Networks. It offers advanced

features over the original code basis like handling topologies with loops, a web-based GUI, and support for newer OpenFlow versions. Because the main northbound interface is a REST-API, there is no definite programming language for applications, making the approach very versatile.

5.4 OpenDaylight

The OpenDaylight[17] project introduces are more general approach to a controller. It

is not fixed on OpenFlow as the only southbound interface. instead, modules can be dynamically added. The scope of southbound interfaces covers protocols like NETCONF,

LISP, PCEP and SNMP. Like the Floodlight controller, OpenDaylight offers a REST interface as a general way of interacting with the controller. It is very actively developed and backed by the Linux Foundation and Cisco.

5.5 Ryu

Ryu[18] is a component-based, flexible controller written in python. It’s specialty is the

broad support of OpenFlow versions, and the ability to create new northbound interfaces via RPC mechanisms. Also, Ryu support alternative southbound interfaces, like the

NETCONF or SNMP protocols. Own applications can make use of a variety of built-in modules to, for example, gather topology information or implement a firewall.

5.6 FlowVisor

The FlowVisor[19] is a special purpose controller developed at Stanford. It acts like a

transparent proxy between OpenFlow controlled switches and other controllers. It creates so called “slices” in the network traffic, where each slice is controlled by one controller

Project: Software Defined Networking 11 exclusively. These slices are defined like flow rules: A combination of different OpenFlow

1.0 protocol fields, like switch port, IP or ethernet address, or TCP/UDP ports.

Project: Software Defined Networking 12

6 OpenFlow on Virtual Machines

This experiment aims to give an understanding of the basic setup, configuration and function of an OpenFlow enabled network by deploying the Open vSwitch in a simple virtual environment. The OpenFlow functionality of the vSwitch can be controlled by an OpenFlow controller via the OpenFlow protocol, thus representing the characteristic

OpenFlow-architecture as shown in section 3. To that end, a flexible, virtual testing

environment is created, based on VMware’s virtualization technology.

6.1 Hardware/Software


• ESXi Server 5.5


• vSphere Webclient

• Ubuntu Server 14.04.1 64 bit

• Open vSwitch 2.3.1

• Pox Controller

The virtual machines are deployed on a VMware ESXi-server with the configuration

shown in tab. 4, although the experiment could be run on a workstation as well. The

configuration of the virtual environment is conducted via the vSphere Webclient, the only

VMware configuration tool that supports all features. In general, it can not be accessed from a Linux operating system, because a recent version of the Adobe Flash player is needed, which is discontinued under Linux. As a workaround, the Google Chrome browser with it’s integrated Flash implementation can be used.

All virtual machines (hosts and switches) run the Ubuntu Server 14.04.1 64 bit operating system. Although almost any Unix-like operating system could be used, one without a graphical user interface is preferred in order to reduce complexity and resource consumption. The virtual machines that act as OpenFlow switches run the self-compiled Open vSwitch 2.3.

Table 4: Configuration of the ESXi Server

Property Configuration



Supermicro X8DT3

8 x 2,4 GHz Xeon E5620


VM Hypervisor vSphere v5.5.0, Build 1623101

6.2 Installation

An OpenFlow enabled switch is needed as the centerpiece of the virtual networking en-

vironment. To that end, the virtual Open vSwitch [10] is deployed on a VM, taking over

the switching functionality of the Linux kernel on layer 2 of the ISO-OSI reference model.

The software is available as precompiled packages in the Ubuntu 14.04 repository, but

Project: Software Defined Networking 13 only in a rather outdated version (2.0.1). Installation through the package management is as simple as: r o o t @ o v s :~# apt - get i n s t a l l o p e n v s w i t c h - c o m m o n

A short test revealed that the version installed this way is indeed fully operational, but with the constraints that come with the version, for example the limited support of newer

OpenFlow versions as shown in section 4. In the following, we use the self-compiled version

2.3.0. It is available via Github [20] or the Open vSwitch project website [10].

The installation steps shown below comply with the documentation in the extensive FAQ

on the Open vSwitch Github repository [20]. First, all dependencies needed to compile

and run the Open vSwitch have to be installed: r o o t @ o v s :~# apt - get i n s t a l l python - s i m p l e j s o n python - qt4 libssl - dev \ python - twisted - c o n c h a u t o m a k e a u t o c o n f gcc uml - u t i l i t i e s l i b t o o l \ build - e s s e n t i a l pkg - c o n f i g linux - headers - $ ( u n a m e - r ) git

The most recent version of the source code can be obtained by using git.

r o o t @ o v s :~# git c l o n e h t t p s :// g i t h u b . com / o p e n v s w i t c h / ovs / r o o t @ o v s :~# cd ovs

After descending into the new directory, the vSwitch is compiled and installed by entering r o o t @ o v s :~/ ovs # ./ b o o t . sh r o o t @ o v s :~/ ovs # ./ c o n f i g u r e - - with - l i n u x =/ lib / m o d u l e s / $ ( u n a m e - r )/ b u i l d r o o t @ o v s :~/ ovs # m a k e r o o t @ o v s :~/ ovs # m a k e i n s t a l l

The use of the --with-linux switch is optional but recommended, as it generates a kernel module. Contrary to running the vSwitch in user space, the kernel module offers enhanced performance, but is only available in Linux. The kernel module can be loaded by entering: r o o t @ o v s :~/ ovs # cd d a t a p a t h / l i n u x / r o o t @ o v s :~/ ovs / d a t a p a t h / l i n u x # m o d p r o b e o p e n v s w i t c h r o o t @ o v s :~/ ovs # cd . . / . . /

Alternatively, the module can be integrated more permanently into the system by copying the module into the default directory and enable it on every system start automatically.

r o o t @ o v s :~/ ovs # cp d a t a p a t h / l i n u x / o p e n v s w i t c h . ko / lib / m o d u l e s / $ ( u n a m e - r )/ r o o t @ o v s :~/ ovs # d e p m o d - a r o o t @ o v s :~/ ovs # m o d p r o b e o p e n v s w i t c h r o o t @ o v s :~/ ovs # e c h o " o p e n v s w i t c h " > > / etc / m o d u l e s

To complete the installation, two configuration files need to be created. On the one hand, the configuration file for the vSwitch daemon (ovs-vswitchd), and on the other the database that contains the switch configuration (ovsdb-server ), for example which interfaces are connected to a virtual switch.

r o o t @ o v s :~/ ovs # t o u c h / usr / l o c a l / etc / ovs - v s w i t c h d . c o n f r o o t @ o v s :~/ ovs # m k d i r - p / usr / l o c a l / etc / o p e n v s w i t c h r o o t @ o v s :~/ ovs # ovsdb - t o o l c r e a t e / usr / l o c a l / etc / o p e n v s w i t c h / c o n f . db \ v s w i t c h d / v s w i t c h . o v s s c h e m a

These files do not contain any content at first, because they are filled automatically and can be altered through the Open vSwitch command line tools. At last, a start script is created that simplifies the process of bringing the vSwitch daemon up. The lines beginning with

–private-key, –certificate and –bootstrap-ca-cert can be omitted if there is no SSL support needed.

Project: Software Defined Networking 14

#!/ bin / b a s h ovsdb - s e r v e r - - r e m o t e = p u n i x :/ usr / l o c a l / var / run / o p e n v s w i t c h / db . s o c k \

- - r e m o t e = db : O p e n _ v S w i t c h , O p e n _ v S w i t c h , m a n a g e r _ o p t i o n s \

- - private - key = db : O p e n _ v S w i t c h , SSL , p r i v a t e _ k e y \

- - c e r t i f i c a t e = db : O p e n _ v S w i t c h , SSL , c e r t i f i c a t e \

- - b o o t s t r a p - ca - c e r t = db : O p e n _ v S w i t c h , SSL , c a _ c e r t \

- - p i d f i l e - - d e t a c h ovs - v s c t l - - no - w a i t i n i t ovs - v s w i t c h d - - p i d f i l e - - d e t a c h ovs - v s c t l s h o w

After running the script, if the installation was a success, the script shows the output from it’s last command. It should contain the ID of the first, automatically created datapath, a structure in the kernel module that represents a virtual switch:

2 d3f70ad - 6 4 3 3 - 4 0 0 8 - 8 7 5 9 - 2 9 d d 0 8 8 b c 6 3 b

Check if the components are running.

r o o t @ o v s :~# ps - e | g r e p ovs

1 2 7 9 ?

0 0 : 0 1 : 5 1 ovsdb - s e r v e r

1 2 8 2 ?

0 0 : 2 3 : 4 4 ovs - v s w i t c h d

Now the installation process is completed. The steps to reactivate the Open vSwitch after a reboot are

• loading the kernel module (if not loaded automatically as shown above)

• running the start script.

Of course, this procedure can be automated by, for example, adding it to the /etc/rc.local file (possibly with a delay because the networking needs to be up before running the script).

6.3 Configuration

Open vSwitch

Without any further configuration the vSwitch has no function at all. There are four command-line programs to set up and query the Open vSwitch. Each of them has a man-page, where additional information can be found.

ovs-vsctl Configures the ovs-vswitchd by representing a high-level interface to the configuration database. Connects to the ovsdb-server process to query and update the configuration according to the passed parameters.

ovs-ofctl Communicates with the OpenFlow part of the virtual switch showing the current state, features and administrating flow table entries. Because the OpenFlow protocol is standardized, this command should work with any OpenFlow enabled Switch.

ovs-appctl Tool for querying the vSwitch daemon, mostly used for logging. This is the

only tool to dump hidden flows (see section 6.5).

ovs-dpctl Manages flow table entries on the level of the kernel-based datapaths. Requires the kernel module to be used. If the ovs-vswitchd is used, as in this case, the manpage advises the use of ovs-vsctl instead.

Project: Software Defined Networking 15

Figure 4: Configuration of the Open vSwitch

The first command (ovs-vsctl) is the most important one for configuring and managing the switch. In general, the concept for setting up the vSwitch is creating a bridge between all interfaces of one device that are participating in the OpenFlow managed network. The behaviour of this bridge is then determined by the given flow rules. For this experiment, a

VM is set up as shown in figure 4. In addition to the OpenFlow managed interfaces eth1

and eth2, a separate configuration interface (eth0) is created. This way, if configuring the

VM via SSH, there is always a reliable connection that is not influenced by setting up the Open vSwitch, providing a more comfortable basis for experimenting with different settings.

The following steps are inspired by the very extensive FAQ in the Open vSwitch Github

repository [11]. First, the virtual bridge has to be created, automatically generating a

virtual bridge interface with the same name as the bridge. More interfaces are added to this bridge as needed: r o o t @ o v s :~# ovs - v s c t l add - br br0 r o o t @ o v s :~# ovs - v s c t l add - p o r t br0 e t h 1 r o o t @ o v s :~# ovs - v s c t l add - p o r t br0 e t h 2

Now the interfaces, including the bridge interface, are being set up. To that end, the bridge interface br0 is assigned an IP address, while the attached interfaces eth1 and eth2 are stripped of their configuration, ensuring they are up. At this point at the latest, the additional configuration interface comes in handy. As the bridged interfaces are stripped of their functionality, the ability to access the machine through them is disrupted, making physical access to the machine necessary (or via the vSphere Webclient in this case).

r o o t @ o v s :~# i f c o n f i g br0 1 9 2 . 1 6 8 . 1 . 1 1 n e t m a s k 2 5 5 . 2 5 5 . 2 5 5 . 0 up r o o t @ o v s :~# i f c o n f i g e t h 1 0 up r o o t @ o v s :~# i f c o n f i g e t h 2 0 up

For these settings to be permanent they can be written to the /etc/network/interfaces file.

# / etc / n e t w o r k / i n t e r f a c e s i f a c e br0 i n e t s t a t i c

Project: Software Defined Networking 16 a d d r e s s 1 9 2 . 1 6 8 . 1 . 1 1 n e t m a s k 2 5 5 . 2 5 5 . 2 5 5 . 0

Finally, two last settings are necessary. In OpenFlow, switches probe actively for one controller, while the controller only listens on a specified port (port 6633 if not configured differently). Which controller to use is determined by giving the controller’s IP to the switch manually. Additionally, there is a fallback mechanism built into the Open vSwitch.

If there is no response after three tries reaching the controller, the bridge starts acting like a traditional MAC-learning switch until the connection can be (re-)established. For this experiment there is no need for such a fallback, especially since there is no telling whether the OpenFlow or the fallback switching is active at any moment without constantly querying and monitoring the vSwitch. The two possible settings are

• standalone (fallback active)

• secure (no fallback) r o o t @ o v s :~# ovs - v s c t l set - c o n t r o l l e r br0 tcp : 1 0 . 2 0 . 1 4 3 . 7 1 r o o t @ o v s :~# ovs - v s c t l set - fail - m o d e br0 s e c u r e

After the setup is complete, the status of the bridge can be obtained by the command below, showing the datapath ID, the bridge name, the controller IP address, the fallback setting, the added interfaces and the automatically created, virtual bridge interface that holds the bridge’s IP address.

r o o t @ o v s :~# ovs - v s c t l s h o w

2 d3f70ad - 6 4 3 3 - 4 0 0 8 - 8 7 5 9 - 2 9 d d 0 8 8 b c 6 3 b

B r i d g e " br0 "

C o n t r o l l e r " tcp : 1 0 . 2 0 . 1 4 3 . 7 1 " f a i l _ m o d e : s e c u r e

P o r t " e t h 1 "

I n t e r f a c e " e t h 1 "

P o r t " e t h 2 "

I n t e r f a c e " e t h 2 "

P o r t " br0 "

I n t e r f a c e " br0 " t y p e : i n t e r n a l

Virtual Networks

To connect the interfaces of the virtual machines, virtual networks are required to simulate a simple wired connection between two hosts. These networks are configured via the vSphere Webclient, but not in the category Networking as one would suspect, but in

• category Hosts and Clusters

• right click on the host and select configuration

• select network

• select add host network

• select add portgroup of the virtual machine for a standard switch

Project: Software Defined Networking 17

These virtual networks are also called virtual switches. For every pair of interfaces that are to be connected, one virtual switch has to be created. After that, the interfaces of the virtual machines can be connected to the newly created networks in their respective properties.

However, there is a Problem using these virtual networks and Open vSwitch: When creating this experiment, the traffic over one virtual network was running without a problem, while the traffic over a second, identically configured virtual network only worked in

one direction. Figure 4 can be used to explain this unexpected behavior.

As shown in the previous section, the vSwitch consists of a bridge br0 that has the other interfaces attached to it. If a packet is sent from the bridge, for example to a host that is connected to VM_Net1, an ARP-request with the source MAC-address of the virtual bridge interface br0 is sent out. This virtual interface does not have a MAC-address of it’s own, but takes the address of one of the interfaces that are attached to it instead. In this case it took the MAC-address of eth1. The ARP-request is broadcasted through the virtual network to the host. ARP-replies from the host are directed at the MAC-address of br0 (= eth1) and delivered to the eth1 interface by the virtual network without a problem.

Now, a packet is sent through the bridge to a host behind VM_Net2. Again, the ARPrequest has the source MAC-address of br0, which is in fact the address of eth1. The virtual network broadcasts this ARP-request to the host. An ARP-reply is sent out from the host to the MAC-address of br0. VM_Net2 does not forward the packet to eth2.

In contrast to the assumption that the virtual networks would behave like a traditional switch, there are important differences which cause this behavior. The network only has knowledge of MAC-addresses of VMs that have been added directly to it in VMware. There is no capability of learning about new MAC-addresses that are not directly connected.

In the first case, the MAC-address for the host to reply to (br0) is the same address that is directly connected to the virtual network (eth1). In the second case, the MAC-address the host has to reply to (br0) is not directly connected to the virtual network, causing the

ARP-reply to get dropped by the network. This problem will not occur specifically when using Open vSwitch, but every time a VM acts as a layer 2 forwarding device.

As a workaround, the virtual networks can be set to promiscious mode using the following steps, causing them to forward every incoming packet to every VM connected to it. This behavior is similar to a simple hub.

• category Hosts and Clusters

• right click on the host and select configuration

• select network

• select the respective network and click modify configuration

• select security and set promiscious mode to accept

6.4 Test Setup

In the final version of this experiment two hosts can communicate through a network of

OpenFlow controlled switches. To start with the smallest configuration possible, the setup

depicted in figure 5 is created.

VM_Net1 connects Host1 to the vSwitch, whereas VM_Net2 connects the vSwitch to

Host2. Additionally, all virtual machines are connected to the network VM_Net3. This

Project: Software Defined Networking 18

Figure 5: Virtual Test Setup with Out-of-Band Controller

Network is used for configuration and monitoring purposes only, and it is not part of the

OpenFlow controlled networking. It is possible to attach the controller to this out-of-band

network, details in this regard are explained in section 6.5. A SSH-server is installed on all

virtual machines and is reachable via VM_Net3 to maintain a connection to all devices that is independent from the OpenFlow controlled network. This enables the configuration of all

OpenFlow related interfaces without shutting down the own connection. Furthermore, this network provides internet access for all virtual machines via the university network, and allows downloading additional packages and software as needed. While the IP addresses in the OpenFlow network are set up manually, the configuration network uses an existing

DHCP server.

To do a quick test of the environment, a SSH session to both Host1 and the controller is established. When trying to ping from Host1 to Host2, the command will return no answer. The packets are relayed to the OpenFlow switch, but because there is no rule present for this traffic flow and the controller is not up to be queried, the packets are dropped.

In the next step, the pox controller is started on the controller VM with the l2_learning module enabled, setting the switch’s behavior to a layer 2 learning switch.

u s e r @ c o n t r o l l e r :~/ p o x $ ./ pox . py f o r w a r d i n g . l 2 _ l e a r n i n g

After a few seconds, there should be a message saying a switch connected to the controller.

If the ping command is still in progress, the pings will be able to get through after a few

more seconds. In case the debug level logging is enabled in pox (see section 5), the flows

pushed down to the switch are visible on stdout on the controller VM.

From this point on, expanding the test setup is easy: More VMs configured as OpenFlow enabled switches can be added as needed in any setup necessary by copying the first switch

VM and changing the bridge’s IP. In a quick test, the controller was able to supervise at least 20 switches at the same time.

6.5 In-Band vs. Out-of-Band

The previous setup had the controller attached to a separate network, that is not part of the OpenFlow management. This is called an out-of-band controller. Alternatively, it is possible to include the controller in-band, as part of the OpenFlow managed network.

Project: Software Defined Networking 19

Figure 6: Virtual Test Setup with In-Band Controller

Figure 6 exemplifies the use of an in-band controller with multiple vSwitches in the virtual

test setup. Both methods are supported by Open vSwitch, but which option to use is depending on some circumstantial factors, for example:

• Should the control messages be separated from the data?

• Is there an infrastructure for out-of-band controllers?

• Will an unreliable (e.g. wireless) in-band network disconnect the controller from the whole network?

If an out-of-band controller is used, a traditional switching / routing network is responsible for delivering the control messages to the controller. There are no further configuration steps necessary. In case of an in-band controller, the messages have to travel through devices controlled via OpenFlow. The problem that arises is that without a controller connected to the switches, there is no forwarding of packets in general, including OpenFlow control messages.

There are two possible solutions to this issue:

1. Use a fallback mode (traditional switching) when no controller is connected

2. Insert flow rules for forwarding OpenFlow messages into the switches manually

The first method bears the risk of undesired network behavior, as there is no differentiation between flows. Fortunately, Open vSwitch has the latter method as a built-in feature already. These flow rules are not visible to the standard ovs-ofctl command used to query flows from switches, but through the use of the ovs-appctl command.

r o o t @ v s w i t c h :~# ovs - o f c t l dump - f l o w s br0 r o o t @ v s w i t c h :~# ovs - a p p c t l b r i d g e / dump - f l o w s br0

# f l o w s not v i s i b l e

# f l o w s v i s i b l e

Project: Software Defined Networking 20

7 OpenFlow on Raspberry Pi

A Raspberry Pi can be used instead of designated networking hardware to test and examine

OpenFlow functionality. To this end, this section describes how to install and configure the needed software on a Raspberry Pi with additional network interfaces. In a short test, the performance of this setup is tested.

7.1 Hardware/Software


• Raspberry Pi Model B+

• Speed Dragon USB 2.0 10/100Mbps

Ethernet Adapter Model: UNW01


• Raspbian Wheezy (January 2014)

Kernel 3.12.35

• Open vSwitch 2.3.1

• Pox Controller

Basis is the Raspberry Pi Model B+ with it’s 4 USB interfaces which allow for up to 4 additional Ethernet interfaces via USB-to-Ethernet adapters. The Raspberry Pi is driven by the Raspbian operating system in the version January 2014. As a Debianbased operating system, it is possible to install the Open vSwitch similar to the virtual environment. The Pox controller is used to manage the vSwitch from either locally on the

Raspberry Pi or on a remote machine.

7.2 Installation

Open vSwitch

The Raspbian operating system is installed on a micro-SD card via the dd command.

u s e r @ p c :~ $ dd if =2014 -12 -15 - r a s p b i a n - w h e e z y . img of =/ dev / m m c b l k 0 bs =4 M

After booting into textmode, the first step is to install the Open vSwitch. In contrast to Ubuntu, there is no precompiled package available via apt-get. The source code for compiling Open vSwitch can be obtained from the Github repository as show in section

6.2, or downloaded from the project’s website via wget.

p i @ r a s p i :~ $ w g e t h t t p :// o p e n v s w i t c h . org / r e l e a s e s / o p e n v s w i t c h - 2 . 3 . 1 . tar . gz p i @ r a s p i :~ $ tar - x v z f o p e n v s w i t c h - 2 . 3 . 1 . tar . gz p i @ r a s p i :~ $ cd o p e n v s w i t c h - 2 . 3 . 1

Before compilation, the build dependencies have to be installed.

p i @ r a s p i :~ $ s u d o su r o o t @ r a s p i :~# apt - get u p d a t e r o o @ r a s p i :~# apt - get i n s t a l l python - s i m p l e j s o n python - qt4 libssl - dev \ python - twisted - c o n c h a u t o m a k e a u t o c o n f gcc uml - u t i l i t i e s l i b t o o l \ build - e s s e n t i a l pkg - c o n f i g

A problem is choosing the right kernel header files for the compilation of the kernel module.

There is no exact match for the kernel version in use. The correct package to install for kernel 3.12.35 is r o o t @ r a s p i :~# apt - get i n s t a l l linux - headers -3.12 -1 - rpi

Project: Software Defined Networking 21

The compilation itself is similar to the one in the virtual environment, but choosing the previously installed kernel header for compiling the Open vSwitch kernel module.

r o o t @ r a s p i :~# cd o p e n v s w i t c h - 2 . 3 . 1 r o o t @ r a s p i :~/ o p e n v s w i t c h - 2 . 3 . 1 # ./ b o o t r o o t @ r a s p i :~/ o p e n v s w i t c h - 2 . 3 . 1 # ./ c o n f i g u r e - - with - l i n u x =\

/ lib / m o d u l e s /3.12 -1 - rpi / b u i l d r o o t @ r a s p i :~/ o p e n v s w i t c h - 2 . 3 . 1 # ./ m a k e r o o t @ r a s p i :~/ o p e n v s w i t c h - 2 . 3 . 1 # ./ m a k e i n s t a l l

After these steps are completed, the kernel module needs to be loaded and the configuration

files are beeing set up. This is analog to the setup on Ubuntu described in section 6.2,

including the start script for the vSwitch.

USB-to-Ethernet Adapter

The USB-to-ethernet adapter mentioned above works out of the box, without installing additional software or drivers on the used Raspbian operating system and kernel verison.

For a more reliable mapping of the interfaces to the device name, a rule is created in the

/etc/udev/rules.d/70-persistent-net.rules file for each adapter.

# USB to e t h e r n e t a d a p t e r ( M O S C H I P usb - e t h e r n e t d r i v e r ) - > e t h 1

S U B S Y S T E M ==" net " , A C T I O N ==" add " , D R I V E R S =="?*" ,

A T T R { a d d r e s s } = = " 0 0 : 1 3 : 3 b : 9 9 : 0 3 : f2 " , A T T R { d e v _ i d } = = " 0 x0 " , A T T R { t y p e }=="1" ,

K E R N E L ==" eth *" , N A M E =" e t h 1 "

# USB to e t h e r n e t a d a p t e r ( M O S C H I P usb - e t h e r n e t d r i v e r ) - > e t h 2

S U B S Y S T E M ==" net " , A C T I O N ==" add " , D R I V E R S =="?*" ,

A T T R { a d d r e s s } = = " 0 0 : 1 3 : 3 b : 9 9 : 0 4 : 2 a " , A T T R { d e v _ i d } = = " 0 x0 " , A T T R { t y p e }=="1" ,

K E R N E L ==" eth *" , N A M E =" e t h 2 "

This configuration is specific to the Raspberry Pi, because there are detachable interfaces.

In the virtual environment or on OpenWrt, interfaces will not change their device name without changing the configuration.

7.3 Configuration

The configuration of the Open vSwitch is exactly the same as shown in section 6.3. It is

listed briefly for reference:

# add the ovs - b r i d g e r o o t @ r a s p i :~# ovs - v s c t l add - br br0

# add the i n t e r f a c e s to the b r i d g e r o o t @ r a s p i :~# ovs - v s c t l add - p o r t br0 e t h 0 r o o t @ r a s p i :~# ovs - v s c t l add - p o r t br0 e t h 1 r o o t @ r a s p i :~# ovs - v s c t l add - p o r t br0 e t h 2

# c o n f i g u r e the i n t e r f a c e s

# use / etc / n e t w o r k / i n t e r f a c e s for p e r m a n e n t c o n f i g u r a t i o n r o o t @ r a s p i :~# i f c o n f i g br0 1 9 2 . 1 6 8 . 1 . 1 1 n e t m a s k 2 5 5 . 2 5 5 . 2 5 5 . 0 up r o o t @ r a s p i :~# i f c o n f i g e t h 0 0 up r o o t @ r a s p i :~# i f c o n f i g e t h 1 0 up r o o t @ r a s p i :~# i f c o n f i g e t h 2 0 up

# set the c o n t r o l l e r a d d r e s s and f a l l b a c k m o d e r o o t @ r a s p i :~# ovs - v s c t l set - c o n t r o l l e r br0 tcp : 1 9 2 . 1 6 8 . 1 . 1 0 r o o t @ r a s p i :~# ovs - v s c t l set - fail - m o d e br0 s e c u r e

Project: Software Defined Networking 22

Figure 7: OpenFlow enabled Raspberry Pi with additional USB to LAN interfaces

7.4 Test Setup

The test setup for the OpenFlow enabled Raspberry Pi consists of two host PCs, connected to the USB-to-ethernet interfaces, and an external Pox controller on a third PC, connected

to the on-board interface (figure 7). The goal of this test is to determine if the Raspberry

Pi offers enough performance to run the installed Open vSwitch.

To test the throughput, the Iperf command is run between the two hosts for 30 seconds to allow for flow rules to be placed by the controller without influencing the average values

too much. The results are shown in table 5. A first test failed with very low transmission

speeds of about 25 Mbit/s for TCP and about 55 Mbit/s for UDP. At the same time the

CPU load was at maximum capacity. The reason for this was a misconfiguration when compiling without the appropriate kernel headers. There was no kernel module created and the switch was running in user space.

But even with the kernel module in place, the performance is only at 70 Mbit/s for TCP and 90 Mbit/s for UDP, while the CPU load remains at high levels. While this test only used one traffic flow, performance is to be expected even lower when deployed in a larger network with concurrent traffic streams.

In conclusion, the Raspberry Pi model B+ is not fit for using it with Open vSwitch. The

CPU is not fast enough to handle the incoming traffic, including the Open vSwitch and

OpenFlow overhead. A possible solution could be to exchange the Raspberry Pi B+ for the recently introduced Raspberry Pi 2, which offers enhanced computation capabilities.

Project: Software Defined Networking

Table 5: Average Iperf performance running Open vSwitch

Transmission speed [Mbit/s]

Protcol no kmod with kmod

CPU load [%] no kmod with kmod










80 kmod: Open vSwitch kernel module


Project: Software Defined Networking 24

8 OpenFlow on OpenWRT

OpenWrt enhances consumer-grade networking hardware with full access to the system and the possibility to add additional capabilities. This includes installing Open vSwitch and turning devices supported by OpenWrt into OpenFlow capable switches. This section gives an introduction to installing and configuring Open vSwitch on OpenWrt and presents a testbed for experimentation and to showcase OpenFlow capabilities.

8.1 Hardware/Software


• TP-Link WDR3600

• Raspberry Pi Model B+


• OpenWRT Trunk “Chaos Calmer”

• Open vSwitch for OpenWRT

• Pox Controller

• Ubuntu 14.04.1

The router model TP-Link WDR3600 is used in this setup. It is well supported by

OpenWrt and offers 5 ethernet interfaces to use for OpenFlow controlled networking. A most recent OpenWrt version is installed on every switch from the development trunk.

The controller runs on a Raspberry Pi. For cross-compiling the needed OpenWrt version with Open vSwitch support, a Workstation with Ubuntu 14.04.1 is used.

8.2 Installation


It is important to note that the required version of OpenWrt has to come from the development trunk. There is no Open vSwitch package in the last official release Barrier Braker.

There are two possible ways to get an appropriate OpenWrt image for the WDR3600:

1. Download a trunk snapshot from [21], which is created every day, and install the

Open vSwitch package via the opkg package management system.

2. Download the trunk source code via Subversion and compile OpenWrt after choosing the Open vSwitch package in the menuconfig.

The first option was working fine at first, but in newer snapshots it is impossible to install

Open vSwitch due to unsatisfied dependencies. The exact error message is

C o l l e c t e d e r r o r s :

* s a t i s f y _ d e p e n d e n c i e s _ f o r : C a n n o t s a t i s f y the f o l l o w i n g

* d e p e n d e n c i e s for o p e n v s w i t c h :

* kmod - u d p t u n n e l 4 * kmod - u d p t u n n e l 6 *

* o p k g _ i n s t a l l _ c m d : C a n n o t i n s t a l l p a c k a g e o p e n v s w i t c h .

The needed dependencies are no longer in the extra packages called feeds. A bug report through the OpenWrt bug reporting system was closed without comment.

Fortunately, the self-compiled image still works, indicating that the missing dependencies are not needed in the first place. Before compiling, the build dependencies have to be installed on the Ubuntu machine.

Project: Software Defined Networking 25 u s e r @ p c :~ $ s u d o apt - get i n s t a l l g c c g ++ b i n u t i l s p a t c h b z i p 2 f l e x \ b i s o n m a k e a u t o c o n f g e t t e x t u n z i p s u b v e r s i o n l i b n c u r s e s 5 - dev \ ncurses - t e r m zlib1g - dev g a w k git - c o r e libz - dev

After that, the trunk source code can be downloaded via Subversion. Additionally the feeds packages, which include Open vSwitch, have to be downloaded and integrated into the trunk source code. This can be done through a script that is already in the source files.

u s e r @ p c :~ $ svn co svn :// svn . o p e n w r t . org / o p e n w r t / t r u n k t r u n k u s e r @ p c :~ $ cd t r u n k u s e r @ p c :~ $ ./ s c r i p t s / f e e d s u p d a t e - a u s e r @ p c :~ $ ./ s c r i p t s / f e e d s i n s t a l l - a

Now, the settings for compiling the image have to be made.

u s e r @ p c :~ $ m a k e m e n u c o n f i g

In the opening menu, first choose the target system and device OpenWrt will be installed on, in this case the values are:

• Target System: Atheros (ar7xxx/ar9xxx)

• Subtarget: Generic

• Target Profile: TP-Link TL-WDR3500/3600/4300/4310/MW4350R

To compile Open vSwitch into the image, two more packages have to be selected. The

Open vSwitch main package and the additional kernel module. They have to selected with an “*” symbol, and not with “M”, as in manual installation, else the installation will not be possible afterwards because of the missing dependencies.

• Network → openvswitch

• Kernel Modules → Network Support → kmod-openvswitch

The compilation can be started after exiting and saving the menuconfig. To do that, enter u s e r @ p c :~ $ m a k e V =99 for maximum verbosity in case an error occurs when compiling. If the compilation was successful, the image files can be found in the trunk/bin/ar7xxx/ directory. The filename should look like this: openwrt - ar71xx - generic - tl - wdr3600 - s q u a s h f s - f a c t o r y . bin

For flashing, it is advisable to only use the factory images, which create a clean installation on the device. The sysupgrade files only come in handy when the configuration on the device has to stay intact. In case the original vendor-issued firmware is still installed, the easiest way to install the newly compiled image is to connect via the webinterface and choose the factory file as a system upgrade.

If there is an older OpenWrt firmware installed already, the following set of commands has proven to be useful (not only when changing from original firmware to OpenWrt, but also to start with a clean, up to date installation). An important detail to note is, that the /tmp directory is in fact mounted into RAM. Else there would not be enough memory for the image file.

Project: Software Defined Networking 26 r o o t @ o p e n w r t :~# cd / tmp r o o t @ o p e n w r t :/ tmp # scp u s e r @ w o r k s t a t i o n :~/ openwrt - f a c t o r y . bin ./ r o o t @ o p e n w r t :/ tmp # mtd - r w r i t e openwrt - f a c t o r y . bin f i r m w a r e

There is no Webinterface installed, so after the device reboots it can be accessed via telnet on After setting a password (passwd command) for root, the device is only accessible via SSH and the telnet service is deactivated.

Open vSwitch

When it was possible to install Open vSwitch on the trunk snapshot, and after flashing the downloaded image as shown above, only the following commands were necessary: r o o t @ o p e n w r t :~# o p k g u p d a t e r o o t @ o p e n w r t :~# o p k g i n s t a l l o p e n v s w i t c h kmod - o p e n v s w i t c h r o o t @ o p e n w r t :~# r e b o o t

Of course, these commands require a working internet connection on the device. To achieve this with the default configuration, the WAN port of the device is connected to a network with a working DHCP server and internet access.

8.3 Configuration


The Open vSwitch components are started automatically, there is no need to manually load the kernel module or start the processes as seen with the virtual environment or on the Raspberry Pi. On the other hand, the configuration of the OpenWrt networking is more complex.

Figure 8 shows the internal architecture of the WDR3600 router. It contains an internal

switch that controls the 5 ethernet ports of the device.

This means without further configuration the ports are not distinguishable for control through the Open vSwitch.

The special use of port 1 as a WAN port in the default configuration hints at a solution for this problem: It is separated from the other ports by using two VLANs, one for the

WAN and one for LAN1 - LAN4.

Port 0 is used as the uplink to the CPU. Packets leaving through this port have to be tagged so they can be attributed to the respective VLAN. The switch is accessible through the eth0 interface from the CPU. The general concept is to assign one VLAN to each port and create an interface for each VLAN. This interface can be used in the configuration of the Open vSwitch. To this end, the /etc/config/network file has to be edited. First, all configurations except the loopback interface are deleted. Then, the switch is configured to make use of VLANs.

c o n f i g s w i t c h o p t i o n n a m e ’ switch0 ’ o p t i o n e n a b l e _ v l a n ’1 ’ o p t i o n r e s e t ’1 ’

For every port that takes part in the OpenFlow controlled networking, the following lines have to be added. In the first part, the VLAN is configured. VLAN 1 is assigned to ports

0 and 1, where port 0 has to be marked with a “t” to indicate tagging on this port. The second part adds an interface for this VLAN. The interface name lan1 can be set to any given value, but the option ifname is determined by the interface name for the switch

(eth0) and the VLAN number (.1).

Project: Software Defined Networking 27

Figure 8: Internal architecture of the TP-Link WDR3600 internal switch c o n f i g s w i t c h _ v l a n o p t i o n d e v i c e ’ switch0 ’ o p t i o n v l a n ’1 ’ o p t i o n p o r t s ’0 t 1 ’ c o n f i g i n t e r f a c e ’ lan1 ’ o p t i o n i f n a m e ’ e t h 0 .1 ’ o p t i o n p r o t o ’ static ’

For the second port, the configuration lines look like this: c o n f i g s w i t c h _ v l a n o p t i o n d e v i c e ’ switch0 ’ o p t i o n v l a n ’2 ’ o p t i o n p o r t s ’0 t 2 ’ c o n f i g i n t e r f a c e ’ lan2 ’ o p t i o n i f n a m e ’ e t h 0 .2 ’ o p t i o n p r o t o ’ static ’

At last, the Open vSwitch bridge, that is created in the next step, is configured with a static IP address.

c o n f i g i n t e r f a c e ’ ovs ’ o p t i o n i f n a m e ’ br0 ’ o p t i o n p r o t o ’ static ’ o p t i o n i p a d d r ’ 1 9 2 . 1 6 8 . 1 . 1 1 ’ o p t i o n n e t m a s k ’ 2 5 5 . 2 5 5 . 2 5 5 . 0 ’

Open vSwitch

The Open vSwitch is configured as explained in section 6.3 and 7.3, with the interface

names adjusted to match OpenWRT.

# add the ovs - b r i d g e r o o t @ o p e n w r t :~# ovs - v s c t l add - br br0

Project: Software Defined Networking 28

# add the i n t e r f a c e s to the b r i d g e r o o t @ o p e n w r t :~# ovs - v s c t l add - p o r t br0 e t h 0 .1

r o o t @ o p e n w r t :~# ovs - v s c t l add - p o r t br0 e t h 0 .2

r o o t @ o p e n w r t :~# ovs - v s c t l add - p o r t br0 e t h 0 .3

r o o t @ o p e n w r t :~# ovs - v s c t l add - p o r t br0 e t h 0 .4

r o o t @ o p e n w r t :~# ovs - v s c t l add - p o r t br0 e t h 0 .5

# set the c o n t r o l l e r a d d r e s s and f a l l b a c k m o d e r o o t @ o p e n w r t :~# ovs - v s c t l set - c o n t r o l l e r br0 tcp : 1 9 2 . 1 6 8 . 1 . 1 0 r o o t @ o p e n w r t :~# ovs - v s c t l set - fail - m o d e br0 s e c u r e

Open vSwitch not connecting to controller

When testing the newly installed and configured device after a reboot, the switch would not connect to a controller. After checking the processes and configurations, there was no mistake noticeable. However, the switch started to work after changing a random setting in the Open vSwitch. The same behavior could be observed on all WDR3600 devices used.

As a workaround for this bug, the following lines are added to the /etc/rc.local file. The point is to set an arbitrary setting to another value, and in the next step to set it back to the original value. Setting a configuration with the same value it already has does not have any effect.

# w o r k a r o u n d for o p e n v s w i t c h s l e e p 5 ovs - v s c t l set - fail - m o d e br0 s t a n d a l o n e s l e e p 5 ovs - v s c t l set - fail - m o d e br0 s e c u r e

8.4 Test Setup

As a first test environment and to prove the viability of using Open vSwitch on OpenWrt,

the setup in figure 9 is used. Two WDR3600 switches are connected via ethernet. A

host is connected to each switch to generate and receive traffic in the network. A Raspberry Pi with Pox is connected to one of the switches in-band. Short tests with different kinds of traffic (Iperf, TCP/UDP datatransfer, video streaming) showed no noticeable shortcomings.

As a second, more permanent testbed the board in figure 10 was created. It consists

of 4 WDR3600 routers and 3 Raspberry Pis model B+. The WDR3600 routers serve as

OpenFlow enabled switches, one Pi is configured as a controller, and the remaining two

Raspberry Pis represent hosts in the network. The wiring between the devices is depicted

in figure 11. This board can be used in future OpenFlow experiments or demonstrations,

for example to showcase failover mechanisms or flow-based “routing”.

8.5 Wireless Interfaces

Wireless interfaces can be added to the OpenFlow bridge as well.

The testbed from

figure 9 was used to confirm an OpenFlow controlled wireless connection between the two

WDR3600 routers. To this end, the devices are no longer connected by cable , but places several meters apart.

One drawback of the current OpenFlow protocol is that configuration of interfaces is not implemented, only the flow tables can be influenced. This means there is no way

Project: Software Defined Networking 29

Figure 9: Testing environment with two WDR3600 OpenFlow-enabled devices and Raspberry Pi controller

Figure 10: OpenFlow on OpenWrt testbed with WDR3600 routers

Project: Software Defined Networking 30

Figure 11: Wiring of the OpenFlow on OpenWRT testbed of programmatically configuring the wireless interface from within OpenFlow. For this experiment, the wireless interface was set up manually as an access point in the /etc/con-

fig/wireless file.

c o n f i g wifi - d e v i c e ’ radio0 ’ o p t i o n t y p e ’ m a c 8 0 2 1 1 ’ o p t i o n h w m o d e ’11 g ’ o p t i o n p a t h ’ p l a t f o r m / a r 9 3 4 x _ w m a c ’ o p t i o n c o u n t r y ’ DE ’ o p t i o n h t m o d e ’ HT20 ’ o p t i o n t x p o w e r ’10 ’ o p t i o n c h a n n e l ’6 ’ c o n f i g wifi - i f a c e o p t i o n d e v i c e ’ radio0 ’ o p t i o n s s i d ’ OpenWrt ’ o p t i o n e n c r y p t i o n ’ none ’ o p t i o n m o d e ’ ap ’

After that, the wireless interface is added to the OpenFlow controlled bridge like any other interface.

r o o t @ o p e n w r t :~# ovs - v s c t l add - p o r t br0 r a d i o 0

Project: Software Defined Networking 31

9 Conclusion

Chapter 2 gave an overview over one SDN architecture, hinting at the fact that there is no

definite standard to turn to. Chapter 3 described the OpenFlow protocol and architecture,

including how packet forwarding is controlled through flows, flow tables and matching fields. The software switches needed to form an OpenFlow controlled network, opposed

to buying enterprise hardware, was described in chapter 4. Different controllers, software

that decides over how packets are handled on the switches, are presented in chapter 5.

The first testing environment in chapter 6 showed how to install and configure normal

(virtual) hosts running the Ubuntu operating system as OpenFlow controlled switches using the Open vSwitch. The difference between in-band and out-of-band placement of the controller was explained. Overall, the virtual environment proved to be a very flexible and viable basis for further experiments.

Turning a Raspberry Pi into an OpenFlow controlled device, chapter 7 demonstrated

the process of installation and configuration, before testing the setup. Unfortunately, the computational power of the device was not high enough to support the packet forwarding through the Open vSwitch.

Chapter 8 consisted of installing and configuring the OpenWRT firmware with Open-

Flow support on WDR3600 devices. The OpenWRT specific configuration proved to be more complicated than in the previous chapters, including a bug that prevents the Open vSwitch to function correctly after reboot. Despite that, once installed, the OpenWRT environment proved to be a reliable and cheap deployment for an OpenFlow enabled test-

ing environment. As a result, the testbed in figure 10 was created for running future


Project: Software Defined Networking 32


[1] Open Networking Foundation, “SDN architecture.” https://www.opennetworking.


ARCH_1.0_06062014.pdf, 2014.

[2] E. Haleplidis, K. Pentikousis, S. Denazis, J. Hadi Salim, D. Meyer, and

O. Koufopavlou, “Internet Draft: SDN Layers and Architecture Terminology.” https:

//, 2014.

[3] International Telecommunications Union, “Recommendation Y.3300: Framework of Software-Defined Networking.”

3300-201406-I/en, 2014.

[4] E. Haleplidis, K. Pentikousis, S. Denazis, J. Hadi Salim, D. Meyer, and

O. Koufopavlou, “SDN Layers and Architecture Terminology, Slides,” in IETF 88

Meeting, IETF, 2014.

[5] Open Networking Foundation, “OpenFlow Switch Specification 1.4.0.” onf-specifications/openflow/openflow-spec-v1.4.0.pdf, 2013.

[6] “Stanford CS244 Wiki.”


[7] B. A. A. Nunes, M. Mendonca, X.-N. Nguyen, K. Obraczka, and T. Turletti, “A

Survey of Software-Defined Networking: Past, Present, and Future of Programmable

Networks,” IEEE Communications Surveys & Tutorials, vol. 16, no. 3, pp. 1617–1634,


[8] “Stanford OpenFlow Reference Switch.”


[9] “Pantou OpenFlow Switch.”


[10] “Open vSwitch Homepage.”

[11] “Open vSwitch FAQ.”


[12] “CPqD OpenFlow Switch.”

[13] “Nox/Pox Controller Website.”

[14] “POX Controller Github Repository.”

[15] “Beacon Controller Website.”


[16] “Floodlight floodlight/.

Controller Website.”

Project: Software Defined Networking 33

[17] “OpenDaylight Controller Website.”

[18] “Ryu Controller Website.”

[19] “Flowvisor Controller Website.” flowvisor/wiki.

[20] “Open vSwitch GitHub Repository.”

[21] “OpenWrt Trunk Snapshots.” trunk/.

Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project