Day 47: Way Forward - Phase 3 of architecture implementation

Coming back to the architecture we have been building, let us look at what has been completed:

  • The switch can communicate with the controller for installing flows
  • This communication happens over a load balancer
  • Load balancer takes care of failover mechanism
  • Load balancer also takes care of switch-controller mapping
  • Load balancer is protected from Single point of failure through keepalived
  • Controllers are protected from crashing by limiting the number of connections they can handle - this is also the responsibility of the load balancer (could be fine tuned)
So, the major chunk of work left to complete building a highly available, reliable and secure SDN controller architecture is as follows:
  • We need to take care of assigning master controller a hierarchy 1 by forwarding all packets that enter the controller network
  • We need to protect master controller from single point of failure
Strategies to achieve the same:
  • Today, I looked at a publisher-subscriber model which you guys are pretty familiar with: Kafka and Zookeeper. I tried to implement a messaging system as explained by Swati in her post on Day 27. Observations I made:
    • I can forward tcpdump data from any of my controller to the master controller
    • But, my master controller can only view this as a text file and won't be subjected to the traffic itself. It needs to do further processing to analyze the packets
    • This is not my requirement, as I am required to multicast packets from either load balancer or the controllers in hierarchy 2
    • The master controller can listen on any other port and not on 6633 where my controller is running. So extra forwarding needs to be done from the consumer port to my ryu controller port. This leads to complicating things.
  • Another option I looked at today, is tcpreplay. Few features I thought might suit my requirements better are:
    • It has an option to collect tcpdump or wireshark packets and store it as .pcap file which can be replayed later
    • The master controller can be subjected to the stored traffic through tcpliveplay
The two features mentioned under tcpreplay seem more useful than Kafka and Zookeeper implementation. Although, I am still yet to decide how to send these .pcap files from a hierarchy 2 controller to hierarchy 1. I might be using kafka for this, if required. In case you have better suggestions, please drop them down as a comment to this post.

Coming to the second task that is yet to be done, I shall again use keepalived for protecting my master controller from Single point of failure.

You can refer to previous and next articles 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