Time to rethink your zoning strategy –peerzones

With the advance of the FC-GS and FC-SW protocols the change, or more the enhancement, of being able to use Target Driven Zoning provided Brocade with the option to tinker a bit on the implementation of the functionality.

As I explained briefly in a post (here) as of FOS 7.4.0 you are able to utilize two new sorts of zoning.

  1. Peer zoning
  2. Target Driven Zoning.

Peer zoning is basically the same as a TDZone with the exception that it is a manual configuration where you have to add member to a peer-zone via cli or BNA whereas TDZ allows a storage array (or other target) to do that. For TDZ you need support in the firmware of the target otherwise nothing happens.

For two decades the rule-of-thumb/best-practice was to have single initiator zoning, meaning you would zone a WWN (or domain/port ID) of an HBA (initiator) to an array or tape (target) counterpart.

Reasoning was, and still is,  that it prevented HBA’s to “see” each other on a fabric which could have a nasty side effect that if the hosts behind an HBA accepted a login from some other HBA it could potentially present its local disks to that other machine with all sorts of nastiness following. A second reason was to prevent, so called, RSCN storms. An RSCN (Registered State Change Notification) is an ELS frame send by the switch, which tells a connected device something has changed in the connectivity map which may be of influence and therefore it should start investigating if that was the case. That connected device would then start polling the nameserver to see if already known devices have dropped off and thus it could no longer talk to, or if any new devices where added to which it should start sending port-login/process-login frames. As you can imagine if zones are created with a large amount of devices, or zoning is not applied at all, the number of these RSCN’s and subsequent “inventory/connect” frames grow exponentially which might have an adverse effect on overall fabric operations, performance and even significant outages may be observed.

If you have a single initiator zones you will prevent this from happening as only one device will be notified if its zone-counterpart is going offline or online. The drawback of this is that the administrative overhead becomes rather large and creates room for errors. Second to that is the issue when you have a large number of devices in your fabric the zoning database may grow to a size which may not be supported by a previous generation of switches. This then leaves you stuck to a point where you cannot grow or you have to adjust your architecture where you have to either split fabrics or use methods like fibre-channel routing (FCR)

To overcome that you can now create a new zone type called a “peer-zone” where you define a single principal member to which other zone-members can connect. These other zone-members remain isolated from each-other so when they come online they will not only just receive the fabric ID of the principle member but any rogue frame it may send out will be discarded by the ASICs ingress port right away.


Just to show an small example of some numbers you will save in administrative overhead.

To show a small fabric with only 50 initiators and 10 targets plus a fan-in ratio of 5:1 you only need 60 zones. Grow to a fabric that has 300 target and 1200 initiator ports even increasing the fan-in ratio to 10:1 and each initiator is indeed mapped according to this ratio, you need to create 30*1200 zones equaling to 36000 zones to uphold the “single initiator to target” mapping.

With peer zoning you just create 300 zones and define the 300 target WWN’s as a principal and your done. Based upon needs you simply add or remove a member (either WPN or pre-defined alias) into a peer zone, enable it, done. As you can see this not only saves a huge amount of administrative overhead but also drastically reduces the change of human error.

As a simple check on your current fabric issue the cli command “zone –validate” and check how many WWN’s (or port ID’s) show up with an “*” behind it. These are entries in the zone database and active configuration but are not logged in anywhere in the fabric.

I hope this has convinced you to upgrade your fabric to FOS 7.4.x and convert your zoning methodology to peer zoning.





Print Friendly, PDF & Email

Subscribe to our newsletter to receive updates on products, services and general information around Linux, Storage and Cybersecurity.

The Cybersecurity option is an OPT-OUT selection due to the importance of the category. Modify your choice if needed.

Select list(s):

5 responses on “Time to rethink your zoning strategy –peerzones

  1. pvwoude


    Does the entire fabric have to be running FOS 7.4.x before you can use TDZ? I have some old brocade 4020 in ibm blade chassis’, that are stuck at 6.2.2.


    1. Erwin van Londen

      Yes, the entire fabric need to have that installed. It has to do with the way the CAM tables are programmed in the ASIC and that code is simply not available in older code levels.

  2. Stephen Bracken

    I am currently using peer zoning in some of my development environment fabrics and it is a really great addition and one that should have been implemented a long time ago.
    The one major problem with peer zoning in its current format or at least in Brocades implementation of it, is that it will not allow the use of aliases. Which I’m sure you’ll agree, increases the administrative burden that it was meant to ease and reduces user friendliness .
    I can only hope this gets resolved in the very near future before I will consider the migration of zones from traditional to peer in my production environment.

    1. Erwin van Londen

      Hi Stephen,

      I agree that the use of aliases would have been a nice addition. You have to remember though that peer-zoning is simply piggy-backing on TDZ actually being the underlying idea. You don’t need any administration for that on the switches as it is the arrays who will add and remove zone-members as needed. Peer-zoning is in my view a simple intermediate step until all the array vendors start supporting TDZ.

    2. Erwin van Londen

      Hello Stephen,

      A short followup on your comment above. As you may have seen Brocade added the alias naming convention to the peer zoning functionality in FOS 8.1.0. You just have to wait a short time now till the OEM’s have qualified this version.

      Hope this helps.