lOMoARcPSD|24851052

SDN LAB Intro - Lab practical using Mininet OpenFlow

OpenDaylight Controller (ODL) on Linux
Telecommunication Core Networks (University of Moratuwa)

Scan to open on Studocu

Studocu is not sponsored or endorsed by any college or university

Downloaded by GUNA Kaliya (gunanotes134@gmail.com)
 lOMoARcPSD|24851052

1 Introduction
This practical uses Mininet to build a software defined network (SDN) using different controllers, followed
by an analysis of the packets, connectivity and flow entries in each case using both the terminal of the
Ubuntu virtual machine (VM) and the Wireshark software. An SDN running with no controller, with a
local default controller and with OpenDaylight controller is looked at.

Objectives
Using the Mininet network emulator on a VM to configure:
1. A standalone OpenFlow network using Mininet
2. Using OpenDaylight controller
3. Mininet network using OpenDaylight controller
4. Adding flow entries and observe the exchange of OpenFlow messages between the controller and
the virtual switches

2 Observations & Discussion

Part I
1. SDN without a controller
i) Setup

Figure 1.1: Setting up SDN without a controller

Figure 1.2: Observing SDN network structure

We can see that 1 switch, 2 hosts and 2 links connecting the hosts to the switches have been set up when
initializing the network in fig 1.1. In fig 1.2, we use the nodes and net command to get a list of the

Downloaded by GUNA Kaliya (gunanotes134@gmail.com)

 lOMoARcPSD|24851052

components and connections in the network. It can be noted that there is no controller in the network,
so there is a simple LAN setup between a switch and two hosts.

ii) Attempt pings between the hosts.

Figure 1.3: Attempting to ping hosts in SDN

The pings do not succeed in this network setup. This is because, with only two hosts and a switch which
does not have routing capability, the switch cannot forward any packets, including pings.
In an SDN, the control and data planes are divided, so all networks require a controller to handle routing.
Without this, the routing paths are not built up and the switch cannot forward any packets.

iii) Check the flow table of the switch.

Figure 1.4: Flow entries after ping

The flow table of the switch s1 is empty as shown in the figure, due to the reasons discussed in the
previous part. A controller is required to set up the flow table in an SDN.

2. Standalone OpenFlow network with controller

i) Setup
In order to set up a local controller, the default controller ”openvswitch-testcontroller” was installed.
This controller is set up to run in a different terminal (fig 2.1) before running the Mininet SDN network.

Figure 2.1: Activating openvswitch testcontroller

Downloaded by GUNA Kaliya (gunanotes134@gmail.com)

 lOMoARcPSD|24851052

Figure 2.2: Start up SDN

ii) Understand the network setup.

Figure 2.3: Observe nodes, network and paths

Here, we can observe an activated controller and its links in addition to the default nodes set up in section
1.

iii) Check the flow table of the switch.

Figure 2.4: Flow table before any messages are passed

Unlike in section 1., the flow table of the OVS switch is not empty. It contains a single flow entry.
Observing some fields of this entry:

action : CONTROLLER
priority : 0
duration : 22.137s
no packets : 12
no bytes : 976

Downloaded by GUNA Kaliya (gunanotes134@gmail.com)

 lOMoARcPSD|24851052

iv) Attempt pings between hosts.

Figure 2.5: Ping between hosts

The pings are successful, and have a 0% packet loss rate. Unlike in section 1., here the controller is taking
the routing decisions and setting up the path for the package to be sent.

v) Check the switch flow table after pings.

Figure 2.6: Flow table after pings

The image 2.6 shows the complete flow table after pinging is done in both directions to and from h1 and
h2.
Hence, it can be observed that the first four entries are (internet control message protocol) ICMP
packet flows, the next four are (address resolution protocol) ARP packet flows.
Each of these sets of four entries describes a particular flow of either the request (icmp type=8;
arp op=1) or reply (icmp type=0; arp op=2) from h1 to h2 and vice versa. This can be seen by observing
the fields dl src and dl dst, which gives the source and destination data link layer (MAC) address.
Alternatively, the nw src and nw dst shows the network layer address of the flow being forwarded by the
switch. Similarly, the in port shows the port name in the SDN. Finally, the output port for a packet with
the corresponding properties of the flow entry is specified in the ‘actions’ field.
The priority of all the above mentioned flows is 1, which is higher than the controller-bound flow with
a priority of 0. The idle timeout is 60s. It is expected that this flow will be removed from the table once
this time period has passed with no activity of transmitting packets.
It can be noted that with 5 pings done in either direction in figure 2.5 above, the n packets of each
flow type that was passed after the flow entry was set up is 4.
The last entry is the same as in figure 2.4, with the expected increase in the duration, n packets and
n bytes fields. This entry will always be visible in the following sections.

