Day 14 Part 2: Few Road-blocks in simulating the required Architecture

This article was meant to be published on 24/01/2019, but due to forgetfulness on my part, it is getting published a day later xP

Continuing the simulation where we left off, we had built a master slave architecture of controllers where all switches were accessed by all controllers.

Today, we shall simulate a very similar network to what our problem statement demands: A distributed SDN controller where each switch is only connected to two controllers - one master controller and one equal controller.

The code pretty much remains very similar. Instead of running the code on one controller, today we shall make copies of the same code and run it on different controllers. Only the master controller will remain common wrt all switches. If we assume 'c1' from the previous codes as master controller, we have to run the code with 2 cotrollers on c2, c3 and c4 machines to achieve the above architecture.

In case you want to refer to the codes again, I have compiled it into a GitHub repository: https://github.com/shravanyag/Distributed-SDN-Controller-Security
Hope this helps!

Once the simulation of the architecture is built, it is time to test it. All hosts that are connected to the same controller remain reachbale from each other provided you are running the simple_switch_13.py program on Ryu controller. The problem arises when we have to communicate across controllers. After surveying the same, I have come to the conclusion that it is not simple to build libraries from scratch to do the same. Instead there are the following approaches we could take:

1) TCP connection
2) communication using JGroups
3) SDNi library in OpenDayLight (of course this means that we need to learn a new controller along with the interfaces provided by SDNi to establish communications among controllers)

We shall be looing at these possibilities in tomorrow's article. Also, we have to still address the issues we shall be facing when we start the hardware implementaion of the architecture with Zodiac FX switches, which would hopefully be soon.

One major issue with the Zodiac FX switches and the designed architecture is that Zodiac FX switches have reserved only 1 port for OpenFlow Controller-switch communication. How can we install more than one controller per switch? We shall try addressing this problem soon. If you happen to know any solution, feel free to write it down as a comment to this post!

Comments

Post a Comment

Popular posts from this blog

Day 12: Master Slave SDN Controller Architecture

In the previous post, I was struggling to figure out why all controllers can install flows in all switches irrespective of the code. Well, today the mystery is getting resolved. I found this book that explains beautifully the various roles that a controller can play. The three roles are: Equal : this happens by default all the equal controllers in a network that are connected to the switch can add and delete flows from it Slave: it has a read-only limitation to the switch openflow tables Master: very similar to the switch, but only 1 master can be connected to the switch at that point of time, and no other flows can intercept the communication between switch and master. I highly recommend you go through the above link to get a better picture. Since the default role of any controller is "Equal", we couldn't really differentiate between the three controller flows yesterday. But one good news from this is that we don't really need extensive coding to assi
Read more

Day 50: Tcpreplay and tcpliveplay approach

Today we shall be exploring how to copy and redirect the OpenFlow packets to more than one controller from the load balancer. The load balancer is anyway sending the OpenFlow packets to one of the slave controllers - c1 or c2. The packets sent to these two controllers needs to be sent to master controller so the master controller can update the new flows added by c1 or c2 on the switches. This ensures synchronization between controllers. There are two implementation methods to achieve the same: Copy all packets generated from the load balancer to the controller side. Only the packets having destination IP address of c1 and c2 can be redirected to the master controller. Thus we can prevent the packets which already are reaching the master controller to be sent as duplicates Copy and redirect packets from the slave controllers - c1 and c2. We need not take care of duplicate packets reaching master controller. This will reduce the time taken to redirect packets. Since the second a
Read more

Day 10: Mininet Simulation of a basic distributed SDN controller architeture

Hi and welcome back! We have not been able to update the blog since we were busy debugging and figuring out!!! We are back to give you an in-detail explanation of how we have simulated a basic distributed SDN controller architecture. Requirement: 2 Hosts Mininet up and running Ryu controller up and running on each 1 D-link switch We have used two linux machines with Ubuntu 16.04 OS running on them.  How to install Mininet? Run the following command on a terminal to install mininet: > sudo apt-get install mininet How to install Ryu Controller? Make sure to install Ryu controller on each of the Linux machines so that they can act as a controller. Run the following commands for a successful installation of Ryu controller: > git clone git://github.com/osrg/ryu.git > cd ryu > sudo apt-get install python-dev python-pip python-setuptools   > sudo pip install . > sudo pip install webob eventlet paramiko routes Set Up the network
Read more