Quoting Peter Rathlev <[email protected]>:
Drops on account of MTU wouldn't show up as errors in your end.
Only way
to see them was to look for "giant frames" on the other end. If your drop counter increases you have to look at why. Look at
"show
interface Gi0/X counters errors". If they're OutDiscards, look at
"show
platform port-asic stats drop Gi0/X". Maybe adjust the QoS model.
(Even
with QoS disabled it uses queueing.)
Yes - they are outdiscards: #sh interface gigabitEthernet 0/1 counters errors Port Align-Err FCS-Err Xmit-Err Rcv-Err UnderSize OutDiscards Gi0/1 0 0 0 0 0 3489015 Port Single-Col Multi-Col Late-Col Excess-Col Carri-Sen Runts Giants Gi0/1 0 0 0 0 0 0 0 #sh platform port-asic stats drop gigabitEthernet 0/1 Interface Gi0/1 TxQueue Drop Statistics Queue 0 Weight 0 Frames 0 Weight 1 Frames 0 Weight 2 Frames 0 Queue 1 Weight 0 Frames 5387809 Weight 1 Frames 251 Weight 2 Frames 0 Queue 2 Weight 0 Frames 139 Weight 1 Frames 0 Weight 2 Frames 0 Queue 3 Weight 0 Frames 0 Weight 1 Frames 0 Weight 2 Frames 0 The drops only occur when there is egress data - Minimal traffic(i.e 10Mb/sec) I see counters increase
If the ISP link is 100 Mbps, the other links are 1 Gbps and traffic
is
primarily in their direction you might've run into the much discussed-about buffering on the 3560 platform.
Yes - As stated above, it is only egress traffic that appears to cause the drops - but we start to see the drops with only minimal traffic running over the link? Thanks for your assistance. ------------------------------------------------------------------------- This e-mail was sent via GCOMM WebMail http://www.gcomm.com.au/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
