Zoning Brocade switches zoning overview


Storage area networks (SANs) are deployed at most larger organizations, and provide centralized administration for storage devices and management functions. When multiple clients are accessing storage resources through a SAN, you need a way to limit which targets and logical units each initiator can see. Typically LUN masking is used on the storage array to limit which initiators can see which logical units, and zoning is used on the SAN switches to limit which initiators can see which targets. In the next five blog posts, I plan to provide a step-by-step guide to zoning Brocade switches.

Brocade zoning comes in two main flavors. There is hard zoning (port-based zoning), which allows you to create a zone with a collection of switch ports. The second zoning method is soft zoning (WWN-based zoning), which allows you to create a zone with one or more WWNs. There are tons of documents that describe why you would want to use each form of zoning. I typically use the following two rules to determine which zoning method I will use:

  1. Will I ever need to move the host to a different switch or port? If so, I will implement soft zoning.
  2. Are there any policies that require me to lock an initiator to a specific port? If so, I will use hard zoning.

I prefer soft zoning, since it provides tons of flexibility when dealing with switch upgrades, faulty SFPs, and defective hardware. But each location has different policies, so it’s best to to take that into account each time you design or implement your zone layout.

To implement zoning on a Brocade switch, the following tasks need to be performed:

  1. Add aliases for each port / WWN
  2. Add the aliases to a zone
  3. Add the zone to a configuration
  4. Save and enable the new configuration

Brocade provides awesome zoning documentation, which you can access though the help and zonehelp commands:

Fabric1Switch1:admin> **zonehelp**

aliAdd Add a member to a zone alias
aliCopy Copy a zone alias
aliCreate Create a zone alias
aliDelete Delete a zone alias
aliRemove Remove a member from a zone alias
aliRename Rename a zone alias
aliShow Print zone alias information

cfgAdd Add a member to a configuration
cfgCopy Copy a zone configuration
cfgCreate Create a zone configuration
cfgDelete Delete a zone configuration
cfgRemove Remove a member from a configuration
cfgRename Rename a zone configuration
cfgShow Print zone configuration information

zoneAdd Add a member to a zone
zoneCopy Copy a zone
zoneCreate Create a zone
zoneDelete Delete a zone
zoneRemove Remove a member from a zone
zoneRename Rename a zone
zoneShow Print zone information

cfgClear Clear all zone configurations
cfgDisable Disable a zone configuration
cfgEnable Enable a zone configuration
cfgSave Save zone configurations in flash
cfgSize Print size details of zone database
cfgActvShow Print effective zone configuration
cfgTransAbort Abort zone configuration transaction

Reading through (i.e., running help ) the help sections prior to implementing your zone layout will save you a lot of hassle, especially when you start to ask yourself questions like “Does cfgremove or cfgdelete remove an entry from a configuration?“. Well, that is all for today. Tomorrow I will discuss aliases, and how to use the ali* commands to create and manage them.

This article was posted by Matty on 2009-05-25 11:15:00 -0400 EDT