In this article, we take a look at the logic of CLI Template Compliance in Cisco DNA Center and go through some tips on what to consider when you are making CLI Templates of your own that need to be “compliant friendly”.
Introduction
Cisco DNA Center offers several controls to make sure your network devices are running approved software and are configured correctly according to your company’s policies, this is called Compliance.
One of the tougher parts of compliance is CLI Compliance, which ensures that the running configuration on your network devices matches the content of the Templates that have been pushed out to your network devices during the provisioning phase.
All the information below is based on the following software:
Cisco DNA Center version 2.3.5
Do note that previous versions of DNA Center (pre 2.3.5) had some differences in terms of logic/process CLI Compliance. I’ve highlighted some of these differences throughout the article but look into the official documentation from Cisco for complete details.
What is CLI Compliance?
The CLI Compliance runs on something called the comparator engine in DNA Center. The comparator engine compares the network device’s configuration line-by-line between the intended configuration (found in Network Settings and Day-N Templates in DNA Center) to the startup and running configuration found on the network device and displays the differences. To achieve compliance on network devices, there shouldn’t be any differences in the Network Settings and Day-N Templates pushed by DNA Center to the network device and the startup and running configurations.
All it takes is one little error or mistake in the configuration running on the network devices and DNA Center will throw a fit and say that the network device is Non-Compliant.
When does CLI Compliance apply?
Since configuration can be pushed from DNA Center to network devices at different stages of its lifecycle, it’s important to know which configuration will be compared line-by-line.
Configuration found in Onboarding (Day 0) Templates are not checked.
Configuration found in Network Settings are checked (in 2.3.5 and onwards)
Configuration found in Day-N Templates are checked.
Checking Compliance Status of Network Device
To manually run the Compliance Check on a network device, navigate to Provision > Inventory > check the box for your network devices > click on Actions > Compliance > Run Compliance Check.
Do note, it can take up to 5 minutes before Compliance status is correctly updated in DNAC, even after the Compliance Check says it has finished, so try to be patient.
Key Takeaways - What To Look Out For
There are a lot of small things that need to be considered when you are putting together your Day-N Templates. The comparator engine isn’t particularly “smart” in many cases and you might have to adjust your previous templates accordingly when pasting them into Day-N Templates in DNA Center to start your automation journey.
Let’s go through some of the odd cases I’ve encountered that have made my network devices fail the Compliance Check.
Spaces Matter (in some places…)
As of DNA Center version 2.3.5, you are no longer forced to include indentation spaces in front of commands that are sub-commands to other commands.
For example, before version 2.3.5, the following configuration would fail the Compliance Check because there are no indentation spaces before each of the “permit…” lines of the access list.
However, there are also some cases where commands must be put together without a space between certain parts of the command, even if it isn’t necessary when manually typing in the same command. This still applies for version 2.3.5 and onwards.
For example, one such case is when defining a VLAN to be used as the source interface for certain management traffic. While there are a few different ways to type in the commands below, how it looks in the running configuration determines how it should look in your Day-N Templates. In this case, there should not be a space between the word “Vlan” and the VLAN ID number. This also applies when you are using variables to get the VLAN ID to be used for these commands.
All of the commands on the left side would’ve flagged this as a non-compliant error by the comparator engine. To be compliant, there can not be any space between “Vlan” and the “16”.
Uppercase and Lowercase Matters
Simply put, uppercase and lowercase letters matter to the comparator engine. If you look at the running configuration of a switch and you see which letters or words are capitalized in specific commands, that is exactly how the commands should look in your Day-N templates.
Continuing with the previous example, if you would’ve written that command and similar ones (like on the image below) using an all uppercase “VLAN”, these would’ve been flagged as non-compliant because in the running configuration, only the “V” is uppercase while the rest is lowercase. A bit nitpicky if you ask me, but it is what it is.
Enter Passwords and Secrets in Encrypted form
Password and Secrets are used in many places in the configuration of a network device and most of the time, hopefully, these cannot be easily read by humans due to something like “service password-encryption” being configured, which would encrypt these passwords/secrets using Type 7-encryption (which is more of a "masking” of passwords/secrets, really).
If you have “service password-encryption” enabled and you still have cleartext passwords/secrets further down in this or other templates, the password/secret would be marked as non-compliant.
To get around this, make sure to enter your passwords/secrets in an already encrypted form, because then they would look identical in the running configuration, which would then be considered compliant by the comparator engine.
Some instances where passwords/secrets are used are:
Local Username’s passwords/secrets
Enable password/secret
RADIUS servers shared secrets
TACACS servers shared secrets
Declare Encrypted Passwords Containing “$” as “Not Variables”
If you are using “secret” passwords for local users and your Enable password, chances are high that they contain the dollar sign (“$“) symbol. This is tricky for DNA Center since the $-symbol is used to denote that something is a variable in the Velocity language, like ${SW-MGMT-VLAN}.
In this case, we want DNA Center to view the encrypted password as a simple encrypted string and not a variable. To do this, we have to mark this $-symbol as “Not a variable” in the Day-N Templates.
In your Day-N Templates, locate the passwords/secrets containing the “$”-symbol (sometimes multiple of them) and use the Variables menu to deny DNA Center from treating them as variables and instead treat them as regular text by unchecking the Variable box.
Do NOT shorten Commands in Day-N Templates
Only use full/complete commands in your Day-N Templates or they will be flagged as non-compliant. Shortening commands like you probably would’ve done when entering them in a switch manually will not pass the compliance check.
Do NOT use “interface range…” Commands
Avoid using “range” commands for things like interfaces, because the comparator engine does not support the logic of these commands since it only works by checking commands line-by-line. Since an interface range command cannot exist in a running configuration, it would always be marked as missing and therefore non-compliant.
Keep interface descriptions out of Day-N Templates
Depending on your network, it could be wise to not include specific interface descriptions in your Day-N Templates since you might want to change them later to better reflect what kind of device is connected to the interface, or typing in which data outlet is connected to the interface.
For example, if you are deploying new switches on a site, you might not know right away what will be connected to each of the network ports. If your Day-N Template includes descriptions for interfaces, this configuration would be flagged as non-compliant if you updated the interface description to something else later. In general, I’d say this applies mostly to interfaces in access mode, not trunks. While you technically can put interface descriptions into your Day-N Templates and have different Day-N Templates for every one of your switches, your sure are gonna have a lot of specific Templates to maintain, which kind of defeats the purpose of automation and standardization.
If you leave interface descriptions for access ports completely out of Day-N templates, you can enter them manually at a later time without the comparator engine reacting to them. Another upside of not putting interface descriptions in your Day-N Template is that if you have to push out the Day-N Template to your network devices after updating it later on, your custom interface descriptions (which you put in manually) won’t be overwritten.
Do NOT use Switch Configuration Macro Commands
Don’t use special case macro commands that result in many other commands being configured. Examples of this are “errdisable recovery cause all” and “switchport host” which will generate commands of their own in the global configuration and interface configuration, respectively.
To please the comparator engine, always make sure to put every command in your Day-N Templates.
Do NOT use Template Configuration Macros or Loops
Don’t put Velocity Macros or Loops in your templates, as DNA Center will not be able to decipher the result and treat it as compliant. For example, you may consider using these types of macros or loops to configure access ports or trunk ports simply with a few lines of code, but DNA Center will not be able to work with that in terms of the CLI compliance check.
An example of a Velocity Macro to configure access ports with some lines of configuration can be seen below. First, the macro is defined with a name and all commands belonging to it and then applied under the interface range further down. This example uses the “range” command to address multiple interfaces, which also is a no-no, but you could also do this using a loop with Velocity. Regardless, this would cause the Compliance Check to fail.
Avoid using custom IP Device Tracking Policies
If your DNA Center is configured to provide Device Controllability and Telemetry, it will automatically configure an IP Device Tracking Policy on most non-infrastructure interfaces to gather information about connected endpoints. The name of this policy is “IPDT_POLICY”.
This configuration is considered part of the Network Settings, so if the specific IP Device Tracking Policy created by DNA Center (“IPDT_POLICY”) is not in the configuration for related interfaces, it will cause a compliance error.
Because of this, you should not use a custom IP Device Tracking Policy and apply it to typical endpoint-facing ports in your Day-N Templates, because it would then override the original IP Device Tracking Policy already configured by DNA Center. For a 24 port switch, this would cause 24 compliance violations, as seen below.
If your Day-N Templates contain a custom IP Device Tracking Policy that is applied to the same interface as the default policy, you would end up in a loop of compliance errors because DNA Center would say it’s missing its default IP Device Tracking Policy, which can be re-applied by running the “Fix All Configuration Compliance Issues” task in DNA Center on the switch, which would then re-apply the default IP Device Tracking Policy, which in turn would make the Compliance Check fail for the Day-N Template that applied the custom IP Device Tracking Policy, created by you.
As this specific Compliance Check was introduced in DNA Center version 2.3.5 from what I can tell (which was just released as of this writing), I have yet to find a workaround for the cases where you might want to use a custom IP Device Tracking Policy for endpoint-facing ports instead of the default policy configured by DNA Center.
Update October 2023
It seems you can now exclude Sites inside of DNA Center from being configured with DNA Center’s IP Device Tracking configuration, and instead lets Network Devices belonging to the Site to use the configuration found in Templates/manually configured instead.
Navigate to the Network Settings for a Site and in the Telemetry settings, looks for this setting:
Tell the Comparator Engine to ignore certain configuration
There are some cases where you simply will have to tell DNA Center to ignore certain parts of the configuration and exclude them from being run through the comparator engine.
An example of when this feature is needed is if you have a Day-N Template that contains a command that is configured by default in the network device. In these cases, the command might be invisible in the traditional “show running-configuration” and may only be seen in the “show running-configuration all” command, which includes all default commands activated.
If a default command is invisible in the running configuration, the comparator engine will mark the command as non-compliant, since the command is “missing”. While you could decide to not have these default commands in your Day-N Templates at all since they are defaults after all, you never know if these commands are changed down the road as new software versions come out and some commands might no longer be activated by default, which could cause issues and be a tough problem to troubleshoot.
Also, some “no…” commands might not show up in the running configuration either, so these will have to be marked accordingly as well to be ignored for the compliance check.
To ignore commands for the Compliance Check, enclose them within the statements below.
! @start-ignore-compliance ! @end-ignore-complianceFor an example of default commands that are invisible in the running configuration and needs to be excluded from the Compliance Check, see below.
Another example is if you are pushing out Access Control Lists (ACLs) using Day-N Templates. ACLs can be tricky to update and re-provision out to network devices because they are simply applied line-by-line, meaning if you remove an entry in the ACL and re-provision the Template, DNA Center wouldn’t know to actually remove that line, it would just push out what is left, meaning the line you want gone won’t be affected on the network device.
To fix this, you could add a “no ip access-list…” statement for each ACL to completely clear it out on re-provisioning before all correct lines are entered again. The “no ip access-list…” command in this case would then need to be excluded from the Compliance Check.
References
Cisco DNA Center User Guide, Release 2.3.4 - Compliance Overview
Cisco DNA Center User Guide, Release 2.3.5 - Compliance Overview (Network Settings added to Compliance)
Cisco DNA Center User Guide, Release 2.3.6 - Compliance Overview