Page 1 of 16

Cisco MDS Best Practices

Table of Contents
Introduction...................................................................................................................................................... 1
Change Summary............................................................................................................................................. 1
Back up Configuration Files............................................................................................................................ 1
Procedure......................................................................................................................................................... 2
Save Running-Config to Startup-Config........................................................................................................ 2
GUI.............................................................................................................................................................................. 2
CLI............................................................................................................................................................................... 2
Power off a Switch........................................................................................................................................ 2
Change Best Practices.................................................................................................................................. 2
Check Switch, CLARiiON, and Hosts for Errors before proceeding to Second Fabric...............................................3
Configure Second Fabric after no Errors are found....................................................................................................5
Check for Errors after Configuring Second Fabric......................................................................................................5
Save Running-Config to Startup-Config after Both Fabrics are Confirmed Correct....................................................5
Domain ID......................................................................................................................................................... 5
Resolve Domain ID Overlaps........................................................................................................................ 5
Device Alias...................................................................................................................................................... 5
VSAN................................................................................................................................................................. 6
VSAN Number Assignment........................................................................................................................... 6
Inter-Switch Link (ISL)..................................................................................................................................... 7
Zoning Two MDS Switches after Connecting with an ISL or EISL Link.........................................................7
Zoning......................................................................................................................................................................... 7
Recovery................................................................................................................................................................... 13
Graphical Representation of Zoning Behavior..........................................................................................................14

Introduction
This document outlines the change best practices for the Cisco MDS Switches.

Change Summary
Version Date Change / Summary
Updated by
01 11/16/2006 Brian Rait Initial document
02 12/1/2010 Yew Oon Sian Added Domain ID, Device Alias, VSAN, ISL
03 18-Jun- Cancilla, Bret  Changed to OASIS format
2013 A.  Updated VSAN Names and Numbers
 Added additional information for Zoning Two MDS
Switches After Connecting with an ISL or EISL Link
04 28-Aug- Cancilla, Bret Updated VSAN Names and Numbers for Symmetrix
2014 A. VMWare clusters, Physical HP-UX, and Physical Windows
hosts.

Back up Configuration Files

It is important to safeguard a copy of full configuration and keep it on-hand before configuring the switch.
To backup the running configuration to the TFTP server, issue the command below:

MALMKLQS01# copy running-config tftp://144.201.242.109/malmklqs01.cfg

The configuration file can be viewed in Notepad after it is copied.

retain original - ACT+3 retain copies - ACT+3

 Page 2 of 16

Procedure
Save Running-Config to Startup-Config
Perform this for each switch in the Fabric.
GUI
1. Go to Device Manager > Admin > Save Configuration.

2. Click [Yes].

3. Click [Close].

CLI
> copy running-config startup-config

Power off a Switch

1. Save Running-Config to Startup-Config.
2. Power off each switch by turning the redundant power supplies to the off position on the back of
each switch.

Change Best Practices

1. Perform changes on one fabric at a time.
2. Check for errors before proceeding to the next fabric.
3. Save Running-Config to Startup-Config before making changes.
4. Perform this for each switch in the fabric.
5. Do not save Running-Config to Startup-Config immediately.
6. If exiting Device Manager, click [No].

retain original - ACT+3 retain copies - ACT+3

 Page 3 of 16

7. If exiting Fabric Manager, click [No].

8. If applying Zone changes, uncheck the Save Running to Startup Configuration checkbox.

Check Switch, CLARiiON, and Hosts for Errors before proceeding to Second
Fabric
1. In Fabric Manager, check the End Devices.

NOTE: Look for link failures and VSAN memberships.

2. In Device Manager, click the Device tab and the Summary tab and look for failed ports.

3. In Navisphere, check the connectivity status.

retain original - ACT+3 retain copies - ACT+3

 Page 4 of 16

NOTE: Look for grayed out HBAs whose Logged In is No (this indicates a SAN problem)
4. In Windows, check the System Event Logs for PowerPath, Disk, and NTFS errors.
a. Select Start > Run... on your desktop or on a Windows server.
b. Enter eventvwr \\servername.
c. Click the System log.

NOTE: Look for EmcpBase, Disk, or Ntfs errors.

5. In Unix, check PowerPath.
a. Log into the Unix server.
b. Pbrun to root.
c. Enter #: /etc/powermt display dev=all.

6. In Unix, check the System logs.

