THE BLOG

Software Defined Networking (SDN) Simplified

ccna r/s Jul 26, 2016

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.

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.

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.

SDN’s Pieces, Parts, and Protocols

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?

We typically use Representational State Transfer (REST) APIs. Some of the literature refers to these as RESTful APIs, and they use HTTP messages (e.g. GET or PUT) to send information between an application and an SDN controller. If we wanted to retrieve information from a controller, we could use the GET message. Similarly, we could use the PUT message to send information to a controller. To two most common formats we use when configuring these RESTful APIs are JavaScript Object Notation (JSON) and Extensible Markup Language (XML).

APIC-EM

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.

Your Next Step

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.