Gert Doering wrote: > Queue 3 > Weight 0 Frames 0 > Weight 1 Frames 0 > Weight 2 Frames 3505735486 > > ... so that basically tells me what I was assuming - "all packets go > into the same queue (no QoS marking going on here, all packets are > important), and some of them get dropped". > > I'm not really sure how to start from here towards "*why* is it dropping the packets"?
I've gone through this grief before and microbursts + insufficient default buffer drop thresholds were the theory of the day - adjusting the thresholds resolved the problem after TAC spent many weeks looking at the issue - but in our case, we /did/ have mls qos enabled. I have no idea how these switches manage buffer allocations when mls qos is disabled. Existing queue-set parameters can be checked with 'show mls qos queue-set'. The buffers and drop threshold can be adjusted with 'mls qos queue-set output buffers' and 'mls qos queue-set output threshold'. Obviously it's quite possible these won't do anything unless mls qos is enabled so a workaround might be to fiddle with these in the lab (with mls qos enabled and disabled) to see if you can reproduce and resolve the problem. We had to increase the drop thresholds for the affected queue from 50 to 400. Note the queue numbers in these commands are offset by one compared to the 'show mls qos port-asic stat' output. Then again maybe it's not microbursts and is something else entirely. Have fun with the TAC! Regards, Brad _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
