When you encounter a fabric lock, because you accidentally left the GUI or CLI without committing the changes, you can try the following to clear the lock and retry to apply your changes:
- run ‘show cfs lock’ to see who lock`s the fabric
- run ‘clear device-alias session’ to clear the lock when you were doing zoning activities
To see what changes were being made in that mysterious locked session, you can type:
show device-alias pending-diff
The purpose of this command is to display the differences between the pending device alias configuration and the currently active device alias configuration.
show device-alias pending
The purpose of this command is to display the entire content of the pending device alias database.
Explanation: Unlike pending-diff which shows only the changes, show device-alias pending will list all device aliases that are currently in the “pending” state, whether they are new, modified, or simply part of the configuration that is about to be committed. This gives you a complete view of what the device alias database will look like once the commit operation is successful.
show device-alias session status
The purpose of this command is to provide information about the current or last device alias session, including its status and any errors.
Explanation: When you begin modifying device aliases, a session is implicitly started. This command shows:
Instead of the “clear device-alias session” in line 2, another common possibility to get the lock cleared is:
- ‘clear ivr session’ (when you were in the middle of IVR activities)
Other locks can occur, but the device-alias and ivr are probably the most common. At least the ones that I encountered so far.
Sometimes a lock error pops up when opening a VSAN in DCNM, saying that the fabric is locked from switch ABC. In that case, log on to switch ABC and type (if nobody is actually zoning at that moment):
- clear zone lock vsan 123
This will clear the lock from the entire fabric only if issued on initiating switch
0 Comments.