DNA, SDA, and ACI - What in the Software-Defined World are They?

If there is one thing that drives me crazy, it is the way technology companies market their products. Software-Defined is the new “cloud,” and almost every piece of marketing material is the same. Take the hot new term, add in the obligatory 5-10 “tech sounding” acronyms and sprinkle in some sexy words like scalable, digitization, strategy and boom!

Insert sexy marketing speak, here:  "XYZ is a Software-Defined, cloud-based digitization strategy for the scalable hybrid architecture!" So, what you're saying is switches and routers (or other hardware for that matter) have never been powered by software before? Yeah, exactly.  

I get it. I can fall into the hype too; I love using terms like VXLAN, LISP, API as much as anybody, but it is time to step back and provide some foundational information on Cisco’s latest dive into the “Software-Defined” networking market. 

What are DNA, SDA, and ACI, and why are we discussing them together?

This isn’t helpful without context, so here is a definition for each term: 

• DNA – Digital Network Architecture
• SDA – Software-Defined Access
• ACI – Application Centric Infrastructure

First, there is a hierarchy to understand here, SDA is married to DNA. You can’t implement SDA in isolation.  You can, however, just use DNA for management capabilities – it just doesn’t get you too far. They're also specifically designed for the access layer, or in simple terms: end-users and devices—think IoT here. They are built for connecting people or things to applications. DNA is the management plane, and SDA is the underlying technology to deliver a specific feature set. Which leads me to the third term, Application Centric Infrastructure.

ACI is meant for the data center. Simply put, ACI is the latest networking technology for your server infrastructure:

• whether that is running physical servers with Windows (maybe a few out there?),
• VMware with multiple guests operating systems, or
• a more complex architecture like cloud/containerized applications.

For the history nerds out there, first came ACI, then DNA was delivered second, and most recently, SDA. Let’s look at them each, more specifically.

DNA and SDA

For simplicities sake, I'm going to describe it like this: It's a box (Silicon Valley watchers will appreciate that one).  Obviously, it's more than a box, but when you purchase DNA from Cisco, that's what you get. Either one or three Cisco C-Series servers to plug into your rack. one server = no redundancy, three servers = redundant cluster. These servers are connected to your network via 10G and for the most part, are managed like other appliances you install into the environment. Now, what is running on that box is the application we call DNA, which is the future management platform of all things Cisco networking; with some caveats. How do I make this next comparison without freaking people out? Think Cisco Prime, but…think a working, functional, what you always wanted Prime to be—Prime. Then, imagine 10X better than that. DNA is ridiculously cool, the “box” is running containerized applications orchestrated through Kubernetes, doing all of the cool things people have been preaching for a few years. 

So, for you, DNA is an appliance (or set of appliances) that you plug into the network, throw a few IP addresses into the setup wizard, and then manage via a web browser. This Cisco DNA management platform, among other things, currently does the automation tasks of:

• deploying new switches,
• inventory control,
• wireless SSID management, and
• software version control.

Imagine taking a switch out of a box, plugging it into the infrastructure, and with a few clicks automating the deployment of all of your VLANs, VRF’s, QoS policies and all you did was connect power and some up-link cables. DNA nailed it.  Digital Network Architectures are the heartbeat of automation in the new Cisco world. What it does not do is manage all of your legacy Cisco gear. Even if someone says, it does; trust me, don’t do it. R2 takes the stance that standing up a new DNA stack should be in conjunction with more modern deployments taking advantages of the latest features, which brings me to the next topic: SDA.

Software-Defined Access is the Future of Cisco Switches and APs

There, I said it. Here's my prediction: SDA is the future of all Cisco switches and access points, and if you're a consumer of Cisco products for switching and/or wireless, you will be running SDA within the next 5 years depending on when your future significant Cisco investment happens. For clarification, Meraki products are currently not part of the SDA capable products, but that roadmap is presently being developed. Another disclaimer, SDA has been marketed along with the introduction of the Cisco Catalyst 9000 series of switches, but there is some backward compatibility with older models like the 3850’s and 4500’s (depending on SUP engines). That being said, remember all of the cool features that Cisco has been talking about for years? TrustSec, VXLAN, Identity Services (ISE), 802.1x, port-based security, global ACLs, SGTs, etc.? The kind of things that give you heartburn because you know how painful it will be to stitch it all together? Yeah, those. Well, SDA has wrapped all of these technologies in a nice little deployment bow to give you the deliverable you've always expected. Here's a hypothetical of SDA in Action:

