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.

Example

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.

Regards,

Erwin