For more details, please see ourCookie Policy.

Fibre Channel (SAN)

Occasional Contributor
Posts: 15
Registered: ‎01-16-2017

ISL up-link between core 6510 and the edge blade chassis 5470 [design]

[ Edited ]



I was hoping for a tiny verification/steer in a right direction in regards to a change I'm thinking of implementing in inherited design.


There is a core, to simplify, consisting of two x 6510s in each fabric (linked together by ISL), and blade chassis with two 5470s connected to each fabric respectively. For simplicity, we would only need to consider one fabric, for the sake of this description called - FABA (as per attached design).


Currently, the three ISL links between 5470 (DID5) and core's 6510 (DID=1) are not trunked and cannot be for the time being (no licencing available).


FOS: 7.4


In order to increase resilience and performance during potential outage, most likely caused by disappearance one of the two core 6510s  (i.e. either DID1 or DID3), I was wondering, if this would make sense to either:


  • move one of the ISL links currently connecting DID5 with DID1 to DID3 (so that at least one of the links was going to DID3 from DID5, not causing complete IO outage for the chassis on FABA) or
  • patch in more connections from DID5 (there are three uplinks ports left) towards DID3

Personally, I'd be in favour of the former option (i.e. moving one of the ISLs across to DID3, especially that they are not trunked), potentially adding one more ISL between DID3 and DID5, just not to cause to much saturation on linked moved from DID1 to DID3.


Saying that, am not sure how much this is true and how traffic is routing from one switch to the other when there are basic ISLs in place rather than trunks ... With no trunks available, I can not see perf stats either so am not sure how to monitor current ISL links utilization (Internet sleems to suggest looking up errors on ISL ports porterrshow to start with ...).


I know there is a possibility of traffic-based or fram based congestion and also buffer credits misconfiguration potentially having an impact on this design but this is currently over my head and experience with FC so only mentioned for completeness if this was something to start looking into bedore making decissions.


Any thoughts would be much appreciated.




Broadcom Moderator
Posts: 467
Registered: ‎03-29-2011

Re: ISL up-link between core 6510 and the edge blade chassis 5470 [design]

Hi szy,


Adding ISLs from the 5470 (DID5) to the second core switch, 6510 (DID3) would improve resilence, and is recommended.


I assume that storage is equally connected to both 6510s.


WIth a future trunking in mind, having 2 ISLs between both 6510s,

moving one ISL from the 5470 to 6510 (DID1) to the other 6510 (DID3), and adding a new ISLs - correctly configured

in the port groups for trunking.  I prefer symmetrical design, when possible. 


The second option, to  patch in 3 new ISLs  between the 5470 and the 6510 DID3, might be considered if the existing links

is saturated - if the three existing ISLsare saturated, and if you only had 2 two ISLs to each 6510 and one of the 6510s failed,

the two links to the 6510 left might not be enough. But it is load depedent.  Also, the existing load on the ISLs between needed

to be looked at.  To get a look at the traffic load, use for example portperfshow or 'trunkshow -perf' for the trunks.


For routing, when you see a trunk think bigger ISL.  Basicly, if the EBR (Exchange Based Routing) is enabled, traffic is

distributed on the size of trunks (an single ISL can be though of as a trunk), so a single ISL is 16GB and a trunk of two ISLs

would be 32GB - and the 32GB trunk would take 2/3 of the traffic and the ISL o 16GB would take 1/3.


kind regardss

If this provided you with a solution to this issue, please mark it with the button at the bottom "Accept as solution".

Any and all information provided by me is not reviewed, approved or endorsed by Brocade and is provided solely as a convenience for Brocade customers. All systems and all networks are different and unique. If you have a service affecting network problem, please open a TAC service request for service through Brocade, or through your OEM equipment provider. If this provided you with a solution to this issue, please mark it with the button at the bottom "Accept as solution"

Join the Broadcom Support Community

Get quick and easy access to valuable resources across the Broadcom Community Network.