Device Alias Databases
The device alias feature uses two databases to accept and implement device alias configurations.
- Effective database—The database currently used by the fabric.
- Pending database—Your subsequent device alias configuration changes are stored in the pending database.
If you modify the device alias configuration, you need to commit or discard the changes as the fabric remains locked during this period.
This section includes the following sections:
Creating Device Aliases
To a create a device alias in the pending database, follow these steps:
|
|
|
Step 1 |
switch# config t switch(config)# |
Enters configuration mode. |
Step 2 |
switch(config)# device-alias database switch(config-device-alias-db)# |
Enters the pending database configuration submode. |
Step 3 |
switch(config-device-alias-db)# device-alias name Device1 pwwn 21:01:00:e0:8b:2e:80:93 |
Specifies a device name (Device1) for the device that is identified by its pWWN. Starts writing to the pending database and simultaneously locks the fabric as this is the first-issued device alias configuration command. |
switch(config-device-alias-db)# no device-alias name Device1 |
Removes the device name (Device1) for the device that is identified by its pWWN. |
switch(config-device-alias-db)# device-alias rename Device1 Device2 |
Renames an existing device alias (Device1) with a new name (Device2). |
To display the device alias configuration, use the show device-alias name command.
switch# show device-alias name x
device-alias name x pwwn 21:01:00:e0:8b:2e:80:93
About Device Alias Distribution
By default, device alias distribution is enabled. The device alias feature uses the coordinated distribution mechanism to distribute the modifications to all switches in a fabric.
If you have not committed the changes and you disable distribution, then a commit task will fail.
Example 5-1 Displays a Failed Status
switch# show device-alias status
Fabric Distribution: Disabled
Database:- Device Aliases 25
Status of the last CFS operation issued from this switch:
==========================================================
Status: Failed (Reason: Operation is not permitted as the fabric distribution is
Note From the Cisco MDS NX-OS Release 6.2.9 onwards, the ASCII configuration replay takes longer time for DDAS (Distributing Device Alias Services) without the write erase command.
About Creating a Device Alias
When you perform the first device alias task (regardless of which device alias task), the fabric is automatically locked for the device alias feature. Once you lock the fabric, the following situations apply:
- No other user can make any configuration changes to this feature.
- A copy of the effective database is obtained and used as the pending database. Modifications from this point on are made to the pending database. The pending database remains in effect until you commit the modifications to the pending database or discard (abort) the changes to the pending database.
About Device Alias Configuration Best Practices
As a part of the device-alias configuration best practices, the following guidelines need to be adopted within a device-alias session:
If a device-alias name is reused while configuring a rename command, then the command fails and gets moved to the rejected list.
Example 5-2 Displays the rejected device-alias command
switch(config-device-alias-db)# device-alias name dev10 pwwn 10:10:10:10:10:10:10:10
switch(config-device-alias-db)# device-alias rename dev10 new-dev10
Command rejected. Device-alias reused in current session :dev10
Please use 'show device-alias session rejected' to display the rejected set of commands and for the device-alias best-practices recommendation.
switch(config-device-alias-db)#
If a PWWN is reused while configuring an add or delete command, then the command fails and gets moved to the rejected list.
Example 5-3 Displays the rejected device-alias command
switch(config-device-alias-db)# device-alias name dev11 pwwn 11:11:11:11:11:11:11:11
switch(config-device-alias-db)# no device-alias name dev11
Command rejected. Pwwn reused in current session: 11:11:11:11:11:11:11:11 is mapped to device-alias dev11
Please use 'show device-alias session rejected' to display the rejected set of commands and for the device-alias best-practices recommendation.
switch(config-device-alias-db)#
If a device-alias name is reused in an add command which was earlier being renamed in a rename command, the command fails and gets moved to the rejected list.
switch(config-device-alias-db)# device-alias rename da3 new-da3
switch(config-device-alias-db)# device-alias name da3 pwwn 2:2:2:2:3:3:3:3
Command rejected. Device-alias name reused in current session: da3
Please use 'show device-alias session rejected' to display the rejected set of commands and for the device-alias best-practices recommendation.
switch(config-device-alias-db)#
Example 5-4 Displays the rejected device-alias command
The rejected set of commands can be displayed using the show device-alias session rejected command.
switch(config-device-alias-db)# show device-alias session rejected
To avoid command rejections, within a device alias session
a) a device alias name while configuring a rename command
b) a PWWN while configuring an add or delete command
c) a device alias name already renamed while configuring add command
Rejected commands must be committed in a separate device alias session
which may cause traffic interruption for those devices. Plan accordingly.
Refer to this command in the NX-OS Command Reference Guide
for more information about device alias configuration best practices
device-alias rename dev10 new-dev10
no device-alias name dev11
device-alias name da3 pwwn 02:02:02:02:03:03:03:03
switch(config-device-alias-db)# #
Committing Changes
If you commit the changes made to the pending database, the following events occur:
1. The pending database contents overwrites the effective database contents.
2. The pending database is emptied of its contents.
3. The fabric lock is released for this feature.
To commit the changes, follow these steps:
|
|
|
Step 1 |
switch# config t switch(config)# |
Enters configuration mode. |
Step 2 |
switch(config)# device-alias commit |
Commits the changes made to the currently active session. |
Whenever a switch in the fabric attains a lock and goes for a blank commit, the following warning is thrown out:
WARNING: Device-alias DB is empty in this switch.
Initiating a commit from this switch will clear [wipe out] Device-alias DB across all the switches in the fabric, losing Device-alias full DB config permanently.
Do you want to continue? (y/n) [n]
Note Once the "device-alias commit" is done the running configuration has been modified on all switches participating in device-alias distribution. You can then use the "copy running-config startup-config fabric" command to save the running-config to the startup-config on all the switches in the fabric.
Enabling the Device Alias Pending Diff Display
To enable the display of the pending-diff and the subsequent confirmation on issuing a device-alias commit, follow these steps:
|
|
|
Step 1 |
switch# config t switch(config)# |
Enters configuration mode. |
Step 2 |
switch(config)# device-alias confirm-commit |
Enables the confirm commit option for device- alias. |
Step 3 |
switch(config)# device-alias commit The following device-alias changes are about to be committed + device-alias name Device1 pwwn 21:01:00:e0:8b:2e:80:93 Do you want to continue? (y/n) [n] y |
If the device-alias confirm-commit command is enabled, on committing the pending database, the pending-diff is displayed on the console and user is prompted for Yes or No. If the device -alias confirm-commit command is disabled, the pending-diff is not displayed and the user is not prompted for Yes or No. |
Discarding Changes
If you discard the changes made to the pending database, the following events occur:
1. The effective database contents remain unaffected.
2. The pending database is emptied of its contents.
3. The fabric lock is released for this feature.
To discard the device alias session, perform this task:
|
|
|
Step 1 |
switch# config t switch(config)# |
Enters configuration mode. |
Step 2 |
switch(config)# device-alias abort |
Discards the currently active session. |
To display the status of the discard operation, use the show device alias status command.
switch# show device-alias status
Fabric Distribution: Enabled
Database:- Device Aliases 24
Status of the last CFS operation issued from this switch:
==========================================================
Fabric Lock Override
If you have performed a device alias task and have forgotten to release the lock by either committing or discarding the changes, an administrator can release the lock from any switch in the fabric. If the administrator performs this task, your changes to the pending database are discarded and the fabric lock is released.
Tip The changes are only available in the volatile directory and are subject to being discarded if the switch is restarted.
To clear device-alias session, use the clear device-alias session command in CONFIGURATION mode.
switch(config)# clear device-alias session
To verify the status of the clear operation, use the show device-alias session status command.
switch(config)# show device-alias session status
Last Action Time Stamp : None
Last Action Result : None
Last Action Failure Reason : none
Clearing Database Content
To clear all the database content, use the clear device-alias database command in CONFIGURATION mode.
switch(config)# clear device-alias database
To verify the status of the clear device-alias database command, use the show device-alias database command.
switch(config)# show device-alias database
Clearing Statistics
To clear all the statistics, use the clear device-alias statistics command in CONFIGURATION mode.
switch# clear device-alias statistics
Disabling and Enabling Device Alias Distribution
To disable or enable the device alias distribution, follow these steps:
|
|
|
Step 1 |
switch# config t switch(config)# |
Enters configuration mode. |
Step 2 |
switch(config)# no device-alias distribute |
Disables the distribution. |
switch(config)# device-alias distribute |
Enables the distribution (default). |
To display the status of device alias distribution, use the show device-alias status command (see Example 5-5 and Example 5-6).
Example 5-5 Displays Device Alias Status When Distribution Is Enabled
switch# show device-alias status
Fabric Distribution: Enabled <-------------------------------Distribution is enabled
Database:-Device Aliases 24
Locked By:-User “Test” SWWN 20:00:00:0c:cf:f4:02:83<-Lock holder’s user name and switch ID
Pending Database:- Device Aliases 24
Status of the last CFS operation issued from this switch:
==========================================================
Operation: Enable Fabric Distribution
Example 5-6 Displays Device Alias Status When Distribution Is Disabled
switch# show device-alias status
Fabric Distribution: Disabled
Database:- Device Aliases 24
Status of the last CFS operation issued from this switch:
==========================================================
Operation: Disable Fabric Distribution
Resolving Device Alias Merge Failures
The most common device-alias merge failure issues occur when merging databases. When a device-alias merge fails, we recommend that you review the syslog messages on the switch in which the merge was initiated in order to identify the issues. The application server in each fabric that is responsible for the merge is indicated by the term Merge Master in the messages.
In this example, the syslog messages indicate that the merge failed as a result of a database mismatch:
2007 Apr 9 15:52:42 switch-1 %CFS-3-MERGE_FAILED: Merge failed for app device-alias, local switch wwn 20:00:00:0d:ec:2f:c1:40,ip 172.20.150.38, remote switch wwn 20:00:00:0d:ec:04:99:40, ip 172.20.150.30
2007 Apr 9 15:52:42 switch-1 %DEVICE-ALIAS-3-MERGE_FAILED: Databases could not be merged due to mismatch.
Note Use the device-alias distribute command to initiate a merge or remerge of device-alias databases. Use the device-alias commit command to push a switch's device-alias database to all the other switches in a fabric. If the switches whose device-alias databases are not merged (more than one merge master is shown in the output of the show cfs merge status name device-alias command), then the device-alias commit command causes the device-alias databases that are not merged to be overwritten.
Device Alias Best Practices
This section lists the best practices that you should follow when creating and using device aliases:
- Device aliases should be used to simplify the management of world wide names (WWNs) whenever possible. It is easier to identify devices with aliases rather than with WWNs. Hence, you should assign aliases to WWNs to easily identify the WWNs.
- Device-alias names are case-sensitive.
- Operate device aliases in Enhanced mode whenever possible. In Enhanced mode, applications accept a device-alias name in its native format, rather than expanding the alias to a port world wide name (pWWN). Because applications such as zone server, Inter-VSAN Routing (IVR), Port Security Manager (PSM), and Dynamic Port VSAN Membership automatically track and enforce device-alias membership changes, you have a single point of change.
Note Interop mode VSANs do not accept Enhanced mode configurations.
- Preplan device-alias configurations and implement a consistent naming convention.
- Keep documented backups of all device-alias configurations.
- Plan for what the final device-alias database should be after the merge, before attempting to resolve merge failures. This can prevent traffic disruptions caused by accidentally overwriting device-alias entries.
Caution Avoid performing a
blank commit to resolve Cisco Fabric Services (CFS) merge failures. A blank commit overwrites the device-alias databases on all the switches with the device-alias database on the local switch.
Note A blank commit is a device-alias commit that is used when there are no changes (including mode changes), or when it is okay to overwrite the device-alias databases on the remote switches with the local switch's device-alias database.
Device alias mismatches might occur because of the following reasons:
– Duplicate Device-Alias Names-Same device-alias name, but different pWWNs. In such a scenario, the show device-alias merge status command displays the reason for the merge failure as " Reason: Another device-alias already present with the same name.
"
– Duplicate pWWNs-Different device-alias names, but same pWWN. In such a scenario, the show device-alias merge status command displays the reason for the merge failure as " Reason: Another device-alias already present with the same pwwn.
"
Note Each time device-alias changes are committed, the running configuration should be copied to the startup configuration on all the switches that were updated. Use the copy running-config startup-config fabric command to copy the running configuration to the startup configuration for all the switches in the fabric. If you do not copy the running configuration to the startup configuration after the device-alias changes are committed, and if the switch reloads, or loses power and restarts, the startup configuration will not have the correct device-alias database and merge failure will occur.
Resolving Device Alias Mismatches
If a switch with an existing device-alias database is being added to an existing fabric, conflicts might arise because of the following reasons:
- The same device-alias name is used, but with different pWWNs.
- The same pWWN is used, but with different device-alias names.
To resolve duplicate device-alias names, perform these steps:
Step 1 Run the show cfs merge status name device-alias command to review the CFS or device-alias merge failure syslogs to confirm that the merge failed:
switch-1#
show cfs merge status name device-alias
Physical-fc Merge Status: Failed
[Sun Sep 25 14:45:55 2016]
Failure Reason: Another device-alias already present with the same pwwn
Local Fabric
--------------------------------------------------------------------------------
Switch WWN IP Address
--------------------------------------------------------------------------------
20:00:54:7f:ee:1b:0e:b0 10.127.103.211 [Merge Master] <<< Merge Master#1
[switch-1]
Total number of switches = 1
Remote Fabric
--------------------------------------------------------------------------------
Switch WWN IP Address
--------------------------------------------------------------------------------
20:00:54:7f:ee:1b:0e:50 10.197.111.54 [Merge Master] <<< Merge Master#2
Total number of switches = 1
Note A properly merged device-alias application should only show a single merge master. If there is more than one merge master, as shown in the above example, it indicates that the device-alias databases are not merged.
Step 2 Use the no device-alias distribute command on the switch in which the merge failure occurred in order to disable the device-alias distribution:
switch-1(config)#
no device-alias distribute
Step 3 Resolve merge failure on the switch. See “Resolving Merge Failures" section.
Resolving Merge Failures
This section provides information about how to resolve merge failures.
Resolving Duplicate Device Alias Names (Same Device Alias Name, Different pWWNs)
Note A device-alias name is considered to be duplicate when the same device-alias name is used to point to different pWWNs.
To verify if a duplicate device-alias name exists in fabrics, perform these steps:
Step 1 Run the show device-alias merge status command to identify if the reason for the merge failure is a database mismatch:
switch#
show device-alias merge status
Result: Failure
Reason: Another device-alias already present with the same name
Step 2 Review the CFS or the device-alias merge failure syslog to confirm that the merge failed. Alternatively, run the show cfs merge status name device-alias command to view the status of the merge.
switch#
show cfs merge status name device-alias
Physical-fc Merge Status: Failed [ Mon Apr 9 15:57:58 2007 ]
<===Merge status
Local Fabric
-------------------------------------------------------------------------
Switch WWN IP Address
-------------------------------------------------------------------------
20:00:00:0d:ec:2f:c1:40 172.20.150.38 [Merge Master]
<<< Merge Master#1
switch-1
Total number of switches = 1
Remote Fabric
-------------------------------------------------------------------------
Switch WWN IP Address
-------------------------------------------------------------------------
20:00:00:0d:ec:04:99:40 172.20.150.30 [Merge Master]
<<< Merge Master#2
switch-2
Total number of switches = 1
Step 3 Compare the device-alias databases manually to identify the duplicate device-alias names.
In the following example, the same device-alias name, A1, is assigned to two different pWWNs-a pWWN on a local switch and a pWWN on a peer switch.
From merge master#1:
switch-1#
show device-alias database
...output trimmed to show only mismatched device-alias
device-alias name A1 pwwn 21:01:01:01:01:01:01:02
switch-2#
show device-alias database
...output trimmed to show only mismatched device-alias
device-alias name A1 pwwn 21:01:01:01:01:01:01:03
Step 4 Run the device-alias name name pwwn id command to change the pWWN on one of the switches to match the pWWN on the other switch.
Note Perform this step after device-alias distribution is disabled by running the no device-alias distribute command.
In the following example, the pWWN 21:01:01:01:01:01:01:02 on switch-1 is changed to match the pWWN 21:01:01:01:01:01:01:03 on switch-2:
switch-1#
configure
Enter configuration commands, one per line. End with CNTL/Z.
switch-1(config)#
device-alias database
switch-1(config-device-alias-db)#
no device-alias name A1
switch-1(config-device-alias-db)#
show device-alias database | i A1
switch-1(config-device-alias-db)#
device-alias name A1 pwwn 21:01:01:01:01:01:01:03
switch-1(config-device-alias-db)#
show device-alias database | i A1
device-alias name A1 pwwn 21:01:01:01:01:01:01:03
Step 5 If there are more duplicate device-alias names, perform step 3 and step 4 to resolve the duplicate device-alias names issue.
Step 6 Use the device-alias distribute command to enable the device-alias distribution and initiate a merge:
switch-1(config)#
device-alias distribute
Step 7 Use the show cfs merge status name device-alias command to verify in the output if the merge was successful.
Resolving Duplicate pWWNs (Different Device Alias Names, Same pWWN)
To verify that the same pWWN is mapped to different device-alias names in fabrics, perform these steps:
Step 1 Run the show device-alias merge status command to identify the reason for the merge failure:
switch# show device-alias merge status
Result: Failure
Reason: Another device-alias already present with the same pwwn.
Step 2 Review the CFS or device-alias merge failure syslog to confirm that the merge failed. Alternatively, run the show cfs merge status name device-alias command to view the status of the merge.
switch# show cfs merge status name device-alias
Physical-fc Merge Status: Failed [ Mon Apr 9 15:57:58 2007 ] <===Merge status
Local Fabric
-------------------------------------------------------------------------
Switch WWN IP Address
-------------------------------------------------------------------------
20:00:00:0d:ec:2f:c1:40 172.20.150.38 [Merge Master] <<< Merge Master#1
switch-1
Total number of switches = 1
Remote Fabric
-------------------------------------------------------------------------
Switch WWN IP Address
-------------------------------------------------------------------------
20:00:00:0d:ec:04:99:40 172.20.150.30 [Merge Master] <<< Merge Master#2
switch-2
Total number of switches = 1
Step 3 Compare the device-alias databases manually to identify the duplicate pWWNs. On the switches where the merge failed in step 1, use the show device-alias database command to identify if a pWWN that is mapped to two different device-alias names exists.
In this example, the pWWN 21:01:01:01:01:01:01:02 is mapped to the device-alias A3 on switch-1 and to the device-alias A1 on switch-2:
switch-1#
show device-alias database
device-alias name A3 pwwn 21:01:01:01:01:01:01:02
Total number of entries = 1
switch-2#
show device-alias database
device-alias name A1 pwwn 21:01:01:01:01:01:01:02
Step 4 Use the device-alias name name pwwn id command to change the device-alias name on one of the switches to match the device-alias name on the other switch.
Note Perform this step after device-alias distribution is disabled by using the no device-alias distribute command.
In the following example, the device-alias name A3 on switch-1 is changed to match the device-alias name A1 on switch-2:
switch-1#
configure
Enter configuration commands, one per line. End with CNTL/Z.
switch-1(config)#
device-alias database
switch-1(config-device-alias-db)#
no device-alias name A3
switch-1(config-device-alias-db)#
device-alias name A1 pwwn 21:01:01:01:01:01:01:02
Step 5 If there are more duplicate device-alias names, perform step 3 and step 4 to resolve the device-alias names.
Step 6 Use the device-alias distribute command to enable the device-alias distribution and initiate a merge:
switch-1(config)#
device-alias distribute
Step 7 Use the show cfs merge status name device-alias command to verify in the output if the merge was successful.
Resolving Mode Mismatch
The Device Alias feature can operate in either Basic or Enhanced mode. If the modes are different in two fabrics, CFS merge between the fabrics fails.
To verify that the device-alias mode is different in two fabrics, perform these steps:
Step 1 Review the CFS or device-alias merge failure syslog to confirm that the merge failed. Alternatively, run the show cfs merge status name device-alias command to view the status of the merge.
switch#
show cfs merge status name device-alias
Physical-fc Merge Status: Failed [ Mon Apr 9 15:57:58 2007 ]
<===Merge status
Local Fabric
-------------------------------------------------------------------------
Switch WWN IP Address
-------------------------------------------------------------------------
20:00:00:0d:ec:2f:c1:40 172.20.150.38 [Merge Master]
<<< Merge Master#1
switch-1
Total number of switches = 1
Remote Fabric
-------------------------------------------------------------------------
Switch WWN IP Address
-------------------------------------------------------------------------
20:00:00:0d:ec:04:99:40 172.20.150.30 [Merge Master]
<<< Merge Master#2
switch-2
Total number of switches = 1
Step 2 Use the show device-alias merge status command to verify that the reason for the merge failure is a mode mismatch. If there is a mode mismatch, the reason that is displayed in the output is either " Databases could not be merged due to mode mismatch
" or " One of the merging fabrics cannot support device-alias Enhanced mode
."
switch#
show device-alias merge status
Result: Failure
Reason: Databases could not be merged due to mode mismatch.
Step 3 Use the show device-alias status command to verify the device-alias mode for each of the fabric.
In this example, switch-1 is running in Enhanced mode, while switch-2 is running in Basic mode:
switch-1#
show device-alias status
Fabric Distribution: Enabled
Database:- Device Aliases 2 Mode: Enhanced
switch-2#
show device-alias status
Fabric Distribution: Enabled
Database:- Device Aliases 2 Mode: Basic
Step 4 Use the no device-alias distribute command to disable device-alias distribution after you detect mismatched device-alias modes.
Step 5 Depending on the mode you want to change in the switch, use either the device-alias mode enhanced command to change the switch mode to Enhanced, or use the no device-alias mode enhanced command to change the switch mode to Basic mode (default mode).
Note If you want to change the device-alias mode from Enhanced to Basic, but an application contains a device-alias configuration in the native format, the device-alias mode cannot be changed until you explicitly remove all the native device-alias configurations or replace all the device-alias members with the corresponding pWWNs.
Step 6 Use the device-alias distribute command to enable the device-alias distribution and initiate a merge.
Resolving a Validation Failure
If the merger of device aliases takes place without any conflicts, the resultant device-alias database is validated with the registered applications on each switch in both the fabrics being merged. If an application fails the validation of the merged database for any reason, the device-alias merge fails.
To verify that the device-alias database merge is failing because of an application-validation failure, perform these steps:
Step 1 Review the CFS or device-alias merge failure syslog to confirm that the merge failed. Alternatively, use the show cfs merge status name device-alias command to view the status of the merge.
Step 2 Use the show device-alias merge status command to verify that the reason for the merge failure is an application-validation failure:
switch#
show device-alias merge status
Result: Failure
Reason: This is a non device-alias error.
Step 3 Examine the syslog messages. The syslog for the switch in which the validation is rejected and the syslog for the switch managing the merge show relevant error messages.
This example shows a sample message on a switch in which the validation is rejected:
2007 Apr 10 00:00:06 switch-2 %DEVICE-ALIAS-3-MERGE_VALIDATION_REJECTED:
Failed SAP: 110 Reason: inter-VSAN zone member cannot be in more than one
VSAN Expln:
This example shows the syslog message on a switch that is managing the merge, and in which the validation is rejected:
2007 Apr 9 16:41:22 switch-1 %DEVICE-ALIAS-3-MERGE_VALIDATION_FAILED: Failed
SWWN: 20:00:00:0d:ec:04:99:40 Failed SAP: 110 Reason: inter-VSAN zone member cannot be in more than one VSAN Expln:
Step 4 Use the show device-alias internal validation-info command on the switch managing the merge, and examine the output.
This example shows that SAP 110 on switch 20:00:00:0d:ec:04:99:40 (switch-2) rejected the validation. The status message shows the reason for the failure along with the system application number:
switch#
show device-alias internal validation-info
Validation timer: 0s
Per SAP Info Table:
===================
SAPS: 0
MTS Buffer Array Details:
=========================
Buffers: 0
Local Status:
=============
Num Reqs Sent: 0 20:00:00:0d:ec:04:99:40
Num SAPs Done: 0
Failed SAP : 0 Status: success Expln:
Remote Status:
==============
CFS Resp Rcvd: TRUE
Failed SWWN : 20:00:00:0d:ec:04:99:40
SAP : 110 Status: inter-VSAN zone member cannot be in more than one VSAN <=== Status
Expln:
Step 5 Use the show system internal mts sup sap number description command to find the application that rejected the configuration on the switch that rejected the validation.
In this example, the application that rejected the device-alias validation was the IVR process.
switch#
show system internal mts sup sap 110 description
IVR-SAP
Step 6 Analyze the device-alias validation failure. This analysis is dependent on the application that failed the validation as well as the device-alias database configuration.
In this example, IVR is failing the validation. To troubleshoot this problem, begin by reviewing the device-alias databases that are being merged. Use the show device-alias database command from the switch managing the merge for each fabric.
switch#
show device-alias database
device-alias name A1 pwwn 21:01:01:01:01:01:01:01
device-alias name A2 pwwn 21:01:01:01:01:01:01:02 => Pre-merge: A2 defined on switch-1
Total number of entries = 2
switch#
show device-alias database
device-alias name A1 pwwn 21:01:01:01:01:01:01:01 => Pre-merge: A2 not defined on switch-2
Total number of entries = 1
Because IVR is enabled on switch-2, review the IVR zone set.
switch# show ivr zoneset
zoneset name s1
zone name z1
pwwn 21:01:01:01:01:01:01:02 vsan 1 autonomous-fabric-id 1
device-alias A2 vsan 2 autonomous-fabric-id 1
Prior to the database merge, device-alias A2 is not defined on switch-2. Because of the merge between switch-1 and switch-2, device-alias A2 becomes available on switch-2, and A2 is mapped to pWWN 21:01:01:01:01:01:01:02.
The device alias-based member A2 in the IVR zone z1 is resolved and mapped to pWWN 21:01:01:01:01:01:01:02, and is a member of VSAN 2. However, pWWN 21:01:01:01:01:01:01:02 is already a member of VSAN 1. The mapping that occurs because of the device-alias merge makes the IVR configuration illegal. The same pWWN cannot be a member of multiple VSANs.
In the case when IVR configuration is illegal, the pWWN in VSAN 2 is defined using the device alias (A2), while the member in VSAN 1 is defined using the actual pWWN. The IVR detects this situation and rejects the device-alias validation. As a result, the device-alias merge fails.
Resolving Database Conflicts
If an entry in the device-alias database conflicts with the configuration of a registered application, the device-alias database commit fails the validation process. Correct either the device-alias database or the application configuration.
To determine the application that failed the validation and the reason for the failure, perform these steps:
Step 1 Use the device-alias commit command to view the output.
This example shows that the commit failed because there is a conflict between the device-alias database and an application configuration:
switch#
configure
Enter configuration commands, one per line. End with CNTL/Z.
switch(config)#
device-alias commit
inter-VSAN zone member cannot be in more than one VSAN ===> reason for commit failure
Step 2 Determine which application configuration is in conflict with the device-alias database by reviewing the syslogs for the switch in which the commit was issued.
This example shows that SAP 110 (IVR) on sWWN 20:00:00:0d:ec:04:99:40 (switch-2) has rejected the validation, and therefore, the device-alias commit has failed:
2007 Apr 10 11:54:24 switch-1 %DEVICE-ALIAS-3-VALIDATION_FAILED: Failed=>Validation Status
SWWN: 20:00:00:0d:ec:04:99:40 Failed SAP: 110 Reason: inter-VSAN zone ==>Switch and SAP member cannot be in more than one VSAN Expln: ==>Reason
2007 Apr 10 11:54:24 switch-1 %DEVICE-ALIAS-3-COMMIT_FAILED: Failed to ==>Commit status commit the pending database: inter-VSAN zone member cannot be in more ==>Reason than one VSAN
Step 3 Review the syslog on the switch in which the validation is rejected.
This example shows that the following syslog is printed on switch-2:
2007 Apr 10 19:13:08 switch-2 %DEVICE-ALIAS-3-VALIDATION_REJECTED: Failed
SAP: 110 Reason: inter-VSAN zone member cannot be in more than one VSAN ==>SAP and reason
Step 4 Compare the existing device-alias database (including the desired changes) and the application configuration to find the conflict.
This example uses the show device-alias database and show ivr zoneset commands along with the console logs of the device-alias database changes made prior to the commit. The comparison shows that the definition of the new device-alias A2 results in the resolution of the enhanced device-alias member A2 in the IVR zone z1 to pWWN 21:01:01:01:01:01:01:02, which is already a member of zone z1. The pWWN is directly defined as a member of VSAN 1, while the enhanced device-alias A2 is defined as a member of VSAN 2. This configuration is not allowed in the IVR. The IVR detects the configuration problem and rejects the device-alias database validation.
switch#
show device-alias database ===> existing device alias database
device-alias name A1 pwwn 21:01:01:01:01:01:01:01
Total number of entries = 1
switch# show ivr zoneset ===> display existing IVR zone set
zoneset name s1
zone name z1
pwwn 21:01:01:01:01:01:01:02 vsan 1 autonomous-fabric-id 1
device-alias A2 vsan 2 autonomous-fabric-id 1
switch#
configure
Enter configuration commands, one per line. End with CNTL/Z.
switch(config)#
device-alias database
switch(config-device-alias-db)#
device-alias name A2 pwwn 21:01:01:01:01:01:01:02
switch(config-device-alias-db)#
exit
switch(config)#
device-alias commit
inter-VSAN zone member cannot be in more than one VSAN
Step 5 Correct the conflict by making adjustments to the application configuration, or by making changes to the device-alias database, and running the device-alias commit command again.
Verifying the Device-Alias Database Status
This section provides information about verifying the device-alias database status.
|
|
show cfs merge status name device-alias |
Displays information about the status of the CFS merge for the device-alias database. |
show device-alias database |
Displays the entire device-alias database. |
show device-alias internal validation info |
Displays information about the status of the validation process (part of a commit or merge). |
show device-alias merge status |
Displays the result of the device-alias merge operation and the reason for the result. |
show device-alias session status |
Returns the status of the last CFS command, such as clear, commit, or terminate. The results of the last used CFS command and reason fields help identify the reason for the failure. |
show device-alias status |
Displays configuration information for the device-alias service, including whether fabric distribution is enabled, the number of device aliases in the database, lock information, and the database mode (Basic or Enhanced). |