Configuration Compliance, Release 4.2.1

The following table provides an overview of the significant changes up to this current release. The table does not provide an exhaustive list of all changes or of the new features up to this release.

The entire intent or expected configuration defined for a given switch is stored in Nexus Dashboard. When you want to push this configuration down to one or more switches, the configuration compliance (CC) module is triggered. Configuration compliance takes the current intent, the current running configuration, and then comes up with the set of configurations that are required to go from the current running configuration to the current expected configuration so that everything will be In-Sync.

When performing a software or firmware upgrade on the switches, the current running configuration on the switches is not changed. Post upgrade, if CC finds that the current running configuration does not have the current expected configuration or intent, it reports an Out-of-Sync status. There is no auto deployment of any configurations. You can preview the differences that will get deployed to get one or more devices back In-Sync.

With CC, the sync is always from the Nexus Dashboard to the switches. There is no reverse sync. So, if you make a change out-of-band on the switches that conflicts with the defined intent in Nexus Dashboard, CC captures this difference, and indicates that the device is Out-of-Sync. The pending differences will undo the configurations done out-of-band to bring back the device In-Sync.

Note that such conflicts due to out-of-band changes are captured by the periodic CC or when you click the Resync button either on a per fabric or per switch basis. The periodic CC runs every 24 hours.

You can configure the custom interval within a range of 30-3600 minutes. To configure custom interval, navigate to Admin > System Settings > General. Under Advanced Settings enable the Display advanced settings and options for TAC support option. Once the advanced settings are enabled, go to Admin > System Settings > Fabric management > Advanced settings > LAN-Fabric to adjust the configuration compliance time interval.

Note that you can also use the CC REST API to capture out-of-band changes for the switch. For more information, see Cisco Nexus Dashboard REST API Guide.

To improve ease of use and readability of deployed configurations, CC in Nexus Dashboard has been enhanced with the following:

Top-level configuration commands on the switch that do not have any associated Nexus Dashboard intent are not checked for compliance by CC. However, CC performs compliance checks, and attempts removal, of the following commands even if there is no Nexus Dashboard intent:

CC performs compliance checks, and attempts removal, of these commands only when Data Center VXLAN EVPN and Routed (BGP) templates are used. On External and inter-fabric connectivity and Classic LAN templates, top-level configuration commands on the switch, including the commands mentioned above, that do not have any associated Nexus Dashboard intent are not checked for compliance by CC.

We recommend using the Nexus Dashboard freeform configuration template to create additional intent and deploy these commands to the switches to avoid unexpected behavior

Now, consider a scenario in which the configuration that exists on the switch has no relationship with the configuration defined in the intent. Examples of such configurations are a new feature that has not been captured in the intent but is present on the switch or some other configuration aspect that has not been captured in the intent. Configuration compliance does not consider these configuration mismatches as a difference. In such cases, strict configuration compliance ensures that every configuration line that is defined in the intent is the only configuration that exists on the switch. However, configurations such as boot string, ROM monitor configuration, and other default configurations are ignored during strict configuration compliance checks. For such cases, the internal configuration compliance engine ensures that these configuration changes are not called out as differences. These differences are also not displayed in the Pending config page. The side-by-side difference utility compares the difference in the two text files and does not leverage the internal logic used in the difference computation. As a result, the difference in default configurations are highlighted in red in the Side-by-side Comparison page.

In Nexus Dashboard, the differences in the default configurations are not highlighted in the Side-by-side Comparison page. The auto-generated default configuration that is highlighted in the Running config page is not visible in the Expected config page.

Any configurations that are shown in the Pending Config page are highlighted in red in the Side-by-side Comparison page if the configurations are seen in the Running config page but not in the Expected config page. Also, any configurations that are shown in the Pending config page are highlighted in green in the Side-by-side Comparison page if the configurations are seen in the Expected config page but not in the Running config page. If there are no configurations displayed in the Pending config page, no configurations are shown in red in the Side-by-side Comparison page.

All freeform configurations have to strictly match the show running configuration output on the switch and any deviations from the configuration will show up as a difference during Recalculate & Deploy. You need to adhere to the leading space indentations.

You can typically enter configuration snippets in Nexus Dashboard using the following methods:

The configuration format should be identical to the show running configuration of the corresponding switch. Otherwise, any missing or incorrect leading spaces in the configuration can cause unexpected deployment errors and unpredictable pending configurations. If any unexpected difference or deployment errors are displayed, check the user-provided or custom configuration snippets for incorrect values.

If Nexus Dashboard displays the "Out-of-Sync" status due to unexpected pending configurations, and this configuration is either unable to be deployed or stays consistent even after a deployment, perform the following steps to recover:

If Nexus Dashboard displays "NA" in the Config Status, the following guidelines apply:

To confirm that the differences have been resolved, click Recalculate & Deploy after updating the policy to validate the changes.

Nexus Dashboard checks only leading spaces, as it implies hierarchy of the command, especially in case of multi-command sequences. Nexus Dashboard does not check any trailing spaces in command sequences.

With external fabrics, any Nexus switches, Cisco IOS-XE devices, Cisco IOS XR devices, and Arista can be imported into the fabric, and there is no restriction on the type of deployment. It can be LAN Classic, VXLAN, FabricPath, vPC, HSRP, etc. When switches are imported into an external fabric, the configuration on the switches is retained so that it is non-disruptive. Only basic policies such as the switch username and mgmt0 interface are created after a switch import.

