Day 36: Keeping it Alived

In the previous posts we had discussed the implementation architecture and also built it to a fairly good extent. Now, it is time to consider what would happen if the load balancer faces a single point of failure. We need to have a standby load balancer that can become active once the master load balancer is down. As explained yesterday, we shall be looking into Keepalived for the same.

Today, I started to implement a new version of the architecture keeping in mind the introduction of a new system to the architecture which would act as the standby load balancer. So, the new architecture I started implementing today is something like this:


These were the diffculties I faced with the above architecture:
  • The controller needs to be configured with one static route to go to the Router subnet. This is possible only by giving a the next hop as the load balancer that is active at that instant. Since it is a static route, the configuration was not possible
  • As a consequence to the above problem, the controller and Zodiac FX switches could not communicate.
  • Also, a next hop must be specified for packets coming from the router subnet to the controller subnet. This next hop keeps dynamically changing with the active load balancer.
Thus, the problem faced was that the dynamic configuration of the active load balancer could not happen with static routing. Thus, we need to assign Virtual IP addresses to both the interfaces of the load balancers. The new diagram would look something like this:



The difference between this and the previous architecture:
  • The load balancers are configured with keepalived on both of their interfaces
  • The Virtual IP is the gateway for the Zodiac FX switch
  • The Virtual IP of the other interface of the load balancer would be the next hop for the controller to communicate with the switches.
In tomorrow's post we shall explore how to implement keepalived in both of the interfaces of the two load balancers - each belong to the different subnet.

Refer to previous and next articles here.

Author: Shravanya
Co-author: Swati


Comments

  1. Ram P RustagiFebruary 22, 2019 at 6:46 AM

    LBs (with backup) need to work with virtual IP (VIPs). Switches does not know if there is one LB or multiple LB. They only know a single IP. You still are confused between routing of packets. IT should not matter whether there is one router or multiple routers between FX switches and LB. Leave it to IP routing and you should not be concerned about the same,

    ReplyDelete

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