Information About Troubleshooting CFS

Many features in Cisco NX-OS require configuration synchronization across multiple devices in the network. CFS provides a common infrastructure for automatic configuration synchronization for an application in the network. It provides the transport function as well as a rich set of common services to the applications. CFS can discover CFS-capable devices in the network as well as their application capabilities.

Some of the applications that can be synchronized using CFS are as follows:

Call Home

RADIUS

TACACS+

User roles

Note:

Do not enable CFS for an application that you manage using Cisco DCNM.

You can use CFS regions to limit the CFS configuration distribution to a subset of devices on the network.

Initial Troubleshooting Checklist

Begin troubleshooting CFS issues by checking the following issues first:

Checklist

Check off

Verify that CFS is enabled for the same applications on all affected devices.

Verify that CFS distribution is enabled for the same applications on all affected devices.

If you are using CFS regions, verify that the application is in the same region on all the affected devices.

Verify that there are no pending changes for an application and that a CFS commit was issued for any configuration changes in a CFS-enabled application.

Verify that there are no unexpected CFS locked sessions. Clear any unexpected locked sessions.

Verifying CFS Using the CLI

To verify CFS using the CLI, follow these steps:

1. Verify that CFS is globally enabled on all devices in the network or CFS region.

The Physical-fc-ip scope means that CFS uses IP to apply the configuration for that application to all devices in the network or region. The Physical-eth scope means that CFS uses Ethernet to apply the configuration for that application to all devices in the network or region.

3. Verify that CFS distribution is enabled for the application on all devices in the network or CFS region.

If the list of switch WWNs in the show cfs merge status name command output is shorter than the list of switch WWNs in theshow cfs peers name command output, the network is partitioned into multiple CFS fabrics and the merge status may show that the merge has failed, is pending, or is waiting.

7. Verify that a distribution is not in progress in the network for the application.

Troubleshooting Merge Failures

During a merge, the merge managers in the merging networks exchange their configuration databases with each other. The application on the merge master device merges the information, decides if the merge is successful, and informs all devices in the combined network of the status of the merge. When a merge is successful, the merge master distributes the database to all devices in the combined network and the combined network remains in a consistent state. A merge failure indicates that the merged network contains inconsistent data that could not be merged.

If you add a new device to the network and the merge status for any application shows "In Progress" for a prolonged period of time, then there may be an active session for that application in some other device. Use the show cfs lock command to check the lock status for that application on all the devices. The merge will not proceed if there are any locks present for that application on any device in the network or CFS region. Use the application-namecommit command to commit the changes or use the clear application-name session command to clear the session lock so that the merge can proceed.

2. Commit the application configuration to restore all peers in the fabric to the same configuration database.

switch(config)# callhome commit

Troubleshooting Lock Failures

In order to distribute a configuration in the network, CFS must first acquire a lock on all devices in the network or CFS region. Once CFS acquires the locks, CFS issues a commit to distribute the configuration to all devices in the network or CFS region. Under normal circumstances, CFS releases the lock after the commit.

When another application peer acquires a lock, you cannot commit new configuration changes. This is a normal operation and you should postpone any changes to an application until the application peer releases the lock.

An inconsistent lock state also occur in the following scenarios:

When locks are not held on all of the devices in the network or CFS region.

When locks are held on all devices in the network or region, but a CFS session does not exist on the device that holds the lock.

Note:

Use the troubleshooting steps in this section only if you believe the lock has not been properly released.

To troubleshoot a lock failure, follow these steps:

1. Determine all the devices that participate in the CFS distribution for this application.

You must reassign an application to a region whenever you disable that application. CFS assigns new applications in the default region.

Changing CFS Regions

If you move an application from one region to another, you may encounter a database mismatch when attempting a merge. Follow the steps outlined in the Troubleshooting Merge Failures to identify and resolve the conflicts.

Note:

When an application is moved from one region to another (including the default region), the application loses all CFS history.