Downloaded by GUNA Kaliya (gunanotes134@gmail.com)

 lOMoARcPSD|24851052

vi) Check the switch flow table after enabling background ‘snoop’.
Before running the background snoop command, we wait for the flow entries to time out, and get a result
for ‘dpctl dump-flows’ similar to figure 2.4. We run ‘snoop &’ after this, and observe the flow table shown
below. Here, the packets used by the controller to monitor the network are listed as well. Primarily, the
OFPT ECHO request and reply packets, which are used to measure network conditions and liveliness of
the network[1], are seen.

Figure 2.7: Running ‘snoop’ in the background.

After some more activity has happened in the network, in the form of pings in both directions, we
can see several new flow entries that communicate between the switch s1 and the controller c0.

Figure 2.8: Flow table with snoop active after ping

The image figure 2.8 above shows the first few flow entries. Below are some images that take a look
at these entries in detail.The OpenFlow OFPT flow entries are of mainly three types:
1. OFPT PACKET IN: Packet sent in to controller from switch.
2. OFPT PACKET OUT: Packet sent out from controller to switch.
3. OFPT FLOW MOD: Packet sent from controller to switch to modify the state of an OpenFlow
switch[1].

Downloaded by GUNA Kaliya (gunanotes134@gmail.com)

 lOMoARcPSD|24851052

Figure 2.9: OpenFlow flow entries: CLI

Highlighted in figure 2.9 are the flows that have CLI packets encapsulated inside.

First, the switch sends the packet-in to the controller, encapsulating the unmatched message. The
controller then sends a flow-mod that modifies the flow table, and returns the CLI packet with the
packt-out. An icmp csum or check-sum is used to confirm correct reception of this packet.

The flow-mod entry shown here sends all the fields of the flow entry that should be setup to the switch.
The ADD priority sets the priority, and the ‘idle’ field sets the idle timeout for the entry. In addition,
the matching fields for source and destination addresses etc. as well as the action i.e., the output port
number of the switch, is specified here.

Downloaded by GUNA Kaliya (gunanotes134@gmail.com)

 lOMoARcPSD|24851052

Figure 2.10: OpenFlow flow entries: ARP

Similar to the CLI packet-in, flow-mod and packet-out described above, the figure 2.10 shows the same
communication taking place for ARP packets.The fields here are corresponding to the fields relevant to
an ARP packet.

Figure 2.11: Ethernet flow entries

The last few entries of the flow table are very similar to the entries in figure 2.6, since they occurred after
pinging between the hosts.

Downloaded by GUNA Kaliya (gunanotes134@gmail.com)

 lOMoARcPSD|24851052

Part II
3. SDN with OpenDaylight controller
i) Setting up the OpenDaylight controller

Figure 3.1: Running the controller

Figure 3.2: Installed all required features

Figure 3.3: Run the SDN network with OpenDaylight

Here, we use OpenFlow 1.3 protocol, and connect to the OpenDaylight controller set up on port 6633.

Downloaded by GUNA Kaliya (gunanotes134@gmail.com)

 lOMoARcPSD|24851052

ii) Check the flow table of the switch.

Figure 3.4: Flow entries after setting up simple SDN

This flow table looks considerably different from what was observed in part I above. The controller
initiates a discovery all node connectors of the connected switches[2]. This is why we see four entries
upon initiating the SDN network; one to each switch port, one to the controller and the other one to be
dropped.

iii) Analysis with Wireshark

(b) Flow mod packet of the last flow table entry

(a) Filtering flow-mod

(c) Flow mod packet of the first flow table entry (d) Flow mod packet of second flow table entry

Figure 3.5: FLow-mod packets for SDN setup with ODL

When comparing the flow table entries to the OFPT FLOW MOD packets captured by Wireshark:
1. The first entry has priority 100, and sends packets to the controller.
2. The second and third entries have priority 2 and assign packets to each of the two ports of the
switch.
3. The final entry has a priority 0 and drops the packet.

Downloaded by GUNA Kaliya (gunanotes134@gmail.com)

 lOMoARcPSD|24851052

iv) Attempt pings between hosts.

Figure 3.6: Ping

v) Check the switch flow table after pings.

Figure 3.7: Flow entries after ping

After carrying out the pings, there are just two new entries in the flow table: each has a different action to
be implemented (unlike in part I, where there was one for each action/output port based on the protocol
and type). There are also less fields for matching, and an additional hard timeout counter.

vi) Observe the topology on the OpenDaylight GUI.

(a) Topology after setting up SDN (b) Topology after pinging between two hosts

Figure 3.8: ODL Topology

