Cisco UCS and MDS 9124: SAN zoning made easy

Posted by: admin  :  Category: Networking

So you’ve got one of these nice decent Cisco Unified Computing Systems (UCS) connected to a multi-terabyte storage system?
One of the nasty things to get done is SAN zoning. Unfortunately, Cisco’s UCS doesn’t help much about getting this done automagically on the MDS SAN switches.
This is however no big deal to automate using a little script magic.

Let’s have a quick look at the topology. In a typical UCS environment, all chassis are connected redundantly to two fabric interconnect switches (let’s call them fabric interconnect A and B).
As for the single blade servers, each of them usually gets two virtual FC host bus adapters, fc0 connected to fabric A, fc1 connected to fabric B.
For the “A” side, we use VLAN 4001 on the UCS to carry vsan 101 originating from fc0. On the “B” side, VLAN 4002 is used to carry vsan 102 originativ from fc1.
While fabric interconnect A ist connected to the MDS “A” switch, the fabric interconnect B is connected to the MDS “B” switch respectively.
Since there are two storage systems, each of which has two independet storage controllers, each of the MDS switches is cross-over connected to every storage controller.
This is illustrated in the drawing below:

Diving into deeper detail, let’s check out the end-to-end connectivity from a single blade server to the storage systems. As far as communication in a SAN is concerned, we talk strictly point-to-point here. So for each host bust adapter (fc0 and fc1), we need to add four SAN zones, as there is four point-to-point connections per HBA. Let’s look at the illustration:

Considering the first illustration, where fc0 is connected through fabric A and MDS “A” and fc1 is connected through fabric B and MDS “B”, we can summarize the following SAN zones to be created:

SAN Switch SAN Zone
MDS “A” fc0 to Primary Storage, Controller A0
MDS “A” fc0 to Primary Storage, Controller B1
MDS “A” fc0 to Secondary Storage, Controller A0
MDS “A” fc0 to Secondary Storage, Controller B1
MDS “B” fc1 to Primary Storage, Controller A1
MDS “B” fc1 to Primary Storage, Controller B0
MDS “B” fc1 to Secondary Storage, Controller A1
MDS “B” fc1 to Secondary Storage, Controller B0

In SAN terminology, a “zone” depicts this particular end-to-end connection from the initiator (controller) to the target (HBA).
The end points are determined by the world-wide port-names (WWPN), a “MAC address like” ID.
Multiple zones again build up a so called “zoneset”, which add all the particular zones to a given VSAN.

In terms of the example Above, on every MDS switch we need to add the correspondig FC HBA to the device-alias databases, add four zones per HBA (remember, for end-points to the storage controllers) and make them member of the VSAN zoneset.

Here’s what this would look like on MDS “A” for fc-0:

device-alias database
device-alias name HOST1_fc0 pwwn 20:00:00:25:B5:0A:00:01
device-alias commit
zone name SAN-001_SP-A0__HOST1_fc0 vsan 101
    member pwwn 20:00:00:25:B5:0A:00:01
    member pwwn 50:06:01:60:46:00:00:01

zone name SAN-001_SP-B1__HOST1_fc0 vsan 101
    member pwwn 20:00:00:25:B5:0A:00:01
    member pwwn 50:06:01:69:46:00:00:01

zone name SAN-002_SP-A0__HOST1_fc0 vsan 101
    member pwwn 20:00:00:25:B5:0A:00:01
    member pwwn 50:06:01:60:46:00:00:02

zone name SAN-002_SP-B1__HOST1_fc0 vsan 101
    member pwwn 20:00:00:25:B5:0A:00:01
    member pwwn 50:06:01:69:46:00:00:02

zoneset name FABRIC_A vsan 101
    member SAN-001_SP-A0__HOST1_fc0
    member SAN-001_SP-B1__HOST1_fc0
    member SAN-002_SP-A0__HOST1_fc0
    member SAN-002_SP-B1__HOST1_fc0

On MDS “B” this would look like this:

device-alias database
device-alias name HOST1_fc1 pwwn 20:00:00:25:B5:0B:00:01
device-alias commit
zone name SAN-001_SP-A1__HOST1_fc1 vsan 102
    member pwwn 20:00:00:25:B5:0B:00:01
    member pwwn 50:06:01:61:46:00:00:01

zone name SAN-001_SP-B0__HOST1_fc1 vsan 102
    member pwwn 20:00:00:25:B5:0B:00:01
    member pwwn 50:06:01:68:46:00:00:01

zone name SAN-002_SP-A1__HOST1_fc1 vsan 102
    member pwwn 20:00:00:25:B5:0B:00:01
    member pwwn 50:06:01:61:46:00:00:02

zone name SAN-002_SP-B0__HOST1_fc1 vsan 102
    member pwwn 20:00:00:25:B5:0B:00:01
    member pwwn 50:06:01:68:46:00:00:02

zoneset name FABRIC_B vsan 102
    member SAN-001_SP-A1__HOST1_fc1
    member SAN-001_SP-B0__HOST1_fc1
    member SAN-002_SP-A1__HOST1_fc1
    member SAN-002_SP-B0__HOST1_fc1

After all, that’s not too complicated to understand, is it? Well, at last it’s fairly simple to configure SAN zoning on the MDS switches on the CLI once you get used to it. However, as there is a lot of fiddling around this hosts, HBAs, WWPNs and other abstract stuff, there’s a lot of typing and/or copy-pasting involved, which leaves plenty of room for mistakes.

As such, I’ve written up a little shell script, which eases this process by parsing the UCS configuration to build up the SAN zoning configuration.

This is a fairly straight forward process, since the only thing needed is the FC HBA WWPNs assigned within the UCS.
To get this, login to any of the two UCS fabric interconnects and run this command:

