Day 68: Syncing between master and slave controllers Part 2

We decided in our previous post that we need to keep our slave controller in sync.

What is the scenario we are looking at?

  • The master controller gets connected to all switches and contributed to installing flows in them, thus master controller knows all flows in all switches
  • The slave controllers mostly get connected to only switches in their domain and thus whenever a switch migrates from one slave to another slave, the second slave controller has to spend bandwidth and time knowing about the flows installed in it
To avoid the overhead that exists during switch migration, we need to ensure that all controllers are in sync with what flows exist in what switches. I had initially decided to follow the below approach:

Since the master controller knows all flows at all times, the slave controller would contact the master controller just after switch migration. The master controller which is aware of the switch migration would give necessary details of the flows in the switch for the proper communication between slave controller and switch.

Few problems with this approach:
  • Switch migration is not a functionality of the master controller, it happens in the load balancer
  • Once the switch migrates from one slave controller 1 to another slave controller, there is no conclusive way of telling if it was switch migration or an addition of a new switch
  • The master controller has to keep monitoring both slave controllers to detect any switch migration - I tries this but seemed like an overhead. Thus, I found a better solution
The new approach:
  • Each switch gets connected to 1 slave and 1 master when new flows have to be installed in it
  • In the rest of the time, it is required for all controllers to monitor all switches if they are going through a DoS attcak
  • As explained in post Day 65, all controllers keep monitoring switch statistics by creating new TCP connections
  • These connections get initiated on the controller side and receive a reply from the switch
  • During this phase, switch flows are also exchanged as statistical information
  • Thus, all controller monitoring a particular switch know about all flows installed in them
  • Each controller monitors switches in a round-robin sort of fashion by applying necessary locks and removing these locks once the data is extracted
  • Thus all controller remain in sync, but just without the intervention of the master controller
  • Whatever I had planned to communicate between master and slave controllers in my previous approach, I am doing the same by just contacting the switch directly now.
Refer to previous and next posts here.

Author: Shravanya
Co-author: Swati

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