Day 52: Switchover mechanism vs tcpliveplay

In Day 50's article we familiarized ourselves with tcpliveplay and how to use the same to redirect OpenFlow packets to the master controller. Yesterday, I tried to create TCP connections from master controller to the switch from which the duplicated packets reached the master controller.

These were few findings that made me rethink my tcpliveplay approach:
  • Zodiac FX switch cannot forward packets to the required port if it is not connected to any controller. This is irrespective of whether the flows are already installed in it or not.
  • Whenever a Zodiac FX switch contacts any controller, it informs the controller of all the flows it already has installed in it. Only new flows get installed from then on. Thus the controller automatically becomes aware of the previously installed flows. This does not take perceivable amount of time.
  • The flows installed in the FX switch keep getting updated and this is the reason the FX switch needs to be connected to a controller at all times. Failing which, the FX switch fails to forward packets.
Considering the above newly found facts, we need to reconsider if our tcpliveplay strategy is even necessary. By tcpliveplay we can definitely ensure synchronization between slave and master controllers as the packets that reach slave controllers also reach master controller. But the master controller doesn't have the liberty to respond to this OpenFlow request message as slave controller is responsible of the same. Imagine a scenario where both the slave and master controller send OpenFlow replies to the FX switch. Here comes a race condition. The FX switch could either receive slave controller reply first which would get replaced by master controller's reply, the reverse of this situation could happen or worse, no flow gets installed since both come in simultaneously and FX switch doesn't have any priority or race condition resolving algorithm or strategy.

This is when I thought of another strategy that could work: continuous switch-over between slave and master controllers. In this scenario, say s1 has slave controller as c1 and master controller as mc. It will first contact c1, install few flows for a particular amount of time. A switch-over happens and now the switch s1 is connected to mc. The first communication they have, the FX switch makes mc aware of all flows installed and thus mc can install more flows if there are any or keep on updating the existing flows. In our previous strategy, a switch-over would happen only if the controller went down. But now, it happens every few seconds or minutes based on the load each slave and master controller are subjected to.

In case s1 is under a DDoS attack and thus floods the controller with request packets, this switch-over frequency increases. This also ensures that not too many resources of a particular controller gets exhausted. The switch-over functionality is implemented on the load balancer by mentioning two backend servers for one ACL rule.

If unfortunately the slave controller comes down, the other slave controller c2 will take-over. Thus the switch migration task is also taken care by the load balancer.

We are yet to address the case when the master controller is down. We shall look into a back-up master controller and using keepalived to automatically activate it when the actual master controller is down. I shall discuss the same in the near future.

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 1: Understanding Ransomware and how to detect them?

Image
To start this journey, let’s begin at the basics and learn about what ransomwares are, what is the meaning of a ransomware attack, how have other people detected it so far? By learning the above, we will be in a position to analyze any ransomware attack and devise methods to detect, mitigate and prevent them. Definition: Ransomware is a type of malicious software from cryptovirology that threatens to publish the victim's data or perpetually block access to it unless a ransom is paid. To continue understanding and addressing the threats posed by ransomware, let us dig a little deeper. As the definition specifies, ransomware is a type of malicious software. Now, what is a malicious software? Definition: Malware (= Malicious + Software) is a software which is specifically designed to disrupt, damage, or gain authorized access to a computer system. These malwares (or simply dangerous content that can corrupt your system), can enter your system from various s...
Read more