Zoning Brocade switches: Putting it all together

I wanted to conclude my Brocade zoning posts by discussing a couple of best practices. Two issues I have seen in the real world are inconsistent and non-descriptive names, and a lack of configuration backups. Using descriptive names such as “Fabric1Switch1Port8” or “AppServer1Port1” makes the output quite a bit more readable, which is extremely helpful when you are trying to gauge the impact of a faulty initiator or SFP at 3am.

Backing up the configuration on a switch is super easy to do, and there are a number of tools available to automate this process (I have written pexpect scripts to do this). To perform a manual backup of a switch configuration, you can run the “configupload” utility:

Fabric1Switch1:admin> configupload
Server Name or IP Address [host]:
User Name [user]: matty
File Name [config.txt]: switch1config.txt
Protocol (RSHD or FTP) [rshd]: ftp
upload complete

This will prompt you for the IP of a server to write the configs to, as well as the name of the file to write the configuration to. I have thoroughly enjoyed working with Brocade switches over the past few years, and really enjoy the simplicity and power that they provide in their CLI. Nice!

Zoning Brocade switches: Creating configurations

I’ve previously talked about creating Brocade aliases and zones, and wanted to discuss zone configurations in this post. Brocade zone configurations allow you to group one or more zones into an administrative unit, which you can then apply to a switch. Brocade has a number of commands that can be used to manage configurations, and they start with the string “cfg”:

cfgadd – Add a member to the configuration
cfgcopy – Copy a zone configuration
cfgcreate – Create a zone configuration
cfgdelete – Delete a zone configuration
cfgremove – Remove a member from a zone configuration
cfgrename – Rename a zone configuration
cfgshow – Print zone configuration

To create a new configuration, you can run the cfgcreate command with the name of the configuration to create, and an initial zone to place in the configuration:

Fabric1Switch1:admin>cfgcreate “SANFabricOne”, “CentOSNode1Zone1”

Once the configuration is created, you can add additional zones using the cfgadd command:

Fabric1Switch1:admin> cfgadd “SANFabricOne”, “CentOSNode1Zone2”

To ensure that your changes persistent through switch reboots, you can run cfgsave to write the configuration to flash memory:

Fabric1Switch1:admin> cfgsave

Starting the Commit operation...
0x102572c0 (tRcs): May  8 08:51:37
    INFO ZONE-MSGSAVE, 4, cfgSave completes successfully.

cfgSave successfully completed

To view a configuration, you can run the cfgshow command:

Fabric1Switch1:admin> cfgshow

Defined configuration:
 cfg:	SANFabricOne	
		CentOSNode1Zone1; CentOSNode1Zone2; CentOSNode2Zone1; 
 zone:	CentOSNode1Zone1	
		CentOSNode1Port1; NevadaPort1
 zone:	CentOSNode1Zone2	
		CentOSNode1Port2; NevadaPort2
 zone:	CentOSNode2Zone1	
		NevadaPort1; CentosNode2Port1
 zone:	CentOSNode2Zone2	
		NevadaPort2; CentosNode2Port2
 alias:	CentOSNode1Port1	
 alias:	CentOSNode1Port2	
 alias:	CentosNode2Port1	
 alias:	CentosNode2Port2	
 alias:	NevadaPort1	
 alias:	NevadaPort2	

Effective configuration:
 cfg:	SANFabricOne	
 zone:	CentOSNode1Zone1	
 zone:	CentOSNode1Zone2	
 zone:	CentOSNode2Zone1	
 zone:	CentOSNode2Zone2	

Now you may notice in the output that there is a defined and effective configuration. The effective configuration contains the configuration that is currently running on the switch, and the defined configuration contains the configuration that is saved in flash. To make the configuration in flash effective, the cfgenable command needs to be run (this should be run after you make alias/switch/configuration changes and issue a cfgsave):

Fabric1Switch1:admin> cfgenable “SANFabricOne”
Starting the Commit operation…
0x1024f980 (tRcs): Apr 29 20:44:39
INFO ZONE-MSGSAVE, 4, cfgSave completes successfully.

cfgEnable successfully completed

Once the cfgenable runs, the effective configuration will be updated to match the configuration you have defined and saved. This completes this part of the Brocade series, and the final installation will cover switch backups and putting all the pieces together.

Zoning Brocade switches: creating zones

