Blog O’ Matty

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 <command>) 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.