Finding Stale Brocade Zone Configurations

I recently wrote about a situation where I was creating a zoning configuration and had to figure out which fiber channel devices were active.  After we finished that project, we decided that we should go through and actually remove the inactive aliases and zones.  We had a list of active devices, so we were all ready to move forward and say "delete everything that isn't on this list!".  That'll work great, right?

Of course not; we needed the opposite.  "Delete everything that is on this list" is a far better instruction that is way less likely to lead to painful mistakes.  Even better is "run these commands to delete all of these unnecessary objects" and I know one good way to generate such a list of commands: a script (I feel like I'm developing a battle-cry...).

I put together a script that does a few basic things.  First, it uses the nsshow command to get a list of all of the active WWNs on a given Brocade fiber switch.  Then, it compares all of the defined aliases against that list of active WWNs, flagging any aliases that are not active.  Next, it looks for any zones that are defined that use those stale aliases, so that it can flag them for deletion, too.  After all, if there's a zone with a stale initiator and a valid target, that's a stale zone config.  Same thing for the inverse; if either the target or the initiator are stale, the whole thing's stale.

And that'll work fine, as everyone uses 1:1 target:initiator zoning configurations, right?  I wish.  So, I can't just assume that any zone that contains at least 1 stale alias is a stale zone, for what happens if I have a valid Initiator, a stale Target and a valid Target?  That zone is still really important!  So, the script reports a zone's "staleness" as being one of three states: True, False or Suspect.

An object that has a stale rating of True is most probably really a stale object.  That means that it's an alias with a WWN that's not checked in, or it's a zone with no more than 1 active alias.  A zoning relationship between an active alias and itself isn't really facilitating any communication.

An object that has a stale rating of False is most probably really an active object.  That means that it's an alias with a WWN that is checked in, or it's a zone with no stale aliases.  If the zone has no stale aliases, that tells me that it's still functioning as designed and is actively facilitating communication between all of its configured devices.

The Suspect rating is only ever assigned to zones.  A zone is Suspect if it contains 2 or more Active aliases, and 1 or more Stale aliases.  In this case, the zone is facilitating some some form of active communication between devices, however it also contains some unnecessary configuration.  Basically, someone needs to look at Suspect zones to determine if they should be removed entirely or if they just need to have the stale aliases removed from them.

After the script has categorized all of the objects that it found in the configuration, it then generates recommended CLI commands to delete the objects that it thinks are either Stale or Suspect.  If you actually need to keep any of those Suspect zones, don't delete them.  In fact, triple check the script's findings before you execute any of those delete commands, and make sure that you've got a backup of your switch configurations before making any changes!

So, that leaves the question of how to use the script.  It's pretty easy - I just do the following:

$results = .\Get-StaleBrocadeConfigs.ps1 -user <username> -switch <switch IP> -password <password>

The script will check to make sure that plink is available and will then use it to SSH into the specified switch using the specified credentials.  It will then spit out its results, which I'm capturing in the $results variable.  That variable will be filled with an array of objects, with properties that reveal all of the configurations that it found as well as if each one is stale, an appropriate cleanup command and any notes that might be helpful for Suspect zones.

As always, this script is provided as-is; pay extra attention to validating these results before acting on them!  Zoning mistakes can be highly disruptive; this script should do a pretty good job of identifying stale zones, but make sure that you're 100% confident in the results before acting on them!


Popular posts from this blog

Orphaned VMDK Files

Migrating from one vCenter to Another, Improved

Copying VM Folders and Permissions from One vCenter to Another