03-26-2016 10:47 PM
I'd like to know if trunking license have limitations (no more than 2 ISL link per trunk group ?).
Because despite our 3 ISL present and online between 2 SAN Switches (DCX and Edge in the fabric),
the 3rd ISL link tend to either stay out of the trunk group, or join a different and independant trunk group...
Let's say 3 ISL links between our SAN switches in our fabrics usually form 2 trunks : one with 2 ISL links, and one with the last 3rd ISL link... (a trunk with only one ISL does not make great sense either...)
Faced with recurrents bottlenecks concerning ISLs, I discovered this situation... So I retreived brocade best practises...
Ports seem to be contigious and on different ASICs and slots... SFP modules are of same types...
PortCfgShow confirm ISL ports eligible for trunk. I also removed Lock G-port activations... Why do switches still behave that way ?
I Think it is better to have 2 trunks of 2 ISL instead... for resiliency and performance reasons... if so, ports reorganisation would be at stake... What do you think of this all ? Any help and opinion would be appreciated...
Solved! Go to Solution.
03-27-2016 12:41 AM
-->>> I'd like to know if trunking license have limitations (no more than 2 ISL link per trunk group ?
Theoretically there is no limitation in Trunking, you can create many trunk as you have port free.
-->>>Because despite our 3 ISL present and online between 2 SAN Switches (DCX and Edge in the fabric),
the 3rd ISL link tend to either stay out of the trunk group, or join a different and independant trunk group
a Single Trunk ( min. 2 or more ISL ) must be create in the same Trunkgroup / Octet.
-->>>a trunk with only one ISL does not make great sense either...)
trunk with only one ISL cannot be created, in order to create a trunk you need TWO or more port.
--->>>What do you think of this all ? Any help and opinion would be appreciated...
i think you should first learning the basically features and functionality
i.e. command "trunkshow" you get the output where Trunk is formed
03-27-2016 03:23 AM
03-27-2016 03:32 AM
Thanks for your contribution,
As a Brocade Certified, No I don't think I should learn basics,
I just want to discuss and pinpoint what appears to be a misbehaviour about how ISL trunking is implemented on our corporate network.
I've already analyzed islshow and trunkshow outpus...
Below are examples between DCX 8510 and 6520 edge SAN Switches :
On the Edge SAN Switch named B80 :
1: 1-> 17 10:00:00:05:1e:44:f2:00 100 B100 sp: 8.000G bw: 16.000G TRUNK
2: 2->163 10:00:00:05:1e:44:f2:00 100 B100 sp: 8.000G bw: 8.000G TRUNK
1: 1-> 17 10:00:00:05:1e:44:f2:00 100 deskew 18 MASTER
0-> 22 10:00:00:05:1e:44:f2:00 100 deskew 15
2: 2->163 10:00:00:05:1e:44:f2:00 100 deskew 15 MASTER
On the DCX switch named B100 :
B100:xsos> islshow | grep B80
7: 17-> 1 10:00:00:05:33:c7:3d:fd 80 B80 sp: 8.000G bw: 16.000G TRUNK
32:163-> 2 10:00:00:05:33:c7:3d:fd 80 B80 sp: 8.000G bw: 8.000G TRUNK
4: 17-> 1 10:00:00:05:33:c7:3d:fd 80 deskew 17 MASTER
22-> 0 10:00:00:05:33:c7:3d:fd 80 deskew 15
18:163-> 2 10:00:00:05:33:c7:3d:fd 80 deskew 15 MASTER
Indeed, you cannot form a trunk when only one ISL exists between switchs,
but the subjet title explicitely put forward " 3rd ISL "
There are many more ISL ports on the DCX, so I truncated DCX output to keep only relevant ports...
I'd like to get one global trunk that increases bandwidth up to 3x8Gb between both swicthes.
but presently, as you can see from the outputs,
There formed 2 trunks : on with 2 ISL ports, the other with 1 ISL... instead of 1 global trunk with 3 ISL links...
A "slotshow -m" gives me blade types, I've got FC8-32 blade type...
I wonder if this behaviour were because of ISL ports choice ?
As the 3rd ISL is port 163 and is does not depend on the same ASIC and/or slot,
this might be the reason why ISL port 163 does not join the one and same trunk as ports B100,17&22
To me, I'm afraid I will have to get the port positions reorganized for my client,
Brocade best practises require adjacent ports...
what do you think ? any other suggestion ?
03-27-2016 03:35 AM
I replied to Antonio before reading your answer,
mine seems to concord with your opinion, I agree with you...
03-27-2016 03:44 AM
first, about Blade, ASIC's, trunk and octet Group, here is a another threads, with deply descriptions.
in you first post, you wrote:
-->>...a trunk with only one ISL....
not sure what you mean, but again Trunk with only one ISL don't exist, for this reason make no sense to spoken or diskuss about
"a trunk with only one ISL"
-->>A "slotshow -m" gives me blade types, I've got FC8-32 blade type...
I wonder if this behaviour ".....were because of ISL ports choice ?"
the problem is you have at the moment one Trunk correct formed, and ONE SINGLE ISL into another different port group, and for this reason, this port cannot partecipate in the same trunk group
03-27-2016 03:51 AM
Hi to all,
so this confirms what I thought,
I'll have to repllug some ports to other positions,
thanks to all of you
03-31-2016 01:43 AM
Antonio, we agree with you that it make no sense if Trunk consists of only 1 ISL but Brocade in its documentation writes smth like "use at least 2 ISL per trunk"
and again, sometimes when you issue either switchshow or trunkshow you can see ISL marked as Trunk Master with no other ISL related to this trunk (as in example above for instance).
So I don't know why this all happens. make me frustrated
03-31-2016 02:32 AM
No doubt that all these considerations about ISL trunking are interesting to share, bearing in mind that a misconfiguration can possibly impair performance...
To discuss again about the fact that Trunks should not form when only one ISL link present, below is an output that tends to highlight the contrary... Trunk with only one ISL E-port existing... (FOS 7.3.1d)
1: 0-> 1 10:00:00:05:1e:47:e6:00 100 A100 sp: 8.000G bw: 8.000G TRUNK QOS
1: 0-> 1 10:00:00:05:1e:47:e6:00 100 deskew 15 MASTER
unless this is historically justified (there might have been at least two ISL links present one day ? which is now no longer true...),
never mind, what unsets me more is when ISL ports do not join expected trunks...
I re-examined all SAN ports in the fabrics, and discovered ISL ports did not respect brocade requirements...
Thus, I will have some ISL ports repplugued so that they are part of the same trunk group/ASIC, this will THE solution.
Other option to check : ISL R_RDY Mode must be disable on ISL ports (already done in my case).
I also noticed the "Lock G-Port" was ON too, disabling this mode did put an end to some OffLine/OnLine port states...