A3 handouts

A3 handouts
Fall Term 2013
Network Virtualization and Data Center
Assignment 3: Software Defined Networking
Assignment 3 out:
Assignment 3 due:
Marking session 3:
Monday 11:59am,
Nov. 19, 2013
Dec. 9, 2013
Dec. 10, 2013
NOTE: This assignment can be solved in groups of 2 people.
NOTE: The deployment of your code and the evaluation will be performed on Amazon EC2 nodes.
The goal of this assignment is to give introduce you to the key concepts and practices of software
defined networking (SDN) using OpenFlow [1]. You will use Mininet to emulate a small data center
network consisting of OpenFlow switches and end-hosts. You will write a controller application
that routes end-host traffic along the shortest path through the data center by installing the
appropriate forwarding rules in the emulated OpenFlow switches.
Learning Outcomes
After completing this assignment, you should be able to:
• Describe the interfaces exposed by SDN switches and SDN controllers for managing the flow
of traffic through the network.
• Make use of common tools for emulating an OpenFlow network, managing OpenFlow switches,
and generating test traffic.
• Create a basic SDN application for directing traffic along a specific path.
More on OpenFlow
OpenFlow proposes a way for researchers to run experimental protocols in the networks they use
every day. It is based on an Ethernet switch, with an internal flow-table, and a standardized
interface to add and remove flow entries. OpenFlow is a pragmatic compromise: on one hand,
it allows researchers to run experiments on heterogeneous switches in a uniform way at linerate and with high port-density; while on the other hand, vendors do not need to expose the
internal workings of their switches. In addition to allowing researchers to evaluate their ideas
1 Acknowledgement: this assignment is based on material from a similar course at University of WisconsinMadison: http://pages.cs.wisc.edu/˜akella/CS838/F12/assignment4.html
in real-world traffic settings, OpenFlow could serve as a useful campus component in proposed
large-scale testbeds like GENI.
OpenFlow exploits the fact that most modern Ethernet switches and routers contain flow-tables
(typically built from TCAMs) that run at line-rate to implement firewalls, NAT, QoS, and to
collect statistics. An OpenFlow Switch consists of at least three parts:
a) a flow table, which keeps an entry for every flow and tells each switch how to process the
b) a secure channel that connects the switch to a remote control process, namely the controller – that adds and removes flow entries from the flow table for different experiments –
allowing commands and packets to be sent between a controller and the switch by using
c) a protocol, which provides an open and standard way for a controller to communicate with
a switch.
In the context of OpenFlow, a flow can be a TCP connection, or all packets from a particular
MAC address or IP address, or all packets with the same VLAN tag, or all packets from the same
switch port. Every flow entry in the flow table has 3 basic actions associated with it:
a) Forward the flow’s packets to a given port or ports, which means packets are to be routed
through the network.
b) Encapsulate and forward the flow’s packets to a controller, which either processes them or
decides if the flow needs to be added as a new entry to the flow table (i.e. if the packet is
the first in a new flow).
c) Drop the flow’s packets, which can be used for security issues, to curb denial-of-service
attacks and so on.
Read the OpenFlow whitepaper [1] and familiarize yourselves with the basic OpenFlow elements,
before setting up the environment.
Setting up OpenFlow
There is plenty documentation on how to install and setup OpenFlow and a step-by-step tutorial
is provided in [4].
The parts that should be interesting for you from this tutorial are:
• Learn Development Tools
• Create Learning Switch (only the POX part)
Additionally, [2] provides a more up to date Mininet walkthrough.
In this chapter we will make a summary of these tutorials, focused on the main things you need
following the next steps:
• how to launch your own EC2 Mininet VM
• how to use Wireshark analyzer
• how to start your first OpenFlow controller POX Controller
• how to start a basic topology and follow its OpenFlow traffic in Wireshark
Launch your own EC2 Mininet VM
You don’t need to worry about setting up Mininet into a machine as you can already launch a preconfigured AMI in Amazon EC2 that has Mininet, POX and other tools (e.g.: Wireshark). In order
to deploy this AMI the most important things you need to know is the AMI ID (ami-d34367ba).
You can create your instance, as in the previous assignment, with the following code. (For more
details check A2 consultation slides.)
#!/usr/bin/env python
import boto.ec2
conn = boto.ec2.connect to region("us-east-1")
conn.run_instances(’ami-d34367ba’, key_name=’your key’, instance_type=’t1.micro’)
All development takes places through a SSH session to the VM. Thus, you will need an X Forwarding client running in order to have any graphical interaction through the session. On Mac/Linux
systems this means checking that you have the -Y option when running SSH commands. On
Windows machines, check that your X Forwarding application is running.
For example, the way to connect to your newly created machine is:
ssh -Y -i <key file name.pem> [email protected]<instance public dns>
Take note that you need to login under the ubuntu user, not your usual username.
Wireshark analyzer
Wireshark is a great tool to help you analyze traffic flowing through nodes in the network. You
would use Wireshark to analyze network behavior with the command:
sudo wireshark &
This should open a graphical pop-up window (if there is an error saying a window cannot be
created, your X Forwarding client may not be running). In the Wireshark filter box, enter
and then click Apply. Click Capture, then Interfaces, then Start on the loopback interface
(lo). For now you don’t have any OpenFlow traffic, so there are no packets displayed in the main
window with this filtering.
POX Controller
Start a basic POX controller
cd ∼ /pox
./pox.py log.level --DEBUG misc.of_tutorial
All packets flowing through the controller will show up in Wireshark.
Exploring the default topology
The default topology, discussed in the tutorial, includes 3 hosts and 1 switch. To create this
network, issue the command:
sudo mn --topo single,3 --mac --switch ovsk --controller remote
This tells Mininet to start up a 3-host, single-switch topology, set the MAC address of each host
equal to its IP address and point to a remote controller which defaults to the localhost. A few
useful commands to use in the Mininet console are provided below:
• nodes – see the list of available nodes.
• h1 ifconfig – check h1’s IP address.
• h2 ping -c 1 h3 – pinging combined with Wireshark is very useful in diagnosing controller
behavior; if you view the Wireshark output, you should be able to view the traffic in the
network as a result of the ping.
• exit – end the Mininet session.
Understanding prerequisites
In this assignment you will be developing traffic forwarding in OpenFlow networks using different
topologies: binary tree topology and fat tree-like topology.
In the next section we will provide a brief overview of two scenarios: one for binary tree, respectively one for fat-tree and provide a more in-depth tutorial on using Mininet.
Binary-tree, fat-tree overview
Data center networks typically have a tree-like topology. End-hosts connect to top-of-rack switches,
which form the leaves of the tree; one or more core switches form the root; and one or more layers of
aggregation switches form the middle of the tree. In a basic tree topology, each switch (except the
core switch) has a single parent switch. Additional switches and links may be added to construct
more complex tree topologies (e.g., fat tree) in an effort to improve fault tolerance or increase
inter-rack bandwidth.
In this assignment, both simple binary tree topologies and simple fat-tree-like topologies will be
considered. For example, a binary tree network of depth 3 looks like:
Figure 1: Binary Tree Topology
Hosts are represented with squares; switches are represented with circles. The number of hosts
and switches reflects the numbering used by Mininet. Our custom fat-tree-like topology looks like:
Figure 2: Fat Tree Topology
More details on using Mininet
Mininet emulates an OpenFlow network and end-hosts within a single machine. It includes built-in
support to create several common topologies, plus it allows for construction of custom topologies
using a Python script. Since we are only considering tree-like data center topologies, will only use
the tree topology built-in, plus a custom topology.
To launch Mininet with the network arranged in a binary tree topology with depth 3, run the
following command (either directly in the VM console or in an SSH session to the VM):
$ sudo mn --topo tree,3 --mac --arp --switch ovsk --controller=remote,ip=
Each of the part of the command does the following:
--topo tree,3
--switch ovsk
--controller remote
,ip <host ip>
runs as root
runs Mininet
creates a tree topology of depth 3 with the default fanout of 2 (i.e., binary)
makes the mac address of Mininet hosts the same as their node number
installs static ARP entries in all hosts
uses Open vSwitch in kernel mode for each of the switches
the SDN controller will run outside of Mininet
the IP address to which the switches should connect
We have also provided a custom topology script that generates a fat-tree-like topology of depth
3. To launch Mininet with the network arranged in a fat tree topology run the following:
$ sudo mn --custom ∼/mininet/custom/topo-fattree.py --topo fattree --mac --arp --switch
ovsk --controller=remote,ip=<host ip>
Once Mininet is running, you can obtain information about the network, generate traffic, and
run commands on individual hosts. To display all of the elements in the network, run the nodes
command within Mininet:
mininet> nodes
Nodes starting with “h” are hosts, and nodes starting with “s” are switches.
To display the list of links in the network, run the net command within Mininet:
mininet> net
This will output a list of switches, and for each switch, list the hosts and switches connected to
that switch (along with the network interface on each host and switch that is used for the link).
One option to generate traffic is to run ping or iperf on individual hosts. To do so, you need
to run a command on a specific host within Mininet. This is achieved by typing the hosts name,
followed by the command. For example, to send 10 ping packets to h2 from h1, run:
mininet> h1 ping -c 10 h2
To run iperf, you’ll need to start the iperf server on one host, running the command in the
background, and then start the iperf client on another host. For example, to run an iperf server
on h1 and an iperf client on h2, run:
mininet> h1 iperf -s &
mininet> h2 iperf -c h1
You can also provide other options to iperf, if desired. Also, you should kill the iperf server on
h1, when you are finished:
mininet> h1 kill $(ps | grep iperf | cut -f2 -d)
Note that if you run ping or iperf without an SDN controller running on your local machine, no
traffic will be sent across the switches (since there are no OpenFlow rules in the switches) and the
commands will timeout.
An alternative option to generate traffic is to to use the Mininet commands pingpair, pingall,
and iperf. Using these commands avoids the need to run commands on individual hosts. You
can use the Mininet help command or consult the Mininet documentation to learn more about
these commands [2].
Traffic forwarding
In this chapter we will describe the three different tasks that you should implement in your
Forwarding in a Single Switch
Your first task is to properly forward traffic between two hosts connected to a single switch.
You should create a binary tree topology of depth 1 in Mininet, which will create two hosts (h1
and h2) and a single switch (s3). The switch’s datapath identifier (DPID) that is reported to the
controller will be 3. On the switch, h1 will be connected to port 1 and h2 will be connected to
port 2.
Rather than hard coding the ports, you should use the IP address of a packet to determine which
port it should be sent to. Your controller should read in a comma-separated variable (CSV) file
called hostlist.csv that contains three columns: IP address, switch DPID, and switch port. For
this first task, the file will contain:,3,1,3,2
If you use POX, the file should be placed in the top-level pox directory.
We have provided a Python script gen host list.py in the VM to automatically generate this
file for a given topology. It takes one argument: the depth of the tree. To generate the file for this
first task, you will would run:
$ ./gen host list.py 1 > hostlist.csv
To get started on this first task in POX, you should look at the files:
- pox/pox/misc/of tutorial.py
- pox/pox/forwarding/l2 learning.py
For further details you can also consult the OpenFlow tutorial [3] or wiki [5].
Forwarding in a Binary Tree
Your second task is to properly forward traffic between two hosts connected in a binary tree
You should create a binary tree topology of at least depth 2 in Mininet. You should also create
the correct corresponding hostlist.csv file using the gen host list.py script.
To complete this task in POX, you should rely on the discovery module which sends LLDP
messages between OpenFlow switches and constructs a list of links between switches. The launch
function in your POX module should include the following to start the discovery module:
import pox.openflow.discovery
You can access the list of links created by the discovery module by adding the following line of
code within your POX module:
link list = core.openflow discovery.adjacency
The POX spanning tree module relies on the discovery module, so you should look at the file
pox/openflow/spanning tree.py for guidance on how to use the list of links created by the
discovery module. You can also look at the source code for the discovery module in the file
Forwarding along the Shortest Path in a Fat-Tree-Like Topology
Your final task is to properly forward traffic along the shortest path between two hosts connected
in a fat-tree-like topology. In a binary tree topology, there is only one path between two hosts,
but a fat-tree-like topology has multiple paths. You should pick the shortest path; if there are
multiple paths of equal length, then you may either pick just one of those paths or balance the
traffic among these evenly.
Again, you should rely on topology information provided by existing modules/classes in POX.
To generate the fat-tree-like topology depicted in Figure 3.1 use the script ∼/mininet/custom/topo-fattree.py
as described in Section 3.2.
What to turn in?
Turn in your solution under:
https://svn.inf.ethz.ch/svn/roscoe/virnet13 students/trunk/NAME/A3
This directory should contain:
• PDF report: any bugs you have in your code, any extra features you added, and anything
else you think we should know about your project
• Code for your controller application, including all files necessary to build/run the application
atop POX.
• A script to automate starting your environment and sending packets over the network.
[1] Nick McKeown, Tom Anderson, Hari Balakrishnan, Guru Parulkar, Larry Peterson, Jennifer
Rexford, Scott Shenker, and Jonathan Turner. OpenFlow: enabling innovation in campus
networks. ACM SIGCOMM Computer Communication Review, 38(2):69–74, 2008.
[2] Mininet Walkthrough. http://mininet.org/walkthrough/, 2013. [Last visited on 2013-1114].
[3] OpenFlow tutorial – Sending OpenFlow messages with POX. http://archive.openflow.
[Last visited on 2013-11-14].
[4] OpenFlow tutorial. http://archive.openflow.org/wk/index.php/OpenFlow_Tutorial,
2013. [Last visited on 2013-11-14].
[5] POX Wiki. https://openflow.stanford.edu/display/ONL/POX+Wiki, 2013. [Last visited
on 2013-11-14].
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

Download PDF