With SDA, you'll have the ability to put an end-user in a group in an Active Directory – let’s call her Jane in Accounting – and no matter which way Jane connects to the network, wired or wirelessly, she:

• is authenticated as Jane,
• gets the same IP/VLAN she always should have,
• gets the same ACL assignment wherever she goes, and
• her traffic doesn’t intersect with other routing domains you want to keep separate. 

It’s like Jane has her own dedicated lane between her and her default gateway so that all of her L3/L2 traffic is controlled by a single policy. Jane can no longer move laterally to her peers or access IoT devices without you explicitly authorizing it for her group. Jane and the rest of the team have the mobility they require, with the security they need, all with a simple group assignment. Feel free to roam about the campus, Jane.

Better yet, now, you don't have to: manage ACL’s across multiple switches, manage VLANs across multiple switches, prune VLANs based on location, manage QoS policies, extend L2 over L3, and, most importantly login to a single switch. Just grab yourself a Starbucks (or Dunkin' if that’s your preference) and give a wink and a smile to the domain admin.

There is a lot of complexity to SDA when you dive deep into the details, like fabric border (core) and fabric edge requirements, but DNA as a management plane has executed it all for you and allowed you to point and click your way to happiness. I have been incredibly critical of previous versions of management software from Cisco, even early versions of DNA – but this has me impressed and excited to see what is next.

If ACI came first, why leave it for last?

Foundationally, ACI and SDA have very similar deliverables, but Jane is no longer an end-user. Instead, Jane is now a server or application. I leave it for last because I think it is easier to explain micro-segmentation in terms of end-user access than it is in the server/application world, there is a physical nature that seems to be more comfortable for customers to grasp. While the deliverables are similar-ish, the technologies are slightly different. For example, ACI doesn’t require an identity engine because the idea of authentication to the network doesn’t exist in the data center as it does in an IDF. While SDA uses [fabric] core/edge design on switches, ACI calls it spine/leaf. ACI’s big debut was made during the introduction of the Nexus 9000 series of switches – not to be confused with the Catalyst 9000 series, or of course the new Catalyst 9100 series AP’s; thanks Cisco! ACI, like DNA, starts with a box, or series of boxes that run the management application Application Policy Infrastructure Controller (APIC). In this case, APIC is most similar to DNA, the management plane. I can’t say for sure DNA was born out of APIC, but it wouldn’t surprise me one bit.

Cisco Application Policy Infrastructure Controller (APIC)

While SDA was built for the access layer, ACI was created for the data center. It is focused heavily on micro-segmentation, extending L2 over L3, virtual machine integration, and API integration. Instead of the system admin adding Jane to a group to restrict access, now the system admin creates a policy during processes like backup windows which tailor a security or QoS policy during the time the job runs. It allows the network to “flow” with applications based on policy rather than configuring each switch independently with unique QoS and ACL’s. ACI also automates operations for switch management, not entirely as touch-free as DNA, but with the same concepts in mind – release control, L2/L3 management, etc. ACI can be deployed with many hypervisors and the latest version now support “ACI Anywhere” which is a cloud-based deployment model. ACI Anywhere, at least for me, sounds like where Cisco’s Intercloud (now dead) wanted to go but could never get there. Imagine finally being able to deploy applications independent of underlying infrastructure and have L3-L7 services available no matter where the application operates. I think this is the goal everyone (except maybe the hypervisor and cloud companies) are hoping for, pure commoditized computing and portability. That is a little further into the future than today, but it is an incredibly bright future.

Getting Started with DNA, SDA, and ACI: What You Need

If you're looking to get started with either of these technologies today, here's a, “fairly simple,” list of things you would need (sans licensing):

DNA/SDA:

• DNA Appliance (either single or a cluster of 3) 
• Fabric border switches (Catalyst 9000 series switch capable of being a core, likely the 9500/9600 series)
• Fabric edge switches for connecting end users (Catalyst 9000, Catalyst 3850, Catalyst 4500, etc.)
• ISE (Identity Services Engine)

For wireless:

• SDA compatible WLC (Catalyst 9800 series, 3504’s, 5520’s, 8540’s)
• SDA compatible AP’s (Most AC Wave 1/2 are supported)

• APIC Appliance(s)
• Spine switches (Nexus 9000 series)
• Leaf switches (Nexus 9000 series)

Both of these architectures have entry points that don’t involve churning 100% of your environment, so next time you are looking at expansion or replacement, take a look at a strategy that allows you to start moving this direction for both campus and data center networks.  If you're ready to take this conversation to the next level, join us onsite as we dive into the Cisco Network Intuitive.