Quick and Dirty Guide to Zoning Brocade Switch

[Chris_Lionetti]

The first thing you will discover is that there are two different methods to zone the switch, you can use what is called hard zoning which requires you to zone specific ports. You can also use what is called World-wide-Port-Name (WWPN) zoning, in which your WWPN is used to determine which other devices you can see. You can also run a mixed mode in which you use a little of each method.

There is a value to each type of zoning however I recommend using WWPN zoning as it lends itself to better remote support and enhanced automation. To see my reasoning, see the appendix on common support activities, and on automation

You must first consider using real world names and implementing a switch Alias which will simplify future operations. I need to reserve the Hosts Name (netbios name) for the Zone name, use the identifier of HBA and prefix the Hostname.  

Alias Creation

Additionally, the host will contain dual ports, but only one of those ports will be connected to this (current) fabric. To lower the chance of cross-wiring a server, we can simply add both of this hosts WWPNs to the Alias for this server. Care should be taken that a server is connected once to each fabric and not doubly connected to a single fabric.

switch:admin> AliCreate “AzLHost1HBA”, “50:05:07:63:00:c7:01:99; 50:05:07:63:00:c7:01:9A"

I will create this exact alias on both the A and B fabrics, this also simplifies operations, since if I must disconnect this server and reconnect it; I don't have to worry about mixing up the A and B cables.

The format of this command is as follows where “members” can represent many values separated by semicolons;

Alicreate “AliasName”, “members”

 I should note that a single alias can support many WWPNs, so you can create a single port for an entire Target Array or separate them out by controller. Separating them out by controller offers more granular control as a hosts can be set to see only subsets of target ports. Combining these ports to a single alias offers less management tasks and a simpler zone table to worry about.

