Tag Archives: BNA

Brocade Network Advisor vulnerable to SWEET32

OK, OK, don’t panic. In 99.999% of all cases you’re BNA management system is well dug deep inside the datacenter’s behind a fair few layers of firewalls, switch ACL’s and other physical or non-physical borders so bad dudes being able to exploit the vulnerability is relatively unlikely. Just in the event you still want to prevent  from even being remotely possible here is a procedure to remove the underlying issue as well as being able to remove some older, less-secure, protocols.

Continue reading

Brocade Fabric Assist Zones

Huh, what did they come up with now??? A new way of zoning? FCoE zones? Is this the opposite of target initiated zoning??

Well, no, actually nothing of such sort. Brocade abandoned FA and QL zoning over a decade ago but so very rarely I run into it. From a FOS configuration perspective these zone still operate but no management application is able to handle it any more.

Continue reading

Brocade Network Advisor Database access

So every now and then I get the question if it is possible to access the BNA database in order to get info which then can be used to fill an excel spreadsheet for reference purposes. The though process is that often BNA/Storage administrators don’t want server admins to fool around in BNA and accidentally make changes or configuration mistakes but in the same time be able to provide insight in the SAN from a install base and configuration perspective. Although there is nothing wrong with the intent of that thought the method is however very questionable.

Continue reading

Brocade supportsave via BNA or DCFM

If you work with Brocade gear you might have come across their management tool called Brocade Network Advisor. A very nifty piece of software which lets you do almost 99% of all things you want to do with your fabrics whether is FOS or NOS based.

When you work in support you often need logs and the Brocade switches provide these in two flavours: the useful and useless. (ie supportsave vs supportshow respectively)

If you need a reference of your configuration and want to do some checking on logs and configuration settings a supportSHOW is useful for you. When you work in support you most often need to dig a fair bit deeper and thats where the supportSAVE comes into play. Basically it’s a collection method of the entire status of the box including ASIC and linux panic dumps, stack-traces etc. This process runs on the CP itself so its not a screengrab of tekst as you can imagine.

Normally when you collect these you’ll log into the switch and type “supportsave”, fill in the blanks and some directory on your ftp or ssh system fills up with these files which you then zip up and send to your vendor.

If you have a large fabric please make sure you collect these files per switch in a subfolder and upload these seperatly !!!!!

If you are in the luck position you have BNA you also can collect these via this interface. The BNA process will create the subfolders for you and zip these up for later.

When you look in the zip-file you’ll see that  all filenames have the following structure:

“Supportinfo-date-time\switcname-IPaddress-switchWWN\

Obviously if you work on a Windows box to extract all this Windows will create all subfolders for you. Given the fact I do my work on a Linux box I get one large dump of files with the same file-names as depicted above without the directory structure so every files from every switch is still located in the same folder. This is due to the fact Linux (or  POSIX in general) allows the “\” as a valid character in the file name and the “/” is used for folder separation. 🙁

I used to come across this every so now and then and it didn’t anoy me to such an extent to fix it but lately the use of this collection method (BNA style)  seems to increase so i needed something simple to fix it.

Since Linux can do almost everything i wrote this little oneliner to create a subfolder per switch and move all files belonging to that switch into that folder:

1. #!/bin/bash
2. pushd $@
3. for i in `ls`;do x=$(echo $i | awk -F\\ ‘{print $3 }’);y=$(echo $i | awk -F\\ ‘{print $2 }’); mkdir -p $y; mv $i $y/$x; done
4. popd

Link this to a Nautilus-script softlink and a right click in the Nautilus file manager will do the trick for me.

Voila, lots of time saved. Hope it helps somebody.

Cheers,
Erwin

Brocade and the "Woodstock Generation"

I encourage change especially if there are technological advances that improves functionality, reliability, availability and serviceability (or RAS in short). What I hate if these changes increase risk and require a fair chuck of organisational change even more if they amplify each other (like FCoE).

What I hate even more though is for marketing people to take ownership of an industry standard and try to re-brand it for their own purposes and this is why I’m absolutely flabbergasted about Brocades press-release in which they announce a “new” generation of the fibre-channel protocol.

