The buzz about Software Defined Networking has been reaching new heights lately. After being taught about it in the class, the idea of handling packets via an external software, known as controller, will catch anyone's eye. Before talking more about SDN, let us see what switches in network do these days.
What are the operations of a switch?
If even S2 and S3 don't have corresponding MAC entries, they broadcast the packet as well to all other interfaces except the one where they received from. Hence, S2 will send packet to H2 and S3 while S3 will send the packet to H3 and S2.
Now, the packet received by S3 and S2 by other switches will send the packets to the hosts connected and also back to S1. When switch S1 gets back the same packet, since there were no MAC entries for the headers of the packet, it broadcasts to all other interfaces. This leads to flooding in the network in which the packets continue to remain in the network without getting dropped.
Note: Hosts h1, h2 and h3 will also receive the packet which they will drop due to unmatched headers.
If there are 4 connections among these 3 switches as shown in the image below, it is an open invitation to broadcast storm. In a broadcast storm the packets are never dropped and they always multiply resulting into throttling of the network. We would like you to give a try to see how the packet is getting multiplied using a pen and a paper for the given topology below.
It is not the fault of a switch that causes broadcast storm, it is the decision made by switches "locally" that results to a broadcast storm. The switches are not aware of the topology they are in, so they do not know the consequences for their action. If somehow a forwarding decision could be made globally and taking care of the topology, all the packets will then be sent along the path decided. Here we introduce Software Defined Networking abbreviated as SDN.
As a brief idea about SDN was given in the Prologue, separating control plane from the switches and making them centralized will allow the controller to be made aware of the entire topology of the network and make better forwarding decisions. This will eliminate the chances of having a broadcast storm or flooding and also reduce the existence of unnecessary packets in the network.
By having a control plane outside the switches, the network management team can also define specific actions for the switches against the specific headers of a packet, without physically accessing the switch. This means, in huge data centers, after the initial setup of the network, the network team need not physically visit the rack for making changes in the flow of packets. Actions could be drop, flood, forward, etc. that will be discussed in the later posts.
We hope that this post has helped you in getting a rough idea for the requirement of this technology. We can safely comment that:
In the next post, we will cover the basic concepts of Software Defined Networking
What do traditional self-learning L2 switches do?
Switches maintain a table known as Switch Table with the following headers:| MAC Address | Interface No. | Timeout |
What are the operations of a switch?
- Store-and-forward: When a packet arrives in a switch, the switch stores the source MAC address of the packet. If the MAC address is already present then no updates in the Switch Table are made. The destination MAC address stored in the headers of the packet is mapped with that available in the Switch Table. If an entry is found, the switch forwards the arrived packet to the Interface No. corresponding to the MAC Address in the switch table.
- Broadcast: If a switch doesn't have a matching entry for the destination MAC address in it's switch table, it broadcasts the packet to all interfaces except from the one where it received the packet.
If even S2 and S3 don't have corresponding MAC entries, they broadcast the packet as well to all other interfaces except the one where they received from. Hence, S2 will send packet to H2 and S3 while S3 will send the packet to H3 and S2.
Note: Hosts h1, h2 and h3 will also receive the packet which they will drop due to unmatched headers.
If there are 4 connections among these 3 switches as shown in the image below, it is an open invitation to broadcast storm. In a broadcast storm the packets are never dropped and they always multiply resulting into throttling of the network. We would like you to give a try to see how the packet is getting multiplied using a pen and a paper for the given topology below.
It is not the fault of a switch that causes broadcast storm, it is the decision made by switches "locally" that results to a broadcast storm. The switches are not aware of the topology they are in, so they do not know the consequences for their action. If somehow a forwarding decision could be made globally and taking care of the topology, all the packets will then be sent along the path decided. Here we introduce Software Defined Networking abbreviated as SDN.
As a brief idea about SDN was given in the Prologue, separating control plane from the switches and making them centralized will allow the controller to be made aware of the entire topology of the network and make better forwarding decisions. This will eliminate the chances of having a broadcast storm or flooding and also reduce the existence of unnecessary packets in the network.
By having a control plane outside the switches, the network management team can also define specific actions for the switches against the specific headers of a packet, without physically accessing the switch. This means, in huge data centers, after the initial setup of the network, the network team need not physically visit the rack for making changes in the flow of packets. Actions could be drop, flood, forward, etc. that will be discussed in the later posts.
We hope that this post has helped you in getting a rough idea for the requirement of this technology. We can safely comment that:
| "Software Defined Networking makes a switch dumber but the network more intelligent" |
In the next post, we will cover the basic concepts of Software Defined Networking
Nice intro to flooding and broadcast storm.
ReplyDeleteA question..
SDN expects to know the "entire topology"(which makes the network intelligent),is it scale-able also when their are millions of computers across network?
Hey Ritesh,
ReplyDeleteIt won't be scalable for large networks as the decision making might take more time to determine the right path which will inadvertently affect the average rate of data transfer. Just putting my thoughts, we can have multiple controllers and create a via points in between. For A to talk to D, controller X will forward from A to B and B will have a flow to forward it to C. Controller Y handles C and D, hence Y will forward flows to C for forwarding to D. This way, the entire network is divided among to certain controllers thereby relinquishing the burden on controllers once the packet is sent out.
Yes, the controllers need to communicate among themselves as well for deciding.