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.
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.
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.
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:
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.
This network controller can then communicate with the routers and switches. This communication can be two-way, in that the network controller can send instructions to the routers and switches (e.g. telling them how to update their tables), while also gleaning information from these devices. In such a situation, where the control planes of our network devices are residing on a centralized network controller, we have what is referred to as a centralized control plane.
Notice the dashed arrows in the above graphic. Those are Application Programming Interfaces(APIs), representing how the controller communicates with the network devices. Typically, when we draw this out, the controller sits above the network devices. So, these APIs, which go from the controller down to the network devices, are called southbound APIs, or southbound interfaces (SBIs).
Did you notice the network controller is labeled with a couple of acronyms, APIC and ACI? Let’s discuss what these mean?
Cisco ACI, which stands for Application Centric Infrastructure, is the name Cisco gives its SDN architecture. So, Cisco ACI is not something different than SDN. Rather, it’s how Cisco brands their SDN solution.
APIC, which stands for Application Policy Infrastructure Controller, is a component of Cisco ACI that acts as an SDN network controller. The APIC commonly uses a southbound API called OpFlexwhen it communicates with network devices. OpFlex can communicate with multiple Cisco and third-party devices supporting OpFlex.
However, how does our network controller know what to control? Well, we can have applications that talk with the network controller. For example, an application might tell a network controller to create a VLAN on a couple of switches or to configure an OSPF routing process on a couple of routers. Remember how we had southbound APIs to talk from the controller down to the network devices? Well, you guessed it, we have northbound APIs, or northbound interfaces (NBIs), that go from the network controller up to the applications (since we typically draw the applications above (i.e. north of) the network controller).
These NBIs allow us to not only send instructions to the controller, but we can retrieve monitoring information from the controller (e.g. to monitor processor utilization on our network devices). NBIs also give us a layer of abstraction, meaning that we can tell an application what we want to happen in the network (e.g. give voice traffic 2 Mbps of priority bandwidth) rather than issuing the specific commands to make it happen.
Earlier, we mentioned that we might be using OpFlex as the API between our APIC and our network devices. This begs the question, how are we communicating between our applications and the APIC?
Interestingly, SDN does not always use a centralized control plane. For example, we might have lots of traditional Cisco routers and switches in our network that have no knowledge of OpFlex or the concept of a centralized control plane. Devices such as these must have and maintain their own local control plane, meaning that we need to be running in a distributed control plane environment. For situations like this, Cisco gives us another type of SDN network controller. It’s called the Application Policy Infrastructure Controller Enterprise Module (APIC-EM).
The APIC-EM is a Cisco SDN network controller that can communicate with traditional routers and switches via more familiar southbound interfaces such as Telnet, SSH, or SNMP. This brings up the question, if the APIC-EM is not centralizing the control planes of network devices, what is it doing?
For one thing, the APIC-EM collects tons of diagnostic information from our network devices. We can also centrally make configuration changes and then push out those changes to our network devices. Basically, the APIC-EM supports network programmability but does not support a centralized control plane.
The APIC-EM also supports a variety of apps. One such app is the Discovery app, which lets the APIC-EM discover a network’s topology.
Another app is the APIC-EM Path Trace app, which takes information collected by the Discovery app and simulates what would happen if a specific type of traffic was sent from a specified source to a specified destination. This is accomplished without actually sending any traffic through the network.
The list of topics for the CCNA R/S v3 exam specifically lists the APIC-EM Path Trace ACL Analysis Tool, which is a component of the Path Trace app. What this tool does is a synthetic path trace (i.e. no data is actually sent), while accounting for any ACLs configured in our network devices. Therefore, if traffic is blocked because of an ACL, we get to see exactly where that ACL is applied, and even what instruction in the ACL blocked the traffic.
If you’re studying for the CCNA R/S v3 exam (or even if you’re not), I hope you’ve found this article helpful. For even more information about this exciting topic, please check out my CCNA R/S v3 Complete Video Course, available from Cisco Press later this year. In that course, I’ll also demonstrate the sending of RESTful APIs to a controller and even show you how to use the APIC-EM Path Trace ACL Analysis Tool to discover where traffic is being blocked along its path.
All the best in your studies!
Kevin Wallace, CCIEx2 (R/S and Collaboration) #7945
If you enjoyed this article, you might also want to subscribe to my podcast: