Cisco Catalyst Center: Pros and Cons

PETER WELCHER | Solutions Architect 

This blog steps back from describing Cisco SD-Acccess (“SDA”)/ Cisco Catalyst Center (“CCC”, the former Cisco DNA Center), and instead covers pros and cons from a customer perspective. As well as providing some lessons learned and advice.  

This is effectively Part 2 of the previous blog, “Defining SD-Access and Cisco Catalyst Center: Why You Should Care”.  

The prior blog heavily covered the capabilities of SDA and CCC, what they do, why you might want them, and discusses technical design aspects and key functionality. It also includes some advice at the end.  

This blog assumes you’ve read that blog first, because it heavily covers the “pros” side of the SDA technology and CCC product. Consequently, this blog will focus more on some negative factors, considerations, or concerns that might apply, as well as more thoughts and advice about the SDA technology and the CCC product.  

Some major deciding factors concerning using SDA/CCC are the size of the network, network staffing headcount, and skill level of an organization. But we’ll get to that and more below. 

Potential CCC Negatives 

Here are some potential downsides:   

• Vendor lock-in. SDA and CCC are Cisco-only.  
• The learning curve for SDA and SDA design. You’ll need to wrap your brain around various names for things and what the various components do, at least at a high level. You don’t necessarily need to get deep into LISP or VXLAN details. The good news: Cisco has some great design and overview documents covering this.  
• The learning curve for using CCC. There’s a lot of GUI there! I’d give the GUI an A- or B grade: it’s well-organized but just feels ponderous to me. Hard to avoid that given all the functionality. Some of the workflows strike me as requiring a good bit of clicking around to accomplish, one major sub-tree then another/back-and-forth. Once you catch on, you can plan to enter all the sites, devices, etc. and then separately do all the specifics for them: manage them, and push out configuration elements. That way there is less overall back-and-forth in the GUI, and you’re less likely to get confused, lose your place, and put info about one site into the screens for another.   
• Learning curve for the Zero Touch or Plug-and-Play automated deployment, if you wish to use that functionality. Great capability, but you’ll want to work with it and make sure you can diagnose problems so as to not slow down field deployment of gear, etc.  
• Some things you may take for granted in a campus network may not work yet in SDA. For example, IP multicast was somewhat broken for quite a while (my impression: years) with SDA-Transit. Some IPv6 features have just been implemented. Others may still be absent. (No, I don’t have a handy IPv6 feature checklist for this!) 
• The problems with IP multicast between sites under SD-Transit appears to have recently been resolved as of 12/2023 (not verified).  
• The way CCC handles global IP pools creation and sub-pool allocation is a bit clunky. (Create global pool, create sub-pool, assign it somewhere. This is an example of the back-and-forth mentioned above.) 
• ISE integration is simple to accomplish, but ISE and CCC are two large (and capable) tools to learn. You do have to decide (once and for all) which tool’s GUI you’ll use for certain tasks – small amount of GUI overlap between ISE and CCC.  
• On-prem CCC cluster management (or Cloud). Upgrades reportedly take a long time, and may well fail for obscure reasons. Upgrade problems or other CCC cluster issues can be painful to resolve.  
• There is some other clunkiness for workflows. Logical but clunky. (For example: do global something then create a specific instance of that, then tell SDA to use that at a site.) 
• CCC is Catalyst-specific to a fair degree (may provide some very basic support for Nexus – I haven’t tried to determine how much as this is a “why would you do that?” item). 

My general advice : 

• Use a very vanilla design approach, sticking closely to the Cisco Validated Designs.  
• Stick to basics for deployment, then add segments or VRFs etc. after getting the important functionality and some basic segmentation deployed.  
• In particular, I’m (even outside of SDA) a big fan of regular hierarchical designs: access layer, distribution layer, core layer, dual uplinks, etc. SDA doesn’t care too much about that at the site level. Between sites and Internet access is where redundancy and a balanced structured design matter.  
• Note that having e.g. geographically far apart Internet access paths and wanting sites’ routing to prefer the “nearer” Internet exit can get painful with SDA Transit – the issue is LISP does not have some of the amenities that routing does for biasing the forwarding path.  
• *Carefully* prepare an inventory of protocols and features you are currently using (e.g. IP multicast variants, broadcasts!, IPv6 features, etc.) and make sure they’re supported before you start.  
• Don’t assume that someone won’t buy a networked software or tool product and only then discover they need you to deploy one of the unsupported features. This is especially a risk in large hospital networks. Third party product vendors sometimes can make strange and sub-optimal choices about protocols, assumptions about networking best practices, security, etc.  
• Be aware of the inter-site transit options and their pros and cons. Don’t try to extend SDA-Transit beyond the specified distances. Use multiple SDA regions instead.  
• Think about integration with your SD-WAN product, if using one or considering one.  

CCC Caveats 

Who is CCC appropriate for?  

Given the CCC product learning curve, small/medium-sized single-site or few-site organizations may not want to use CCC. If they use it, it may be more as a Cisco Prime replacement for switch (etc.) management, and not for SDA deployment, etc.  

