Blade Cannot See the Backup Array After VSAN 200 Zoning
A pair of Nexus 5548UP switches runs NPV toward two MDS 9148S core switches, with four links per Nexus in a SAN port-channel. A UCS 6248UP domain with B200 M5 blades and VIC 1340 carries FCoE, and the FI SAN port-channels carry FCoE VLAN 200 mapped to VSAN 200. Blade 3 was added to a new backup-array zone in VSAN 200. After activation, the blade HBA logs in, but the host OS sees no LUNs. On the MDS, show flogi database vsan 200 lists the initiator PWWN from the NPV but no target PWWN. The array's port fc1/5 is up, and the array GUI reports the host mapping as complete. show zone active vsan 200 displays zone BKUP_BLADE3 with device-alias members init_blade3 and tgt_backup1. show device-alias database shows tgt_backup1 as 20:11:00:25:b5:00:00:99, while the array GUI shows its target port as 20:11:00:25:b5:00:00:9a. On the MDS, show interface fc1/5 shows VSAN 1, and show flogi database vsan 1 contains the array's PWWN. show zoneset active vsan 200 confirms the zone set is active.
1. Separate symptoms from root causes. What are the two independent problems, and how do you prove each one with show commands?
Read the worked answer
Two independent faults are present.
First, the array port is not a member of VSAN 200: show interface fc1/5 shows VSAN 1, and show flogi database vsan 1 contains the array PWWN, while show flogi database vsan 200 contains only the initiator. Zoning can only match devices logged into the same VSAN, so the target can never appear in the VSAN 200 name server.
Second, the zone itself is wrong: device-alias tgt_backup1 resolves to 20:11:00:25:b5:00:00:99, while the array's target port is 20:11:00:25:b5:00:00:9a. Prove it with show device-alias database and show zone active vsan 200, then compare the zone member against the PWWN that logs in after the VSAN fix. show zoneset active vsan 200 confirms the zone set is activated, so the zone is being enforced with the wrong member rather than being inactive.
2. Give the fix order and the verification for each step, including impact on the existing VSAN 1 traffic.
Read the worked answer
Fix the VSAN membership first: move the array port from VSAN 1 to VSAN 200 (or, if it is a TE port, add VSAN 200 to the allowed list) and verify with show interface fc1/5, show flogi database vsan 200 on both MDS switches, and show npv flogi-table on the NPV pair, which should now show the target as well as the initiator. This can disrupt any existing VSAN 1 traffic on that port, so confirm with the storage team that the array has no VSAN 1 presentation.
Then correct the device alias to the real PWWN, run device-alias commit, and reactivate the zone set (zoneset activate name <name> vsan 200) because basic zoning does not push an edited member into the active set automatically. Verify show zone active vsan 200 shows the correct target PWWN.
Finally, confirm LUN masking on the array and rescan the host. The earlier success of the initiator FLOGI only proves fabric login, not zone or LUN access.
3. Why does a successful initiator FLOGI not prove that zoning is correct?
Read the worked answer
FLOGI is a fabric login to the name server. It proves the physical path, the VSAN in which the port operates, and, on FCoE links, that the FCoE VLAN/VSAN mapping and the vNIC/vHBA path are working. It says nothing about which other devices the port may communicate with.
Zoning is enforced separately by the name server and the data plane: a device can log in successfully and still be unable to see any target because the zone omits it, misnames it, or is not part of the active zone set. This is why the troubleshooting order is port state and VSAN, then show flogi database on both ends, then show zone active/show zoneset active, then LUN masking. Each layer can fail independently and produce the same host-side symptom: no LUNs.