In the external fabric, for any intent that is defined in the Nexus Dashboard, configuration compliance (CC) ensures that this intent is present on the corresponding switch. If this intent is not present on the switch, CC reports an Out-of-Sync status. Additionally, there will be a Pending Config generated to push this intent to the switch to change the status to In-Sync. Any additional configuration that is on the switch but not in intent defined in Nexus Dashboard, will be ignored by CC, as long as there is no conflict with anything in the intent.

When there is user-defined intent added on Nexus Dashboard and the switch has additional configuration under the same top-level command, as mentioned earlier, CC will only ensure that the intent defined in Nexus Dashboard is present on the switch. When this user defined intent on Nexus Dashboard is deleted as a whole with the intention of removing it from the switch and the corresponding configuration exists on the switch, CC will report an Out-of-Sync status for the switch and will generate Pending Config to remove the config from the switch. This Pending Config includes the removal of the top-level command. This action leads to removal of the other out-of-band configurations made on the switch under this top-level command as well. If you choose to override this behavior, the recommendation is that, you create a freeform policy and add the relevant top-level command to the freeform policy.

Let us see this behavior with an example.

The following configuration CLIs are ignored during configuration compliance checks:

Any CLIs that match the above will not show up in pending differences and clicking Save & Deploy in the Fabric Builder window will not push such configurations to the switch. These CLIs will not show up in the Side-by-side Comparison window also.

To deploy such configuration CLIs, perform the following procedure:

By default, all differences generated in Nexus Dashboard while comparing intent, also known as the expected configuration, and the running configuration, are case-sensitive. However, a switch has many commands that are case-insensitive, and therefore it may not be appropriate to flag these commands as differences. These are captured in the compliance_case_insensitive_clis.txt template that can be found under Manage > Template Library.

If you apply access control lists (ACLs) out-of-band and exclude them from reconciliation, case-sensitivity can cause failures. Ensure that ACL names use the same case in the intent and the switch configuration, or adjust the case-insensitive Command template.

Enhanced Classic LAN (ECL) fabrics do not support the compliance_case_insensitive_clis.txt template and its defined regex patterns. To perform case-insensitive configuration compliance checks for these fabrics, enable the dedicated setting by following these steps.

The compliance_case_insensitive_clis.txt file, along with the compliance_strict_cc_exclude_clis.txt and compliance_ipv6_clis.txt files, are part of the shipped templates. You can find all the templates in Manage > Template Library. Modification of templates can be done after disabling Template In-Use Override.

There could be additional commands that are not included in the existing compliance_case_insensitive_clis.txt file that should be treated as case insensitive. If the pending configuration is due to the differences of cases between the expected configuration in Nexus Dashboard and the running configuration, you can configure Nexus Dashboard to ignore these case differences as follows:

After importing switches in Nexus Dashboard, configuration compliance for a switch can fail because of an extra space in the management interface (mgmt0) description field.

For example, before importing the switch:

interface mgmt0
  description SRC=SDS-LB-LF111-mgmt0, DST=SDS-LB-SW001-Fa0/5

After importing the switch and creating a configuration profile:

interface mgmt0
  description SRC=SDS-LB-LF111-mgmt0,DST=SDS-LB-SW001-Fa0/5

Navigate to the Interface Manager and click the Edit icon after selecting the mgmt0 interface. Remove the extra space in the description.

Strict configuration compliance checks for difference between the switch configuration and the associated intent and generates no commands for the configurations that present on the switch but are not present in the associated intent. When you click Recalculate and deploy, switch configurations that are not present on the associated intent are removed. You can enable this feature by choosing the Enable Strict Config Compliance check box under the Advanced tab in the Create Fabric or Edit Fabric window. By default, this feature is disabled.

The strict configuration compliance feature is supported on the Data Center VXLAN EVPN and Routed (BGP) templates. To avoid generating difference for commands that are auto-generated by the switch, such as vdc, rmon, and so on, a file that has a list of default commands is used by CC to ensure that differences are not generated for these commands. This file is maintained in the Manage > Template Library, compliance_strict_cc_exclude_clis.txt template.

Nexus Dashboard detects and reconciles operational changes that users make directly on managed Nexus switches outside the Nexus Dashboard intent model. This capability ensures operational flexibility while maintaining configuration accuracy and compliance.

Nexus Dashboard supports automatic reconciliation for configuration compliance only on Nexus switches.

Reconciliation includes these main capabilities:

The reconciliation workflow follows these main steps:

Example: Reconciliation of local operational switch changes

Let us consider an example where you configure a new interface description directly on a Nexus switch CLI for troubleshooting. Later, Nexus Dashboard compliance check identifies this local operational change.

---

Using reconciliation, you can also setup global configuration, ACLs, and route maps.

---

• Nexus Dashboard runs a scheduled or on-demand compliance check and detects that the running configuration on Switch A differs from the Nexus Dashboard intent.

• Open the compliance report to see the difference highlights the new interface description added directly on the switch.

• Choose Reconcile to add the new interface description into the Nexus Dashboard intent.

• Audit and confirm the action is logged in system policy history, and Switch A returns to a compliant status.

• The operational change is reconciled with Nexus Dashboard, ensuring that Nexus Dashboard continues to represent the single source of truth while accommodating necessary local actions.

---

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS" WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: https://www.cisco.com/go/trademarks. Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1110R)

© 2017-2026 Cisco Systems, Inc. All rights reserved.

Americas Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
https://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 527-0883