FABRIC-A# show identity wwn | grep fc-fc

This command will filter for assigned world-wide port-names used for fibre-channel interfaces.
You should come up with something like this:

20:00:00:25:B5:0A:02:2F Yes Pool org-root/org-MyOrg/org-VMware/ls-UCS-ESX-C01-005/fc-fc0
20:00:00:25:B5:0A:02:3F Yes Pool org-root/org-MyOrg/org-VMware/ls-UCS-ESX-C01-006/fc-fc0
20:00:00:25:B5:0A:02:4F Yes Pool org-root/org-MyOrg/org-VMware/ls-UCS-ESX-C01-003/fc-fc0
20:00:00:25:B5:0A:02:5F Yes Pool org-root/org-MyOrg/org-VMware/ls-UCS-ESX-C01-004/fc-fc0
20:00:00:25:B5:0A:02:6F Yes Pool org-root/org-MyOrg/org-VMware/ls-UCS-ESX-C01-001/fc-fc0
20:00:00:25:B5:0A:02:7F Yes Pool org-root/org-MyOrg/org-VMware/ls-UCS-ESX-C01-002/fc-fc0
20:00:00:25:B5:0A:02:8F Yes Pool org-root/org-MyOrg/org-Hyper-V/ls-UCS-HPV-C01-005/fc-fc0
20:00:00:25:B5:0A:02:9F Yes Pool org-root/org-MyOrg/org-Hyper-V/ls-UCS-HPV-C01-006/fc-fc0
20:00:00:25:B5:0A:03:AF Yes Pool org-root/org-MyOrg/org-Hyper-V/ls-UCS-HPV-C01-004/fc-fc0
20:00:00:25:B5:0A:03:BF Yes Pool org-root/org-MyOrg/org-Hyper-V/ls-UCS-HPV-C01-002/fc-fc0
20:00:00:25:B5:0A:03:CF Yes Pool org-root/org-MyOrg/org-Hyper-V/ls-UCS-HPV-C01-003/fc-fc0
20:00:00:25:B5:0A:03:DF Yes Pool org-root/org-MyOrg/org-Hyper-V/ls-UCS-HPV-C01-001/fc-fc0
20:00:00:25:B5:0B:00:AF Yes Pool org-root/org-MyOrg/org-Hyper-V/ls-UCS-HPV-C01-006/fc-fc1
20:00:00:25:B5:0B:00:BF Yes Pool org-root/org-MyOrg/org-Hyper-V/ls-UCS-HPV-C01-004/fc-fc1
20:00:00:25:B5:0B:00:CF Yes Pool org-root/org-MyOrg/org-Hyper-V/ls-UCS-HPV-C01-005/fc-fc1
20:00:00:25:B5:0B:00:DF Yes Pool org-root/org-MyOrg/org-Hyper-V/ls-UCS-HPV-C01-002/fc-fc1
20:00:00:25:B5:0B:00:EF Yes Pool org-root/org-MyOrg/org-Hyper-V/ls-UCS-HPV-C01-003/fc-fc1
20:00:00:25:B5:0B:00:FF Yes Pool org-root/org-MyOrg/org-Hyper-V/ls-UCS-HPV-C01-001/fc-fc1
20:00:00:25:B5:0B:01:4F Yes Pool org-root/org-MyOrg/org-VMware/ls-UCS-ESX-C01-005/fc-fc1
20:00:00:25:B5:0B:01:5F Yes Pool org-root/org-MyOrg/org-VMware/ls-UCS-ESX-C01-006/fc-fc1
20:00:00:25:B5:0B:01:6F Yes Pool org-root/org-MyOrg/org-VMware/ls-UCS-ESX-C01-003/fc-fc1
20:00:00:25:B5:0B:01:7F Yes Pool org-root/org-MyOrg/org-VMware/ls-UCS-ESX-C01-004/fc-fc1
20:00:00:25:B5:0B:01:8F Yes Pool org-root/org-MyOrg/org-VMware/ls-UCS-ESX-C01-001/fc-fc1
20:00:00:25:B5:0B:01:9F Yes Pool org-root/org-MyOrg/org-VMware/ls-UCS-ESX-C01-002/fc-fc1

For my example, this conforms to the given scenario with one node and two FC HBA each. As for the output, to fourth columns shows the name of the assigned service profile name on the UCS blade. So, following up the afore mentioned configuration, this can be used to build up descriptive names in the SAN zoning configuration.

To work with my script later on, please safe your retrieved list to a temporary directory with the name of “wwnlist”. Please do not use my list from the example above – it won’t be usable for you, as your configuration is very, very likely to be all but different from mine.

Now download my script and extract it to the same location where you saved the “wwnlist” file.
Then open the “” script in your favorite text editor and change the variables to reflect your environment. The important sections are marked red in the screenshot.

For your convencience and for testing purposes, I’ve added some fake data. But, really, you WILL NEED to change these in each and every case to get a working configuration.
After you have done so, run the script:


If you receive an error message stating that “wwnlist” was not found (“cat: wwnlist: No such file or directory”), then make sure, that you stored your wwnlist file in the same directory as the script itself. I didn’t do much error checking on this 😉

Upon a successful run, the script will produce two blocks of output, one for each of the two MDS switches. You can simply copy-paste these into your MDS.

... config output follows here ...

... config output follows here ...

Please note that you may need to redistribute the changed zoneset manually after importing the configuration. The script does not take care about this!
If I had to do it on my switches, it’ll look like this:

MDS-A# zoneset distribute full vsan 101
MDS-B# zoneset distribute full vsan 102

Comments are closed.