1 Nickel

Zoning Best Practice?

Just wondering how other folks are doing their zoning.

Is it better to use a single initiator/single target or single initiator/multiple target when creating a zone?


ESXi host has HBA1 and HBA2

Two Brocade 6520 FC switches (two fabrics): SW1 and SW2

EMC VMAX with eight FC ports (1-4 on SW1 and 5-8 on SW2)

Create four zones on SW1: one for each initiator/target pair

Create four zones on SW2: one for each initiator/target pair.

Total of eight zones.


Create one zone on SW1: one initiator and four targets

Create one zone on SW2: one initiator and four targets

Total of two zones

For 30 hosts, that's 240 zones versus 60 zones.

Thanks in advance for any feedback.

Labels (1)
0 Kudos
1 Nickel

Re: Zoning Best Practice?

Always better

Single target single initiator

This will be best practice cuts down on rscn traffic

Sent through the clouds from EMC

2 Iron

Re: Zoning Best Practice?

In my experience, the biggest drawback of single initiator/multiple target zoning is that if you have any FC issues whatsoever it will be suggested as a possible cause, and it will side-track and slow down the proper diagnosis and correction of your real issue.

Which is like arriving at the emergency room with arterial bleeding and being handed a clipboard full of forms you need to fill out before they will treat you.

It is best to make single target single initiator zones from the start, and avoid the possibility of any future inconvenience.

2 Iron

Re: Zoning Best Practice?


In principle single hba / target zoning, for obvious reasons.

But you are using a DS-6520B, so you should be able to upgrade to FOS 7.4. And FOS 7.4 can use "peer zones". these are zones, with single initiator / multiple targets. This is all described on page 351 of the FOS 7.4 Administrator guide, downloadable from the EMC support site.



Peer Zoning allows a "principal" device to communicate with the rest of the devices in the zone. The

principal device manages a Peer Zone. Other "non-principal" devices in the zone can communicate with

the principal device only; they cannot communicate with each other.


This will give you easier zoning and less RSCN, to the other devices in the zones.

I believe this is your best option.

Best Regards,


6 Gallium

Re: Zoning Best Practice?

The same functionaly that Ed describes for Brocade exists on Cisco too. It's called Smart Zoning, it can be enabled on the fly on per VSAN bases.  Something to consider for shops running MDS (not available on Nexus).

1 Copper

Re: Zoning Best Practice?

One issue with the single-initiator single target is that in a large environment with multiple arrays is that you might hit the maximum number of zones limit. 8000 per VSAN, or 8000 total for the MDS 9509/9513 switch if you have multiple VSANS.   Multiple arrays can have many targets what with FAs or SP ports, and if you have hosts that need to hit all it your arrays then zones can add up fast.
0 Kudos
5 Tungsten

Re: Zoning Best Practice?

One smart zoning blog post coming up! (tomorrow afternoon)

Watch out for it on!

2 Iron

Re: Zoning Best Practice?

I was planning to upgrade from 7.2 to 7.4 in the near future, just to level up.  But after reading your post I am now relatively excited about doing that.

I don't have a huge environment, but I do do have both storage that serves 30 or more hosts, and hosts that are attached to 10 or more storage units with the result that each of my two primary fabrics has ~1600 zones in it.

Peer zoning looks like it would drop that to around 120.  I'd end up making one zone for each storage unit port, and assigning the appropriate hosts as peers.  The storage end is far less volatile (I install and keep units for 5-6 years versus 2-4 years for hosts recently), so I will be modifying zones regularly, but only adding/subtracting them when storage units come and go.

I like that idea...a lot.

1 Nickel

Re: Zoning Best Practice?

Smart zoning and Peer zoning should both work well.  A couple of points:

1) From an Initiator's point of view, it will not be able to tell whether it's in multiple single initiator / single target zones or one single initiator / multiple target zone.  When it queries the name server it will get back a list of FCIDs and there is no way for it to tell based on this list how the zoning was done.

2) From a Target's point of view, the target will notice a difference if SIST is used because when it is, the response to a NS query will contains fewer FCIDs.  This means that each target will place less of a load on the NS (no queries about other targets) and overall this is good for fabric stability.

That having been said, given the average size of our customer's fabrics, either SIST or SIMT will work fine in the vast majority of cases.

The only downside to either Smart or Peer Zoning is that you still need to create the zones manually and this is where Target Driven Zoning will help.

If you're interested in more detail about zoning in general, see this blog post.   

2 Iron

Re: Zoning Best Practice?

I played with peer zoning a bit, but ran into a significant downside:

From the FOS Administrators guide (pp 356)

Peer Zones are configured and managed using zone commands with the



In the Peer Zone, devices must be identified as either WWN or D,I devices. Mixing WWN and D,I

device identification within a single Peer Zone is not allowed. Aliases are not supported as devices for

a Peer Zone. 


If you have a large and complex environment, then aliases are pretty much essential to keeping things clear and readable.  Maintaining peer zones, when they are just a pile of WWNs, is going to be a difficult, and error prone, undertaking.

0 Kudos