PETER WELCHER | Solutions Architect 

This blog discusses what the products SD-Access (“SDA”) and Cisco Catalyst Center (“CCC”) encompass , and what they might do for you and your organization. Cisco renaming alert: CCC is the product formerly known as Cisco DNA Center. 

Short version (TL;DR): SDA/CCC are fairly recent Cisco technology, possibly the future of your campus switching, providing powerful automation and potential for major labor– savings. 

While this blog covers what Cisco SDA and Catalyst Center (CCC) consist of and what they can do for you and your organization, a follow-on blog covers considerations and the cons (as in pros/cons). It also provides some advice, discussion of considerations, and takes a brief look at some competing (or sort-of-competing) products.

What Is SD-Access? 

SD-Access (“SD” for “Software Defined”, “SDA” for short) is a strategic combination of Cisco technologies and products. It is now mostly mature architecture with an expanding role in automating campus LAN and WLAN deployment and management, and some ties to Cisco SD-WAN.  

Cisco Catalyst Center (“CCC”, formerly “DNA Center” or “DNAC”) is a GUI for automating and managing SDA, although it can also just be used as a Cisco Prime replacement for managing Catalyst switches.  

Key points about SDA/CCC: 

• SDA requires appropriate Cisco switches, wireless AP’s, and routers. No surprise there! Its coverage even includes just about anything within 1 to 2 prior product lines, i.e. products from the last 10 years or so. 
• SDA and CCC automate  and manage campus switch and Wi–Fi deployments. Not intended for datacenters, WAN routers, or Internet edge.  
• SDA uses a design approach that is physically just the usual modular hierarchical site designs. It configures on top of a sophisticated VXLAN overlay that adds some technical complexity. But that overlay also enables some significant simplification of security segmentation. (Try saying THAT three times fast!)  
• In particular, if you’re getting tired of “VRF rainbows” (extending per-VRF VLANs between devices), SDA’s use of VXLAN provides a simplifying alternative on the switch fabric part of the network.  
• Wireless APs are tied in to all this. SDA automates handling WLAN user traffic in much the same way as wired user traffic if you choose to do so.  
• Firewalls can be used with SDA, effectively “on the edges,”, but are not currently configured by CCC. They do not do VXLAN. You do still need to extend VRF’s via VLANs to firewalls or a legacy WAN or SD-WAN (apparently now with automation).  
• For “close” sites, VXLAN can even be used between them in a two-tier tunneling scheme, simply deployed as LISP-based SD-Access Transit.   
• SDA CCC and Cisco SD-WAN support some automated interoperation with each other. It is already possible to manually tie the two together preserving VRF segmentation. Micro-segmentation carries over in the form of Security Group Tags (SGTs) — TrustSec. 
• SDA extends ISE and Cisco TrustSec (NAC plus group tags) with automation of deployment providing a full segmentation solution.  
• The Cisco ISE security management product is a key component of the SDA architecture. It provides for solid 802.1x or NAC (Network Admission Control) and TrustSec related functionality. It supports the micro-segmentation tagging used by SDA and CCC.  
• CCC smoothly integrates with ISE for most of the functionality where the two products overlap. A few security features can be configured via either product (but you must choose which one you intend to use).   

Some specifics: 

• Cisco ISE allows campus designs to use ISE to automatically assign users to groups, impose logical or physical security (“scalable”) group tags (SGT’s) on their traffic, set their switch port’s access VLAN, and optionally apply dynamic access lists. This can leverage other information known about the users or devices.  
• ISE also supports the onboarding of devices, BYOD devices, etc. Because ISE strongly supports 802.1x or NAC (Network Admission Control), it provides support for SDA-adjacent services (TrustSec: SGT’s).  
• CCC automates that and ties in IP addressing, the creation of VLAN’s and security groups, plus VRFs (“VNs” in SDA nomenclature) segmentation across one or many sites.  
• CCC also automates configuration of BGP and LISP routing at sites, enabling dynamic LISP-based VXLAN tunnels within each site. Doing so robustly extends VLANs across each site, mitigating spanning tree instability risk.  

How this helps you operate your network: 

