A state university MDS already has device-alias distribution enabled. An engineer adds an alias and the peer still shows the old database. The change was never committed. What is missing?
Select an answer to reveal the explanation.
Short Explanation
You’ve enabled distribution, but the new alias is still staged because the change was never committed. Commit the device-alias database to push it to the peer. Zoneset activation enforces zoning; it does not distribute the alias database.
Full Explanation
Device aliases are distributed with Cisco Fabric Services, but adding an alias stages the change on the switch where you made it; committing the device-alias database pushes that staged change to the peer. Since distribution is already enabled, the missing step is the commit, and the peer can correctly continue to show its old database until then. Zoneset activation enforces zoning; it does not distribute the device-alias database, even if a zone later uses the alias. Converting the name to an fcalias does not flood it through CFS: an fcalias belongs to the zoning configuration and is local to a VSAN, so conversion is not a substitute for committing a device alias. A new principal switch is also unnecessary. The principal allocates domain IDs, but device-alias commits are not restricted to the principal, and electing a new one will not publish a staged change. Caveat: a CFS lock held by another session can block a commit, so a failed commit may indicate a lock rather than a missing distribution feature. Practical check: commit the device-alias database, verify that the peer shows the new alias, and confirm that the application reports the databases merged.