Catalyst Center Network Profile / CLI Deviations Compliance

[SeptemberRain]

We use a bunch of Catalyst Center CLI Templates to configure our switches.  Past versions of Catalyst Center / DNAC didn't do a really good job at checking configurations against the CLI Templates so we haven't really looked at compliance until recently.  I've modified many of our CLI Templates to use the ! @start-ignore-compliance and ! @ENd-ignore-compliance to reduce / remove "false positivies" in the compliance summary for Network Profiles.  That compliance section is almost useful now.

The main problem I have now is that the compliance against CLI Templates seems to look at the differences between the running-config and the template as it stood when it was deployed to the switch.  In our case that means that almost all of our switches are non-compliant against most of the CLI Templates that were applied to those switches as there are commands in the templates that should have had the ! @start-ignore-compliance and ! @ENd-ignore-compliance around them.

As an example one of the commands in almost ALL of our CLI Templates is do write mem.  That will never appear in the running-configuration and will therefore would be flagged as non-compliant if a CLI Template was deployed to that switch before it was modified with the ! @start-ignore-compliance and ! @ENd-ignore-compliance tags around that command.

I have two questions:

1. is it possible to acknowledge all violations in the Compliance Summary for "Network Profiles" for all switches?  That way at least we'd get rid of the bulk of the noise in our compliance.

2. this is probably the hard one...  We'd like to always compare compliance against the LATEST version of our CLI Templates rather than the one that was originally deployed.  It makes sense that our standards will evolve over time and that we would like to ensure that all our switches are using the current standard.  For example if we update our CLI Templates to send out a new errdisable recovery command because we identify that it should be enabled it would be nice to check in DNAC and see which switches don't have that command.  Is there a way to do that?

thanks for any help

[pieterh]

>>>  the compliance against CLI Templates seems to look at the differences between the running-config and the template as it stood when it was deployed to the switch.  <<<
-> yes that is correct
after correcting the template did you reapply/redeploy them to the device?

[SeptemberRain]

Hi PieterH.  Thanks for the reply.

I have deployed the newer CLI Templates to some of the switches.  Once I do that the switches show up as compliant.  In theory I could do that to ALL the switches, however with over 1000 switches and an average of 5 templates per switch it's a lot of work to re-deploy the updated templates to all of them (some of the templates require variables, so it wouldn't be as simple as just selecting a bunch of switches and deploying to them).  If that's what is required I can slowly churn through them, but I was wondering if there was an easier way.

The flip side is that we'd like to use the compliance reports to show if the switches are compliant to our current standards.  If the compliance is always looking at the version of the template that was last deployed to the switch and not the current template all compliance is really telling you is nothing has changed since last time that template was deployed.  Is there any clever way to get DNAC to tell you either what version of the template was last deployed to the switch OR to compare against the latest version of the template?

Thanks again

[SeptemberRain]

Just replying to one of my own questions here.  I can tell which template version is deployed to each switch if I go to the template in the Design > CLI Templates and find my template and then click on the number in provision status.  It'll give me a list of switches and the version deployed to each.  I might work through that list to find switches that need updating for the templates that had "real" changes (as opposed to the ones that were just modified to ignore commands that would show them up as non-compliant).

[pieterh]

hi there,
>>> If the compliance is always looking at the version of the template that was last deployed to the switch <<<
no that is not what is compared.
     Catalyst Center allows the network administrator to compare the CLI template with the running configuration of the device. 
NB! it is not queried in realtime the running config is the last archived running config
     The running configuration for CLI template compliance is taken from the latest archive that is available for the device. 

and you can choose a template to compare to:

1. Click the Network Profile tile.

2. From the CLI Deviations area, choose the CLI template for which you want to view the mismatch.

also check this note and the paragraph it refers to:

Note	There are some limitations in CLI template compliance. See Limitations in CLI template compliance.

[SeptemberRain · Accepted solution]

Hi Pieterh,

Thanks for your reply, but that's not the behavior I am seeing.  Maybe I am looking at behavior that has been fixed since our version of Catalyst Center - 2.3.7.9-70301.  It seems that the compliance looks at the most recent version of the running configuration held in Catalyst Center and makes sure that all the command lines in the template version that you last deployed to the switch are in that configuration (there are some limitations / exceptions like those in the document you linked).

If I give an example - we have a template that sets up all of our AAA and SNMP configuration.  If I look at that template under Design > CLI Templates and click on the number in Provision Status I can see a number of switches with a "Template Provision Status" of Out of Sync.  If I choose one of them (one with a very old template version showing) and look up its Compliance Status for Network Profiles I can see an Open Violation against that template.  Looking at the differences on the right hand side of that window I can see one of them is this:

So it looks like Catalyst Center believes there is a violation because of a line in that template with the command do write mem that does not appear in the most recently saved running configuration.  The thing is that we changed the template a few versions back so that the code that deploys the comment and do write mem looks like this:
! @start-ignore-compliance
do write mem
! @ENd-ignore-compliance

That implies that Catalyst Center is NOT comparing the current template with the most recent running configuration in Catalyst Center.  It looks like it is comparing the version of the template that was last deployed to that switch.  If I deploy the latest version that violation disappears.

So, I guess operationally what we should be doing to find devices that do not comply with our current standards is click on the number for the provision status of each template then look at the version deployed to each switch.  If the latest has not been deployed we should re-deploy it to that switch, if the latest version has been deployed and it shows as "Out of Sync" we should redeploy it too.  For the moment though a lot of those re-deployments will just clean up the cosmetic compliance violations (the ones that are fixed by flagging them with ! @start-ignore-compliance and ! @ENd-ignore-compliance ).

I think I might just work through them all since these cosmetic differences are just a one-off and note down that we need to check compliance by looking at template versions rather than looking at the number of compliance violations at the switch end.

[pieterh]

too bad my info did not help you very much
thanks for reporting your findings

regards, Pieter

[SeptemberRain]

Thanks for your replies Pieterh.