Cisco DNAC Journey Part 1 – Expectations and Reality

We’ve just finished Cisco DNA Assurance PoV… what can I say about it? Not much… It feels like a right product, but way too young for mass adoption. We only deployed the appliance itself with the aim to try DNA Assurance. However, we faced a number of issues from Day 1 even though it was a mentored install. I just thought I will share some information and maybe it will make someone’s life easier 🙂

  • DNAC was shipped with software version 1.1.x, so we’ve upgraded to version 1.2.5 right after completing initial configuration
  • Upgrade was successfully applied and we carefully followed deployment/upgrade guide for this version (1.2.5)
  • After upgrade Enterprise VIP stopped responding, which resulted in a TAC case and escalation to BU. Eventually they admitted that deployment/upgrade guide was not correct (had fundamental error). Basically, as per deployment guide, if you’re planning to run DNAC as a standalone appliance (no clustering), then you only have to cable two interfaces (bare minimum) – Enterprise (management and data plane) and CIMC (appliance management). Other ports, including Cluster 10Gbps, did not require any cabling, even though Cluster interface required an IP address. It worked well on 1.1.x, but upgrade introduced two key requirements
    • Cluster interface MUST be cabled and link MUST be up from Layer 2 perspective
    • Both, Cluster and Enterprise, interfaces MUST have VIP configured. You can’t have only one VIP for Enterprise, both ports require VIP configuration – when you configure appliance using maglev config tool make sure to list both VIPs separated by space.
  • We have been forced to travel to our DC to get this fixed!
  • Upgrade to 1.2.5 has broken Assurance in a way that telemetry configuration (syslog/snmp/netflow) was not pushed to network devices. This issue has been just fixed with the release of 1.2.6 (confirmed in our environment)

Apart from these issues we have faced the following limitations, which shouldn’t affect Greenfield deployments, but are show stoppers for Brownfield deployments:

  • Provisioning only works, if devices are managed using Loopback0 interfaces. One of BU guys told us that this is a fundamental design issue. Cisco SDA works by utilizing Loopback0 interfaces, which are configured in an automated fashion. As far as I understand developers are now looking to change this behavior as it affects multiple customers. Not surprised at all. For example, we use Loopbacks to manage our devices, but not Loopback0. What does it mean? We can’t use automation tool, such as Configuration Templates provisioning.
  • If you have multiple Smart Accounts associated with your CCO ID, then DNAC will automatically associate itself with the first in the list returned by licensing API. In my case it picked up wrong Smart Account (the one we use for Security EA, but not Switching EA). As a result, I am unable to automate license provisioning. Been told this is going to be fixed in 1.3. A suggestion has been made to use dedicated CCO ID associated to only one Smart Account.
  • It doesn’t support legacy WLC platforms. By legacy I mean Cisco 5508, 2504 and vWLC. This is where I’ve gone mad. DNAC discovers these platforms and onboards them without any issues, but then it shows all as NO DATA affecting Overall Network Health Rating. Effectively all WLCs and associated APs are treated as DOWN. At the same time my lab Catalyst 3750, which is EoL for many years was green-green with score of 10 on the dashboard and didn’t affect Overall Health Score. Whoever made this decision is wrong. DNAC either should not allow engineers to add/discover legacy devices (be it Catalyst 3750, or WLC 5508), or otherwise it should at least provide some meaningful monitoring data. Come on. Cisco Prime Infrastructure can do better!
  • Templates. Overall this tool looks promising. It is sleek. There’s templates editor with syntax highlighting. There’s simulation to test templates output providing input values for variables, there’s version control. But… it’s incomplete. For example, composite templates seem to be very buggy. I wasn’t able to create ANY meaningful composite template as it did not allow me to drag and drop regular templates except ONE (even though I had multiple templates defined for that exact device and software type)
  • Network Plug and Play. No way to provision device using composite template. Well… composite templates don’t work well anyway (see above). Not quite sure if this toolkit is as complete as Prime’s… need to read more about it and compare it to Prime with PnP gateway and ability to push bootstrap configuration using iOS Plug and Play application (and lightning console cable).
  • Last one… if you want to enable Maximal Visibility for Assurance on ISR platform know this – NetFlow configuration will ONLY be enabled on interfaces which have LAN word in their description. That’s it. Can be suffix, prefix, can be separated by dash, or underscore, but this keyword MUST be part of description. Otherwise DNAC won’t apply NetFlow and won’t provide any Assurance for applications.

On a positive note, I liked the following

  • Feel and look is finally 21st century (it’s a Meraki influence). Topology diagrams have been taken from Meraki, I am telling you!
  • Command Runner is awesome and easy to use. Basically, you select multiple devices, then type mutiple CLI show commands and DNAC executes all those on all selected devices. Engineer then analyzes the output from multiple devices and multiple commands from a single place. Super handy. This feature only allows to execute show commands – no way to mess up with the config! 1st line won’t even need CLI access anymore.

As I said previously… if you’re going to run Greenfield deployment, it might work… if you’re trying to put this tool on top of existing network infrastructure be prepared for a long adoption period. We are still learning… looking for limitations and trying to get the most of it. But… honestly, no more a WOW effect. I’ll keep you posted with my findings.

4 thoughts on “Cisco DNAC Journey Part 1 – Expectations and Reality

  1. Brian S Turner

    It is so critical that Cisco get this right. Now is not the time for them to stumble. Sounds like there is a communication barrier with the guys writing the back end code. How can you assume all customers will be using Loopback0 for management? I doubt even “Most” customers use loopback 0.

    Do you know what Wireless Controllers they do support?

    1. Tim Dmitrenko Post author

      Thanks for your feedback. I believe the biggest issue of modern world is too damn fast pace. In SDN era, companies compete who can release the code/new feature first. Cisco is no different, Q&A is not there anymore, at least how we understand it. As to your question, they support 5520, 3504, and new Catalyst WLCs, or SDA-Wireless on Catalyst 9Ks. Officially, they support starting from code However, even though we are on, Assurance doesn’t work and DNAC shows WLCs as unsupported devices. Very strange. I am going to deploy 3504 on tomorrow. Hopefully Assurance will be working with it, or I’ll give up.

  2. Thejarec

    Hello Tim, where did you see that vWLC is not compatible? , i saw a bug that mention that but i also see a bulletin of some versions of airOS that says that are compatible with vWLC and DNAC Assurance.


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.