MDS NPV Uplink VSAN Mismatch and Stale Device Alias
A media company runs a Fibre Channel SAN with two Cisco MDS 9700 core switches and four MDS 9148S edge switches in NPV mode. Hosts connect to the edge switches; the storage array connects to the core. VSAN 10 carries production traffic. A new ESXi host is dual-homed to edge-1 and edge-2. Each edge uplink is configured as a trunk allowed for VSAN 10 and 20. The host HBA logs in to edge-1 and edge-2, and show npv flogi-table on both edges shows the host pWWN. However, the core show flogi database vsan 10 shows the host only through edge-1. The host sees one path to the array, and path failover tests fail when edge-1 is rebooted. The zoning on the core uses device aliases that still point to the old HBA pWWN.
1. Why does the core see the host only through edge-1? What would you check first?
Read the worked answer
NPV does not run full fabric services on the edge; it proxies the host FLOGI to the core using NPIV. If the core sees the host only through edge-1, the edge-2 uplink is probably not carrying VSAN 10 correctly even though its local host port logged in. Check the edge-2 uplink trunk and VSAN membership first: show interface trunk, show npv status, show npv traffic-map, and show flogi database on edge-2. Confirm that the uplink port is operational, is an NP uplink, and is trunking VSAN 10. Also check that the host-facing port is in VSAN 10 and that the edge's NPIV is enabled. If show npv flogi-table shows a local entry but the core has no corresponding FCNS or FLOGI entry for that VSAN, the problem is on the uplink or VSAN path, not the host HBA. The stale device alias is a separate zoning issue and would not prevent FLOGI from reaching the core.
2. What is the correct zoning fix, and why must it be done on the core rather than the edge?
Read the worked answer
In NPV mode, the edge switch does not enforce zoning; the core fabric does. The active zone set must contain the new host pWWN and the array pWWN in VSAN 10. Update the device alias to the new HBA pWWN, create or modify the zone with both members, add it to the zone set, and activate the zone set. On MDS, use device-alias database, device-alias commit, zone name, zoneset name, and zoneset activate vsan 10. Then verify with show zoneset active vsan 10, show device-alias database, and show flogi database vsan 10. If the old alias still points to the old pWWN, the new host may log in but remain unzoned, which explains a single path or no path. Do not try to fix zoning on the NPV edge, because its zone database is not the enforcement point. After activation, confirm that both the host and array pWWNs appear in the active zone set.
3. How would you validate multipath after the fix?
Read the worked answer
Validate at three layers. On the fabric, confirm the host appears twice in show flogi database vsan 10 and show fcns database vsan 10, once through each core-facing edge uplink. Confirm that both edge uplinks trunk VSAN 10 with show interface trunk and that NPV traffic maps are correct. On the host, use esxcli storage nmp path list and esxcli storage core path list to verify two active paths to the array, and check that the path state is active or standby according to the PSP. On the array, confirm both initiator pWWNs are logged in and that LUN masking includes both. Finally, perform a controlled failover: reboot or disable the edge-1 uplink and confirm that the host keeps I/O through edge-2, then restore edge-1 and confirm path recovery. If only one path appears, recheck VSAN trunking and active zoning before changing the host.