Here are some tipcs based on experience. Not necessarily negatives, just factors to be aware of.  

• I have found the Cisco CCC (DNAC) documentation almost solely focused on single site deployments, etc. That may be a side-effect of Cisco’s apparent documentation and staffing budget cuts / de-emphasis over the last couple of years. Multi-site documentation can be found but may have gaps.  
• Be aware that multi-site designs significantly benefits from solid up-front effort. Design and testing. My prior SDA blogs (which we plan to port to BlueAlly.com) cover a good bit of what I found and consider advisable – things Cisco had not documented.  
• IMPORTANT: I **most highly** recommend you work with someone experienced with SDA and CCC, especially on overall design. Especially if you plan on using SD-Transit.  
• That means working with your Cisco teams (and BlueAlly, of course!) to make sure you haven’t made any problematic assumptions or planned on doing things the hard way.  
• This is a real concern: BlueAlly staff has had several protracted design discussions with customers around ways their current network operated that would not fit well with SDA, or would require work-arounds and some complexity. Best: clean up the way the network works, then implement SDA. The alternative is to do a complex workaround with SDA and rework it later or never – and live with the additional complexity.  
• In short: experience suggests that cleaning up some frugal but sub-optimal topology design features can make your SDA deployment a lot simpler, and easier to support!  
• Hence my general advice: fix connectivity/topology short-cuts, clean up compromise topology features caused by running out of funding, and use a cookie-cutter design with no quirks, to ensure that your SDA deployment doesn’t run into issues. The SDA design guides show diagrams of various size campus fabrics suitable for SDA. In other words, stick closely to a Cisco Validated Design and you’ll likely have fewer regrets later! 
• Cleanly separate SDA edge devices from e.g. datacenter core routers/switches. Separate devices for separate network roles can be helpful in cleanly separating SDA from non-SDA portions of your network (e.g. datacenter, firewall and Internet, etc.). Shared functionality can add complexity! 

To summarize: 

• Plan multi-site first (and lab it up if you can). 
• Fix topology asymmetries and quick fixes, including complex Internet egress designs. 

Thus, I highly recommend budgeting two things:  

• Buying hardware for a small SDA/CCC lab (and yes, I have a blog about a minimal but sufficient lab layout). It is best to keep the lab separate for testing changes in your design, or later planning of deployment changes. Better to ID snags in the lab than in production! 
• Ensuring staff has plenty of time to use the lab. Like weeks (over a few months).  

Time spent working with CCC and SDA before deploying will be well worth the effort, as you will not have to  do re-work or put up with a quirky deployment for years. Discover “gotchas” in porting what you have to SDA before they affect production.  

My prior blogs covered what I used for a fairly minimal lab (and I hope we’ll get that ported to the BlueAlly website fairly soon!) Note also that old 3750/3850 L3 switches, etc. can help build the lab economically, as infrastructure non-SDA components. Ditto old firewalls! 

If you’re in a rush to do last-minute out-of-support switch replacement, you won’t have time for such cleanup, and also won’t be able to lab things up to gain hands-on experience and train staff. That will likely make deploying SDA more painful! 

Potential Gaps 

If you have strange or corner use cases such as those mentioned above (multicast, IPv6), you do need to verify they can be made to work in a reasonable way with SDA designs. This is where a lab can be very helpful! 

The following are items I have flagged as potential issues.  

• Dual Internet egress sites with SDA Transit – failover is now supported, but as far as I know LISP-based load balancing egress traffic is not (which might be a Good Thing anyway, in terms of complexity). You can probably load balance traffic across egress sites outside the SDA portion of the network, assuming you have a good high-speed link with relatively low latency between the egress sites, are willing to tolerate indirect paths, are willing to do NAT to force stateful returns through firewalls, etc.   
• For dual Internet (or other) egress, you can apply LISP priorities (see another blog) to prefer one exit over the other. But that is NOT simple and adds complexity. 
• IPv6: I haven’t checked for gaps around IPv6 connectivity and routing in SDA/CCC. What you want is probably there, but it is a good idea to verify that all features you require are in fact supported. This would of course be particularly important if you are running pure IPv6 with no IPv4.  

Alternatives to CCC 

Here are some alternatives that come to mind:  

• Manual configuration (painful at scale?) 
• Automation with scripting. Lot of work to code, who maintains it after the programming author leaves employment?  
• Third-party tools instead (support, quality?) 
• Use Meraki switches, or Catalyst switches in limited “Meraki” mode, for cloud management of many small sites and lower costs (but fewer technical options) 
• Nexus Dashboard Fabric Controller may, to some extent, support Catalyst 9K switches, e.g. when used in a small datacenter. (I haven’t used it or explored it in depth recently. It is rather clear this is NOT the primary intended use case, i.e. inadvisable.) 

About Zero Touch Deployment with CCC 

Zero Touch Deployment seems to be everyone’s favorite feature to not use. Well, support is built into CCC, and Zero Touch can be quite a productivity enhancer for large deployments. 