retain original - ACT+3 retain copies - ACT+3

 Page 5 of 16

a. Log into the Unix server.

b. Enter tail /var/adm/xom_syslog.

NOTE: Look for Downed Fibre Channel Loops and Dead Paths and look for Dead paths and
Errors.

Configure Second Fabric after no Errors are found

Follow the same practices as the first fabric configuration.
Check for Errors after Configuring Second Fabric
See “Check Switch, CLARiiON, and Hosts for Errors” above.
Save Running-Config to Startup-Config after Both Fabrics are Confirmed
Correct
Perform this for each switch in both fabrics.

Domain ID
Each VSAN has its own principal switch and domain ID allocation policy. Each switch has a separate
domain ID for each active VSAN. Inter-VSAN Routing (IVR) also requires unique domain IDs across all
switches and VSANs participating in IVR.
Domain IDs must be unique across interconnected VSANs. To ensure unique domain IDs across
interconnected VSAN, consider these guidelines:
 Minimize the number of switches that require a domain ID assignment to ensure minimum traffic
disruption.
 Minimize the coordination between interconnected VSANs when configuring the SAN for the first
time as well as when you add each new switch.

NOTE: A static domain is specifically configured by the user and can be different from the runtime domain.
If the domain IDs are different, the runtime domain ID changes to take on the static domain ID after next
restart.

Resolve Domain ID Overlaps

To resolve a domain ID overlap:
 Manually assign domain IDs.
 Disruptive restart is required when assigning preferred IDs, and usually when assigning
static IDs.
 Non-disruptive restart is acceptable only when changing a preferred ID into a static without
actually changing the ID.

Device Alias
A device-alias is a user-friendly name for a port WWN (pWWN) that can be used in all configuration
commands as required. All switches in the Cisco MDS 9000 Family support Distributed Device Alias
Services.
This section provides the best practices for creating and using device aliases:

retain original - ACT+3 retain copies - ACT+3

 Page 6 of 16

 Device aliases should be used to simplify management whenever possible. It is easier to identify
devices with aliases than with WWNs. In general, assign aliases to WWNs.
 Operate device aliases in enhanced mode whenever possible. In enhanced mode, applications
accept the device alias name in its “native” format, rather than expanding the alias to a pWWN.
Because applications such as zone server, IVR, PSM, and DPVM automatically track and enforce
device alias membership changes, you have a single point of change. To operate in enhanced
mode, all switches in the fabric must be running Cisco SAN-OS 3.2(3a) or later.
 Preplan device alias configurations, and implement a consistent naming convention.
 Keep documented backups of all device alias configurations.
 Have a clear understanding of what the final device alias database should be after the merge
before attempting to resolve merge failures. This can prevent traffic disruptions caused by
accidentally overwriting device alias entries.
 Avoid doing a blank commit to resolve all CFS merge failures. A blank commit overwrites the
device alias databases on all switches with the device alias database on the local switch. The
database entries on all other switches are lost. Use this type of commit with caution. Be sure that
this behavior matches your expectations. A blank commit, however, could be helpful in resolving a
merge failure resulting from mode mismatch.
 If a merge fails due to a validation failure, analyze the failure from the application perspective, and
fix it accordingly.

NOTE: The existing device alias configurations that automatically expanded to pWWN must be explicitly
removed and reconfigure it in the native format. Because the device alias was previously running in the
basic mode, it remained the expanded pWWN.

VSAN
VSANs help achieve traffic isolation in the fabric by adding control over each incoming and outgoing port.
There can be up to 256 VSANs in the switch and 239 switches per VSAN.
The default VSAN number is VSAN 1. The maximum number of VSANs per switch includes default VSAN
1 and isolated VSAN 4079 and 4094.
VSAN recommended practices:
 Avoid using VSAN 1 for production network traffic.
 Avoid using VSAN other than VSAN 2 to VSAN 3839.
 Create at least one VSAN to carry production traffic.
 Isolate devices in VSANs whenever practical.
 Use IVR when necessary to selectively connect devices across VSANs.

VSAN Number Assignment

VSAN Description
1 Default (Unused ports, Suspend)
100 VSAN100_VMAX_HPUX (Depreciated)
101 VSAN101_MirrorView_Odd
102 VSAN102_MirrorView_Even
200 VSAN200_VMAX_AIX
300 VSAN300_VMAX_SUN
400 VSAN400_VMAX_Windows (Depreciated)
401 VSAN401_VMAX_Windows_A
402 VSAN402_VMAX_Windows_B
500 VSAN500_VMAX_Tape_Backup
501 VSAN501_Tape_Backup_Odd

