A Twitter conversation I had a while ago discussed the merits of learning the NX-OS CLI. A friend who is a consultant was talking about installing Fabric Manager/Device Manager on his laptop and having to use it with the different versions of switch code his clients were using. He would not need to use Fabric Manager/Device Manager if he got more comfortable with the CLI.
I have pretty much abandoned Fabric Manager/Device Manager a while ago. For the longest time, I relied upon Fabric Manager’s ease of use. Fire up the GUI, login, pop on an alias and zone, commit and done. I hadn’t really used the CLI since learning about it in class. I quickly found that Fabric Manager was nice when you had to add small set of aliases and zones. It wasn’t so cute when you have to add them en masse or if you had a lab environment where you were constantly creating and removing configs. Recently, we added two new arrays to two 24 node ESX clusters. 4 zones per ESX server. 384 zones total. Had I used Fabric Manager, I’d still be clicking away and adding zones. When you add that much volume, you are bound to have config errors. There simply had to be a better way.
That ‘better way’ became mkzone. You simply fill out a spreadsheet with some basic switch information, device names and pwwn’s, and what you want zoned. Export to CSV and feed it into a script that spits out the config. It even gives you a back out plan. Said configs can then be copied and pasted into Change Management procedures (try that with Fabric Manager). More importantly, when it is ‘go’ time, you can copy and paste into an ssh session. A win all around.
As a commitment to helping others, I can releasing mkzone and its config spreadsheet to the public under the beerware license (you grab it and use it, if you like it and we meet someday, feel free to buy me a beer). That being said, please note that it also comes with no warranty or liability of any kind. Please use at your own risk! I ask that when you use it, please double-check the config BEFORE you press it into production. There will be instances where you will remove some items before you copy/paste, such as already existing aliases.
Some limitations of the script:
- It configures one fabric. You have to do two configs and two separate runs to cover redundant fabrics.
- It is currently works only for Cisco SAN switches running NX-OS. Someday I hope to expand it to include Brocades.
- It is for one VSAN. If you use multiple VSANs, you will need to run this multiple times with separate configs per VSAN.
- It is a Bourne shell script. It will run on unix/linux and its variants (like OSX). If you are using this on a Windows machine, you will need to install something that has Bourne shell. I recommend Cygwin.
- It would be nice someday to run this as a CGI script, hosted somewhere where folks can upload their configs and get the results. If you are interested in hosting it, please contact me.
Here is the explanation for the items in the config spreadsheet:
- SwitchName and VSAN – Pretty self explanatory.
- ZonesetName – The name of the zone set you want to create with the info in the spreadsheet. I like to use dates in the zone set name because then I know when exactly it was created. Also, if I have to back out of my change, I can just reactivate the previous zone set.
- ZonesetClone – If you already have a zone set in use and you are adding zones to that zone set, list that zone set name here. The script output will script out a copy (clone) of that zone set, add your new zones to it and then activate the new zone set. If you are setting up a zone set from scratch (like in a lab), you can just leave NOT_IN_USE on this line.
- ZoneBy – You have the option of zoning by pwwn or devaliases. Either will work. Zoning by devaliases is easier to double-check before you commit although the switch internally will still use pwwn zoning.
The next bit needs its own explanation. This is where you list the devices, their pwwn’s and group them according to how you want them zoned. In the Type column, you list the kind of device it is: array port, server HBA or another switch port. Switch port examples include the port on the other end of an ISL or NPV connection (like from a UCS Fabric Interconnect). You won’t zone switch-to-switch ports but it is nice to have them defined in the device alias database.
The script will match up all of the server ports with its corresponding array port. All servers listed as SERVER1 will be zoned to array ports listed as ARRAY1. SERVER2 servers will be zoned to ARRAY2 ports. And so on. The script creates all zones as single initiator zones. It will loop through all of the servers marked with SERVER1 and zone them to ARRAY1. In my spreadsheet template, server01_hba0 will be zoned to both clariion01_spa0 and clariion01_spb1. It will create them as two separate zones. server02_hba0 will get zoned to clariion01_spb0 and clariion01_spa1.* If you need to zone any SERVER1 server to a second array, you would also add that second array pwwn’s as ARRAY1. All servers that would need to be zoned to ARRAY1 ports would be listed as SERVER1, even though there may be more than one server.
Once you’ve completed your spreadsheet, export it as a CSV file. You will use that CSV file as a config file to the script, mkzone.sh. The syntax of the script is:
./mkzone.sh ./<configfile.CSV>
ie:
./mkzone.sh ./myconfig.csv
The script will send the output right to the screen. You can redirect the output to a file if you’d like:
./mkzone.sh ./myconfig.csv > zoneoutput.txt
Here is a link to the spreadsheet template and mkzone script. Feedback is welcomed!
* Some of you may notice that my example is zoning a server to both SPs of a clariion. This is following the EMC best practice of crisscross zoning (aka mesh zoning). The B side fabric would zone the servers to clariion_spa2, clariion_sp3, clariion_spb2 and clariion_spb3.
sd0a 