It can be seen that the controller only recognizes the switch up setup of the SDN, and identifies the hosts
only after pinging has been done.

10

Downloaded by GUNA Kaliya (gunanotes134@gmail.com)

 lOMoARcPSD|24851052

vii) Analysis with Wireshark

(a) Two flow-mod entries created as shown in fig. 3.7

(b) Set flow entry action = port 1 (c) Set flow entry action = port 2

Figure 3.9: Flow-mod packets

Corresponding to the two new flow entries in figure 3.7, two OFPT FLOW MOD packets have been
captured. A closer look at the content of the packet reveals that the content is mostly identical, as shown
in figures 3.9b and 3.9c, but with different port numbers under the ”action” field.

(a) Filtering packet-in packet type (b) Components of a packet-in with an IPv6 packet

Figure 3.10: Packet-in packets

The packet-in packets are sent corresponding to each a miss in the match tables or if forwarding to the
controller is required.Hence, the packets received by the switch for each destination port with different
protocols have been sent within packet-in messages as shown in figures 3.10b, 3.11a and 3.11b.

11

Downloaded by GUNA Kaliya (gunanotes134@gmail.com)

 lOMoARcPSD|24851052

(b) Components of a packet-in with an IPv4 CLI

(a) Components of a packet-in with an ARP packet packet

Figure 3.11: Packet-in packets cont.

(a) Packet-out packets (b) Features-request packets

(c) Port-status packets (d) Set-config packets

Figure 3.12: Filtering OpenFlow packets on wireshark - 1

12

Downloaded by GUNA Kaliya (gunanotes134@gmail.com)

 lOMoARcPSD|24851052

(a) Packet-out packets (b) Features-request packets

(c) Port-status packets (d) Set-config packets

Figure 3.13: Filtering OpenFlow packets on wireshark - 2

PACKET OUT : Packets injected by the controller to switch

FEATURES REQUEST : Controller request information about its capabilities before set-
ting up transport layer connection
PORT STATUS : Switch informs controller about change in port status
SET CONFIG : The third in a sequence of GET CONFIG REQ,
GET CONFIG RES (ack) and SET CONFIG to set the
switch’s pipeline properties
BARRIER REQ : State modification messages sent to the switch - can be used to
set sync points
BARRIER RES : Switch’s response to above request
STATS REQ (MULTIPART) : Controller requests information about individual flows
STATS RES (MULTIPART) : Switch’s response to above request

Table 2.1: OpenFlow packets identified on wireshark

Source:[1]

13

Downloaded by GUNA Kaliya (gunanotes134@gmail.com)

 lOMoARcPSD|24851052

4. Tree topology with OpenDaylight Controller

(a) 3-layer tree topology - before pings (b) Pinging between h1, h2 and h5

(c) Pinging between h1, h2 and h5

Figure 4.1: ODL tree topology

The tree topology specified when running with the additional option ‘–topo tree,3’ setup can be seen
here. Pinging allows the ODL controller to see the hosts connected to these switches.

14

Downloaded by GUNA Kaliya (gunanotes134@gmail.com)

 lOMoARcPSD|24851052

Figure 4.2: Observing the network using CLI

Figure 4.3: Running dump-flows for the tree topology SDN

15

Downloaded by GUNA Kaliya (gunanotes134@gmail.com)

 lOMoARcPSD|24851052

Figure 4.4: The remaining entries for the above

As shown in the two figures above, before any pinging is done, all the flow tables of each switch are
filled with the four basic entries as in figure 3.5a.

3 Conclusion
During the implementation of this lab, the types of packets used to set up, monitor and maintain a
network, the default values for various flow types such as timeout and priority, as well as the passing
of a simple ping message across an SDN was observed, using both a default OVS controller and an
OpenDaylight controller.

Problems & solutions.

There were several issues faced when running the practical. Firstly, the default ovs-testcontroller was not
installed, and it had to be manually installed, then run on the localhost LAN of the VM and accessed
via the remote command as shown in figures 2.1 and 2.2.

Another issue was that when installing OpenDaylight features for part II, an error would pop after
after a day or two. This was identified to be due to the auto refreshing mode, which is the default option
when installing the switch. In my case, I uninstalled odl-l2switch-switch package and reinstalled with the
option :
feature:install --no-auto-refresh odl-l2switch-switch
This fixed the problem.

Finally, several minor issues in using VNC software to run the VM, such as its slow speed and often
freezing etc. had to be handled during the implementation.

References
[1] OpenFlow Message Layer, http://flowgrammable.org/sdn/openflow/message-layer/
[2] OpenFlow plugin operation,
https://docs.opendaylight.org/projects/openflowplugin/en/latest/users/operation.html

16

Downloaded by GUNA Kaliya (gunanotes134@gmail.com)