You can combine them to a single alias as shown below. Note that a WWPN format is a set of 16 bytes, separated by colons into 8 octets (xx:xx:xx:xx:xx:xx:xx:xx), and to add a second WWPN, use a semicolon as a separator ( wwpn1;wwpn2;wwpn3...

switch:admin> AliCreate "AzLHost1HBA", "50:05:07:63:00:c7:01:99; 50:05:07:63:00:c7:01:9A"

Following is if you want to create a single alias for multiple ports

switch:admin> AliCreate AlletraB10KTargets, "10:05:07:63:00:c7:01:99; 50:05:07:63:00:c7:01:00; 10:05:07:63:00:c7:01:9B; 50:05:07:63:00:c7:01:02; 10:05:07:63:00:c7:01:99; 50:05:07:63:03:c7:01:00; 10:05:07:63:00:c7:01:9B; 50:05:07:63:00:c7:01:04"

Or you can use a unique alias for each controller or each target port

switch:admin> AliCreate "AlletraB10KCtrl1A", "10:05:07:63:00:c7:01:99; 50:05:07:63:00:c7:01:00"

switch:admin> AliCreate "AlletraB10KCtrl1B", "10:05:07:63:00:c7:01:99; 50:05:07:63:00:c7:01:00"

switch:admin> AliCreate "AlletraB10KCtrl2A", "10:05:07:63:00:c7:01:99; 50:05:07:63:00:c7:01:00"

switch:admin> AliCreate "AlletraB10KCtrl1B", "10:05:07:63:00:c7:01:99; 50:05:07:63:00:c7:01:00"

The complete list of Alias commands for a Brocade switch are aliAdd, aliCreate, aliDelete,aliRemove, and aliShow

Zone Creation

The zone creation process is very similar to the alias creation process in that the command simply requires the zone name and a list of members. These members can be aliases (recommended) or ports or WWPNs.

switch:admin> ZoneCreate "AzLHost1", "AlletraB10KTargetPorts, AzLHost1HBA"

switch:admin> ZoneCreate "AzLHost2", "AlletraB10KTargetPorts, AzLHost2HBA"

switch:admin> ZoneCreate "AzLHost3", "AlletraB10KTargetPorts, AzLHost3HBA"

switch:admin> ZoneCreate "AzLHost4", "AlletraB10KTargetPorts, AzLHost4HBA"

Again, just as with aliases, you can create a single zone that contains ALL the Azure Local nodes, however you then lack the granularity to be able to troubleshoot problems that only affect a single node. Additionally, most vendors recommend a model called 'Single Initiator Zoning' in which you want to prevent individual HBAs from being exposed to other HBAs. For that reason, the expectation is that you will have the same number of Zones as you have Hosts in your fabric.

switch:admin> ZoneCreate "AzLHost1", "AlletraB10KCtrl1A; AlletraB10KCtrl1B; AlletraB10KCtrl2A; AlletraB10KCtrl2B; AzureLocalHost1HBA"

switch:admin> ZoneCreate "AzLHost2", "AlletraB10KCtrl1A; AlletraB10KCtrl1B; AlletraB10KCtrl2A; AlletraB10KCtrl2B; AzureLocalHost2HBA"

switch:admin> ZoneCreate "AzLHost3", "AlletraB10KCtrl1A; AlletraB10KCtrl1B; AlletraB10KCtrl2A; AlletraB10KCtrl2B; AzureLocalHost3HBA"

switch:admin> ZoneCreate "AzLHost4", "AlletraB10KCtrl1A; AlletraB10KCtrl1B; AlletraB10KCtrl2A; AlletraB10KCtrl2B; AzureLocalHost4HBA"

The commands that are Zone Specific are ZoneAdd, ZoneCreate, ZoneDelete, ZoneRemove, and ZoneShow.

Configuration Creation (ZoneSet)

Creation of a Configuration. Are you starting with a fresh switch with no existing configuration you will need to create a new configuration using the following command. Use the cfgShow command to see if a current configuration exists.

switch:admin> CfgShow

If no configuration exists, use the next command, otherwise use the name of your configuration instead of 'FabricA_CFG' for all future commands. If you want to create a fresh new configuration it needs to contain at least a single zone, so use the following command

switch:admin> CfgCreate "FabricA_CFG", "AzLHost1"

Now that the switch has a configuration, you can add all the required host zones to that configuration. It should be noted that the switch always contains an ACTIVE(effective) configuration as well as a CURRENT configuration. When you issue zoning commands you will be editing the current configuration however those changes will not take effect until you issue the command to enable the configuration. Also note that any changes are NOT saved on the switch and the switch will revert to the older version unless you also save the current configuration.

We now need to add all of the zones that we have created to the current configuration.

switch:admin> CfgAdd "FabricA", "AzLHost1"

switch:admin> CfgAdd "FabricA", "AzLHost2"

switch:admin> CfgAdd "FabricA", "AzLHost3"

switch:admin> CfgAdd "FabricA", "AzLHost4"

Once you have all of the correct zones added to the configuration, you can choose to enable that configuration. The moment that configuration has been enabled, you will find your hosts will be able to communicate with your storage devices.

switch:admin> CfgEnable "FabricA"

You should be able to validate the current configuration by using the following command.

switch:admin> cfgActvShow

If you are satisfied with the current configuration of the switch you want to make sure that you save your changes so that your configuration will return if the switch is rebooted for some reason. The following command will save that configuration

switch:admin> cfgSave "FabricA"

Special Note : The Defined Configuration is the working set that you can modify at will, but is NOT actually running, the effective configuration is what is currently running.

The following list shows useful configuration commands; CfgAdd, CfgClear, CfgEnable, CfgDisable, CfgDelete, CfgSave, CfgRemove and CfgActvShow

Configuration Sample

When the CfgEnable command is run, the switch will resolve the aliases and create the effective configuration without the alias names. The Aliases exist as a convenience on the switch to help you track down which WWPNs belong to which hosts/targets, and to make the effective configuration easier to create without the possibility too hard to spot typographical errors. Below is a sample output of a small fabric cfgShow command.

swtich:admin> cfgShow

Defined Configuration:

cfg:   FabricA

zone:  AzLHost1      10:05:07:63:00:c7:01:99; 50:05:07:63:00:c7:01:00; 10:05:07:63:00:c7:01:99; 50:05:07:63:00:c7:01:00; 10:05:07:63:00:c7:01:9B; 50:05:07:63:00:c7:01:02; 10:05:07:63:00:c7:01:99; 50:05:07:63:03:c7:01:00; 10:05:07:63:00:c7:01:9B; 50:05:07:63:00:c7:01:04

zone:  AzLHost2      10:05:07:63:00:c7:01:9A; 50:05:07:63:00:c7:01:00; 10:05:07:63:00:c7:01:99; 50:05:07:63:00:c7:01:00; 10:05:07:63:00:c7:01:9B; 50:05:07:63:00:c7:01:02; 10:05:07:63:00:c7:01:99; 50:05:07:63:03:c7:01:00; 10:05:07:63:00:c7:01:9B; 50:05:07:63:00:c7:01:04

zone:  AzLHost3      10:05:07:63:00:c7:01:9B; 50:05:07:63:00:c7:01:00; 10:05:07:63:00:c7:01:99; 50:05:07:63:00:c7:01:00; 10:05:07:63:00:c7:01:9B; 50:05:07:63:00:c7:01:02; 10:05:07:63:00:c7:01:99; 50:05:07:63:03:c7:01:00; 10:05:07:63:00:c7:01:9B; 50:05:07:63:00:c7:01:04

zone:  AzLHost4      10:05:07:63:00:c7:01:9C; 50:05:07:63:00:c7:01:00; 10:05:07:63:00:c7:01:99; 50:05:07:63:00:c7:01:00; 10:05:07:63:00:c7:01:9B; 50:05:07:63:00:c7:01:02; 10:05:07:63:00:c7:01:99; 50:05:07:63:03:c7:01:00; 10:05:07:63:00:c7:01:9B; 50:05:07:63:00:c7:01:04

Effective Configuration:

cfg:   FabricA

zone: AzLHost1      AzLHost1HBA; AlletraB10KTargets

zone: AzLHost2  AzLHost2HBA; AlletraB10KTargets

zone: AzLHost3  AzLHost3HBA; AlletraB10KTargets

zone: AzLHost4  AzLHost4HBA; AlletraB10KTargets

alias: AzLHost1HBA   50:05:07:63:00:c7:01:04; 50:05:07:63:00:c7:01:0a

alias: AzLHost2HBA   50:05:07:63:00:c7:01:05; 50:05:07:63:00:c7:01:0b

alias: AzLHost3HBA   50:05:07:63:00:c7:01:06; 50:05:07:63:00:c7:01:0c

alias: AzLHost4HBA   50:05:07:63:00:c7:01:07; 50:05:07:63:00:c7:01:0d

alias: AlletraB10KTargets    10:05:07:63:00:c7:01:9C; 50:05:07:63:00:c7:01:00; 10:05:07:63:00:c7:01:99; 50:05:07:63:00:c7:01:00; 10:05:07:63:00:c7:01:9B; 50:05:07:63:00:c7:01:02; 10:05:07:63:00:c7:01:99; 50:05:07:63:03:c7:01:00; 

Appendix Concerning Port vs WWPN zoning

There are advantages to each type of zoning but consider firstly that in a scale out data centre, that you as the architect/administrator of the solution will likely be required to use on-site personal (smart-hands) that have little knowledge of the architecture to run cables, and connect hardware. Using WWPN zoning is more forgiving. If a server is connected to the wrong switch port, and port zoning is used, unpredictable results can occur, since the zone is based only on the port connected to.

Another advantage of WWPN zoning is that a failed socket on the Fibre Channel Switch can be easily fixed by moving the exiting host from the failed port to any other available port without any zone change.

There are two specific advantages of Port Zoning. If a servers HBA in a server were to fail, and need replacement, that servers’ ports may not change, but the WWPNs of that server would change. In this case a port zoned switch would not need to have its zoning changed, but a WWPN zoned switch would require you to update the Alias to reflect the new WWPNs.

The other advantage of Port Zoning is if you are using the NPIV feature, which allows a HBA to act as a pseudo–Fibre Channel Switch, and allows for the host to offer Virtual Fibre Channel Adapters.  

A final advantage of WWPN zoning vs Port Zoning, is that to create a Port based zone you need to know what the switch domain number (or switch blade) you are on, which prefixes the port number, As an example, your switch domain in number 3, and the port is 7, it would be port “3,7”. When deploying WWPN zoning you only need to know the WWPNs from the hosts and the array target ports, both of which can be obtained via PowerShell or via the GUI.

Fabric Design Requirements

The above recommendations also assume that best practices for Fabric Designs are being deployed. These include that you have two Separate Fabrics which are not connected to each other.

When I refer to a Fabric, I should define terms to ensure clarity. A Single Fibre Channel Switch can be a Fabric, however when you connect an additional Fibre Channel switch these switches will join to create a single Fabric which is served by a single Fibre Chanel Name Service (NS). You refer to unique switches in a single Fabric by their domain ID which must be unique for each fabric.

Best practices are to have two independent fabrics which are not interconnected. If you were to connect these two fabrics, they would no longer be two fabrics but join into a single fabric. For simplicity call them the “Fabric A” and Fabric B” or any such name scheme that differentiates them. The requirement to keep the fabrics separate greatly enhances reliability as a fabric failure, or zoning corruption should only affect a single fabric, and alternate paths will still exist to all hosts and targets.

It is also best practice for the switches to be configured identically. If using WWPN zoning, and you have added both WWPNs for each host and target to the appropriate zones, even the configuration/zoning will be identical. i.e. On Fabric ‘A’ you may have a Configuration which has the exact same list of Aliases and Zones as the alternate Fabric ‘B’. This can greatly reduce service time as if a switch were to fail and be replaced in one fabric, the configuration in whole can be copied from the alternate fabric and work immediately without change.     

[srujan_kumar]

Thank you, @Chris_Lionetti, it gives a clear picture of zoning. There are prerequisites for zoning that one should follow before the zoning process to avoid basic errors.

Regards, 
D Srujan Kumar