The recently announced CCNA R/S version 3 includes a collection of topics falling under the category of Network Programmability. The underlying technology here is Software Defined Network (SDN), which allows network device configurations to be orchestrated through software applications. Basically, instead of accessing a router or switch command line to enter traditional Cisco IOS commands, we can write a program (typically written in the Python programming language) to make changes to one or more devices. So, the purpose of this blog post is for you to learn the theory and architecture behind SDN.
SDN Orchestrates Network Operations
The Promise of SDN
Traditional networks, where we individually configure routers and switches, simply do not scale well nor do they adapt well to dynamic environments. For example, maybe you run an e-commerce business, and you’re about to announce a big sale. To handle the anticipated spike in traffic, you spin up some virtual machines (VMs) and want to route a portion of your traffic to those VMs just coming online. Also, you might need to adjust your quality of service (QoS) policies to account for the increase in bandwidth demand. Then, when your big sale is over, you want to return to your previous configuration. Making such a change involves many moving parts, and instead of individually visiting each network device and making changes via the command line, you could have a centralized point of control that oversees those changes. That’s the benefit and the promise of SDN.
The Concern of Cisco Professionals
Before diving into the theory, let’s address the elephant in the room, and that is the future for traditional Cisco professionals that are experts with Cisco IOS configurations but might be lacking in programming skills. Many strong opinions are currently circulating in the network community regarding this concern. Recently, I attended Cisco Live where I talked with multiple people within Cisco knowledgeable about SDN and its impact on what it means to be a Cisco professional. Based on those conversations, here’s my take on this controversy:
Over the coming years, knowing how to write programs (that talk with an SDN controller) is going to be increasingly important for Cisco professionals. This applies not just to those network engineers working on routers and switches, but also to those working with most any other Cisco technology (e.g. collaboration servers, wireless devices, security appliances, and on and on). You see, Cisco publicly announced they see a future where all network components can be controlled by software.
However, while I’m certainly being proactive and teaching myself Python programming, I fervently believe that knowledge of all the underlying technologies is still critical. Otherwise, we wouldn’t really understand what we’re doing when writing those programs. So, in brief, I believe the Cisco professional of tomorrow should definitely have some basic programming skills, while simultaneously being grounded in network theory.
Review of Architectural Planes
Now, let’s start getting into what SDN is all about. One benefit that SDN offers (in some but not all situations) is having a centralized control plane. Recall that a Cisco router or switch has three basic architectural planes of operation:
Data Plane: The data plane is in charge of frame or packet forwarding. For example, it’s this plane that handles things like encapsulation, decapsulation, checking a MAC address table on a switch to determine an appropriate exit interface, checking the IP routing table on a router to determine an appropriate exit interface, filtering traffic with access control lists (ACLs), and encrypting traffic.
Control Plane: The control plane is controlling the data plane, in that it populates a switch’s MAC address table and a router’s IP routing table. It’s here at the control plane where protocols such as Spanning Tree Protocol (STP) and IP routing protocols run.
Management Plane: The management plane is concerned with administrative access to a network device. For example, when you connect to a router or switch via a Telnet or Secure Shell (SSH) session, that’s made possible by the management plane. Or perhaps you have a network management station running Simple Network Management Protocol (SNMP) that communicates with a network device. That communication is occurring at the management plane.
Distributed vs. Centralized Control Planes
When we have multiple network devices, each of which have their own data, control, and management planes, we call that a distributed control plane. To make things more efficient, some SDN installations allow us to have a network controller, and move the control planes from each network device and consolidate all of them in the network controller.