ViPR SRM and Brocade switch names

SRM doe snot collect the switch name today, but it will collect the chassis name if you set it, which should make it easy to identify the switches. 

Any idea where the chassis name is set for the Brocade switches?

Somewhere in Device Manager or BNA? I went looking for that name match but no luck so far.

If I find it later I’ll report back to the thread here.

--

Todd Larson | Professional Services, World Wide Technology

todd.larson@wwt.com | Mobile: 214.394.4860

This has been a problem since day one which makes no sense to us. We reported this problem via our PS resource over a year ago and still to this day 3.7 has no such user-friendly names in "most" of the built in metrics or reports. There are "some" however where you CAN see that SRM is getting the user-friendly names, but for whatever reason, the most commonly used reports and displays leave this out, requiring the secret decoder ring to transpose all the switches from the obscure name to something we can recognize as humans. This is a drag to say the least.

I understand your frustration.  It is not a simple fix to get the switch name via SMI.  Brocade has indicated it will be available via their new REST API, but that has been slower in coming than they originally thought. 

What you're seeing in the reports must be the chassis name?  If so, we might be able to modify the built-in reports to use that (or offer it as an option) instead.

Dan

Agreed. My customers certainly don’t like looking at the Switch WWN when they’ve been used to seeing a friendly alias from the other Brocade tools.

--

Todd Larson | Professional Services, World Wide Technology

todd.larson@wwt.com | Mobile: 214.394.4860

Well, the best example I can give is not specifically under the Report Library for Brocade FC Switch, but when you Explore | Storage Connectivity | Fabrics – voila – all the switch names are there and easily digestible. So, it figures out all the topology and such “somehow” via SMS as we are not using SNMP for anything, and yet the reports (under the library) are generally useless with regards to publishing them and having them be digestible by mere mortals.

The Logical Switch Name(s) are in the database obviously, so why the reports use the “incorrect” Switch Name for the lot, well, that is baffling.

Thanks Dan

We've been fighting with the same issue. We have gone through a few steps to address this and get useful names into reports. First off we went back and updated the Chassis Name on all our switches to match the switch name. This allowed us to get the strange mashup in ViPR SRM of the "switchname" & "WWN". Then I use Data Enrichment to tag all the data coming in with an additional property which is the actual switch name. Unfortunately there is some manual work to keep the data enrichment tagging up to date as it requires an entry for each switch. It looks for the mashup name as the key and adds the "swfrname" property when it finds it. Right now I have 60 names to search for and translate. I'd hate to try and maintain it in a larger environment. Thankfully our larger fabrics are using high density 8510-8 directors.

We set it directly on the switch. If there is a way to do it through BNA we didn't find it. One of my guys wrote a script to log into each of the switches through SSH and update the chassis name to match the switch name

Yeah, it’s simply the command “chassisName thename”.

Interestingly enough, after setting a few of these names in our lab switches and re-discovering them in CMCNE, even CMCNE doesn’t reflect the change, at least not “description”. Remains to be seen if SRM will pick this up. It hadn’t even after restarting the collector service.

This tip might help, but I still don’t get why the “switchname” isn’t picket up as-is and used as the identifier.

Ok we found the chassis name for ours and it matches what SRM builds the “name” with, then appends the WWN to it.

We’ll update 1 DCX switch chassis name , then rediscovery and see what happens.

-Todd

Why wouldn’t the switch name be unique when that is the field which is populated when you initially configure the switch?

We’ve never even looked at the chassis name as it seems to not yield what you would want in CMCNE. Changing the chassisname doesn’t seem to be reflected in CMCNE, or I’m missing the field, yet the switch name is the “key” used for managing them in that tool.

Also, the net effect of changing the chassis name once you’ve already discovered them is now I have 2x the number of switches in SRM. It doesn’t seem to link the reports or stats by WWN or SN, only by chassisname? That seems bizarre to us.

Please refer the FAQ document in support zone @  https://community.emc.com/docs/DOC-36040.  First question under "Known behaviors" should answer the query.

If the user has not set the Chassis name on the switch and is having switches with the same model, it would have caused bigger problems if we've not implemented the current behavior.  In that scenario, physical switch's chassis name will return same model name for all the switches.  As switch name is not unique, we'll just show one switch in the UI as all the switch names are same. 

alampk asked me to post this response - he's having issues with the forum:

Regarding displaying 2x the number of switches, yes, SRM would show both the switches in the UI for about 24 hours.  As the old chassis name will not be collected anymore after the change, its respective metrics will go into an inactive state and stop being shown in the reports after 24 hours.

Switch name and Chassis name are different.  CMCNE displays the switch name in its UI.  Chassis name is given for the whole physical enclosure.  In the case of a virtual fabrics environment, the physical chassis will contain multiple logical switches/switches.  Brocade's SMI-S model in combination with the optional feature of setting chassis name on the switch has resulted in showing the physical switch name in the current format in SRM.

As Dan mentioned above, fixing the issue through SMI-S is not easy.

I agree that the doubling of count does resolve itself after 24 hours. But that doesn't fix the fact that you lose all history from the point you switch over. I understand there are challenges for product engineering, but there are challenges for customers too... and we are the ones paying to use the product.