EE 555 Broadband Network Architectures - Project: Build an SDN controller
EE 555 Project
Overview
The objective of this project is to build an SDN controller that has the capabilities of a router and a switch. SDN stands for Software Defined Networking. Traditional / legacy networking devices mainly have two components / modules in them. One is the forwarding plane / data plane and the other is the control plane. The control plane is responsible for interacting with peer devices and evaluate network topology, develop routing tables and ARP caches so that packets can be forwarded to either destination hosts or next hop routers depending on the destination IP Address / MAC Address. For example, a switch will have a MAC to port info mapping table. In this table, the switch will keep a mapping of the MAC address of the host and the output port to use, so that when the switch receives a packet with a specific MAC address, it can forward the packet in the corresponding port.
But, in case of SDN, both control plane and data plane are separated. SDN has two main types of devices in its architecture. The first is a controller that is responsible for control plane and the second is a packet forwarding switch that is responsible for data plane. Instead of every router computing and deriving the routing tables, SDN uses a centralized controller that does all the computation part. The SDN controller has complete visibility of the total network and is aware of which subnets are connected to which router. Once the controller gathers all the information about the network topology, it computes the routing tables. When a packet forwarding switch receives a packet, it sends the packet to the controller.
If the packet forwarding switch sends every packet to the controller, then the latency in the network will be increased. Increase in latency is not desirable as far as a network performance is concerned. So, to avoid this, the controller will “push” OpenFlow rules to the packet forwarding switch. Let us look at a small example that can tell you how these rules can be helpful. If a host, say ‘A’ is attached to a switch on port 1. All the packets with a destination MAC of host A, needs to be forwarded to port 1. Once the controller realizes that host A is on port 1 of the switch, it can push a rule to switch telling “forward all the packets with destination MAC address of A on output port 1.” The same is the case with a router, except the conditions and actions for the router might be different.
In this project, you will be developing a controller that has the capabilities of both a router and a switch.
First steps
We will be using the Mininet emulation software for this project. A very customized and trimmed version of Linux is available with Mininet installed in it at the github link below. https://github.com/mininet/openflow-tutorial/wiki You will be needing Oracle VM Virtual Box, the VM image that has Mininet software, some SSH applications like putty or Mobaxterm, X11 display connectors like Xming etc., to execute the lab. Please go through installing required software section of the tutorial at the above link. The recommended setup is to use MobaXterm as the SSH client and VirtualBox VM with the network configured in ‘Bridged Mode’. Below is a quick guide to the recommended setup. However, you are free to use the official instructions provided here set up virtual machine and Virtual Box Specific Instructions or some other software you are comfortable with.
- Configure bridged mode for Mininet VM.
- Start up mininet VM, the default username is ‘mininet’ and password is ‘mininet’.
- Issue the command ‘ifconfig’ and look for the IP address of an ethX interface
- In MobaXterm, remotely connect to mininet with the command ‘ssh mininet@X.X.X.X’ where X.X.X.X is the IP address you obtained from part 3.
- MobaXterm provides a convenient SFTP toolbar to remotely manage the directory of your VM. Simply drag and drop for file transfer between the host machine and the VM. You can also use an editor (like VSCode) and save the files directly to your VM with the ‘Open With …’ function.
Note: Please ensure that you have the host-only network configured properly in your Virtual Box, as the host only network will be used to SSH into your VM from your Host Operating System (Windows / MAC). As mentioned above, the Mininet VM is a highly trimmed version of Linux and you will not have GUI and it will be cumbersome and difficult to access the VM from the virtual machine console. So, please ensure that your host-only network is setup properly and you can SSH into your VM from your guest OS (Windows / MAC). Once VM is setup, please go through the below link. Learn Development Tools and create a learning switch. There are multiple controllers available in Mininet. But you are required to implement the project using Python POX library only. There are three scenarios in the project. Their description is as below.
Scenarios Description
Scenario 1
In this scenario, you will have a single layer 2 switch that has 3 hosts connected to it. Since all the hosts are connected by a layer 2 switch, all the hosts will be in the same subnet. The below is the topology of scenario 1.
Figure 1 Scenario 1 Topology The IP addresses of the three hosts are shown above and all the three hosts belong to the network 10.0.0.0/24. The IP address, network ID and subnet mask detail of each host is provided below:
Table 1 Host details for scenario 1
Scenario 2
Topology of Scenario 2 is similar to that of scenario 1. But in this case, the layer 2 switch in scenario 1 will be replaced by a router. So, the three hosts in scenario 2 will be in different subnets. The below is the topology of scenario 1.
Figure 2 Scenario 2 Topology The detailed parameters of the host, the router port info and the router routing table are provided here below:
Scenario 3
Scenario 3 is the most complex of all the three and it is designed to be as close as possible to real- life deployments. This scenario has both switches and routers and multiple networks all inter- connected with these switches and routers. The below is the topology for scenario 3.
Figure 3 Scenario 3 Topology In the above figure, h9 to h23 represents hosts, S4 to S8 represents switches and we have three routers Router1, Router2, Router3. The detailed parameters of the hosts, the router port info and routing tables of all the routers are given below:
Scenario 3b This scenario is an extension of scenario 3 where we will explore the traffic filtering functionality of the SDN controller. Following the same topology and controller as the completed Scenario 3. Install rules to the network devices to support the following situations:
- It was found out that the user device h12 has been infected with a deadly Malware, all communications to this device should be stopped immediately. Install rules to allow no communication to h12.
- h17 is a secure server, we want to block all unauthorized IP and TCP connections to h17. Only the CEO, who is using the h18 computer, is allowed to make a TCP connection to h17 for upload/download. However, the IT team also requires to be able to check the health of h17.
You will be performing a total of three scenarios in this project. Please go to the project folder in the DEN website. There you can find 9 python files along with this project description pdf. Please download all those files. The below is the list of files and the locations to copy them.
Code Description
The files controller_1.py, controller_2.py, controller_3.py and controller_3b.py are the controller files corresponding to scenario 1, scenario 2, scenario 3 and scenario 3b, respectively. The main functions in these files and their description is provided below:
launch ()
This function is invoked whenever a packet forwarding switch connects to the controller. This function then creates a unique object of the Tutorial class for every packet forwarding switch. From this function, the control goes to the tutorial class initializing function init ()
In the init function, you need to classify whether the device is a router or a switch based on the DPID of the device. The DPIDs will be assigned depending on how you define the devices in your topology files. So, be careful while writing your topology files. For scenario 1 and scenario 2, there is only one device – switch in scenario 1 and router in scenario 2, so you will not have much complexity in these two scenarios. But, be careful while writing the topology file of scenario 3.
Once you know the type of device based on its DPID, you need to initialize all the data structures that are required for it. Read the comments given in the function for more details.
handle_PacketIn ()
Whenever the controller receives a packet from a packet forwarding switch (could be a router or a switch) over OpenFlow, this function gets invoked. “packet” variable that gets created in this function is the actual ethernet frame that the packet forwarding switch has received from other device in the network (other networking device can be a host or another packet forwarding device). The “packet_in” variable that gets created in this function is the OpenFlow header inside which the “packet” ethernet frame is encapsulated and sent to the controller. Depending on whether the packet forwarding switch from which the packet is received is a router or a switch, you should either invoke the switch_handler or the router_handler passing the appropriate arguments. Read the comments given in the function for more details.
switch_handler ()
This function is in the switch.py file and this function is the beginning for your
switch code. This function gets invoked when a packet is received by controller from
a switch in the topology. This function receives three input arguments. The switch
object, the packet and the packet_in. Write the switch code here and if you wish to
have any helper functions for switch, write them in the switch.py file. Read the
comments given in the function for more details.
router_handler ()
This function is in the router.py file and this function is the beginning for your router
code. This function gets invoked when a packet is received by controller from a
router in the topology. This function receives three input arguments. The router
object, the packet and the packet_in. Write the router code here and if you wish to
have any helper functions for router, write them in the router.py file. Read the
comments given in the function for more details.
Topology Files
You need to write the code for the topology for the three scenarios in the topology files provided to you. topology_1.py, topology_2.py and topology_3.py are for the topologies of scenario 1, scenario 2 and scenario 3 respectively. Note: The comments are mentioned as [555 Comments] in each file.
Design of data structures and code Remember one thing while you design your data structures for switches and routers and the code for switch and router. Even though you have three different scenarios, they will all use two and only two functions viz., switch_handler and router_handler. The first two scenarios are to keep things easy and let you help start with the coding. In real-life deployments there will be many routers and switches and all these devices will be controlled by a single controller.
Support for buffering packets if there is no MAC address for a destination host in the router cache. ARP request should be generated by router when a packet destined to a host in a network attached to the routers interface is received. Once the ARP reply is received by the router, the router should retrieve the queued packets and forward them to the hosts on the appropriate port. Support for ICMP Echo Reply (Ping reply if ping request received for router’s interface IP address)
Support for ICMP Network Unreachable - in case router cannot find a route to the destination IP address in the packet.
Once the controller determines the output port for a destination IP address, it should install OpenFlow rules in the router so that subsequent packets should not come to the controller. The conditions and actions should be determined by you and the OpenFlow rules should be installed accordingly by controller in the routers in the topology.
Commands to start controller and topology Commands to start controllers to be given from the folder – “/home/mininet/pox” Commands to start topology to be given from the folder – “/home/mininet/mininet/custom” Ensure you issue “sudo mn -c” (from any folder) before starting the controller and topology. Always controller should be started first, followed by topology. Scenario 1 Controller - ./pox.py log.level --DEBUG misc.controller_1 Topology - sudo mn --custom topology_1.py --topo mytopo --mac --controller remote Scenario 2 Controller - ./pox.py log.level --DEBUG misc.controller_2 Topology - sudo mn --custom topology_2.py --topo mytopo --mac --controller remote Scenario 3 Controller - ./pox.py log.level --DEBUG misc.controller_3 Topology - sudo mn --custom topology_3.py --topo mytopo --mac --controller remote Scenario 3b Controller - ./pox.py log.level --DEBUG misc.controller_3b Topology - sudo mn --custom topology_3.py --topo mytopo --mac --controller remote
Report
Please submit a report in PDF format that contains a high-level description of your router design, switch design and the data structures you used to achieve the functionalities of router and switch. The report must be named “report.pdf” (all small case letters).
Grading Guidelines
The below are the grading guidelines for the three scenarios. e possible: 110 points
