Guest

Cisco MDS 9000 Series Multilayer Switches

Zoning Two MDS Switches After Connecting with an ISL or EISL Link

Document ID: 46202

Updated: Jan 18, 2006

   Print

Introduction

This document 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.

Before You Begin

Conventions

For more information on document conventions, see the Cisco Technical Tips Conventions.

Prerequisites

Readers of this document should be knowledgeable of:

  • configuring zoning on the Cisco MDS 9000 series switches

  • cabling and configuring an (E)ISL trunk between Cisco MDS 9000 switches

Components Used

This document is not restricted to specific software and hardware versions.

The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.

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 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 zon e3 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 
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. 
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 
  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

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 

  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 
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

zoning_switches-1.gif

zoning_switches-2.gif

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

zoning_switches-3.gif

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.

Related Information

Updated: Jan 18, 2006
Document ID: 46202