retain original - ACT+3 retain copies - ACT+3

 Page 7 of 16

VSAN Description
502 VSAN502_Tape_Backup_Even
600 VSAN600_VMAX_AS400_VMware (Depreciated)
700 VSAN700_VMAX_AS400
801 VSAN801_CLARiiON_A
802 VSAN802_CLARiiON__B
901 VSAN901_FAS-Series_A
902 VSAN902_FAS-Series_B
3800 VSAN3800_Links
1001 VSAN1001_VMAX_VMware_A
1002 VSAN1002_VMAX_VMWare_B
1101 VSAN1101_VMAX_HPUX_A
1102 VSAN1102_VMAX_HPUX_B
1201 VSAN1201_E-Series_A
1202 VSAN1202_E-Series_B
3840 - 4078 Reserved VSANs and they are not available for user configuration
4079 EVFP isolated VSAN
4080 - 4094 Used for vendor-specific VSANs

Inter-Switch Link (ISL)

ISLs are used to transfer host-to-storage data, as well as fabric management traffic from one switch to
another. When planning the quantity and locations of ISLs around the fabric, the effects of routing,
redundancy requirements, ISL load balancing, and trunking should be considered.
ISL layout recommendations:
 A minimum of two ISLs must be connected between any two switches for redundancy. Additional
ISL requirement should be based on the actual/estimated performance data.
 ISLs connected ports must have dedicated bandwidth.
 Avoid two ISLs on the same port-group (ASIC).
 On a modular switch, separate two same-cost ISLs on different line cards.
 Do not bring up the ports until all the port configurations are done and verified.

Zoning Two MDS Switches after Connecting with an ISL or EISL Link
This section examines situations that can arise when allowing two Cisco MDS switches to merge
zone information after each already has zoning information, and an Extended ISL (EISL) link is
configured between them.
Zoning
Concept
When two Fibre Channel (FC) switches that have already been configured with active zonesets and
are not yet connected are brought together with an EISL link, the zonesets merge. Steps must be
taken, however, to ensure zone consistency before configuring and activating new zones.
Best Practices
When a zone merge occurs, as long as there is not competing information, each switch learns the
others zones. Each switch then has three configuration entities. The switches have:
 The saved configuration in NVRAM. This is the configuration as it was the last time the copy
running−configuration startup−configuration command was issued.
 The running configuration. This represents the configuration brought into memory upon the last

retain original - ACT+3 retain copies - ACT+3

 Page 8 of 16

time the MDS was brought up, plus any changes that have been made to the configuration. With
reference to the zoning information, the running configuration represents the configurable
database, known as the full database.
 The configured zoning information from the running configuration plus the zoning information
learned from the zone merge. This combination of configured and learned zone information is the
active zoneset.
When a MDS is booted, it comes up with the configuration previously saved in NVRAM. If you
configured the switch after loading the configuration from NVRAM, there is a difference between the
bootup and running configuration until the running configuration is saved to the startup configuration.
This can be likened to having a file on the local hard drive of your PC. The file is saved and static,
but if you open the file and edit, there exists a difference between the changed file and the file that
still exists on saved storage. Only when you save the changes, does the saved entity look represent
the changes made to the file.
When zoning information is learned from a zone merge, this learned information is not part of the
running configuration. Only when the zone copy active−zoneset full−zoneset vsan <x>
command is issued the learned information becomes incorporated into the running configuration.
This is key because when a zone merge is initiated by a new EISL link or activating a zoneset, the
zoneset part is ignored by the other switch and the member zone information is considered topical.
Example
For example, you have two standalone MDS switches, already in place and each with their own
configured zone and zoneset information. Switch 1 has an active zoneset known as set A, and
Switch 2 has an active zoneset known as set B. Within set A on Switch 1 is zone 1, and on Switch 2,
set B has member zone 2. When an ISL link is created between these two switches, each sends
their zone information to the other switch. Zoneset information is transferred on this zone merge, but
zoneset information is ignored on a merge. On a merge, only the member information is calculated.
After the zone merge, set A on Switch 1 has two members, set A and set B. Likewise, after the zone
merge, Switch 2 has two zones in its active zoneset, zone 1 and zone 2. While both switches have
both zones in their active zonesets, however, the running configuration has not changed, and does
not reflect the zoning information learned from the other switch.
Everything should still be working for all of the devices in zone 1 and zone 2. To add a zone on either
switch, you have to create the zone, add the new zone to the zoneset, and activate the zoneset. If
you activate the zoneset without issuing the copy zoneset active−zoneset full−zoneset
vsan <x> command, the switch where the new zone has been configured does a zone merge, and
advertises only the configured zoneset out. This does not include the zone information that had been
previously learned, overwrites the zone information in the other switch, and loses the zone
information that had been previously defined in the receiving switch. If a zone 3 is created in Switch
1, added to the zoneset, and that zoneset is activated, zone 1 and zone 3 are sent to Switch 2.
Switch 2 now has set A as the active zoneset with zone members zone 1 and zone 3.
Step−by−step, the switches are booted up and have no zoning information. You need to create the
zones on the switches and add them to the zonesets. Refer to the sample command output below.

