Paris-Saclay M2 CCN –SDN

Lab 2: Netconf, Mininet, OpenFlow, OpenVSwitch, Controllers (ODL,

Exercise 1: Mininet
Many data centers use a tree-like network topology. End-hosts (i.e. servers) connect to top-of-rack
switches, called edge switches, and form the leaves of the tree; one or more core switches form the root
of the tree; and one or more aggregation switches form the intermediate nodes of the tree. In a simple
tree topology, there is only one core switch connected to 𝑛 aggregation switches; each aggregation switch
is connected to 𝑛 edge switches; each edge switch is connected to 𝑛 hosts (servers). The following figure
shows a simple tree topology where n =2.

C1 Core

A1 A2
Aggregation

E1 E2 E3 E4 Edge

H1 H2 H3 H4 H5 H6 H7 lin

Host

Question 1: Write a Python program to use the high-level API and create a simple-tree data center
topology. The program gets the value of 𝑛 as an input. You must organize all the source code in a single
source file, name it simpletree_highlevel.py, and include this file in the submission archive.
Question 2: Repeat the previous question but now use the low-level API. You must organize all the source
code in a single source file, name it simpletree_lowlevel.py, and include this file in the submission archive.
Question 3: Use your program (either high-level or low-level) to create a simple-tree with 𝑛 =2, as shown
in previous Figure. Check the connectivity of all nodes in the network and write your observations. Now
stop the core switch using command switch c1 stop, check the connectivity of all hosts, and report your
observations. How do you explain your findings? Write up your answer in the report.
Finally, name the submission archive <firstname>_<lastname>_lab2-1.zip

1
Exercise 2: Breaking a network

Now let’s try something you shouldn't do in real life. Create a network with a loop out of cheap Ethernet
switches that don't run the spanning tree protocol using mininet python API. The script must build up
the network and bring up the CLI.

You won't get any indication there is a problem unless you try to ping between the hosts. Try to ping the
hosts. What are your observations? Explain.

Exercise 3: Understanding OpenFlow messages between a SDN controller and an OF Switch

OpenFlow version 1.3 is the version of OpenFlow that has support from switch vendors. It is significantly
different from OpenFlow version 1.0 (which was the previous version several vendors supported). Among
others, the main features added since then are:

 1.1: Support for MPLS, Q-in-Q, VLANs, multipath, multiple tables, logical ports
 1.2: Support for extensible headers (in match, packet_in, set_field), IPv6
 1.3: Support for tunneling, per-flow traffic meters, Provider Backbone Bridging

In this tutorial you will learn more about OpenFlow version 1.4 under the covers.

Setup

To get started you can download and set up the SDNHub VM (http://sdnhub.org/tutorials/sdn-tutorial-
vm/) in VirtualBox or VMware. The VM has Wireshark and OFDissector installed for OpenFlow version 1.3.
and 1.4. The dissector is based on CPqD’s release. This enables us to inspect the exact syntax of the
OpenFlow messages.

Install python2-ryu in your mininet VM following the instructions in the site :

https://command-not-found.com/python2-ryu

Quick start

Run mininet on a terminal window using the following command. This starts a network emulation
environment to emulate 1 switch with 3 hosts.
$ sudo mn --topo single,3 --mac --controller remote --switch ovsk,protocols=OpenFlow13

Note that the above command will only work in this patched mininet. For other mininet installations, you
can run the following command to make a switch supports OF 1.3:

$ ovs-vsctl set bridge s1 protocols=OpenFlow13

2
The Wireshark 1.11.3 that is part of the VM can parse OpenFlow 1.0, 1.1., 1.2, 1.3 and 1.4 messages. To
start Wireshark and view OpenFlow messages:

$ sudo wireshark &

Next, start the RYU SDN Controller. Assume that the main folder where RYU is installed is in
/home/mininet/ryu, the below command starts the controller by initiating the OpenFlow Protocol
Handler and Simple Switch 1.3 application.
$ cd /home/mininet/ryu && ./bin/ryu-manager --verbose ryu/app/simple_switch_13.py

Next, check if the hosts in the mininet topology can reach each other

mininet> h1 ping h3

PING 10.0.0.3 (10.0.0.3) 56(84) bytes of data.

64 bytes from 10.0.0.3: icmp_req=1 ttl=64 time=2.76 ms

64 bytes from 10.0.0.3: icmp_req=2 ttl=64 time=0.052 ms

64 bytes from 10.0.0.3: icmp_req=3 ttl=64 time=0.051 ms

You can now list the ongoing flows using the following command that is specific to OpenFlow 1.3:
$ sudo ovs-ofctl dump-flows s1 -O OpenFlow13

Understanding OpenFlow Messages

Assuming you built the learning switch application from the previous section, now take a deep dive into
understanding the set of OpenFlow messages exchanged between controller and switch, as shown in the
following figure.

3
Connection Setup

The switch initiates a standard TCP (or TLS) connection to the controller. When an OpenFlow connection
is established, each entity must send an OFPT_HELLO message with the protocol version set to the highest
OpenFlow protocol version supported by the sender. In the below figure, you can see that OpenFlow
version 1.3 has been negotiated.

Feature Request – Reply

After successfully establishing a session, the controller sends an OFPT_FEATURES_REQUEST message. This
message only contains an OpenFlow header and does not contain a body.

4
The switch responds with an OFPT_FEATURES_REPLY message. Notice the Datapath ID and the switch
capabilities sent as part of the Feature reply message.

5
Set Configuration

Next, the controller sends the OFPT_SET_CONFIG message to the switch. This includes the set of flags
and Max bytes of packet that datapath should send to the controller.

Multipart Request – Reply

The controller may request state from the datapath using the OFPT_MULTIPART_REQUEST message. The
message types handled by this message include various statistics
(FLOW/TABLE/PORT/QUEUE/METER/etc.) or description features
(METER_CONFIG/TABLE_FEATURES/PORT_DESC/etc.).

In our simple_switch_13.py, RYU internally sends a MULTIPART_REQUEST to request port description.

6
The switch replies with the PORT_DESCRIPTION of all active ports in the switch. Note: in OF 1.0, the port
descriptions are returned as part of the FEATURE_REPLY message. Now this is handled separately as
MULTIPART_* in OF 1.3.

7
Flow Mod

Flows can be proactively (e.g., pre-install flows like TableMissFlow) or reactively (e.g., react for packet_in
messages) sent from the controller. Flow table modification messages can have the following types (check
in the standard document what is the purpose of each message):
OFPFC_ADD, OFPFC_DELETE, OFPFC_DELETE_STRICT, OFPFC_MODIFY, OFPFC_MODIFY_STRICT.

In the following case, the controller installs a new flow, which shows that apart from the set of OF 1.0
parameters like priority, idle_timeout, etc, the match and instruction structure reflect the new
parameters specified in 1.3.

It is important to note that the switch does not positively acknowledge FLOW_MOD messages. However,
any error in the FLOW_MOD request will be replied with OFPET_FLOW_MOD_FAILED.

Set Async Configuration Message

Asynchronous messages are sent from a switch to the controller. The set of messages supported by the
OpenFlow protocol include “Packet-Ins, Flow-Removed, Port-Status or Error” messages. When the switch

8
connects to the controller, the controller can set the type of messages that it wants to receive on its
OpenFlow channel.

Above picture shows an async config message sent by the controller. Depending on the type of flags set,
various async messages can be received from the switch.

9
Exercise 4: dpctl and ovs-dpctl
Create a mininet topology using the OVS switch as following:
$ sudo mn --topo single,3 --mac --switch ovsk --controller remote

Command Breakdown:
• “sudo mn”: This starts mininet. Mininet always requires sudo to run
• “–topo single,3”: This tells Mininet to start using the topology of a “single” switch and 3 hosts.
• “–mac”: This tells Mininet to assign each host a sequential MAC address, matching its IP address.
• “–switch ovsk”: This tells Mininet that the switches are to be of the type OVSK, this is the type for
OpenFlow
• “–controller remote”: This tells Mininet that each OpenFlow switch is to talk to a controller, which
is located at a remote location (@IP address).

Mininet topology

dpctl is a utility that comes with the OpenFlow reference distribution and enables visibility and control
over a single switch’s flow table. It is especially useful for debugging, by viewing flow state and flow
counters. Most OpenFlow switches can start up with a passive listening port (in your current setup this is
6634), from which you can poll the switch, without having to add debugging code to the controller.

Create a second SSH window if you don’t already have one, and run:
$ dpctl show tcp:127.0.0.1:6634

The “show” command connects to the switch and dumps out its port state and capabilities. Here’s a
more useful command:

10
 $ dpctl dump-flows tcp:127.0.0.1:6634

Since you haven’t started any controller yet, the flow-table should be empty. Ping Test Now, go back to
the Mininet console and try to ping h3 from h2.

In the Mininet console, type:

mininet> h2 ping -c3 h3

Note that the name of host h3 is automatically replaced when running commands in the Mininet console
with its IP address (10.0.0.3).

Do you get any replies?

As you saw before, switch flow table is empty. Besides that, there is no controller connected to the switch
and therefore the switch doesn’t know what to do with incoming traffic, leading to ping failure. You’ll use
dpctl to manually install the necessary flows. In your SSH terminal:

$ dpctl add-flow tcp:127.0.0.1:6634 in_port=1,actions=output:2

$ dpctl add-flow tcp:127.0.0.1:6634 in_port=2,actions=output:1

This will forward packets coming at port 1 to port 2 and vice-versa. Verify by checking the flow-table:
$ dpctl dump-flows tcp:127.0.0.1:6634

Run the ping command again. In your mininet console:

Do you get any replies?

Check the flow-table again and look the statistics for each flow entry.

3 Is this what you expected to see based on the ping traffic?

NOTE: if you didn’t see any ping replies coming through, it might be the case that the flow-entries expired
before you start your ping test. When you do a “dpctl dump-flows” you can see an” idle timeout” option
for each entry, which defaults to 60s. This means that the flow will expire after 60secs if there is no
incoming traffic. Run again respecting this limit, or install a flow-entry with longer timeout.

$ dpctl add-flow tcp:127.0.0.1:6634 in_port=1,idle_timeout=120,actions=output:2

dpctl: https://github.com/CPqD/ofsoftswitch13/wiki/Dpctl-Documentation

11
 Exercise 5: Topology discovery

The global view of the network is crucial for the operation of controller services like routing and network
monitoring. In this first part, you will focus on the SDN network topology discovery in a single-domain
network. SDN network discovery is mainly based on LLDP (Layer Link Discovery Protocol) which is driven
by the SDN controller. This mechanism is sometimes called OFDP (OpenFlow Discovery Protocol) in the
scientific literature. Another non-standard protocol, only used by ONOS, is BDDP (Broadcast Domaine
Discovery Protocol), a declination of LLDP using a broadcast destination MAC (Ethernet) address to
discover multi-hop links in a hybrid OpenFlow-based network (i.e., with both traditional and OpenFlow
supported devices).1

You are going to generate a linear topology of four switches configured with OpenFlow and four hosts, as
presented in the following Figure:

Topology

Open Wireshark and start the capture on the interface s1-eth2 with the following to display the layer 2
frames:
!(ip.version==4)

Open Mininet and deploy the topology in the previous figure. Write the appropriate command.

You can visualize the generated switches on a terminal with the command:
# ovs-vsctl show

Install and start the SDN controller with the following commands (once you finish with ODL do the same
exercise with ONOS (could be in different VMs):

ODL (OpenDayLight):

# <odl path>/distribution-karaf-<version>-Boron-SR3/bin/karaf

1
There are many proprietary protocols like LLDP such as LLTP (Link Layer Topology Protocol) from Microsoft, CDP
(Cisco Discovery Protocol) from Cisco, FDP (Foundry Discovery Protocol) for Brocade, NDP (Nortel Discovery
Protocol) for Ciena and Avaya, but they will not be covered in this lab.

12
 ONOS:

# <onos path>/apache-karaf-<version>/bin/karaf

Ensure that the controller works correctly by pinging between the emulated hosts. From within the
mininet console:

mininet> pingall

You can connect to the Web GUI through the following address depending on the chosen controller:

ODL: http://localhost:8181/index.html (credentials: admin/admin)

ONOS: http://localhost:8181/onos/ui (credentials: karaf/karaf)

The LLDP (and BDDP in case ONOS is your controller) messages should display. What can you tell about
the ethertype field and the destination MAC address values of these frames?

LLDP data unit frame carries a set of message structures called TLV (Type-Length-Value). Open a LLDP data
unit and explore them. How many TLVs are there? Try to explain TLVs structure.

Now restart the capture on the loopback interface with the filter lldp. By applying this filter, OpenFlow
packets should appear. What do the PACKET_IN and PACKET_OUT OpenFlow types mean? Try to describe
what they contain.

What is the default LLDP data unit transmission frequency? What do you think the advantage and
disadvantage if you increase or decrease this value?

Based on your previous answers, summarize how the controller do to discover the topology.

6 13
Exercise 6: Switching rules

In this part, you will focus on the flow switching rules. After having discovered the topology (and even
before in some cases), the SDN controller sends default flow rules to the switches. A flow rule is
characterized by an INSTRUCTION which is composed of a flow field pattern matching and an ACTION.

After having established the connection, the SDN controller, and the OF switches exchange information.
You are going to analyze the main OpenFlow messages and try to understand the default behavior of the
network. To begin, you are going to generate a linear topology with only two switches.

s1 s1-eth2 s2

s1-eth1

h1-eth0

h1 h2

Topology

Start the Wireshark to capture on the loopback interface and set the filter to openflow_v4.

Generate the topology in Mininet and force it to use OpenFlow v4. Write the command.

Stop the capture after 5 seconds and filter one of the two connections between the switches and the
controller: right click on a packet  Follow TCP stream. If the filter openflow_v4 disappears, add it with
an AND operator.

Summarize the observed OpenFlow exchanges and the data contained into the different OpenFlow packet
types. Pay attention that an OpenFlow frame can contain several OpenFlow messages.

14
Filter the OpenFlow packets with the filter openflow_v4.type==14.

What are the displayed packets used for?

Now destroy the previous topology and build the topology used in Exercise 5. In a terminal, print the
default rules set up on the switch s2 with the following command:

# ovs-ofctl dump-flows s2

Comment and interpret the printed flows.

What is the difference between the IDLE_TIMEOUT (or IDLE_AGE) and the HEAD_TIMEOUT in OpenFlow
protocol? Find the default values used by the controller for a new flow.

Capture the traffic on the loopback interface with the filter ICMP || openflow_v4 and ping between all
hosts from the mininet console. Comment what you see.

Is there a new flow added into the switch s2? Explain Why ?.

15
Display the rules on s1, and observe the n_packets fields:

# ovs-ofctl dump-flows s1

Now open the XTERM terminal of h1 from the mininet console and ping a non-existent IP address:

mininet> xterm h1
$ ping 10.0.0.10 -c8

Display again the rules on s1:

# ovs-ofctl dump-flows s1

Observe the n_packets fields. With which rule the ping has matched?

16