« Hard zoning versus soft zoning in a FC/FCoE SAN | Main | Partner Mac Address: 00:00:00:00:00:00 »



Feed You can follow this conversation by subscribing to the comment feed for this post.

Stuart Miniman

Congratulations Erik - I know you put a time of energy and passion into this effort. As you said, hopefully customers will help move this from a good idea to real deployments.

Erik Smith

Thanks Stu!

Chris Carter

Congrats Erik (and others). Sounds very useful to me.

Erik Smith

Thanks Chris!


Excellent and interesting work!

Anthony Padula

Hi Erik, quick question about this.

Will the storage port be able to remove peer zones when a WWPN is removed from the masking configuration?

We still have upper limits on the number of zones in the fabric, and since this doesn't actually remove the requirement for the zone, we may still need to remove unused zones. Especially in the case of a VMax, where every host WWPN is added to the masking configuration of every storage port in the masking view, this would actually increase the number of zones in each fabric.

Great work by the way, this will be of great benefit once it becomes widely available.

Erik Smith

Thanks Victor!

Erik Smith

Hi Anthony, great question! Yes, the peer zone will be updated each time the masking configuration changes. Each change could represent the addition or removal of a host WWPN.

Scott DeShong

How often would the array query the NS if a host is masked but is not yet powered on? If the NS doesn't have an entry would the zone still be created or would the array wait until it received an NS response that included the masked WWN? I like the overall idea but I see many organizations looking for the network team to take over SAN switch operations and having a storage admin who may or may not keep a consistent clean environment decide who can talk to what storage could be a scary proposition. I would prefer to see a little more intelligence related to removal of unused or inactive zones.

Willington Echeverri

Great work! Congratulations Erik.

Erik Smith

Hi Scott, thanks for the feedback! The array port pushes peer members out to the switch (using AAPZ) when either:
1) The LUN Mask on the storage port changes; or
2) The array port detects that that current peer zone does not match the current masking database (using GAPZ)

In the situation you are describing, there are at least four different scenarios that need to be considered:
a) The host port has never logged into the array port and its WWPN is not associated with a storage group.
b) The host port has never logged into the array port and its WWPN was manually added to the storage group.
c) The host port was previously logged into the array port and its WWPN is not associated with a storage group.
d) The host port was previously logged into the array port and its WWPN is associated with a storage group.

Scenarios b and d would result in AAPZ being used as soon as the LUN Masking database was updated. See update case 1 above.

Scenarios a and c would result in no peer zone changes being made by the array port.

In regards to house keeping tasks:
When a host adapter is replaced, it’s WWPN will change and this change will need to be reflected in the LUN Masking database, which will in turn be reflected in the peer zone members. In other words the house keeping is done automatically for them.

The peer zone will also be automatically updated if a storage group is destroyed due to a host being decommissioned.

Does the approach described above fully address your concerns?

Erik Smith

Thanks Willington!

mike warner

Nice work Erik! This will resolve a lot of issues in storage networking.

Erik Smith

Hi Mike, thanks!

Scott DeShong

Thanks for the additional information. So if I'm understanding correctly, the array will always implement zones for any defined storage group (configured LUN masking) regardless of host state. The zones will only change when the array masking changes.

How would multiple arrays within the same fabric handle zoning? How would they agree on a common zoneset name? Would the GAPZ only check for zones in the active zoneset that match their respective LUN masking and ignore everything else? Would fabric locking be required to ensure only one array can update the zoneset at any one time?

Thanks again for the great discussion!

Chris Conniff

Great Post Erik, Let's hope that it becomes an approved AND accepted standard. This way anyone that finds current zoning in a SAN difficult could give it a try instead of trying to run OLTP Apps on NFS!

Erik Smith

Hi Scott, thanks for the great questions! These are points that I should have included in the original post.

You’re right; the peer zone members will always match the LUN mask.

In regards to your other points:
1. Multiple arrays: Multiple arrays are allowed and this situation isn’t actually any different from the case where you have multiple ports from the same array attached to the same fabric because as of right now every array port will transmit its own AAPZ.

2. Zone set names: By design the target port doesn’t have any knowledge of the zone set name. The AAPZ simply requests that the fabric add a peer zone to the active zone set.

3. Zone Names: The target can specify any zone name desired, but this could lead to conflicts. As a result, I’m pushing to have EMC Array ports just use the default zone name of X0_'WWPN of principal device'. Since the WWPN of principal device is the same as the WWPN of the target port using the AAPZ and the WWPN is unique, we shouldn’t run into any zone name conflicts.
4. Fabric Locking: The fabric has to be locked every time the active zone set it modified. This is an integral part of the three phase commit used today and was not something that could be changed. As a result, AAPZ commands are accepted by the switch and then added to the active zone set at a later time. The maximum amount of time between the AAPZ accept and when the change will actually take effect is one minute. This one minute time period will allow the switches to coalesce AAPZ requests and it avoids zone set activation storms. In practice, I am expecting the time between AAPZ and activation to be much less than one minute.

Erik Smith

Hi Chris, thanks! Agreed, accepted and requested by our customers is the next hurdle..

Sandeep MP

Congrats :)...
Looking forward to start working on this ..

Kiran Kumar

Its perfect and too interesting..


This is superb Stuff :) .Article was very informative.I have two questions
1.How this is going to work with auto provisioning in VMAX models ?
2.Since zoning is done at storage port level ,does current storage processors support this technology ,i am pretty sure this will create more problems if front end port is dead,either we cant access storage nor we cant do zoning ?


Erik Smith

Hi Sreejith, thanks!

In regards to question 1, the actual implementation details are still being worked out. As soon as I have a better feeling for how this will be integrated into the UI, I will be doing another post.

For question 2, there is nothing to prevent you from making the same storage device visible on multiple interfaces and then using something like PowerPath for load balancing and failover. Also, traditional fabric based zoning will still function as it does today, so you can always fallback to that if necessary.

Regards, Erik


Thanks Eric ,
I'm pretty sure this will be a turn around .I wish you all the best :)

Chris Norris

Great article Erik, I would very much like to see this technology adopted!

Has there been any thought given to how this could play into multi switch fabrics? Would ISL's still be configured by hand or does this contain provisions for switches to identify and proliferate zones to peer switches?

Erik Smith

Hi Chris, thanks!

Since a Peer Zone is literally a zone tagged with a special attribute, it will be automatically distributed throughout the fabric as a part of the zone set / configuratoin just like a traditonal zone would be.

Physical ISLs would still need to be present (and configured) but if you were using VSANs, one could easily imagine a way to automatically configure IVR to allow the connectivity specified by the target. This is actually a very interesting idea...

The comments to this entry are closed.


  • This is not an official EMC blog.
    The opinions expressed here are my personal opinions. Content published here is not read or approved in advance by EMC and does not necessarily reflect the views and opinions of EMC nor does it constitute any official communication of EMC.