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
