As you may be aware, there have been multiple proprietary networking devices, such as firewalls, switches, and routers, that were made by different network vendors. However, owing to the proprietary information from each different vendor, multiple network devices might not exist in a single network infrastructure environment. Even if they exist together, network engineers have to focus their effort on ensuring that each vendor device can exist in a network path without any hiccups. There might be times when one routing protocol might not be compatible with all the network devices in a multi-vendor environment, and a lot of time is wasted ensuring either the removal of that protocol, or the removal of the vendor which that does not support that protocol. This can waste effort and time, which could be better spent improving the infrastructure.
To solve this type of issue, software-defined networking (SDN) has been introduced. In an SDN scenario, a packet flow is defined from a central controller that in turn interacts with multi-vendor equipment to create/define rules based upon the required packet flow. This shifts the focus of a network engineer entirely to how the traffic flows, which path the packet takes, to even responding to link down situations through automated routing of packets by configuring some rules or policies on the controllers. Another advantage of SDN is that the multi-vendor equipment is now not the center piece of infrastructure. The focus shifts to how optimally the routing and traffic shaping (the process to identify the optimal path of traffic flow) is occurring. As part of Software driven tasks, there are pieces of code that are specifically written to control a specific task or goal (similar to functions or methods in programming). This piece of code is triggered by controller decisions or rules, which in turn adds, modifies, or deletes configs on the multi-vendor device to ensure the rule set on the controller is adhered to. SDN even has the ability to completely isolate a failure domain, through the identification of a physical link down or even a total device failure without affecting the flow of traffic in real time. For example, a switch can issue a request to the controller if it gets a packet destined for a network that it does not know. This would be a packet drop or route not found in a traditional network model, but with SDN, it is the task of a controller to provide the destination or path information to the switches to correctly route the packet.
This ensures the troubleshooting becomes much easier, since a network engineer now has full control of each path/packet flow, irrespective of the vendor-specific protocol or technology support. Additionally, since now we are following a standard set of protocols, we can even lower our costs by removing more expensive proprietary network devices and replacing them with open standards network gear.