I previously talked about creating aliases on Brocade switches, and am going to use this post to discuss zone creation. Zones allow you to control initiators and targets can see each other, which enhances security by limiting access to devices connected to the SAN fabric. As previously discussed, we can assign an alias to each initiator and target. Once an alias is assigned, we can create a zone and add these aliases to it. Brocade managed zones with the zone* commands, which are listed below for reference:

zoneadd – Add a member to an existing zone
zoneCopy – Copy an existing zone
zonecreate – Create a new zone
zoneDelete – Delete a zone
zoneRemove – Remove a one from the configuration
zoneRename – Rename a zone
zoneShow – Show the list of zones

To create a new zone, we can run the zonecreate command with the name of the zone to create, and the list of aliases to add to the zone:

Fabric1Switch1:admin> zonecreate “CentOSNode2Zone1”, “NevadaPort1; CentosNode2Port1”

Once the zone is created, we can view it with the zoneshow command:

Fabric1Switch1:admin> zoneshow “CentOSNode2Zone1”

 zone:	CentOSNode2Zone1	
		NevadaPort1; CentosNode2Port1

Now that we have a zone, we need to add it to the switch configuration and then enable that configuration. I will discuss that in more detail when I discuss managing Brocade configurations.

Zoning Brocade switches: creating aliases

In my previous Brocade post, I talked about Brocade zoning, and mentioned at a high level what is required to implement zoning. Prior to jumping in and creating one or more zones in your fabric, you should add aliases to describe the devices that are going to be zoned together. An alias is a descriptive name for a WWN or port number, which makes your zone configuration much easier to read (if you are the kinda person who can spout off the WWNs of all of the devices in your fabric, you can kindly ignore this post). Brocade switches come with a number of commands to manage aliases, and these commands start with the string “ali”:

aliCreate – Creates a new alias
aliDelete – Deletes an alias
aliRemove – Removes an entry from an alias
aliRename – Renames an existing alias
aliShow – Shows the aliases

To create a new alias, you will first need to locate the WWN(s) or port(s) you want to assign to the alias. The easiest way to do this is by running switchshow on the switch (you can also use the Emulex or QLogic host utilities to gather WWN information):

Fabric1Switch1:admin> switchshow

switchName:	Fabric1Switch1
switchType:	16.2
switchState:	Online   
switchMode:	Native
switchRole:	Principal
switchDomain:	1
switchId:	fffc01
switchWwn:	10:00:00:60:69:c0:32:a4
switchBeacon:	OFF
Zoning:      	ON (Brocade3200)
port  0: id N2 Online         F-Port 10:00:00:00:c9:3e:4c:eb
port  1: id N2 Online         F-Port 10:00:00:00:c9:3e:4c:ea
port  2: id N2 No_Light       
port  3: id N2 No_Light       
port  4: id N2 Online         F-Port 21:00:00:e0:8b:1d:f9:03
port  5: id N2 Online         F-Port 21:01:00:e0:8b:3d:f9:03
port  6: id N2 No_Light       
port  7: id N2 No_Light       

Once you know the port numbers or WWNs, you can run the alicreate command, passing it the name of the alias to create, as well as the port or WWN to associate with the alias (if you assign more than one port or WWN to the alias, they need to be separated with a semi-colon):

Fabric1Switch1:admin> alicreate “CentosNode2Port1”, “21:00:00:e0:8b:1d:f9:03”

After an alias is created, you can view it with the alishow command:

Fabric1Switch1:admin> alishow “CentosNode2Port1”
alias: CentosNode2Port1

If you make a typo while adding a WWN or port to an alias, you can run aliadd to add the correct WWN or port to the alias, and then execute aliremove to remove the entry that was incorrectly added. If you make a typo in the alias name, you can run alirename to rename the entry. That is all for today. In my next blog post, I will talk about how to create zones.

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.

Changing the name of a Brocade switch

When managing large diverse SAN fabrics, it is extremely important to assign a unique and descriptive name to each switch. This descriptive name provides an easy way to determine the purpose of a switch, and is also helpful when debugging problems. To change the name assigned to a Brocade switch, you can use the switchname command:

Switch:admin> switchname

Switch:admin> switchname “Fabric1Switch1”
Updating flash …

Fabric1Switch1:admin> switchname

Switch names should be chosen wisely, especially when dealing with large core/edge fabric topologies.