Create zone and zoneset. Activate on Switch 1.

Switch#1# config t
Enter configuration commands, one per line. End with CNTL/Z.
Switch#1(config)# vsan database
Switch#1(config−vsan−db)# vsan 100
Switch#1(config−vsan−db)# exit
Switch#1(config)# zone name zone1 vsan 100
Switch#1(config−zone)# member pwwn 11:11:11:11:11:11:11:11
Switch#1(config−zone)# exit
Switch#1(config)# zoneset name setA vsan 100
Switch#1(config−zoneset)# member zone1
Switch#1(config−zoneset)# exit
Switch#1(config)# zoneset activate name setA vsan 100

retain original - ACT+3 retain copies - ACT+3

 Page 9 of 16

Zoneset activation initiated. check zone status

Switch#1(config)# exit
Switch#1# sh zoneset active
zoneset name setA vsan 100
zone name zone1 vsan 100
pwwn 11:11:11:11:11:11:11:11
Switch#1#

Create zone and zoneset. Activate on Switch 2.

Switch#2# config t
Enter configuration commands, one per line. End with CNTL/Z.
Switch#2(config)# vsan database
Switch#2(config−vsan−db)# vsan 100
Switch#2(config−vsan−db)# exit
Switch#2(config)# zone name zone2 vsan 100
Switch#2(config−zone)# member pwwn 22:22:22:22:22:22:22:22
Switch#2(config−zone)# exit
Switch#2(config)# zoneset name setB vsan 100
Switch#2(config−zoneset)# member zone2
Switch#2(config−zoneset)# exit
Switch#2# sh zoneset active vs 100
zoneset name setB vsan 100
zone name zone2 vsan 100
pwwn 22:22:22:22:22:22:22:22
Switch#2#
Now, bring up an ISL link between the switches, and allow the zoning information to merge.

Bring ISL link up and verify zone merge on Switch 1.

Switch#1# config t
Enter configuration commands, one per line. End with CNTL/Z.
Switch#1(config)# int fc1/5
Switch#1(config−if)# no shut
Switch#1(config−if)# exit
Switch#1(config)# exit
Switch#1# sh zoneset active vs 100
zoneset name setA vsan 100
zone name zone1 vsan 100
pwwn 11:11:11:11:11:11:11:11
zone name zone2 vsan 100
pwwn 22:22:22:22:22:22:22:22

Bring ISL link up and verify zone merge on Switch 2.

Switch#2# config t
Enter configuration commands, one per line. End with CNTL/Z.

retain original - ACT+3 retain copies - ACT+3

 Page 10 of 16

Switch#2(config)# int fc2/5

Switch#2(config−if)# no shut
Switch#2(config−if)# exit
Switch#2(config)# exit
Switch#2# sh zoneset active vs 100
zoneset name setB vsan 100
zone name zone2 vsan 100
pwwn 22:22:22:22:22:22:22:22
zone name zone1 vsan 100
pwwn 11:11:11:11:11:11:11:11
Notice in a zone merge, zoneset information does not override the other switch zoneset information.
Zoneset information is considered when a zoneset is activated, as explained in further detail later in
this document. Only the zone member information is exchanged in a zone merge such as what is
occurring in this example. Thus, the zoneset names are the same on the switch as before the merge.
To avoid problems, the zone copy active−zoneset full−zoneset vsan 100 command
should be given at this point on the switch where the new zone is created. First, examine if the
command is given, and how the new zoning information is handled. When the zone copy command
is issued, it adds the learned zone information, zone 2 in this case, to the running configuration.
When zone 3 is created, added to the zoneset, and that zoneset is activated, the configured zoneset
information is pushed to the other switch. If zone 2 has not been copied from residing in memory to
copied into the running configuration, zone 2 information is not pushed back out.
Referring back to the three entities of configuration, they are as follows on zone 1 before the zone
merge:
 Saved configuration: nothing since zone information has not been saved by issuing the copy run
