Cisco SDA – Moving Software Defined to the Access Layer

Software Defined “Anything” is a common thread amongst the networking community these days. We have Software Defined Data Center (SDDC), Software Defined WAN (SD-WAN), Software Defined Network Security (SDNS), and now we are actually seeing Cisco move us into the Software Defined Access Layer (SD-Access). This latest announcement of SD-Access falls under the Intent-based networking concept that Cisco touted at Cisco Live 2017, known as “The Network. Intuitive.” A key component of this architecture is what Cisco calls DNA-Center, and it provides a platform for policy, automation, and analytics. This sits atop the Intent-based network infrastructure. What exactly does this jargon equate to in terms of how I operate my access-layer and how I provide network access to clients? Let’s try to break it down.

What is Software-Defined Access?

Software-Defined Access (SD-Access) is actually made possible by several innovations in hardware and software. It includes the QuantumFlow Processor (QFP) and the Unified Access Data Plane (UADP) processor as well as IOS-XE.

The QFP is an advanced, multi-core, feature-rich routing silicon found in the ASR platforms and the UADP processor, now in its 2.x version, provides a high-performance programmable switching silicon found in the Catalyst 3K, Catalyst 9K, Catalyst 4K. So with the power and programability Cisco is now able to deliver the SD-Access solution we’re discussing here. But lets get a little deeper into the weeds. Lets work through the following diagram.

In our graphic we are looking at a campus network and it’s clear that there are three management nodes that sit up at the top. These include the APIC-EM, ISE and NDP.

The Management Piece

The APIC-EM is the controller that handles the policy configuration and automation for the campus, branch, and WAN. It supports both wired and wireless networks, does network discovery, creates a network information database that can be your single source of truth when it comes to devices in the network, and it lets you visualize the network topology. Sounds great right? But what about security controls and authentication? For that we need to swing over to ISE.

ISE controls the authentication and authorization policy for network access. It performs 802.1x authentications for clients and pushes policy to network devices based on how a device may posture, the type of device, who’s logging on, and where the device is located. ISE is the cornerstone of Cisco Trustsec and integrates with most of todays current products. But all this data that ISE has, and all this data that APIC-EM knows, and all this live traffic that these network devices see; where does that go? For this we swing over the NDP.

NDP is an analytics engine. It’s an external data collector that is leveraged to analyze endpoint to app flows and monitor fabric status.

When we put the three of these management solutions in play together we end up with some nice control and visibility over the network. But there’s just one problem. Have you ever configured ISE? Not easy right? There’s a lot to know when it comes to building those policies, navigating the interface and so on. The same is true for these other products. So jumping between them kinda stinks, and doesn’t provide me that “single-pane-of-glass” that everyone says they have but nobody really delivers (mostly). And this is where DNA Center comes into the equation.

DNA Center takes all that functionality and rolls it into a single management GUI. This single GUI approach provides automation & assurance of all Fabric configuration, management and group-based policy and integrate external Service Apps, to orchestrate your entire LAN, Wireless LAN and WAN access network.

And that’s your management portion of SD-Access. But wait… There’s more.

The Campus Fabric

In the campus fabric we have several nodes to be aware of and they are nicely illustrated in the following graphic.

Fabric Border Nodes are like a core device that connect us to an external L3 network.

Fabric Edge Nodes connect wired devices to the fabric. This would be something like your access-layer switch.

Fabrice Wireless Controllers are the equivalent, but obviously they would connect wireless devices to the fabric.

Control Plane Nodes run a host tracking database to map location information, Endpoint IDs, to a current location. Edge and Border nodes sense registration information to the control plane node for known IP prefixes. With all these devices registered the control plane node then services resolution requests from edge and border routers to locate destination Endpoint IDs.

Intermediate Node If you have devices in your network that don’t support SD-Access these can act as intermediate nodes, creating an underlay network. This network is managed separate from the SD-Access network infrastructure but can be used in the interim of an upgrade to the devices.

How it Works

So how does all this work to move my packets? Well essentially the fabric forms an overlay.

The control-plane is based on LISP. The LISP DB and cache mean small tables & less CPU with anycast L3 gateway, compared to the big tables and high CPU we used to burn. The Data-plane is based on VXLAN. And the policy-plane is based on CTS. There’s a lot of technologies in play here but the overall configuration of the network is simplified because we do everything up in DNA-center and let the network figure out the rest. Scary for network engineers that are used to having their hands on everything, but there’s a lot to be said about network automation and the speed at which we can deliver new services.

So lets get back to the DNA-center portion and what we called “The Network. Intuitive.”

Intent-based Networking

If all goes according to plan here’s what I see. I see the use of APIs gluing together these disparate management and monitoring devices into the single DNA Center GUI, which in turn orchestrates connectivity and policy for the infrastructure.

That being said, a network operator should only have to express intent, in human language, and the network “should” understand what to do and be provisioned to do so. Oh, and all that should be monitored.

Our Architecture would look something like this:

My Take

Complex network functions could be simplified if Cisco truly delivers SD-Access in they way they’ve described it at Cisco Live 2017 and Tech Field Day Extra at Cisco Live. I feel that this could be a turning point for Cisco where they have a serious opportunity to be leaders in software defined network at the access-layer, if they can roll all this into DNA-center and deliver it without a lot of tuning and tweaking and mostly bug free. I don’t expect that we will see routers and switches that have been running for 10 years without a reboot these days, but I do expect to see more solid software development and maybe using somewhat open APIs is the answer to consistency in configurations, security application, and monitoring. I’m excited to see what actual customers are saying as SD-access is realized in production networks. Until then I’ll drink the Kool-aid!

Disclaimer

I was invited to attend Tech Field Day Extra at CLUS 2017 as an event delegate. I received no compensation for my time and was not swayed to write anything good or bad about the presenting vendor. I was provided a warm lunch and mediocre coffee.