Environment:2 DCX 8510 connected using ICL ports.5 VF with trunks enabled and working.
DCX11_SVC_IC:FID107:admin> trunkshow1:388->388 10:00:c4:f5:7c:aa:fb:63 27 deskew 15 MASTER384->384 10:00:c4:f5:7c:aa:fb:63 27 deskew 16
2:420->420 10:00:c4:f5:7c:aa:fb:63 27 deskew 15 MASTER416->416 10:00:c4:f5:7c:aa:fb:63 27 deskew 15
DCX11_SVC_IC:FID107:admin> islshow1:388->388 10:00:c4:f5:7c:aa:fb:63 27 DCX21_SVC_IC sp: 16.000G bw: 32.000G TRUNK QOS CR_RECOV FEC 2:420->420 10:00:c4:f5:7c:aa:fb:63 27 DCX21_SVC_IC sp: 16.000G bw: 32.000G TRUNK QOS CR_RECOV FEC
The thing is that Performance in interswitch connections (ILS) are evenly distributedbut NOT among the port belonging a trunkThis happens in every trunk of every VF ..... with trunk comprised of 2 up to 4 ports .....I have appended an example of that behaviour
As far as I know trunking meaning is just to spread all traffic evenly with a better use of th vc channels ... but we got here is just the opposite
Anyone can explain me that?In the other hand .... the deskew value (expresed in nanosecs/10) can vary from 15 to 18 in some isls. Is that relevant??thanks in advance and best regards, Alberto
Since 4Gb (10+ years ago) trunks do not distribute traffic evenly between the individual trunk members.
Trunking algorithm is proprietary. Basically, the links inside the trunk are numbered at the moment of the trunk creation, and then the load is distributed based on some rules. The less the number of a link, the more the load. %portused alarms are just alarms, and they are adjustable. Discarded frames is something very different. It might be that you have a slow drain device attached somewhere up the link. Do you see any other symptoms, e.g. CRC errors?
see the very good description of trunking by @Doc Cherwink in this thread