Software-Defined Networking has been around for a few years, and now we can say it is here to stay. SDN, in fact, is a whole framework of protocols and tools that automates a lot of tasks for network engineers. As a result, you can get rid of tedious and daunting tasks like port configuration, and focus on things that matter like capacity planning. Cisco has introduced Network Programmability in the CCNA to explain to everyone what are the potentialities of an automated network. In this article, we’ll find out!
SDN Introduction
Cisco talks a lot about network programmability, but never mentions SDN in its CCNA topics list. However, this is what network programmability really is, and for that, we don’t want to limit ourselves to just Cisco.
So, what is SDN? A lot of people talk about it, but it’s hard to find a simple SDN introduction. Well, you are now in the right place. SDN is just what the name says: a Software Defined Network. In other words, software running on a server somewhere can control and modify the network. That software can create subnets, configure ports, modify routing protocols, and so on. Virtually, it can do everything that you used to do.
The administrator has to access that server, which then controls all the network devices.
The Controller
An SDN controller is the software controlling the network. It can run on a server, or possibly a couple of them to add redundancy. Furthermore, you can even host it in the cloud.
The administrator connects to the controller and configures the network intelligently. This means that it won’t simply do the same things he did from the controller, he will change the way he works.
Imagine you have to add a subnet on a site. You would need to create a VLAN, assign ports to it, prepare the default gateway, HSRP and configure the routing so that anyone can reach the new subnet. In the controller, you wouldn’t do that. Instead, you would simply tell the controller to add a subnet on a given site, and it will take care of everything. You have saved hours and hours of a tedious job.
Control Plane, Data Plane, Forwarding Plane
Before we can dive deeper into SDN or network programmability, we need to understand the different plans of network devices. In fact, each router or switch has a control plane, data plane, and forwarding plane.
The Control Plane hosts the administrative interface. If you type commands into a switch, it will have some software running in the control plane to understand what you are writing. To work, it will read and write on some memory portions in the control and data plane. We also know this item as Management Plane.
In the Data Plane, the device works with the data in the packets it receives. Here we have the routing table and the information from various routing protocols and static routes. To configure a static route, for example, the control plane will have to write in the data plane. This is the place where
Finally, the Forwarding Plane. This is where forwarding decisions happen. The router uses ASICs to perform fast-forwarding, and occasionally route the packet to the data plane if a routing decision is needed. Note that modern routers prepare a pre-compiled set of routing decisions that are installed in the forwarding plane so that any packet to be router doesn’t need to go to the Data Plane. No matter what, packets are never checked against the control plane.
Northbound and Southbound APIs
Many people think about the CLI when they think about the Control Plane of a device. This is correct, but the CLI isn’t the only element there. Some Cisco devices support HTTP and HTTPs configuration services, which also reside here. However, the most important thing for SDN is APIs.
An API is an Application Programming Interface, a piece of code designed so that another piece of code can control this application. In the case of networking devices, the application to be controlled is the network device itself, while the application controlling it is the ISDN controller.
SDN adopts a layered approach (similar to OSI) when integrating the controller with networking devices. The controller has several API modules, each to control a specific type of device. A Cisco switch will have its API, a Cisco router will have a different API, and so on. Since this API interfaces to lower-level stuff (the network device), it is a Southbound API, because it goes down in the stack.
On the device, on the other hand, we will have a Northbound API ready to receive calls from the Southbound API.
Cisco Network Programmability
With the Cloud, different SDN solutions appeared. For them, VMware started to be a competitor of Cisco, and at the same time, some Open Source projects started to be so solid and reliable to enter the Enterprise market. One of them, designed for the cloud, is OpenStack, which includes a network virtualization (SDN) solution.
To respond to that, Cisco started to work on its SDN solution and forged a new type of Engineer specialized in SDN. For that, they created their SDN toolkit for Datacenters: the Application Centric Infrastructure (ACI), that integrates with Nexus switches. While it is a solid product, its significant cost made it weak in sales. Meanwhile, they designed a new certification track: Network Programmability Developer (NPDEV). If you want to purse this path, here’s what you will need to know.
- Basics of programming
- Basics of networking
- How to configure network devices using Python (programming language)
- How to model the configuration of a network device in a data structure
- Understand the APIs Cisco offers to configure its devices (Nexus, ASA, etc.)
- Be able to work with the Cisco Software Development Kit (SDK)
But that’s a whole other story! However, consider going that way after your CCNA, as SDN will surely disrupt the industry and it’s better to know how to deal with it.
