[c-nsp] 2960S drops/packet loss
Anton Kapela
tkapela at gmail.com
Sun Dec 25 15:24:40 EST 2011
On Wed, Dec 21, 2011 at 9:41 PM, John Elliot <johnelliot67 at hotmail.com> 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
More information about the cisco-nsp
mailing list