Whenever you see a leap in a minor version there is a bucket-load of new functions and features in software and FOS 7.4.0 is no exception. Besides the usual bugfixes and snippet enhancements there are a few that I would like to highlight here.
You might have heard about it, maybe not, but it can become a problem if it stings you: “A stuck VC” . So first of all what is it? Well, basically it is a virtual channel on an E-port or back-end port that has depleted the number of credits on one or more Virtual Channels of that port.
I ran into this in my lab when upgrading a switch which caused a fabric-segmentation and obviously the release notes of a previous version show:
Other Important Notes and Recommendations
Management Server Platform Capability support changes in FOS v6.4
FOS v6.4 no longer automatically enables the Management Server (MS) Platform capability when a switch attempts to join a fabric that has these services enabled. This prevents a FOS v6.4 switch from joining such a fabric, and ISL will be disabled with a RAS log message. To allow a FOS v6.4 switch to join such fabrics msPlMgmtActivate command should be used to enable the Management Server platform services explicitly.
If you’re in my business of looking at logfiles to be able to determine what’s going on or what has happened one of the most annoying, and frightening, things to see is a sheer amount of failed login attempts. In most cases these are simply genuine mistakes where a lingering management application or forgotten script is still trying to login to obtain one piece of information or another out of the switch/fabric. The SAN switches are often well inside the datacentre management firewalls so attacks from outside the company are less likely to occur however when looking at security statistics over the last decade or so it turns out that threats are more likely to originate from inside the company boundaries. Employees mucking around with tools like nmap, MITD software like cane & able, or even an entire Kali Linux distro hooked up to the network “just to see what it does because a mate of mine recommended it”. In 99.999% of all install bases I looked at the normal embedded username/password mechanism is used for authentication and authorisation. This also means that if security management is not configured on these switches, a not so good-Samaritan is able to use significant brute force tactics to try and obtain access to these switches without anyone knowing. When using an external authentication mechanism like LDAP or TACACS+ chances are there are some monitoring procedures in place which monitor and alert on these kind of symptoms however the main issue is that the attack has already occurred and there is no mechanism to prevent these sorts of attacks on a level that really protects the switch. It is fairly simple to overload a switch with authentication attempts by firing off thousands of ssh,telnet and http(s) sessions (which is easily done from any reasonable priced laptop these days with a Linux distro like Kali installed) and therefore crippling the poor e500 CPU on the CP. This can have significant ramifications on overall fabric services in that switch which can bring down a storage network. Now, obviously there is a mechanism to try and prevent this via iptables however there are a number of back-draws.
Historically the need to segregate fibre-channel traffic and have the option to prioritize frames and flows has not been high on design agenda of most of the companies I had under my eyes. Most often if the need is there to differentiate between different levels of importance between the various business applications you’ll very often see that additional equipment is purchased and the topologies are adjusted as needed. This obviously works well however when the ratio of capex vs opex is out of balance but the business is still retaining the need for your applications to be separated in order of criticality, you need to consider other options. As in the IP networking world Fibre-Channel has a similar functionality which has been in the FC standards for a long time but only recently has been introduced by some vendors.
This topic is hardly ever touched when fabric designs are developed and discussed among storage engineers but for me this always sits on my TODO list before hooking up any HBA or array port. It is as important in the storage world as it has been in the IP networking sector for decades. Historically the reasoning to not pay attention to this topic was that the SAN was always deeply embedded in tightly controlled data-centres with strict access policies. Additionally the use of fibre-optics and relatively complex architectures to the storage un-inaugurated even more, unfairly, devalued the necessity of implementing security policies.
Let me make one thing clear: Being able to gain access to a storage infrastructures is like finding the holy grail for archaeologists. If no storage infrastructure security is implemented it will allow you to obtain ALL data for good or bad purposes but even worse it also allows the non-invited guest to corrupt and destroy it. With this chapter I will outline some of the procedures I consider a MUST and some which you REALLY should take a good look at and if possible implement them.
In some of my previous articles here and here I explained how to obtain a supportsave via BNA (Brocade Network Advisor) and/or DCFM (Data Centre Fabric Manager) and which one to grab. But what happens if you don’t have BNA or are not able to manage these switches via BNA. The best way to do this is to implement the “supportftp” settings. Continue reading
Obviously when we need to analyze problems we need to have the correct data. No use of looking at tires when your headlight is broke. Continue reading
After a very busy couple of weeks I’ve spent some time to dissect the release notes of Brocade FOS 7.1 and I must say there are some really nice features in there but also some that I REALLY think should be removed right away.
Port Speed Long Short Vendor Serial Wave Temp Current Voltage RX-Pwr TX-Pwr
wave wave number Length
1/0 8G NA 50 m BROCADE UAF11051000039A 850 31 6.616 3273.4 -2.8 -3.3
1/1 8G NA 50 m BROCADE UAF110510000387 850 32 7.760 3268.8 -3.6 -3.3
1/2 8G NA 50 m BROCADE UAF1105100003A3 850 30 7.450 3270.7 -3.3 -3.3 etc....
A couple of months ago Brocade invited me to come to San Jose for their “next-gen/new/great/ what-have-ya” big box. Unfortunately I had something else on the agenda (yes, my family still comes first) and I had to decline. (they didn’t want to shift the launch of the product because I couldn’t make it. Duhhhh.)
So what is new? Well, it’s not really a surprise that at some point in time they had to come out with a director class piece of iron to extend the VDX portfolio towards the high-end systems. I’m not going to bore you with feeds and speeds and other spec-sheet material since you can download that from their web-site yourself.
What is interesting is that the VDX 8770 looks, smells and feels like a Fibre-Channel DCX8510-8 box. I still can’t prove physically but it seems that many restriction on the L2 side have a fair chunk of resemblance with the fibre-channel specs. As I mentioned in one of my previous posts, flat fabrics are not new to Brocade. They have been building this since the beginning of time in the Fibre-Channel era so they do have quite some experience in scalable flat networks and distribution models. One of the biggest benefits is that you can have multiple distributed locations and provide the same distributed network without having to worry about broadcast domains, Ethernet segments, spanning-tree configurations and other nasty legacy Ethernet problems.
Now I’m not tempted to go deep into the Ethernet and IP side of the fence. People like Ivan Pepelnjack and Greg Ferro are far better in this. (Check here and here )
With the launch of the VDX Brocade once again proves that when they set themselves to get stuff done they really come out with a bang. The specifications far outreach any competing product currently available in the market. Again they run on the bleeding edge of what the standards bodies like IEEE, IETF and INCITS have published lately. Not to mention that Brocade has contributed in that space makes them frontrunners once again.
So what are the draw-backs. As with all new products you can expect some issues. If I recall some high-end car manufacturer had to call-in an entire model world-wide to have something fixed in the brake-system so its not new or isolated to the IT space. Also with the introduction of the VDX an fair chuck of new functionality has gone into the software. It’s funny to see that something we’ve taken for granted in the FC space like layer 1 trunking is new in the networking space.
Nevertheless NOS 3.0 is likely to see some updates and patch releases in the near future. Although I don’t deny some significant Q&A has gone into this release its a fact that by having new equipment with new ASICS and functionality always brings some sort of headaches with them.
Interoperability is certified with the MLX series as well as the majority of the somewhat newer Fibre-Channel kit. Still bear in mind the require code levels since this is always a problem on supportcalls. 🙂
I can’t wait to get my hand on one of these systems and am eager to find out more. If I have I’let you know and do some more write-up here.
Till next time.
Cheers,
Erwin
DISCLAIMER : Brocade had no influence in my view depicted above.