Day 30: Making new mistakes!!!

It is Day 30 already!!! But I'm still making mistakes, but more importantly learning from them!

So today, I started to implement the HAProxy load balancer as we had discussed in yesterday's post. As stated in Day 26's post, we needed 8 hosts and connected each of them as mentioned in that day's post. While I was doing this, I came across many errors.

Few gateway errors, few ICMP not reachable and Host unreachable errors. So to simplify the architecture, I introduced a D-Link switch between all the Zodiac FX switches and the load balancer. But this caused a problem earlier when all my switches were connected to a common D-Link switch and to each other since it formed a loop. So this time, I ensured that the loop doesn't occur by removing the connection between the switches (will let you know even if this approach fails at a later stage).

Well....why did I do that? Since all my Zodiac FX switches are configured on the same subnet, I do not require a differernt interface to listen to each of their traffic. Hence, I combined the interface to one. Another thing I could've tried that would probably make more sense is to configure all switches with different IP Subnets. I shall give that a try tomorrow or by next week.

Coming to the problem I faced today, I had connected two interfaces to my load balancer, one to act as a front-end and one that acts as a back-end. Both the IP adresses assigned to these interfaces were same since the Zodiac FX - Controller communication needs to happen on the same subnet. So whenever I used to ping my load balancer from my controllers, it gave a host unreachable error. But when I pinged from my front-end side, i.e the switches side to the load balancer, it worked perfectly fine.

The reason this happens is because the two interfaces are in the same subnet, the traffic reaches one of the interfaces by default. And this default in my case was the front-end part of the interface. Thus all traffic meant for the back-end was also accumulating in front-end thus messing up the traffic flow.

The solutions I have thought of so far is:

  1. chnage the subnets and try
  2. try if the default can be changed - by mentioning that traffic from these particular IPs should go to particular interfaces
  3. configure each Zodiac FX and Controller pair as one subnet, so potentially we shall be dealing with 3 subnets on the load balancer.
I shall try few of the above soluitons tomorrow with a little more research. Hopefully I find a solution ;)

Refer to previous and next posts here.

PS: This article might not make too much sense unless a visual is used while explaining. It was written for the sole purpose of keeping a record, hence excuse me for not making it too comprehensive.

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