• Automation provides consistency. Doing VXLAN by hand is time-consuming (even with templates) and error-prone. **Been there, done that, and hope I’m not doing that ever again!** 
• SDA controls embedded virtual or standalone WLCs (wireless controllers) as needed to automate integrated wireless access points.  
• Wireless no longer needs to be tunnel back-hauled to a costly Controller. That is a Good Thing: the WLC has always been a potential traffic bottleneck. With SDA, Wi-Fi packets are forwarded similarly to switched packets, not via any controller (unless you prefer that). APs are configured to support this via CCC, with initial control by local distributed virtual or physical controllers (on a site AP, switch, or physical controller, or centralized if so desired).  In particular, the controller is no longer in the data path, no longer a potential bottleneck!  
• If desired, CCC can also automate “SD Access Transit”, configuring BGP and LISP between sites. This is Hierarchical VXLAN. Doing so enables VXLAN tunneling between sites, as well as egress in the datacenter via a pair of “fusion firewalls”. You can think of this as preserving macro and micro segmentation across multiple sites. It is subject to distance (latency) constraints, making it suitable for city/county/regional use.  

Other Key Aspects 

One initially surprising aspect of SDA is that you no typically longer use VLANs for micro-segmentation with one SGT tag per VLAN. Instead, SGT tags are used with the switches doing non-stateful enforcement via SGACL’s, solely based on SGT group membership. You don’t need SDA to do this, just ISE TrustSec, but my impression is that many sites pair SGT’s with VLANs to ensure firewall-based enforcement.  

This does alter site design, since instead of one subnet per VLAN, you now have one bigger subnet across all the micro-segments within a given VRF (VN) macro-segment. While re-addressing is not essential to migrate to this, doing so reduces the amount of GUI work needed to deploy SDA (simpler, less error-prone).  

This choice can interact with 911 end-user location systems.  

Why Should You Care? 

So why would someone do SD-Access?  

This is basically the “pros” side of SDA and CCC. We’ll revisit this in the context of pros versus cons in the follow-on blog.  

CCC provides operational management of the campus (Catalyst) switches and AP’s: 

• Easy use of CCC for device discovery and device inventory. 
• CCC supports configuration templates for working at a basic automation level (no SDA), or for things like standardized management templates. 
• CCC detects and reports on configuration drift (manual changes on a device).  
• CCC provides IOS version management and device IOS upgrade automation. 
• CCC has some integration with Cisco SD-WAN..  
• CCC collects up/down and SNMP/telemetry data, useful for managing a network. 
• CCC is based on IP pools and sub-pool assignments to sites, etc. In effect, it includes basic IPAM-like functionality. It does integrate with InfoBlox DNS fairly well, except that the linkage may not cleanly survive product updates.  

CCC supports troubleshooting: 

• It provides problem alerts along with basic and AI-enhanced troubleshooting. I expect this part to keep getting better and better, now with increasing numbers of AI features. 
• “Wizard” troubleshooting assistance might be useful, especially for inexperienced staff. 
• It can get data from iPhones, in effect turning user cell phones into constant sources of Wi-Fi performance/quality data. You can even watch a Wi-Fi device roaming within a site map. 

CCC includes canned automation-related features, available on Day 1 (i.e. no coding required!): 

• Device inventory tracking and health monitoring. With automated device discovery.  
• Automated deployment of IOS code upgrades while track which code each device is running, and scheduling upgrades.  
• Configuration automation. Pre-built, supported, not DIY. You can reliably deploy complex and consistent VXLAN configurations across 10’s or 100’s of Cisco switches. The configurations will be correct on Day 1.  
• Automation and consistency significantly reduces the number of problems that will arise from manual configuration. Experience bears this out.  
• Both of the above factors can save a lot of time (hours or days). They also allow you to offload deployment to less costly / less skilled teams (modulo a little CCC training): “expert plus remote hands.”.  
• Change detection including config drift can reduce unplanned outages.  

• Provides site-wide roaming. Every micro-segment is active on every switch within a fabric site, in a robust way, taking spanning tree instability off the table. Retaining micro-segmentation SGACL’s.  
• ISE-based mapping of users and devices to VRFs, VLANs and secure groups. Change ISE’s posturing of a given user or device, and there is no reconfiguration of network devices.  
• Automated segmentation of users and devices within each site based on the ISE-assigned groups, consistent across many sites. You can specify policy for traffic within and between user / device groups – micro-segmentation SGACL’s. The SDA switches statelessly enforce SGACL’s to control traffic between and even within segments (groups).  
• Central fusion firewalls can be used to enforce group-based policies to control traffic between the VN’s (VRF’s) and security groups within SDA, and to the rest of the datacenter or network, and the outside world.  
• With SDA-Transit, you can easily VXLAN tunnel the VRF segments back to one or more SDA L3 switches or routers and then to fusion firewall pairs, for centralized policy. This provides a central point for monitoring of most user traffic to the datacenter or outside world as well.  
• AnyConnect and Cisco firewalls can be tied into this in support of assigning groups to remote access users. TrustSec on ASA has been available for quite a while, andwhile and is recent on FTD.  
• Your switch and firewall access lists (ACL’s) can become security / scalable group ACL’s or SGACL’s, leveraging user groups instead of IP addresses. This can greatly reduce ACL management and improve readability. When a new site comes up using existing ISE SGT’s, the firewall SGACL rules will not need updating with new subnets! I.e. Intent-Based security, logically independent of IP addresses! 

