Ok, truth be told it is not a Flow Vision bug but in FOS 9.0.0 it is flagged as such under defect 653188.
As you know Flow Vision can be configured to monitor certain traffic flows. SCSI commands such as read, write, xfer-rdy,, status etc can be viewed with the flow –show command.
Yahooo… (No not the company) FOS version 9 is here. The one that starts to support Gen 7 (64/256 Gbit) Fibre Channel. Now, just in case you’re getting excited and want to go clickety..clickety..click..upgrade <<<< hold on!!.
As you can read in my previous articles (here, here and here) having a physical issue on any of you FC links is detrimental to your entire FC infrastructure. Not only does it corrupt frames and primitives but is also resulting in traffic flow issues which may even propagate to other fabrics which even have a so called air-gap. (See here)
In a Brocade environment the “switchshow” is one of the most used commands out there. It provides a quick overview of what the state of the switch is, switch name, switch attributes and a list of all ports and states. It had however its limitations which, with later codelevels, can be corrected.
I’ve already mentioned that BNA was End-of-Life and will/is (be) replaced by SANNav.
As of the time of this writing any BNA version older than 14.4.1 is no longer supported. This basically means that your BNA (or any OEM version) older than that release is not being looked at when yo have a problem with it.
Whenever you’ve encountered an output of a nameserver entry you may have come across the phenomenon that the fabric has no clue what the attached device is. For a FC switch an attached device (or N-port in technical terms) is not more than a source or destination where frames originate from or can be sent to. As soon as smarter functions are required it may be helpful (or required) to be able to obtain more information from that device.
Like clockwork Brocade releases new FOS version around every 6 months. No news here. FOS 8.2.1 is however a release you may need to pay special attention to especially if you have X6 director class switches hooked up to a 240 volt, 50 Hz power mains as well as sitting between a rock and a hard place with the 7800 extension switch but don;t have the budget to go to a relatively pricey 7840. One other thing is the change in licensing hardening on pizza-box switches which makes the upgrade to this release a one-way street without being able to go back.
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.
System administrators are very inventive and lazy. I know, I used to be one of them. 🙂 Everything that can be done to make ones life easier is about to be scripted, configured, designed etc. If you are responsible for an overall environment from Apps to servers to networks and storage you can make very informed decisions on how you want to set up each different aspect of your environment. The last time I had this opportunity was back in 1995. Since then I have not come across an environment where a single person/team was responsible for each technology aspect of the infrastructure. As environments grow these teams grow as well. Business decisions like splits, acquisitions, outsourcing etc etc have enormous impacts not only on the business itself but also on people who are now forced to work with other people/teams who may have different mind-sets, processes and procedures and even completely different technologies. In many such instances strange things will happen and result in a very unpredictable behaviour of compute, network and storage systems. Below I’ll give you such an example where decisions from a systems-level perspective results in massive problems on a storage network.
There are occasions where you need to remove an entire zoning configuration from a switch. One of them is if you need to add a switch to an existing fabric and it still has a configuration in it. If these two conflict the switch will simply segment and the ISL’s get disabled. Another reason might be in case of configuration conflicts where and administrator had made zone changes whilst one switch was not participating in the fabric. Depending on how the switch is set up and the actual fabric state you need to follow different procedures.