Cisco 300-625 DCSAN: Zone Merge Conflict Between Two Fabrics in VSAN 10

Zone Merge Conflict Between Two Fabrics in VSAN 10

Two data centers are joined by an ISL in VSAN 10. Fabric A has active zoneset PROD_ZS with zone WEB containing pWWNs 20:00:00:25:B5:00:AA:01 and 20:00:00:25:B5:00:AA:02. Fabric B was built from an old template and has active zoneset PROD_ZS with a zone also named WEB, but its members are 20:00:00:25:B5:00:BB:01 and 20:00:00:25:B5:00:BB:02. The physical ISL is up, but the VSAN 10 ISL ports are isolated and no devices from Fabric B can log in through Fabric A. show zone merge-status reports a merge failure; the default zone is deny. Fabric B has no production hosts logged in yet, but its configuration must not be lost until the conflict is documented. The team wants to preserve Fabric A's active zoning as the authority and bring the link into service without touching Fabric A's zones.

1. Explain why the ISL is isolated even though the physical link is up, and what you would check to confirm the conflict.

Read the worked answer

The physical link can be up while the VSAN-level E port is isolated because the fabric services in VSAN 10 cannot merge. Zoning is part of that merge. The same zone name WEB exists in both fabrics with different members, and both fabrics have an active zoneset named PROD_ZS. That is a hard merge conflict; with default zone deny, the switch will not merge the VSAN and isolates the ISL in VSAN 10 rather than risk merging incompatible zoning.

Confirm with:

show zone merge-status vsan 10
show zoneset active vsan 10 on both switches
show zone vsan 10 on both switches
show interface fc<ISL> trunk and show interface fc<ISL>
show fcdomain domain-list vsan 10 to confirm both sides see separate fabrics

Do not assume the ISL optics or FSPF are at fault just because the physical port is up. The merge-status output and the zone database comparison should identify the conflicting zone name and member list.

2. Give a safe resolution sequence on Fabric B that preserves Fabric A's zoning and documents the existing Fabric B configuration.

Read the worked answer

Treat Fabric A as authoritative and Fabric B as non-production during the fix.

Capture Fabric B's current VSAN 10 zoning: save show zoneset active vsan 10, show zone vsan 10, and the relevant running-config sections to an offline file before changing anything.
On Fabric B, deactivate its current zoneset and remove or rename the conflicting WEB zone. Because B has no production logins, removing the old zone is acceptable after the capture. If the old members must remain documented, rename the zone to a site-specific name instead of deleting the data.
Remove or rename B's conflicting PROD_ZS zoneset if it still conflicts with A's zoneset content.
Allow the VSAN to merge again. If the ISL remains isolated, toggle the VSAN 10 ISL port or restart the VSAN domain as appropriate for the platform, then recheck merge status.
Confirm that B now has A's WEB members and that PROD_ZS is active as intended. Activate or distribute the authoritative zoneset if it did not become active automatically.

Fabric A's zone database is never edited in this sequence.

3. How would you verify the merged result and prevent the same conflict on future ISLs?

Read the worked answer

Verify on both fabrics that show zoneset active vsan 10 contains the Fabric A WEB members and that show zone merge-status vsan 10 no longer reports a conflict. Check that the VSAN 10 ISL ports are no longer isolated, that show fcdomain domain-list vsan 10 shows one merged fabric, and that a test Fabric B host can log in and see only its intended targets. Use show flogi database vsan 10 and show zoneset active vsan 10 to confirm pWWN placement.

Prevent recurrence with a unique zone naming convention that includes site or fabric identity, a pre-ISL checklist that compares active zonesets and zone members, and change control that requires capturing both zone databases before enabling a VSAN on an ISL. If a VSAN must never auto-merge, use the platform's zone merge-control feature deliberately and document the operational impact; do not rely on default zone deny as the only protection.