Brocade – Alias and Zone syntax. Or how FOS is a love / hate thing.

I’ve been spending a lot of time recently working through some storage performance issues at a client. One of the outcomes of this work was that a serious amount of remediation was required within their two FC fabrics, as they were running a lot of multi-initiator – multi-target zoning and other crazy stuff. I spent a lot of time rebuilding the configs for the Brocade-based fabrics, and had a colleague double-check my work.

Now, for those of you playing along at home, you might remember that I’ve spent the last 7 years or so working primarily on Cisco MDS environments, so doing work with Brocade gear was meant to be a refreshing change. And for the most part it was. In any case, I generated 148 new aliases and 365 new zone sets, and hoped like heck I hadn’t missed anything.

Here’s the syntax of the commands I was using.

alicreate "SAN1_SPA5","50:06:01:65:3e:a0:1e:d7"
alicreate "SAN1_SPB4","50:06:01:6c:3e:a0:1e:d7"
alicreate "A-HOST1_HBA0","20:00:00:00:c9:53:71:ba"
zonecreate "A-HOST1_HBA0_SAN1_SPA5","A-HOST1_HBA0;SAN1_SPA5"
zonecreate "A-HOST1_HBA0_SAN1_SPB4","A-HOST1_HBA0;SAN1_SPB4"
cfgcreate "PROD1","A-HOST1_HBA0_SAN1_SPA5"
cfgadd "PROD1","A-HOST1_HBA0_SAN1_SPB4"
cfgsave
cfgenable "PROD1"

In this example, I’m creating an alias for two FE ports on a VNX and one host port, zoning them together, and creating a new configuration and adding the zone sets to it. The naming convention I generally use is HOSTNAME_HBAx. Nothing spectacular, and it all looks okay in theory. Except when I saved and enable the configuration, a whole bunch of hosts were missing paths. Anyway, great story Dan, but what was the problem?

Dashes.

Seriously, the problem was dashes in the aliases. The CLI was just ignoring them. Change those to underscores and you’re good to go.

Am I overreacting when I feel really disappointed that this is still a thing with FOS 7.x? If someone wants to set me straight I’m happy to hear the whys and wherefores about this. In the end it was all sorted fairly rapidly, and there were no outages which was great.

Updated Articles Page

I’ve added another article to my articles page. This one covers the basics of initial configuration of various FC switches. It’s a little dated in places, but I found it a handy reference when I was deploying a lot of different vendors’ solutions in the field. You may find useful as well.

Cisco MDS 9XXX Basics – Part 1

So we’ve finally started delivering on the project that I’ve been working on for the last 12 – 18 months. It’s fun to see my detailed designs turn into running infrastructure.

As part of this, I’ve been doing some configuration of some new Cisco 9513 and 9124e switches for our fabric. I have every intention of writing a downloadable article with some of the basic stuff, but I thought I’d do a few, smaller articles for my own reference more than anything else.

Now, most Cisco nerds will already know this stuff, but for someone like me who cut their teeth on Brocade Fabric OS, it’s a little different.

To connect to a 9124e (Cisco’s blade switch), I recommend using the HP OA’s serial connection.

Connect to the active OA via serial, login using your normal credentials and run

connect interconnect 3

This will connect you to the serial console of the first 9124e switch in the chassis. This assumes that you have other devices in bays 1 and 2, such as Cisco 3120s, or whatever.

If this is the first time you’ve connected to the switch, or if you’ve not configured it yet, you’ll get to a very useful first setup screen.

Press [Enter] to display the switch console:
  Enter the password for “admin”:
  Confirm the password for “admin”:

         —- Basic System Configuration Dialog —-

This setup utility will guide you through the basic configuration of
the system. Setup configures only enough connectivity for management
of the system.

Please register Cisco MDS 9000 Family devices promptly with your
supplier. Failure to register may affect response times for initial
service calls. MDS devices must be registered to receive entitled
support services.

Press Enter at anytime to skip a dialog. Use ctrl-c at anytime
to skip the remaining dialogs.

Would you like to enter the basic configuration dialog (yes/no): yes

 

  Create another login account (yes/no) [n]:

  Configure read-only SNMP community string (yes/no) [n]:

  Configure read-write SNMP community string (yes/no) [n]:

  Enter the switch name : FCswitch1

  Continue with Out-of-band (mgmt0) management configuration? (yes/no) [y]:

    Mgmt0 IPv4 address : 192.168.0.10

    Mgmt0 IPv4 netmask : 255.255.255.0

  Configure the default gateway? (yes/no) [y]:

    IPv4 address of the default gateway : 192.168.0.254

  Configure advanced IP options? (yes/no) [n]:

  Enable the ssh service? (yes/no) [y]:

    Type of ssh key you would like to generate (dsa/rsa) [rsa]:

    Number of rsa key bits <768-2048> [1024]:

  Enable the telnet service? (yes/no) [n]:

  Enable the http-server? (yes/no) [y]:

 Configure clock? (yes/no) [n]:

 Configure timezone? (yes/no) [n]:

 Configure summertime? (yes/no) [n]:

  Configure the ntp server? (yes/no) [n]:

  Configure default switchport interface state (shut/noshut) [shut]:

  Configure default switchport trunk mode (on/off/auto) [on]:

  Configure default switchport port mode F (yes/no) [n]:

  Configure default zone policy (permit/deny) [deny]:

  Enable full zoneset distribution? (yes/no) [n]:

  Configure default zone mode (basic/enhanced) [basic]:

