Cisco MDS zoning: pWWNs, aliases, basic mode and enhanced commits

01Capture the active, full and session state

1. Identify the current active zone-set name and verify the full database includes all existing required zones. Back up the configuration and both views.
2. Record basic or enhanced zoning mode, actual default-zone policy and any active/pending session. Coordinate with the session owner instead of clearing a lock.
3. Verify exact HBA and target LIF WWPNs from endpoint and fabric evidence. Confirm all required participants are in the intended VSAN and host multipath service is healthy before modification.

show zone status vsan 10
show zoneset active vsan 10
show zoneset vsan 10
show device-alias status
show device-alias database
show flogi database vsan 10
show fcns database vsan 10

02Choose direct pWWN, fcalias or device-alias deliberately

The worked zone-creation block below uses direct pWWNs so the authorization is explicit. The alias block is an optional alternative, not an additional required zone. Device-alias enhanced mode and enhanced zoning are different features. Inspect both independently; an upgraded switch may retain settings that differ from a new installation’s defaults.

03Optional: define and commit device aliases

1. Check that these names do not already identify different devices. Use the exact observed port WWPNs.
2. Inspect the pending difference and commit only if it contains the intended aliases. A separate alias transaction does not activate a zone set.
3. When using native aliases in a zone, the member form is member device-alias app01_hbaA. Confirm mode/consumer behavior before replacing direct pWWN membership in an existing policy.

configure terminal
device-alias database
  device-alias name app01_hbaA pwwn 10:00:00:90:fa:aa:00:01
  device-alias name ontap_n1_fcA pwwn 20:01:00:a0:98:aa:00:01
  device-alias name ontap_n2_fcA pwwn 20:02:00:a0:98:aa:00:01
exit
show device-alias database pending-diff
device-alias commit
end
show device-alias database

04Create two explicit host-to-target zones

Confirm ZS_FAB_A already represents the complete intended active policy before adding members. Entering a name that is absent can create a new incomplete zone set. Activating that object can remove access for every omitted production zone. On a genuinely new isolated fabric, creating the initial set is valid, but it must still contain every intended zone before activation.

configure terminal
zone name Z_app01_n1_A vsan 10
  member pwwn 10:00:00:90:fa:aa:00:01
  member pwwn 20:01:00:a0:98:aa:00:01
exit
zone name Z_app01_n2_A vsan 10
  member pwwn 10:00:00:90:fa:aa:00:01
  member pwwn 20:02:00:a0:98:aa:00:01
exit
zoneset name ZS_FAB_A vsan 10
  member Z_app01_n1_A
  member Z_app01_n2_A
exit
end

05Basic zoning branch: activate the reviewed complete set

1. Review the complete candidate set and compare it with the baseline. Resolve accidental deletions or changed WWPNs before activation.
2. Activate once in the approved window. Verify the new zones and all pre-existing required zones in the active output.
3. Save the approved running configuration and perform host/application postchecks. A local startup save is not a substitute for checking other participating switches’ persistent full databases.

show zoneset vsan 10
configure terminal
zoneset activate name ZS_FAB_A vsan 10
end
show zoneset active vsan 10
copy running-config startup-config

06Enhanced zoning branch: review pending activation and commit

In enhanced mode the activation request participates in the pending zoning transaction. Inspect the difference and pending active set before committing. A pending activation is not proof that the desired policy is already effective. Device-alias commit does not substitute for zone commit.

1. Coordinate one owner for this change and verify the pending difference belongs to that work.
2. If the difference includes an unexpected deletion or another person’s work, stop and reconcile it. Do not force the commit to bypass ownership.
3. After committing, inspect effective membership, the session state and representative existing services, then retain the approved configuration.

configure terminal
zoneset activate name ZS_FAB_A vsan 10
end
show zone pending-diff vsan 10
show zoneset pending active vsan 10
configure terminal
zone commit vsan 10
end
show zoneset active vsan 10
show zone status vsan 10
copy running-config startup-config

07Abort an incorrect pending change before commit

The documented abort form is no zone commit vsan 10. Use it when the owned pending transaction should be discarded before application. It is not a rollback of a transaction that has already been committed, and it is not permission to discard another administrator’s changes. After a committed error, prepare a scoped corrective transaction using the saved before/after membership and validate it normally.

show zone pending-diff vsan 10
configure terminal
no zone commit vsan 10
end
show zone status vsan 10
show zoneset active vsan 10

08Plan a migration to enhanced zoning separately

Changing zoning mode is broader than adding one zone. First inventory every switch in the VSAN, confirm support/interoperability, reconcile full/active databases, back up and close existing transactions. The mode change is fabric-wide for that VSAN and requires coordinated validation and persistence. It does not enable device-alias enhanced mode by implication.

1. Rehearse the migration using the exact release and participating fabric composition. Record how the resulting session and databases will be verified.
2. Apply the approved mode change from the chosen owner switch, inspect every participant and verify no unresolved transaction or isolation remains.
3. Save the resulting configuration through the planned scope and test existing application access. Do not mix this migration with an unreviewed switch merge.

# Separate approved fabric-mode migration, not a prerequisite to every new zone:
configure terminal
zone mode enhanced vsan 10
end
show zone status vsan 10

09Distribute and save the correct database scope

Choose an authoritative editing/source policy for the fabric and verify peer full databases before later changes. A new operator who edits an out-of-date full database and activates it can unintentionally remove currently working zones. Database distribution and session recovery must use the actual basic/enhanced and fabric configuration.

10Validate end-to-end access after activation

1. Confirm the exact intended initiator-target pairs are active, not merely present in the full/pending view.
2. Verify the storage sees the expected initiator session and the intended LUN is mapped to its correct igroup.
3. Use the supported OS procedure for device discovery, verify persistent LUN identity and usable paths, and run an application-native transaction. Check an existing unaffected service as well as the new host.
4. Export a post-change backup and record VSAN, active set, changed zones, time, observer and acceptance.

show zoneset active vsan 10
show flogi database vsan 10
show fcns database vsan 10
show interface fc1/1 counters detailed
# ONTAP admin:
vserver fcp initiator show -vserver svm_lab
lun mapping show -vserver svm_lab
# Linux host:
multipath -ll

11Reverse only the added access when a committed change must be undone

A reversal is a new reviewed zoning transaction. For the illustrated two-zone addition, first confirm those zones are not needed by another service, then remove their membership from the same complete zone set. Use the same activation and basic/enhanced commit branch as the forward change. Retain zone objects until dependency and cleanup review is complete.

configure terminal
zoneset name ZS_FAB_A vsan 10
  no member Z_app01_n1_A
  no member Z_app01_n2_A
exit
end
# Review complete candidate; reactivate ZS_FAB_A.
# Enhanced mode also requires reviewed zone commit.
# Then verify active policy, affected hosts and persistent backup.

12Advanced zoning design: Smart Zoning and controlled scale

Large conventional zones can consume policy resources for endpoint pairs that never exchange useful traffic. Smart Zoning uses member device roles to reduce unnecessary initiator-to-initiator and target-to-target permissions. It is a separate design and migration decision, not another name for enhanced zoning. Brocade Peer Zoning and Cisco Smart Zoning have vendor-specific semantics and configuration.

1. Inventory registered device types and verify roles against actual endpoint purpose. Incorrect or ambiguous roles need investigation before conversion.
2. Check platform/release limits and application cases that legitimately require a different communication pattern. Rehearse with existing traffic and a tested recovery procedure.
3. Evaluate the resulting active permitted pairs and resource use, then test positive and negative access. Do not automatically convert a production fabric while adding a single host.