A factory IoT network needs one friendly name for a controller port WWN in two VSANs, but an fcalias created in the first VSAN does not resolve in the second VSAN or on the peer switch. Which object supplies that shared name?
Select an answer to reveal the explanation.
Short Explanation
A nickname that every room must share belongs in the building directory, not on a note taped inside one office. You put that port WWN in a device alias so the name is fabric-wide and usable in both VSANs. An fcalias never leaves the VSAN where you created it, so the second VSAN and the peer stay blind to it.
Full Explanation
A device alias is a fabric-wide friendly name for a port WWN, and Cisco Fabric Services distributes that database to the other MDS switches in the fabric. An fcalias is stored with the zoning configuration of one VSAN, so the name this factory created in the first VSAN is invisible in the second VSAN and is not a fabric-wide object on the peer. That scope is why the shared name has to be a device alias. Typing another fcalias by hand into the second VSAN can imitate the string on one switch, but it is still local to that VSAN and it is not what a zoneset activation copies onto the peer. The FCNS name server records devices after they log in. It does not hold a configured alias you can reference before login, and it is not the distribution plane for names. Being the principal switch lets a switch coordinate domain IDs. It does not publish an alias database. Caveat: the device alias still has to be committed in a CFS distribution, and a zone that references it does nothing until that zone is in the active zoneset. Operational check: create the device alias, distribute it, and confirm both VSANs and the peer resolve the same name to the same port WWN.