By  Andrew Stibbards | 4 Min Read | Technical Level: Beginner

Downloadable PDF: Software-Defined Networking (SDN), What Is It and How Does It Work

SDN has been a recent buzzword for the last 2 years and keeps popping up. So what is it? Depending on who you ask, it is either the future of networking or just a cool tool that might help. Some companies, such as Google, have already started to make the move to using SDN in their networks, and have seen performance increases from it. Over the past 2 years, there has been a dramatic uptick in the amount of interest shown to SDN. So let’s look at what it is and how it works.

First, let’s define our current situation. Right now, if you want to affect your network’s knowledge or operating status, you have to configure each device in your network. Adding in new hardware, new programs, and new QOS or security policies can sometimes require an administrator configuring numerous individual devices. Those devices could be from multiple vendors, which will require the administrator to have a working knowledge of the operating system (OS) and configuration methods for each device. As your network scales, it becomes more and more inflexible as more and more devices have to be configured for every change. Eventually, it can stagnate and you will need a new solution, or your administrators won’t want to change anything because it would simply be such a huge undertaking.

Another aspect of our current model is that the control and forwarding planes of devices are usually in the same box. The control plane is the part of the device that makes decisions about how it will handle traffic, the forwarding plane is the part that actually processes and forwards traffic based on how the control plane is configured.

An administrator has to access into the device, using CLI or SNMP or other access methods, and configure the control plane in order to influence new behavior in the forwarding plane. Whether that means modifying an ACL, turning on a routing protocol, adding new HSRP neighbors, really anything, it must be configured on the device. So once your network scales as your business grows, every change and addition will require more and more configuration tasks on existing network devices, in order to guarantee uniform performance. And with more requirements for flexible networking for server provisioning, as well as cloud usage, this can quickly get out of hand. But there is a better solution.

Enter SDN. The big strategy behind SDN is that it decouples the control plane from the forwarding plane. No longer will the decisions for how to handle traffic be made on the same device that is forwarding it. One of the most popular tools for this is the OpenFlow protocol.

So how does OpenFlow work? It will periodically gather information from network devices concerning their status as well as issue commands concerning how to handle traffic. The information it gathers will be passed in an abstract format to a network controller OS, examples of which are ONOS or Cisco’s XNC. On the controller, an administrator can programmatically define how programs and application traffic should be handled. This control information is then pushed out to the network devices through OpenFlow. A great way to think of this is like having a large number of static routes on all your devices, defining traffic forwarding. But instead of the inflexibility of traditional static routes, these SDN routes can auto-adjust and reshape network flow based on what information OpenFlow is receiving from the devices. This also gives administrators a centralized control over their networks. No longer do you have to configure multiple devices when you use a new application. Now you will be able to program how that application should be handled by the network only once; no matter where it goes in your network, it will be treated uniformly.

So this is cool, but it still isn’t the biggest reason why SDN is catching on so quickly. There are two major reasons. The first is cloud usage. With the increased use of cloud computing and storage, there is a concern that your programs and traffic will not be handled the same way “out there” as it is “in here,” or in your local network. What SDN does is view cloud-based services as just more network devices. So when you program how an application should be handled, that control will follow the program out to the cloud, or back to your local network, or wherever your devices exist.

The other major reason is user programmability. OpenFlow currently works with Python and other programming languages, so an individual administrator can define their own tools and protocols for how their network behaves and responds to changes. Sure there will be some standardization, but if there is that One Thing that you wish your network could do, you can now program your network to do it, without waiting for a manufacturer’s OS update to bring you that functionality.

In conclusion, SDN is the answer to some major speed bumps in the world of networking. Before, if there was a problem, we created a solution to that problem and not much else. ACLs, routing protocols, QOS….they all do their job, but each one must be configured individually and on every device. With SDN you get complete control of your network through a single programmable interface, regardless of whether your network is physically present or in the cloud.

To See Sunset Learning Institute’s Full Networking Class Schedule, Please Visit our Routing & Switching Training Page.

To See Additional Instructional Articles and Videos from the Sunset Learning Instructors, Visit the SLI Blog Page.