This all adds up to a very big deal, especially the last item.  

On the security side of things:  

• CCC integrates with ISE, to the extent that one can choose for selected ISE functions to either be operated from ISE, or from CCC (but not both).  
• The big win on this front is that ISE allows integration with Microsoft AD and other identity sources, knows about device OID’s (vendor codes), and so can make sophisticated assignments of devices and users to different security group tags (SGT’s), hence different micro-segments.  
• ISE or DNAC can also then manage “the matrix”, i.e. which SGACL rules to apply for each source/destination group tag pair. Basically, it’s the same GUI, in whichever tool you prefer to use it (but not both – you get to pick one for the site to use).  

Positioning: Where Is SD-Access a Good Fit? 

As with many Cisco products, the ISE product meets large enterprise needs, and therefore supports many ways of doing things, and integrates with many other vendors’ products. That adds some complexity.  

CCC adds mild complexity to ISE, mostly that of learning yet another GUI and of course new ways of  leveraging CCC’s automation.  

CCC workflows are mostly well-documented in deployment guides and are top-down and left-to-right in the GUI. Mostly. There is some mild clunkiness to the GUI, in part perhaps because CCC needs to function as a replacement for Cisco Prime as a general management tool, plus providing all the fancy automation for SD-Access.  

There are a few things that I found hard to find / non-obvious, buried in obscure corners so to speak, so I’d give the GUI a B grade. All of that is minor and may get cleaned up in future releases.  

In terms of skills, ISE is a product that an intermediate level specialist can drive, although an expert might be needed for more complex uses. It is logically organized but can at first be a bit overwhelming due to all the choices and capabilities. Take the course, read the thick book! 

CCC entails a moderate learning curve but hides most of the complexity of what it configures.  

I conclude that an organization might need 1-2 people focused on these two products, and double that if there isn’t an external staffing fallback option. In terms of the skills mix, one skillset might be CCC GUI plus CCNP level switch / AP / router skills. The other might be more of ISE skills. Both with some cross-training on the other.  

Since these personnel / products would be critical across an organization, most organizations would want 2 people with each skillset.  

Firewall skills would also be needed, either by those people or other staff member(s).  

For smaller sites, that number of positions can be tough for staff, as well as costly. Training staff adequately, ditto. Managed services providing support and staff training is one way to compensate for that. MSP sets up and maintains ISE and CCC, trains staff in operational tasks, supports staff with new deployments.  

BlueAlly does that! 

Related factors to consider are staff size, staff turnover rate, network rate of change, and how badly segmentation is needed.  

Conclusion 

CCC, Cisco Catalyst Center, the former DNA Center, can be quite useful for administering campus switches, routers, and access points, across multiple sites. The above focused mostly on potential benefits with some caveats to help you optimize your experience with CCC.  

There are two main use cases where CCC likely fits well: 

• As a Cisco Prime replacement for managing inventory, IOS versions, etc. across non SD-Access sites.  
• As a SD-Access automation and management tool, for varying scales of SD-Access deployment. 

A follow-on blog discusses some negatives, provides more details, and briefly discusses the competition.  

About the Author 

Peter Welcher 

I previously put in considerable design and lab time on Cisco’s SD-Access (“SDA”) technology in a proof of concept / design effort for a fairly large County consulting customer. Since then, I’ve supported my peers in other SD-Access design and deployment work and have received feedback on lessons learned from that original multi-site SDA design. I’ll be incorporating all that into these blogs! 

References 

• Cisco Press book, Software Defined Access 
• Cisco web main page for SD-Access 
• Cisco web page: What Is SD-Access 
• Cisco main web page for Cisco Catalyst Center (which still says Cisco DNA Center in places) 

• Cisco SDA Design Guide 
• Cisco SDA Fabric Deployment Guide (October 2019) 
• Here is the list of prior SD-Access/DNAC/CCC blogs on the NetCraftsmen website: https://netcraftsmen.com/sd-access-dnac-blogs-an-index/

Disclosure Statement