Cisco MDS Zoning: A Field Guide for NetApp AFF Dual-Fabric Setups
A CLI-level reference for performing routine SAN zoning operations on Cisco MDS switches paired with NetApp AFF storage in a dual-fabric topology. Three procedures: creating a new zone, removing a zone during host decommission, and swapping HBA WWPNs during hardware replacement.
Audience: storage administrators and SAN engineers working on production Fibre Channel fabrics. Assumes familiarity with Cisco MDS NX-OS, NetApp ONTAP LIF concepts, and standard change-control practice.
Inventory
Example WWPNs follow real OUI conventions — 21:00:00:24:ff:… for QLogic-family HBAs, 20:XX:00:a0:98:… for NetApp ONTAP LIFs. Swap these for the values from show flogi database on your actual switches.
Examples below place the HBA and both target LIFs in one zone per fabric for compact demonstration. For production fabrics the recommended practice is single-initiator-single-target zoning: one zone per HBA-to-LIF pair, so each fabric carries two zones per host instead of one. SIST reduces RSCN blast radius when a target flaps, simplifies fault isolation, and is what most enterprise change-control gates require. The mechanical steps are identical — just replicated once per LIF.
1. Create a New Zone in the Active Zoneset
Requirement. Enable I/O paths between SERVER001 HBA ports and the AFF A90 LIFs. The server is cabled to FC1/10 on both switches; the corresponding switch ports are already configured into VSAN 100 and VSAN 200 respectively.
Fabric A Switch_A · VSAN 100
Identify the active zoneset
Pipe the show zoneset active output through include zoneset to filter the header line.
Switch_A# show zoneset active vsan 100 | include zoneset zoneset name Production_A vsan 100 Switch_A#
Active zoneset: Production_A.
Create the zone and add member PWWNs
Switch_A# conf t Switch_A(config)# zone name SERVER001_AFFA90_LIF_a02_a04 vsan 100 Switch_A(config-zone)# member pwwn 21:00:00:24:ff:a1:b2:01 ! HBA_1 Switch_A(config-zone)# member pwwn 20:01:00:a0:98:12:34:56 ! LIF a02 Switch_A(config-zone)# member pwwn 20:02:00:a0:98:12:34:56 ! LIF a04 Switch_A(config-zone)# exit
Add the zone to the active zoneset
Switch_A(config)# zoneset name Production_A vsan 100 Switch_A(config-zoneset)# member SERVER001_AFFA90_LIF_a02_a04 Switch_A(config-zoneset)# exit
Preview, activate, commit, save
Run show zone pending-diff before activation — this prints the delta between the running zoneset and the database, line-prefixed with + for additions. Always inspect the diff in a change window before committing.
Switch_A(config)# show zone pending-diff vsan 100 zoneset name Production_A vsan 100 + member SERVER001_AFFA90_LIF_a02_a04 + zone name SERVER001_AFFA90_LIF_a02_a04 vsan 100 + member pwwn 21:00:00:24:ff:a1:b2:01 + member pwwn 20:01:00:a0:98:12:34:56 + member pwwn 20:02:00:a0:98:12:34:56 Switch_A(config)# zoneset activate name Production_A vsan 100 Switch_A(config)# zone commit vsan 100 Switch_A(config)# copy running-config startup-config Switch_A(config)# end
Modern enhanced-mode VSANs propagate the activation automatically. zoneset distribute full vsan N is only required if the VSAN is in basic zone mode — check with show zone status vsan 100.
Skip the typing. The MDS Zone Command Generator takes your HBA + target WWPNs and produces ready-to-paste Cisco MDS CLI for both fabrics — with SIST or multi-target layout, a built-in show zone pending-diff safety reminder, and one-click copy / download. Runs entirely in your browser; no WWPNs are transmitted.
Fabric B Switch_B · VSAN 200
The procedure is symmetric. Identify the zoneset, build the zone with HBA_2 and the two Fabric B LIFs, add to the active zoneset, preview, activate, commit, save.
Switch_B# show zoneset active vsan 200 | include zoneset zoneset name Production_B vsan 200
Switch_B# conf t Switch_B(config)# zone name SERVER001_AFFA90_LIF_b01_b03 vsan 200 Switch_B(config-zone)# member pwwn 21:00:00:24:ff:a1:b2:02 ! HBA_2 Switch_B(config-zone)# member pwwn 20:03:00:a0:98:12:34:56 ! LIF b01 Switch_B(config-zone)# member pwwn 20:04:00:a0:98:12:34:56 ! LIF b03 Switch_B(config-zone)# exit
Switch_B(config)# zoneset name Production_B vsan 200 Switch_B(config-zoneset)# member SERVER001_AFFA90_LIF_b01_b03 Switch_B(config-zoneset)# exit
Switch_B(config)# show zone pending-diff vsan 200 Switch_B(config)# zoneset activate name Production_B vsan 200 Switch_B(config)# zone commit vsan 200 Switch_B(config)# copy running-config startup-config Switch_B(config)# end
After activation, confirm both paths come up under the host OS. For a correctly zoned dual-fabric setup with two LIFs per fabric, expect 4 active paths per LUN (2 HBAs × 2 LIFs through their respective fabric).
Linux — device-mapper-multipath (RHEL, SLES, Ubuntu):
[root@server001 ~]# multipath -ll | grep -A1 NETAPP 3600a09800c123456abcdef0123456789 dm-2 NETAPP,LUN C-Mode size=2.0T features='3 queue_if_no_path pg_init_retries 50' hwhandler='1 alua' wp=rw [root@server001 ~]# multipath -ll mpatha | grep -E "policy|active ready" policy='service-time 0' prio=50 status=active |- 2:0:0:1 sdb 8:16 active ready running # Fabric A · LIF a02 |- 2:0:1:1 sdc 8:32 active ready running # Fabric A · LIF a04 |- 3:0:0:1 sdd 8:48 active ready running # Fabric B · LIF b01 `- 3:0:1:1 sde 8:64 active ready running # Fabric B · LIF b03
Windows Server — MPIO via PowerShell (confirm the MPIO feature is installed and the NetApp DSM or built-in Microsoft DSM is claiming the LUN):
PS C:> Get-WindowsFeature Multipath-IO # confirm MPIO feature installed PS C:> Get-MPIODisk Number Name DSM NumberPaths ------ ---- --- ----------- 1 MPIO Disk1 Microsoft DSM 4 2 MPIO Disk2 Microsoft DSM 4 PS C:> mpclaim.exe -s -d 1 MPIO Disk1: 04 Paths, Round Robin, ALUA Controlling DSM: Microsoft DSM SN: 600A09800C123456ABCDEF0123456789 Path ID State SCSI Address Weight 0000000077030001 Active/Optimized 003|000|001|001 0 # vmhba A · a02 0000000077030002 Active/Optimized 003|000|002|001 0 # vmhba A · a04 0000000077020001 Active/Optimized 002|000|001|001 0 # vmhba B · b01 0000000077020002 Active/Optimized 002|000|002|001 0 # vmhba B · b03
VMware ESXi — rescan first, then verify path count + ALUA state with esxcli:
[root@esxi-01:~] esxcli storage core adapter rescan --all [root@esxi-01:~] esxcli storage nmp device list | grep -A4 NETAPP Device Display Name: NETAPP Fibre Channel Disk (naa.600a09800c123456...) Storage Array Type: VMW_SATP_ALUA Path Selection Policy: VMW_PSP_RR Working Paths: vmhba2:C0:T0:L1, vmhba2:C0:T1:L1, vmhba3:C0:T0:L1, vmhba3:C0:T1:L1 [root@esxi-01:~] esxcli storage core path list -d naa.600a09800c123456abcdef0123456789 | grep -E "Runtime|State" Runtime Name: vmhba2:C0:T0:L1 State: active # Fabric A · a02 Runtime Name: vmhba2:C0:T1:L1 State: active # Fabric A · a04 Runtime Name: vmhba3:C0:T0:L1 State: active # Fabric B · b01 Runtime Name: vmhba3:C0:T1:L1 State: active # Fabric B · b03
If fewer than 4 paths appear, troubleshoot in this order: (1) confirm both HBA PWWNs are logged into the fabric — show flogi database vsan N on each switch; (2) confirm both target LIF PWWNs are visible — show fcns database vsan N; (3) re-check zone membership — show zone active vsan N and look for your initiator and target PWWNs in the same zone; (4) on the host side, force a rescan (echo "- - -" > /sys/class/scsi_host/hostN/scan on Linux, Update-HostStorageCache on Windows, esxcli storage core adapter rescan --all on ESXi) and verify the driver is loaded and ALUA is honoured.
WUC owns the change window for you
Pre-change validation, peer-reviewed CLI scripts, real-time path monitoring, rollback rehearsed in lab. For fabrics carrying production workloads.
2. Remove a Zone During Host Decommission
Requirement. SERVER001 is being decommissioned. Remove the zones from the active zoneset on both fabrics, then optionally purge them from the zone database.
Fabric A Switch_A · VSAN 100
Remove the zone from the active zoneset
Switch_A# conf t Switch_A(config)# zoneset name Production_A vsan 100 Switch_A(config-zoneset)# no member SERVER001_AFFA90_LIF_a02_a04 Switch_A(config-zoneset)# exit
Preview, activate, commit, save
Switch_A(config)# show zone pending-diff vsan 100 Switch_A(config)# zoneset activate name Production_A vsan 100 Switch_A(config)# zone commit vsan 100 Switch_A(config)# copy running-config startup-config Switch_A(config)# end
Fabric B Switch_B · VSAN 200
Switch_B# conf t Switch_B(config)# zoneset name Production_B vsan 200 Switch_B(config-zoneset)# no member SERVER001_AFFA90_LIF_b01_b03 Switch_B(config-zoneset)# exit Switch_B(config)# zoneset activate name Production_B vsan 200 Switch_B(config)# zone commit vsan 200 Switch_B(config)# copy running-config startup-config Switch_B(config)# end
Removing a zone from the active zoneset stops it from being enforced, but the zone definition remains in the zone database and consumes name-space. For a true decommission, purge it explicitly and check for orphan device-aliases referencing the host’s PWWNs.
Switch_A(config)# no zone name SERVER001_AFFA90_LIF_a02_a04 vsan 100 Switch_A(config)# zone commit vsan 100 Switch_A(config)# copy running-config startup-config Switch_A(config)# show device-alias database | include 21:00:00:24:ff:a1:b2:01 ! repeat on Switch_B for vsan 200 + HBA_2 PWWN
3. HBA Replacement — Swap PWWN in Place
Requirement. HBA_2 has failed and been physically replaced. The host’s old PWWN 21:00:00:24:ff:a1:b2:02 is gone; the new card presents 21:00:00:24:ff:c8:99:08. Update the existing Fabric B zone so the new PWWN inherits the same target relationships without recreating the zone.
Fabric B Switch_B · VSAN 200
Confirm the new PWWN logged into the fabric
Switch_B# show flogi database vsan 200 | include 21:00:00:24:ff:c8:99:08 fc1/10 200 0x123456 21:00:00:24:ff:c8:99:08 20:00:00:24:ff:c8:99:08
If the new PWWN doesn’t appear in flogi database, the host hasn’t completed FLOGI — verify cabling, GBIC, and host-side driver before proceeding.
Swap the PWWN inside the existing zone
Switch_B# conf t Switch_B(config)# zone name SERVER001_AFFA90_LIF_b01_b03 vsan 200 Switch_B(config-zone)# no member pwwn 21:00:00:24:ff:a1:b2:02 ! retired HBA_2 Switch_B(config-zone)# member pwwn 21:00:00:24:ff:c8:99:08 ! replacement HBA_2 Switch_B(config-zone)# exit
Preview, activate, commit, save
Switch_B(config)# show zone pending-diff vsan 200 Switch_B(config)# zoneset activate name Production_B vsan 200 Switch_B(config)# zone commit vsan 200 Switch_B(config)# copy running-config startup-config Switch_B(config)# end
If your fabric uses device-alias rather than raw PWWN membership, replace the alias mapping instead of editing the zone. Each PWWN swap then becomes one device-alias database edit followed by a device-alias commit.
Switch_B(config)# device-alias database Switch_B(config-device-alias-db)# no device-alias name SERVER001_HBA2 Switch_B(config-device-alias-db)# device-alias name SERVER001_HBA2 pwwn 21:00:00:24:ff:c8:99:08 Switch_B(config-device-alias-db)# exit Switch_B(config)# device-alias commit
When to call WUC
This guide covers routine zoning work. Escalate to WUC if any of the following apply:
- The fabric is carrying a regulated workload (PCI-DSS, HIPAA, SOX) and the change is outside your existing change-control window.
- You’re cutting over from one storage vendor to another (NetApp → Pure, EMC VMAX → PowerStore, etc.) and need parallel-path zoning with a controlled cutover.
- The MDS pair is being upgraded (NX-OS rev, MDS 9700 hardware swap, fabric merge) and you want zoning continuity audited before and after.
- Multipath behaviour on the host has degraded after a zone change and the root cause isn’t obvious from
show zone analysis+show flogi database. - You inherited a fabric with no documentation and need a baseline of every zone, alias, and orphan PWWN before making changes.
WUC engineers run multi-OEM SAN fabrics — Cisco MDS, Brocade, NetApp, EMC, Pure, HPE 3PAR — under tiered SLAs with peer-reviewed change documentation. See Storage Maintenance and Multi-Vendor Consolidation for the engagement model.
Related Engineering Surfaces
This field guide is part of a growing library of CLI-level runbooks WUC publishes for production storage and networking work. Pieces in the same series — on NetApp aggregate provisioning, Pure Storage host group setup, VPLEX distributed device creation, and Cisco UCS service profile deployment — share the same dual-fabric / change-control framing.
If your team is operating a multi-OEM estate at scale, Managed Services wraps these procedures into a 24×7 operational coverage model with documented response SLAs.