The awesomeness of Brocade FOS 7.

4
erwinvanlonden.net/2015/04/the-awesomeness-of-brocade-fos-7-4/

By Erwin van 29/04/2015

Londen

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.

Peer and TDZ Zoning

The most fantastic change is the concept of “Peer” and “Target Driven Zoning”.

Ever since FOS version “stoneage” with enhanced zoning capabilities the name of the
game has always been to have single initiator zones. This prevented not only from
inadvertently having hosts “seeing” each other on the fabric but also to reduce RSCN
storms which could cause all sorts of nastiness. That being said when you have 1500 dual-
or multi-pathed hosts and 40+ arrays with each around 200 target ports your zoning
database is fairly bloated. (to say the least.) In addition to that you have to retain a very
rigorous naming schema and administrative procedures to keep this in tip-top shape. This
has been a torn in the eye of many administrators (and yes, also support-guys like me)
since the amount of work involved was fairly significant. The chance or introducing errors in
addition to the overall effect of zone changes with such large database accros many
switches in the fabric triggered the need for expediting the introduction of “peer zoning”

Peer zoning
Peer zoning works with a new methodology which is called Principal to Peer
communication. This basically means you create a zone with a single principal and only the
principal is able to see and talk to peers. The principals themselves are not allowed to
see/talk to other principals or peers defined in other zones. In essence what is does is that
ACL are applied on peer-ports in a zone to only see the principal. The principal however
obtains an ACL of all peer-member ports in that zone. Both a peer and principal can be
member of multiple zones (including non-peer zones) which could then alleviate the
statement above and allow them to see/talk each other. If you want/need to do that
depends on requirements. From a schematic view it looks like this.

1/4
The initiators on the left and target on the right are member of the “Blue” zone in the “cloud-
fabric” where the target is specified as a principal and the initiators as peers.

TDZ or Target Driven Zoning

The entire peer zoning methodology does not fall out of the sky. The initiating drive behind
it all was to have the ability to remove human error from doing zone-changes and have
storage devices determine which initiators are allowed to connect to it respective target
ports. It also removed the not-so-smart idea of getting rid of zoning entirely which obviously
would introduce the phenomenon of RSCN storms (as sort of broadcast notification
methodology when something changes in the fabric). The concept itself however was not
new. I’ve been discussing the same scenario and possible solutions (of which one was
indeed TDZ which whe then called Target initiated Zoning) with DEC/Compaq/HP
engineers in Colorado Springs back in 2000 to 2003 when we already saw the negative
side-effects of growing fabrics and their lack of intelligence in this area. Given the fact some
greedy CEO’s more or less used a chain-saw in the HP storage engineering departments
the entire idea was shelved. To my great surprise and pleasure I read an article from Erik
Smith at EMC who seem to have ran into the same observations and he drove the concept
to a formal entry in the now FC-SW-06 and FC-GS-07 standards. (Big Applause !!) For his
articles read his blog over here

Basically what it does is that you create a zone with a single principle member. As as soon
you create a virtual storage port (Host Storage Domain in Hitachi terms)on an array and
add your host options including the WWN to that HSD the zone in the fabric of which the
array port is a principal will get updated with that WWN and the ACL’s on the respective
switchports are adjusted accordingly. The array port in that case is instructing the fabric
configuration server to add the WWN as a peer in that particular zone. An RSCN is sent to
the initiator indicating something has change in the fabric after which is does an inquiry to
the name-server of that change, sees the new port being available and will send a
PLOGI/PRLI request to the array and voilà, connection is made. As you can see this really
reduces the administrative overhead when managing zones. The only ‘gotcha’ now is to
have storage vendors implement the technology. Start nagging your sales-reps and your
vendor’s Product Managers.

FabricWatch vs. MAPS

First off FabricWatch is End-of-Life and does no longer exist in FOS 7.4. I’m in mourning :-
2/4
). As you probably know I’ve been a huge fan and serious advocate of FabricWatch. I’ve
always urged every administrator to put this license on the “need-to-have” section of the
RFP. It provided a wealth of information and is a tremendous tool to keep an eye on almost
every aspect of the logical and physical side of the fabric. As of FOS 7.2 FabricWatch has
been morphing into a new tool called MAPS (Monitor and Alerting Policy Suite). In
combination with FlowVision (as successor of Advanced Performance Monitor which is
also End-of-Life with this release) the new toolkit is called FabricVision. These two
combined create the one of the most powerful tools I’ve ever seen in an embedded
“firmware” image. I’ll write a separate post in that one.

If you have been using FabricWatch in the past and have created rules and alerts you need
to migrate these to MAPS. FOS 7.4 is not able to do that so before you upgrade to 7.4 be
sure to enable MAPS in FOS 7.3 to have the ruleset converted to a MAPS capable
configuration. A simple

“mapsconfig –fwconvert”

will do the trick. I’ve written posts about MAPS over here and here but with FOS 7.3.1+ and
FOS 7.4.x these are obsolete. Brocade has obtained a good feeling for RAS requirements
and has learned a lot from what is coming back to them from the field in the form of
enhancement requests as well as issues that have been affecting customers and they have
been able to translate that into a well organised set of RAS features. MAPS is enabled by
default under a “basic license” schema which allows you to keep track of overall switch
status events. This is enabled by a default policy which cannot be changed. In addition to
this there is a significant leap in rules that can be configured on numerous classes of
events and objects. If you take your fabric serious I urge you to have a look at this. (I MEAN
THAT !!)

Firmware updates.
Ever been in the situation where you get a new switch from spares which is loaded with
FOS version “stoneage” and you need to go through 7 point releases to get it up to the
latest supported level. That sucks doesn’t it. Well, not anymore. With FOS 7.4 you can use
the “firmwarecleaninstall” command which totally wipes the current installed configuration
and installs the version you are downloading. This clean slate also means the pre-
configured OEM parameters are wiped which might conflict with settings your vendor might
have instructed to Brocade to configure. Check with your vendor on this.

Some smaller but really nice enhancements.

When you have configured multiple users who have different authorisation levels on one or
more virtual fabrics they can now ssh into a switch and automatically moved into the context
which that user has configured its home fabric.

3/4
The portloginshow command has improved in a way it now can show the WWN that was
last logged in into this port with the “–history” parameter. From a support-perspective this is
especially useful as we only get a snapshot of a switch at a particular moment in time. It
does not show us what actually was using a port.

Dynamic Load Sharing is also supported on the embedded platforms now. This should
provide a much better performance balance on the ISL’s coming from a blade-system.

FlowVision has improved with some very handy additions which allow you to obtain and
overall picture of the performance of a switch but also added the method to get info around
specific flows from all datapoints in a fabric. (Obviously the hardware needs to be able to
support this)

Conclusion
I would recommend to thoroughly read the release notes as well as the updated manuals
that come with this release. From my view this release is one of the best feature wise. If the
bugs stay away or Brocade is able to identify and fix them quickly I would certainly
recommend moving to this version and use the new and updated features and functions.

Regards,

Erwin

4/4