After
a brief introduction to SDN and followed by mininet, lets dive into the
main objective of our project. In this particular post we would
introduce you to the problem statement and the solution we are trying to
provide in order to extend the capabilities of a switch in Mininet.
In
SDN we came across the concept of controllers and switches, their
interaction with each other through the openFlow protocol. In the first
network topology we have seen switches connected to each other resulting
in flooding and broadcast storm which was solved by a single controller
connected to multiple switches as show in our previous post related to Flooding and Broadcast storm.
/*EDITED*/Now
if the controller fails, it will go into emergency mode providing emergency flows.So how can we change or modify the network in order
to make our openVswitches more intelligent? That is the CRUX of our
project.
- First approach would be introduction of more controllers such that each controller is connected to multiple switches.
- Second would be to modify the switch such that multiple controllers can be connected to a single switch.
Approach 1
As the first approach is already implemented and tested in Mininet 2.1, we would be going with the second approach.
Now
at this stage, you will be having a lot of questions about - How will
the topology look like? What are the advantages? And how are we
implementing this? Are there any drawbacks or extensions?
Lets
answer them, since Mininet uses OpenVSwitch, it is necessary to first
check if the service of multiple controller is provided by the
OpenVSwitch. As per the following link it is clear that OpenVSwitch does have a support for multiple
controllers.
Hence we can GO ahead with our second approach.
With respect to the benefits, there are two major advantages compared to the switches talking to a single controller:
- Decentralization: As we have multiple controllers talking to a switch, there are multiple flow entries provided by different controllers to the switch. If one of the controller fails we can still have the network working which is not possible in the older case. This solves the problem of single point failure.
- Load Balancing: As the packet is sent to multiple controllers, we can expect a fast response from at least one of the controllers whereas in the other case a single controller is bombarded with packets from different switches, hence there is a high chance of delay in the response.
The next section will cover the implementation aspect related to mininet and the process of how we are gonna ATTACK !!
Network doesnt' shutdown when controller failure occurs. It is only that new flows by controller may not be installed, but existing network flow will continue to work.
ReplyDeleteFurther, you need to be clear on what you are trying to achieve with multiple controllers. If load balancing, then this can be done by controller(s) itself and switch doesn't need to care about it. Single Controller IP can actually be a set of controllers doing their own LB.
So, you need to focus more on partitioning of the network rather than load balancing. Similarly, backup controller on failure can still be dealt with Virtual IP being used by primary and secondary controllers and switch can be transparent to that. However, network partitioning i.e. one part of network is managed by one controller and other part of network is managed by other controller is what needs to be focused on.