When the 60’s arrived a whole new concept of how people viewed the world and the way of living changed. Freedom became a concept by which people lived and they moved away from the way their ancestors did in previous decades. They’d shed the straitjacket of the early 20th century and changed the world through various parts of life. This didn’t mean they discredited their parents or grandparents or even the generations before, neither did they perceive to be better or different in a sense they wanted to “re-brand” themselves. They didn’t need differentiation by branding, they did it by way of living.

Fibre-Channel has always been an open standard developed by many companies in the storage industry and I’ll be the last to deny that Brocade has contributed (and still does) a fair chunk of effort into the protocol. This doesn’t mean that they “own” the protocol nor does it give them the right to do anything with it as they please. It’s like claiming ownership of print when you’ve written a book.

So lets go back to their press release. In that they announced the following:

Brocade Advances Fibre Channel Innovation With New Fabric Vision Technology



Also Expands Gen 5 Fibre Channel Portfolio With Industry’s Highest-Density Fixed Port SAN Switch and Enhanced Management Software; Announces Plans for Gen 6 Fibre Channel Technology Supporting the Next-Generation Standard

and a little further-up:

Brocade Fabric Vision technology includes:

  • Policy-based tools that simplify fabric-wide threshold configuration and monitoring
  • Management tools that allow administrators to identify, monitor and analyze specific application data flows, without the need for expensive, disruptive, third-party tools
  • Monitoring tools that detect network congestion and latency in the fabric, providing visualization of bottlenecks and identifying exactly which devices and hosts are impacted
  • Customizable health and performance dashboard views, providing all critical information in one screen
  • Cable and optic diagnostic features that simplify the deployment and support of large fabrics

When I read the first line I thought that a massive stack of brocade engineers had come out of a dungeon and completely overhauled the FC protocol stack but I couldn’t be further from the truth. It were not the engineering people who came out of the dungeon but more the marketing people and they can up with very confusing terms like Gen5 and Gen6 which only represent the differences in speed technologies. Where the entire industry is used to 1G,2G,4G,8G and now 16G plus 32G, Brocade starts to re-brand these as GenX. So in a couple of years time you’ll need a cross-reference spreadsheet to map the speed to the GenX marketing terms.

As for the content of the “Fabric Vision technology” I must say that the majority of component were already available for quite a while. The only thing that is actually new is the ability to map policies onto fabrics via BNA to be able to check quickly for different kind of issues and setting which is indeed a very welcome feature but I wouldn’t call this rocket-science. You take a set of configuration options and you distribute this across one or more switches in a fabric and you report if they comply to these policies. The second bullet-point seems to be targeted at Virtual Instruments. From what I know of VI Brocade is still a long way off to be able to displace their technology. Utilities like frame-monitoring do not compete with fc-analyser kind of equipment.

The software side of BNA and VI seems to be getting closer which I do welcome. BNA is getting better and better with each release and closing the gap to tools which provide a different view of problems will certainly be useful. It also prevents the need for polling fabric-entities for the same info.

Bullet point  3 and 5 piggy back on already available features in FOS but now can be utilised to capture these in a dashboard kind of way via BNA. Bottleneck monitoring commands in addition to credit-recovery features plus D-port diagnostics to check on the health of links were already available. The BNA dashboard also provides a nifty snapshot of most utilised ports, port-errors, cpu and memory status of switches etc. This, in theory, should make my life easier but we’ll wait and see.

Don’t get me wrong, I do like Brocade. I’ve worked with their technologies since 1997 so I think I have a fairly good view of what they provide. They provide around 50% of my bread-and-butter these days (not sure if that’s a good thing to say though if you check out my job-title. :-)) but I cannot give them credit for announcing a speed-bump as a new generation of Fibre-Channel nor can I think of any reason of defining a “Vision” around features, functions and options that have been lacking for a while in their product set. I do applaud them for having it fixed though.

From my personal point of view what would be compulsory is to overhaul the FOS CLI. You can argue to take a consistent approach of using the “Cisco” like tree structure which Brocade also uses in their NOS on VDX switches but that doesn’t work for me either. Moving up and down menu trees to configure individual parts of the configuration is cumbersome. What needs to be done is to painstakingly hold on to consistent command naming and command parameters. This, in addition to the nightmare of inconsistent log-output across different FOS version,  is one of the worst parts of FOS and this should be fixed ASAP.

Cheers,
Erwin