CEG5101 Lab03
CEG5101 Lab03
Laboratory 03
Software-Defined Network (SDN) with POX Controller
LEARNING OBJECTIVES
EQUIPMENT
DISCUSSION
1.2 It helps to control the network centrally and consistently regardless of the underlying
topology.
1.3 Centralized intelligence is achieved by separating the control plane and the data plane
to get control over the network behaviour.
1.4 The data plane is the part of the network which handles traffic forwarding and the
control plane is the part that instructs or configures the data plane on the traffic
forwarding process.
1.5 In a traditional network setup, the control plane and data plane lie together on a single
device. However, SDN decouples the control plane from the data plane and
implements it as software instead to enable flexibility within a network through
programmatic access.
1.6 In this lab activity, we will learn to use a controller to update data forwarding rules on
the Open vSwitch (OVS) to enable communication between different hosts.
*https://noxrepo.github.io/pox-doc/html/#stock-components
http://mininet.org/walkthrough/
pg. 1
Task 2: To download and install POX SDN Controller
2.2 POX controller is a python-based controller platform that allows fast prototyping and
controlling of the network using stock components that are pre-programmed.
2.3 The stock components provide different functionalities and features and are listed on
GitHub*. The code for each component can be found in the installed directory of the
POX.
2.4 In this activity, we will start by downloading and installing the POX controller which
will be used as a remote controller in our further lab tasks.
2.5 To download and get started with the POX controller, simply issue the command
“mininet/util/install.sh -p” on your home directory location.
2.6 To verify successful installation, you will see a folder named POX must be created in
the home directory with contents as shown below.
*https://noxrepo.github.io/pox-doc/html/#stock-components
http://mininet.org/walkthrough/
pg. 2
2.7 Besides, we need to use “curl” to get data from a server. Therefore, download “curl”
in your terminal by type this in your terminal
3.1 In this activity, we will use the stock component and start POX with the basic layer-2
forwarding switch for the controller.
3.3 This POX component will enable traffic forwarding over the connected OVSs.
*https://noxrepo.github.io/pox-doc/html/#stock-components
http://mininet.org/walkthrough/
pg. 3
3.5 Next, assign IP addresses to the hosts and an IP address and port number to the POX
controller according to the table given below.
3.6 Use the host property window, to assign IP addresses to the hosts.
3.7 Use the controller property window, to assign an IP address and port number to the
controller. NOTE: make sure the controller type is chosen as “remote controller”.
*https://noxrepo.github.io/pox-doc/html/#stock-components
http://mininet.org/walkthrough/
pg. 4
3.8 Next, on a different terminal, open the pox directory with the command “cd pox”
and start the pox controller by issuing the following command “sudo python3
pox.py forwarding.l2_learning” to enable layer-2 traffic forwarding. (if
you are using python2, use “sudo ./pox.py forwarding.l2_learning” )
3.9 Once the POX controller is up, your window should like below.
Python2
Python3
3.11 The POX controller terminal will show the connected OVS switches.
*https://noxrepo.github.io/pox-doc/html/#stock-components
http://mininet.org/walkthrough/
pg. 5
3.12 Here, the POX controller starts the basic layer 2 forwarding over the connected
switches.
3.13 At this stage, the flow tables over switches will be empty until the hosts start to send
packets.
3.14 To verify the successful functioning, we will start sending packets from one of the
hosts and monitor the flow of traffic on all connected hosts.
3.15 Next, open terminals for all four hosts by right-clicking on the host at the miniedit
workspace or by issuing the command “xterm h1 h2 h3 h4” over the Mininet
CLI.
*https://noxrepo.github.io/pox-doc/html/#stock-components
http://mininet.org/walkthrough/
pg. 6
3.16 Next, issue the command “tcpdump -n -i hX-eth0” for all hosts except one
because that would be used to send the ping command. Here, X is the number of the
host.
3.17 In this activity, we issue tcpdump over h1, h3, and h4, and we use h2 to send a ping
command toward h4.
*https://noxrepo.github.io/pox-doc/html/#stock-components
http://mininet.org/walkthrough/
pg. 7
3.18 Once the ping starts, we will notice that since at first switch doesn’t have any
information regarding h4 therefore the first packet is sent to all hosts as per the layer-
2 forwarding rule. However, only h4 will send a reply. NOTE: at h1 and h3 you can
notice a line within TCP traffic says “Request who-has 10.0.0.4 tell
10.0.0.2, length 28”.
3.19 Once the first ping is done, the OVS table will have a new flow entry based on the
performed ping command.
3.20 Now, during the second ping, the switch doesn’t need to forward the packet to all
other hosts and this time the traffic will only be forwarded to h4. You can verify this
by ending the current tcpdump and ping commands and issuing the same commands
again.
*https://noxrepo.github.io/pox-doc/html/#stock-components
http://mininet.org/walkthrough/
pg. 8
3.21 You can notice in the below window that this time the traffic is only sent to h4. The
hosts h1 and h3 do not receive any information regarding the ping request from h2.
3.22 This way the controller has successfully enabled layer-2 forwarding within the network
without any manual entries of flows over the switches.
4.1 In this activity, we will use another stock component and start POX with the hub
functioning.
4.3 We will use the same topology and network configuration in this task also.
*https://noxrepo.github.io/pox-doc/html/#stock-components
http://mininet.org/walkthrough/
pg. 9
4.4 To start the pox controller as a hub, we will issue the command : “sudo python
3 pox.py forwarding.hub”
(Python 2 : “sudo ./pox.py forwarding.hub”.)
4.5 The python code for forwarding.hub can be found from the same forwarding folder
of the POX directory.
4.6 Next, to verify the successful flooding among hosts, we will start sending a ping from
one of the hosts and monitor the flow of traffic on all connected hosts. To do so,
open terminals for all four hosts and issue a ping from one host and tcpdump on all
three remaining hosts.
*https://noxrepo.github.io/pox-doc/html/#stock-components
http://mininet.org/walkthrough/
pg. 10
4.7 This time you will notice that the ping command has been flooded and received at all
of the connected hosts.
4.8 You can also print the tables of connected OVS switches to verify the addition of
flows with flooding action.
5.1 In this activity, we will use the POX controller to implement load balancing.
5.2 We will start with creating a below-given topology in the miniedit where single OVS
connects four machines and out of these two machines, h1 and h2 will be used as
HTTP servers, and h3 and h4 will be used as HTTP clients.
5.3 Idea is to balance the load among servers (i.e., h1 and h2) which is generated from
clients named h3 and h4.
*https://noxrepo.github.io/pox-doc/html/#stock-components
http://mininet.org/walkthrough/
pg. 11
5.4 We will use the same IP address and port number as used in the previous
configuration. NOTE: make sure the controller type is chosen as “remote controller”.
5.5 Next, we will run the network and start the HTTP server at h1 and h2. To do so, open
the h1 and h2 terminals and start a server with port number 80 by issuing the
command “python -m http.server 80”.
5.6 Now, we already have the servers running, the next step is to start the load balancing
mechanism at the POX controller.
5.7 To implement load balancing, we will use the stock component named
“misc.ip_loadbalancer”. The code for this component can be found at
~/pox/pox/misc/ip_loadbalancer.py.
5.8 Open the pox directory in the terminal and write the command “sudo ./pox.py
misc.ip_loadbalancer --ip=10.0.10.1 --servers=10.0.0.1,10.0.0.2”.
This command starts the pox controller with the load balancing function, and we also
define that the devices with IP address 10.0.0.1 and 10.0.0.2 will run as a server, and
*https://noxrepo.github.io/pox-doc/html/#stock-components
http://mininet.org/walkthrough/
pg. 12
the IP address to access that server would be 10.0.10.1. Once the pox controller is up,
your window should look like below.
5.9 Next, to verify the successful load balancing among the servers by the controller, we
will start sending a request from clients named h3 and h4.
5.10 To do so, we will use the Linux command “curl” to send the traffic to the server at
IP address 10.0.10.1. At first, we will curl the server once from client h3 and once from
client h4.
5.11 We will observe that controller forwards both requests to the server h1
*https://noxrepo.github.io/pox-doc/html/#stock-components
http://mininet.org/walkthrough/
pg. 13
5.12 Next, issue 3 more curl requests from each client i.e., h3 and h4. You will observe that
this time load is distributed in a way that some clients are forwarded to server h1 and
some are forwarded to server h2.
5.13 Again, issue one more curl request from each client and observe the pattern on the
server side.
5.14 Keep sending more curls and you will notice that the controller is distributing the
incoming traffic from clients among both servers to maintain load balance within the
network.
5.15 You can also observe the flow table over OVS to see how the switch is working by using
the dump-flows function of the ovs-ofctl utility.
5.16 You will notice that as per the flow table entry, OVS is forwarding traffic to the
controller where the controller uses a load balancing mechanism to evenly distribute
traffic within the network and avoid bottlenecks over any single server.
*https://noxrepo.github.io/pox-doc/html/#stock-components
http://mininet.org/walkthrough/
pg. 14