Configuration Compliance

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 diffs 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 diff, and indicates that the device is Out-of-Sync. The pending diffs 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 run that occurs every 60 minutes by default, or when you click the RESYNC option either on a per fabric or per switch basis. The periodic CC runs every 24 hours. You can configure the custom interval with the range of 30-3600 minutes. This configuration can be done by navigating to Admin > System Settings > Fabric management > Advanced settings > LAN-Fabric. Note that you can also capture the out-of-band changes for the entire switch by using the CC REST API. 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 diff. 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 diffs. These diffs are also not displayed in the Pending config page. The side-by-side diff utility compares the diff in the two text files and does not leverage the internal logic used in the diff computation. As a result, the diff in default configurations are highlighted in red in the Side-by-side Comparison page.

In Nexus Dashboard, the diffs 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 diff 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 diffs 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 diffs 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 diffs 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 diffs 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.

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 diff 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 diff 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 diffs are not generated for these commands. This file is maintained in the Manage > Template Library, compliance_strict_cc_exclude_clis.txt template.