start command.
 Running configuration: consists of zone 1.
 Configured and learned information: consists of zone 1.
After the zone merge, the entities are:
 Saved configuration: nothing has been saved.
 Running configuration: consists of zone 1.
 Configured and learned information: consists of zone 1 and zone 2.
Zone 2 has not become part of the running configuration. Zone 2 has been learned, and is in the
active zoneset. Only when the zone copy active−zoneset full−zoneset vsan 100
command is issued, zone 2 becomes copied from being learned to added to the running
configuration. The configuration looks as follows after the command is issued:
 Saved configuration: nothing has been saved.
 Running configuration: consists of zone 1 and zone 2.
 Configured and learned information: consists of zone 1 and zone 2.
The output below shows the configurations on the two switches. The first output shows the zone
copy active−zoneset full−zoneset vsan 100 command issued before adding another
zone, and when it is not given. In the situation where the command is given, zone 2 is seen in the
show zoneset brief command output. The show zoneset brief command output represents
the running zoning configuration, and the show zoneset active command shows the fusion of the
configured and learned information.

Issue the command on Switch 1 and show result. Create, add, and activate the zone.
Switch#1# sh zoneset brief vsan 100
zoneset name setA vsan 100

retain original - ACT+3 retain copies - ACT+3

 Page 11 of 16

zone zone1
Switch#1# sh zoneset active vsan 100
zoneset name setB vsan 100
zone name zone1 vsan 100
pwwn 11:11:11:11:11:11:11:11
zone name zone2 vsan 100
pwwn 22:22:22:22:22:22:22:22
Switch#1# zone copy active−zoneset full−zoneset vsan 100
WARNING: This command may overwrite common zones
in the full zoneset
Please enter yes to proceed.(y/n) [n]? y
Switch#1# sh zoneset brief vsan 100
zoneset name setA vsan 100
zone zone1
zoneset name setB vsan 100
zone zone1
zone zone2
Switch#1# sh zoneset active vsan 100
zoneset name setB vsan 100
zone name zone1 vsan 100
pwwn 11:11:11:11:11:11:11:11
zone name zone2 vsan 100
pwwn 22:22:22:22:22:22:22:22
Switch#1# config t
Switch#1(config)# zone name zone3 vsan 100
Switch#1(config−zone)# member pwwn 33:33:33:33:33:33:33:33
Switch#1(config−zone)# exit
Switch#1(config)# zoneset name setA vs 100
Switch#1(config−zoneset)# member zone3
Switch#1(config−zoneset)# exit
Switch#1(config)# zoneset activate name setA vsan 100
Zoneset activation initiated. check zone status
Switch#1(config)# exit
Switch#1# sh zoneset active
zoneset name setA vsan 100
zone name zone1 vsan 100
pwwn 11:11:11:11:11:11:11:11
zone name zone3 vsan 100
pwwn 33:33:33:33:33:33:33:33
zone name zone2 vsan 100
pwwn 22:22:22:22:22:22:22:22

retain original - ACT+3 retain copies - ACT+3

 Page 12 of 16

Switch 2 now shows all of the zones after the activation.

Switch#2# sh zoneset active
zoneset name setA vsan 100
zone name zone2 vsan 100
pwwn 22:22:22:22:22:22:22:22
zone name zone1 vsan 100
pwwn 11:11:11:11:11:11:11:11
zone name zone3 vsan 100
pwwn 33:33:33:33:33:33:33:33
What happens if you do not issue the zone copy command?
If the zone copy command had not been issued after the ISL link was established and the zone
merge occurred, zone 2 never gets copied into the running configuration of Switch1. Since a zone
activation pushes the configured zoneset to the other switches, zone 2 is not propagated back out to
Switch 2, and Switch 2 learns a zoneset without zone 2 information.