The following configuration will be applied:
  password strength-check
  switchname FCswitch1
  interface mgmt0
    ip address 192.168.0.10 255.255.255.0
    no shutdown
  ip default-gateway 192.168.0.254
  ssh key rsa 1024 force
  feature ssh
  no feature telnet
  feature http-server
  system default switchport shutdown
  system default switchport trunk mode on
  no system default zone default-zone permit
  no system default zone distribute full
  no system default zone mode enhanced

Would you like to edit the configuration? (yes/no) [n]:

Use this configuration and save it? (yes/no) [y]:

At this point, the switch does a copy run start and reboots. For some reason we’ve been getting this error.

 Error: There was an error executing at least one of the commands
Please verify the following log for the command execution errors.
Disabling ssh: as its enabled right now:
 ssh: Cannot disable both telnet and SSH

I’ve been ignoring this error. So, too, has NX-OS. You’ll then see the following:

Would you like to save the running-config to startup-config? (yes/no) [n]: y

[########################################] 100%

The switch then reboots and you can monitor it for any errors. Once you’re satisfied with the config, use CTRL-SHIFT-_ and press d to disconnect from the 9124e terminal. The process is identical for the Cisco MDS 9513, except for the bit about it being a blade switch :)

What have I been doing? – Part 1

I recently had the “pleasure” of working on a project before Christmas that had a number of, er, interesting elements involved.  During the initial scoping, the only thing mentioned was two new arrays (with MirrorView/Asynchronous), a VMware ESX upgrade, and a few new ESX hosts.  But here’s what there really was:

– 4 NetWare 6.5 hosts in 2 NCS clusters;
– An EMC CLARiiON CX200 (remember them?) hosting a large amount (around 5TB) of NetWare and VMware data;
– A single McData switch running version 7 firmware;
– 2 new Dell hosts with incompatible CPUs with the existing 2950 hosts;
– A memory upgrade to the two existing nodes that meant one host had 20GB and the other had 28GB;
– A MirrorView target full of 1TB SATA-II spindles;
– A DR target with only one switch;
– Singley-attached (ie one HBA) hosts everywhere;
– An esXpress installation that needed to be upgraded / re-installed;
– A broken VUM implementation.

Hmmm, sound like fun? It kind of was, just because some of the things I had to do to get it to work were things I wouldn’t normally expect to do.  I don’t know whether this is such a good thing.  There’re a number of things that popped up during the project, each of which would benefit from dedicated blog posts.  But given that I’m fairly lazy, I think I’ll try and cram it all into one post.

Single switches and single HBAs are generally a bad idea

<rant> When I first started working on SANs about 10 minutes ago, I was taught that redundancy in a mid-range system is a good thing. The components that go into your average mid-range systems, while being a bit more reliable than your average gamedude’s gear, are still prone to failure. So you build a level of redundancy into the system such that when, for whatever reason, a component fails (such as a disk, fibre cable, switch or HBA), the system stays up and running. On good systems, the only people who know there’s a failure are the service personnel called out to replace the broken component in question. On a cheapy system, like the one you keep the Marketing Department’s critical morning tea photos on, a few more people might know about it. Mid-range disk arrays can run into the tens and hundreds of thousands of dollars, so sometimes people think that they can save a bit of cash but cutting a few corners by, for example, leaving the nodes with single HBAs, or having only one switch at the DR site, or using SATA as a replication target. But I would argue that, given your spending all of this cash on a decent mid-range array, why wouldn’t you do all you can to ensure it’s available all the time? Saying “My cluster provides the resiliency / We’re not that mission critical / I needed to shave $10K off the price” strikes me as counter-intuitive to the goal of providing reliable, available and sustainable infrastructure solutions. </rant>

All that said, I do understand that sometimes the people making the purchasing decisions aren’t necessarily the best-equipped people to understand the distinction between single- and dual-attached hosts, and what good performance is all about. All I can suggest is that you start with a solid design, and do the best you can to keep that design through to deployment. So what should you be doing? For a simple FC deployment (let’s assume two switches, one array, two HBAs per host), how about something like this?

Zoning

Notice that there’s no connection between the two FC switches here. That’s right kids, you don’t want to merge these fabrics. The idea is that if you munt the config on one switch, it won’t automatically pass that muntedness on to the peer switch. This is a good thing if you, like me, like to do zoning from the CLI but occassionally forget to check the syntax and spelling before you make changes. And for the IBM guys playing at home, the “double redundant loops” excuse doesn’t apply to the CLARiiON. So do yourself a favour, and give yourself 4 paths to the box, dammit!

And don’t listen to Apple and get all excited about just using one switch either – not that they’re necessarily saying that, of course … Or that they’re necessarily saying anything much at all about storage any more, unless Time Capsules count as storage. But I digress …