02-09-2019 02:58 AM - edited 02-10-2019 11:51 PM
2 DCX 8510 connected using ICL ports.
5 VF with trunks enabled and working.
1:388->388 10:00:c4:f5:7c:aa:fb:63 27 deskew 15 MASTER
384->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 MASTER
416->416 10:00:c4:f5:7c:aa:fb:63 27 deskew 15
1: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 distributed
but NOT among the port belonging a trunk
This 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
02-11-2019 12:26 AM
02-11-2019 02:50 AM - edited 02-11-2019 03:52 AM
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?
02-11-2019 03:45 AM
see the very good description of trunking by @doc in this thread