Do not issue the command. Create new zone, add, and activate zoneset.
Switch#1# sh zoneset brief
zoneset name setA vsan 100
zone zone1
Switch#1# sh zoneset active
zoneset name setB vsan 100
zone name zone1 vsan 100
pwwn 11:11:11:11:11:11:11:11
zone name zone2 vsan 100
pwwn 22:22:22:22:22:22:22:22
Switch#1# config t
Enter configuration commands, one per line. End with CNTL/Z.
Switch#1(config)# zone name zone3 vs 100
Switch#1(config−zone)# member pwwn 33:33:33:33:33:33:33:33
Switch#1(config−zone)# exit
Switch#1(config)# zoneset name setA vs 100
Switch#1(config−zoneset)# member zone3
Switch#1(config−zoneset)# exit
Switch#1(config)# zoneset activate name setA vs 100
Zoneset activation initiated. check zone status
Switch#1(config)# exit
Switch#1# sh zoneset brief
zoneset name setA vsan 100
zone zone1
zone zone3
Switch#1# sh zoneset active
zoneset name setA vsan 100
zone name zone1 vsan 100
pwwn 11:11:11:11:11:11:11:11

retain original - ACT+3 retain copies - ACT+3

 Page 13 of 16

zone name zone3 vsan 100

pwwn 33:33:33:33:33:33:33:33

Switch 2 before and after the zoneset activation on Switch 1.

Before Activation
Switch#2# sh zoneset active
zoneset name setB vsan 100
zone name zone2 vsan 100
pwwn 22:22:22:22:22:22:22:22
zone name zone1 vsan 100
pwwn 11:11:11:11:11:11:11:11
After Activation
Switch#2# sh zoneset active
zoneset name setA vsan 100
zone name zone1 vsan 100
pwwn 11:11:11:11:11:11:11:11
zone name zone3 vsan 100
pwwn 33:33:33:33:33:33:33:33

Recovery
If you do not issue the command on Switch1 before creating, adding the zone to the zoneset, and
activating the zoneset, you end up with zone 2 not in the active zoneset on both switches. Devices
configured to be active in zone 2 are not be able to access storage resources. To recover zone 2,
shut the ISL link between the switches down, and activate the original zoneset in Switch 2. Then,
bring the ISL link back up.
Shut the ISL link down on Switch 2 and activate original zoneset.
Switch#2−1# config t
Enter configuration commands, one per line. End with CNTL/Z.
Switch#2−1(config)# interface fc2/5
Switch#2−1(config−if)# shut
Switch#2−1(config−if)# exit
Switch#2−1(config)# exit
Switch#2−1# sh zoneset brief
zoneset name setB vsan 100
zone zone2
zoneset name setA vsan 100
zone zone1
zone zone3
Switch#2−1# config t
Enter configuration commands, one per line. End with CNTL/Z.
Switch#2−1(config)# zoneset activate name setB vs 100
Zoneset activation initiated. check zone status
Reactivate the ISL link and allow zone merge to occur.
Switch#2−1(config)# interface fc2/5
Switch#2−1(config−if)# no shut

retain original - ACT+3 retain copies - ACT+3

 Page 14 of 16

Switch#2−1(config−if)# exit
Switch#2−1(config)# exit
Switch#2−1# show zoneset active
zoneset name setB vsan 100
zone name zone2 vsan 100
pwwn 22:22:22:22:22:22:22:22
zone name zone1 vsan 100
pwwn 11:11:11:11:11:11:11:11
zone name zone3 vsan 100
pwwn 33:33:33:33:33:33:33:33

Graphical Representation of Zoning Behavior

retain original - ACT+3 retain copies - ACT+3

 Page 15 of 16

If you do not issue the zone copy command, the zone activation behaves as shown below.

retain original - ACT+3 retain copies - ACT+3

 Page 16 of 16

Commands
This command was introduced in 1.0.4 SAN−OS to automatically propagate active zoneset:
zoneset distribute full vsan <#>
This will automatically propagate and copy the active zoneset to the full zoneset on each switch
whenever there is a change to the active zoneset. This command must be explicitly enabled on each
VSAN on every switch to function correctly.
This eliminates the need to do a zone copy prior to making zoning changes on any switch in the
fabric. It is still necessary, however, to issue the copy running start command to save to full
zoneset in NVRAM prior to rebooting the switch.

retain original - ACT+3 retain copies - ACT+3