I’ve done it once or twice, and I used to teach it (remember CiscoWorks?). But for small deployments, using a console cable and paste in config is dirt simple. I’ve had the luxury (mostly) of others doing the post-pilot larger deployments.  

Zero Touch can be handy when using relatively unskilled labor for large deployments, or even for connecting it and moving on when doing it yourself!  

The thing about it is that you do have to understand what it does, and resolve field problems, e.g. when a field tech calls in and tells you it isn’t working. Not terrible, just means you need to get some lab time in where you observe it closely, deliberately do something wrong to see what the consequences look like, etc.  

I’ve worked with someone who did a lot of hardware sales/basic deployments, and he swore by Zero Touch (“ZT”). Plug in and cable the box, let it cook while doing the next box. Makes initial deployments go very quickly. He was the CCC / ZT guru, and his team (with lesser skills) did the hands-on box field deployment. E.g. one or several sites (small buildings) with switches and AP’s in a couple/few hours.  

About SDA Design 

My concern (and advice) with that is that if you have more than a couple of sites, it is advisable to do some prior design planning and documentation. For example, establish some structure to your IP addressing scheme. The first time I tried doing this for one site, it would have required ¼ of all the network 10 space, which is a LOT of wasted addressing.  

For SDA, you’ll need at least several subnets per site, possibly of different sizes, probably larger than you’re currently using. Choosing random or sequential subnets prevents you from being able to, say, recognize “that’s a site loopback address.”  

Yes, for IP to site lookups you probably will still need to use the GUI, an IP address manager, or have a list somewhere. 

Note that subnets in CCC tend to be bigger, they don’t need to be per-VLAN. If each site is going to have multiple /20’s, one per VRF, with some room for more, you can burn through address space pretty quickly.  

Anyway, that’s one example of why I previously blogged on the NetCraftsmen website about some of the big picture SD-Access design considerations – and plan to update and revise and post those blogs here on the BlueAlly site.  

Competition 

The competition that the author is aware of competes primarily with Cisco ISE for the 802.1x or NAC (Network Admission Control) role, potentially including dynamic downloadable ACL’s.  

I consider Cisco ISE to be the NAC product with the most features and scalability, with a vast number of options and broad range of supported partners. Some of the competitors appear to claim comparable scaling of number of endpoints supported.   

HPE Aruba ClearPass is Aruba’s answer to ISE, for access control in switch and wireless networks.  

Fortinet sells FortiNAC, formerly Bradford Networks. That used to be popular in colleges, and it was affordable, fairly straightforward, and worked well for a lot of people. I lack recent data on it. It is likely suitable only for small to medium sized sites, as far as I know.  

Others: ForeScout CounterACT, InfoExpress CyberGatekeepr, Auconet BICS, Impulse SafeConnect, Extreme Networks ExtremeControl. See also https://www.esecurityplanet.com/products/top-network-access-control-solutions.html#features.  

Most NAC solutions provide dACL (dynamic ACL) controls at the point of network entry. This is easy to understand and administer but may have scaling and other limitations.  

Firewalls, SDA, and SGACL’s 

Leading firewall vendors have been working to support group-based ACL’s in various forms in their products. Cisco started with SGT awareness, whereas CheckPoint and Palo Alto started with Microsoft Active Directory. The latter two reportedly now also can interact with ISE to pick up Cisco group information and use that in ACL’s.  

The common mechanism is to use Cisco SXP protocol or pxGrid (essentially, Cisco APIs) to get a list of security groups and to map current user IP’s to those groups.  

The author found that CCC and ISE integrated very easily, providing smooth coordination of creation and use of Security Groups. 

The author attempted to install and test CheckPoint’s Identity Collector solution in a lab, but ran into a problem. The relevant CheckPoint installation documentation available at that time was awful. A colleague got it working later. In my defense, the installation directions were terrible.  

Palo Alto has announced something similar. Both Palo Alto’s and CheckPoint’s solutions rely on an intermediary server that gathers groups and IP to group mappings and passes them on. The author was not in a position to test the Palo Alto solution.  

Both CheckPoint and Palo Alto clearly started with the ability to pick up Microsoft groups and attributes, and added ISE integration to that framework.  

Note that these tools (Cisco, CheckPoint, and Palo Alto) obtain the list of groups and configure it into the firewall for you. They also track IP to group mappings. As far as I can tell, none of the products currently do anything regarding policy or SG-based ACL rule creation  in the firewall itself, even starter stub configurations. That may be a good thing from a security perspective.   

References 

• Cisco Press book, Software Defined Access 
• Cisco web main page for SD-Access 
• Cisco web page about SD-Access 
• Cisco main web page for DNA Center 
• 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/  

Conclusion 

Yes, this is a long blog. I hope you’ve found the advice useful, and not off-putting. If some of the above seems limiting, consider that automation means your design needs to observe some constraints – automation of deployment of a free-form network would be HARD! 

CCC is quite powerful. Small sites may want to use it as a basic manager of devices, and larger sites might want to use it to automate and manage SDA deployment.