Tag Archives: isl

5.1 ISL/E-port configuration – The right way.

To many it has always been a mystery what happens when you connect fibre-channel switches to each other and all of a sudden magic happens and you can have an host “talk” to an array or an other device on an other switch. The same mystery however applies when this doesn’t work and you see “E-port segmented, port disabled”. In later FOS codes you may see some additional cryptic reasons like “ESC mismatch” but to many this is as gibberish as particle physics.

This post explains most of the important settings on an Brocade switch port destined to become an E-port in either a standalone master or in a slave role as part of a trunk. I’ll also highlight the importance of some settings when it comes to virtual channel initialization on both short and long distance settings as well as things seen on the wire when an ISL is segmented due to a fabric configuration problem. This post also touches on C/DWDM connectivity in relation to Brocade ISL’s.

Continue reading

Upgrade FOS leads to fabric segmentation.

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.

Continue reading

RFE for Brocade FOS

There is already a fair chunk of functionality in FOS but, being a support-engineer, you always come up with features and functions that will improve storage fabrics.

Being on a Ficon course last week and meeting some Brocade friends I requested them to add the following to the (most likely) long RFE (Request for Enhancement) list.

Continue reading

Performance expectations with ISL compression

So this week I had an interesting case. As you know the Hitachi arrays have a replication functionality called HUR (Hitachi Universal Replicator) which is an advanced a-synchronous replication solution offered for Mainframe and OpenSystems environments. HUR does not use a primary to secondary push method but rather the target system is issuing reads to the primary array after which this one sends the required data. This optimizes the traffic pattern by using batches of data. From a connectivity perspective you will mostly see full 2K FC frames which means on long distance connections (30KM to 100KM) you can very effectively keep a fairly low number of buffer-credits on both sides whilst still maintain optimum link utilization.

Continue reading