On Wed, Dec 21, 2011 at 9:41 PM, John Elliot <[email protected]> wrote: > > Hi Guys, > > Have a pair of 2960's in a stack, one port(trunk) connects to another DC and > we are seeing ~5% packet-lossand large output drops to this DC.
Wait up -- 2960, slight over-sub on trunk/uplink int, averages not close to line-rate, and yet tx discards? you don't say! Depending on the situation, default queue configs (both with and without 'mls qos' globally enabled) are fairly naive -- I suggest: -consider any need for actual QoS -re-apportion queue allocations accordingly (as the defaults are often not ideal for 'real' networks with 'real' RTT's) Here's what I've done on nearly every 2960G, S, 3650G, X, and 3750-whatever I've had to deal with given slight/moderate transmission oversub of any given int. The assumption in this config is that the network does not require fancy QoS, just high and less-high prio queues. That is, we can usually get away with a config that only includes enough queue isolation that bgp, ospf, voip/rtp all work stably, even when iperf and iscsi are slamming the shared links. Consider the following global adjustments -- which, in a nutshell, take any input dscp values below 39 and place then in queue 1, 40 and up queue 2. It then sets discard thresholds for queue 1 and 2 to be 3200% and 3100% of max (usually ~100 packets are buffered), which is what provides a bit more burst ride-through. Previous versions of 2960/3560/3750 code didn't permit more than 100% of normal max buffering, but recent code (12.2(50)SE, later) seems to support permitting any one port having greater access to the anemic shared buffer pool. mls qos map cos-dscp 0 8 16 24 32 46 48 56 mls qos srr-queue input bandwidth 9 1 mls qos srr-queue input threshold 1 90 100 mls qos srr-queue input threshold 2 90 95 mls qos srr-queue input buffers 95 5 mls qos srr-queue input priority-queue 2 bandwidth 5 mls qos srr-queue input cos-map queue 1 threshold 3 0 2 3 4 mls qos srr-queue input cos-map queue 2 threshold 2 5 mls qos srr-queue input cos-map queue 2 threshold 3 6 7 mls qos srr-queue input dscp-map queue 1 threshold 3 0 1 2 3 4 5 6 7 mls qos srr-queue input dscp-map queue 1 threshold 3 16 17 18 19 20 21 22 23 mls qos srr-queue input dscp-map queue 1 threshold 3 24 25 26 27 28 29 30 31 mls qos srr-queue input dscp-map queue 1 threshold 3 32 33 34 35 36 37 38 39 mls qos srr-queue input dscp-map queue 2 threshold 2 40 41 42 43 44 45 46 47 mls qos srr-queue input dscp-map queue 2 threshold 3 48 49 50 51 52 53 54 55 mls qos srr-queue input dscp-map queue 2 threshold 3 56 57 58 59 60 61 62 63 mls qos srr-queue output cos-map queue 1 threshold 3 5 6 7 mls qos srr-queue output cos-map queue 2 threshold 3 0 2 3 4 mls qos srr-queue output dscp-map queue 1 threshold 3 40 41 42 43 44 45 46 47 mls qos srr-queue output dscp-map queue 1 threshold 3 48 49 50 51 52 53 54 55 mls qos srr-queue output dscp-map queue 1 threshold 3 56 57 58 59 60 61 62 63 mls qos srr-queue output dscp-map queue 2 threshold 3 0 1 2 3 4 5 6 7 mls qos srr-queue output dscp-map queue 2 threshold 3 16 17 18 19 20 21 22 23 mls qos srr-queue output dscp-map queue 2 threshold 3 24 25 26 27 28 29 30 31 mls qos srr-queue output dscp-map queue 2 threshold 3 32 33 34 35 36 37 38 39 mls qos queue-set output 1 threshold 1 3200 3200 100 3200 mls qos queue-set output 1 threshold 2 3100 3100 100 3200 mls qos queue-set output 1 buffers 5 95 0 0 mls qos Then the per-interface adjustment, which doesn't really matter until the link is nearing saturation: srr-queue bandwidth share 5 95 1 1 srr-queue bandwidth shape 0 0 0 0 priority-queue out mls qos trust dscp Best of luck, -Tk _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
