Day 26 part 1: "Redirecting" back in the right direction

Welcome back!!!
Sorry for not updating for the past few days. Days 23, 24 and 25 were spent in introspection, reading up on how to build Ryu applications and how to achieve the proposed architecture.

To summarize the mistakes done so far, and where we should rectify ourselves:
  1. The proposed architecture in the previous post was wrong in one place. There is a D-Link switch that connected all the switches to the controller. This is catastrophic. I shall explain why. Although my switches are designed to act as routers, they still exchange ARP, ICMP and few other packets with the each other and the controller. When ARP packets are sent, they get stuck in a loop. Thus discovering MAC addresses of the neighboring switch also leads to an infinite loop. The loop is formed by Zodiac FX switches being connected to a common D-Link switch. I had committed a similar mistake previously when my Zodiac FX switches were acting as layer-2 switches. I assumed that since they are layer-3 now, the loop wouldn't affect the network. But since Zodiac FX switches are responsible for ARP, ICMP and other traffic in both layer-2 and layer-3 functionality, the problem persists.
  2. Assuming that the load balancer should be a controller to capture and redirect the OpenFlow messages. This is not the case, since all OpenFlow messages are also encapsulated in a TCP stream. Any load balancer that can take care of TCP loads, can also take care of the OpenFlow messages flowing between the controller and the switch. Little more about OpenFlow will be discussed in today's article.
  3. Since I had assumed that load balancer = controller, I was going through Ryu application tutorials to build a load balancer using Python. I did find two useful libraries in case anyone is looking for the same - PumpkinLB and DPKT libraries. This was obviously a wrong approach since any normal LBs can also do the job and I need not code from scratch for a load balancing application. HAProxy is one tool I am looking at right now to achieve the same.
 Enough about the past! Let's talk what's cooking. So today I built the network as shown in the below architectural block diagram. The only thing changed from the previous architecture to now, is the elimination of the D-Link switch in between switches and load balancers. I shall upload a video of how to set-up the network, once the design of the load balancer is ready.


Requirement:
  • 8 Linux based systems - atleast one of which has more than or equal to 6 USB/Ethernet ports
  • 1 D-Link switch
  • 3 NICs (Network Interface Cards)
  • 3 Zodiac FX switches
  • 3 USB cables
  • 13 ethernet cables.
 I have recommended 3 NIC cards since all my systems have 6 ports. But each of my systems have only 1 ethernet port and 5 USB ports. Since I needed to convert atleast 3 other USB ports to ethernet, I have used 3 NICs. Right now, the systems are just connected, IP addresses are set. So the functionality possible is:
  • Switches can talk to the load balancer since that is the single point of contact to the controller
  • Controllers can talk to each other since all my controllers are present in the same subnet. I could change this, but for now I am planning to work with it since in my previous experiments a switch and controller in different subnets couldn't talk to each other.
What we need to know about OpenFlow to design the Load Balancer?

OpenFlow comes in two contexts - When someone says OpenFLow Controllers, they just mean that the controller communicates with the SDN enabled switch through the OpenFlow protocol. Here OpenFlow Controller or OpenFlow communication constitutes the layer 2 of the OSI model - the data link layer. The SDN switches and controllers also lie in the data-link layer. That is the reason OpenFlow communication is termed as a layer 2 activity.

This is not to be confused with OpenFlow protocol. OpenFlow protocol is the a protocol that is used in OpenFlow communication. Since our control plane layer runs the application layer on top of it, the controller needs to communicate with some application layer protocol that is encapsulated in other protocols. This application layer protocol is the OpenFlow protocol. This is further encapsulated in TCP, IPv4 and Ethernet formats. Since I had this confusion of how can OpenFlow be addressed as both layer 2 and application layer protocol, I've addressed this issue to clarify the same for anyone else who had the same doubt.

To look at an OpenFlow packet, you could refer to the below diagram that I've borrowed from the link: https://www.slideshare.net/openflow/openflow-tutorial



From now on, our focus is completely implementation of the above architecture. In tomorrow's post, I shall be discussing how to build the Load Balancer in our architecture. I shall be referring to this link for the same.

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