Cat 2960 QoS egress priority-queue drops

eclipsefnd · ‎06-09-2011

We use a 2960 as our main switch, with QoS to ensure public web pages and code repository traffic gets out faster than the deluge of http download traffic. Our 1 Gbps Ethernet colo port is rate-limited to about 120Mbps to keep costs down, and for most of the day, it's running at full capacity.

My question is: since I'm using priority-queue out on Gi0/2, and all priority traffic is mapped to egress Q1, I'm wondering why I'm still seeing drops.

Here are the relevant snippets of my config. In my case, Gi0/1 'feeds' Gi0/2 on the outgoing.

mls qos srr-queue output dscp-map queue 1 threshold 1 8

mls qos srr-queue output dscp-map queue 1 threshold 2 16

mls qos queue-set output 2 threshold 1 3200 3200 100 3200

mls qos queue-set output 2 threshold 2 1200 1500 100 1500

mls qos queue-set output 2 threshold 3 100 100 50 200

mls qos queue-set output 2 threshold 4 100 100 50 200

mls qos queue-set output 2 buffers 60 38 1 1

mls qos

class-map match-any twenty

match access-group name twenty

class-map match-any all-traffic

match access-group 100

class-map match-any sixteen

match access-group name sixteen

!

policy-map servers

description Will guarantee specified amount of bandwidth for hosts/services listed in the classes.

class sixteen

set dscp cs2

class twenty

set dscp cs1

interface GigabitEthernet0/1

description CSS1 Outside

switchport access vlan 2

service-policy input servers

!

interface GigabitEthernet0/2

description ASA Inside

switchport access vlan 2

load-interval 30

speed 1000

duplex full

srr-queue bandwidth share 20 40 1 1

srr-queue bandwidth shape 0 0 0 0

srr-queue bandwidth limit 18

queue-set 2

priority-queue out

no mdix auto

[snip]

ip access-list extended sixteen

permit tcp host etc...

ip access-list extended twenty

permit ip host etc..

On Gi0/2, traffic seems to be classified correctly:

switch2#show mls qos interface gigabitEthernet 0/2 statistics

GigabitEthernet0/2

dscp: incoming

-------------------------------

0 - 4 : 4096374062 0 12 0 0

5 - 9 : 0 0 0 3063838 0

10 - 14 : 0 0 0 0 0

15 - 19 : 0 475335 0 0 0

20 - 24 : 0 0 0 0 0

25 - 29 : 0 0 0 0 0

30 - 34 : 0 0 0 0 0

35 - 39 : 0 0 0 0 0

40 - 44 : 0 0 0 0 0

45 - 49 : 0 0 0 50 0

50 - 54 : 0 0 0 0 0

55 - 59 : 0 0 0 0 0

60 - 64 : 0 0 0 0

dscp: outgoing

-------------------------------

0 - 4 : 189186360 0 710015 0 21585

5 - 9 : 0 0 0 1415513422 0

10 - 14 : 0 0 0 0 0

15 - 19 : 0 94767695 0 0 0

20 - 24 : 0 0 0 0 0

25 - 29 : 0 0 0 0 0

30 - 34 : 0 0 0 0 0

35 - 39 : 0 0 0 0 0

40 - 44 : 0 0 0 0 0

45 - 49 : 0 0 0 22872 0

50 - 54 : 0 0 0 0 0

55 - 59 : 0 0 0 0 0

60 - 64 : 0 0 0 0

cos: incoming

-------------------------------

0 - 4 : 4099913361 0 0 0 0

5 - 7 : 0 0 0

cos: outgoing

-------------------------------

0 - 4 : 189941016 1415513423 94767695 0 0

5 - 7 : 0 0 0

Policer: Inprofile: 0 OutofProfile: 0

But I still see drops on Q1, which I am assuming is Q0 here:

switch2#show platform port-asic stats drop gig0/2

Interface Gi0/2 TxQueue Drop Statistics

Queue 0

Weight 0 Frames 1668287

Weight 1 Frames 71709

Weight 2 Frames 0

Queue 1

Weight 0 Frames 57702079

Weight 1 Frames 0

Weight 2 Frames 2960

Queue 2

Weight 0 Frames 27720

Weight 1 Frames 0

Weight 2 Frames 0

Queue 3

Weight 0 Frames 0

Weight 1 Frames 0

Weight 2 Frames 227

QoS seems to otherwise be working, but I'm wondering if I'm doing this wrong. Thanks for your insight.

switch2#show version

Cisco IOS Software, C2960 Software (C2960-LANBASE-M), Version 12.2(35)SE5, RELEASE SOFTWARE (fc1)

paolo bevilacqua · ‎06-10-2011

A basic switch is not anything right for the job of shaping to 120 MBps and apply priorties within the constrain.

For this task you need a router, and leave QoS disabled (sane default) on the switch altogether.

eclipsefnd · ‎06-13-2011

Thanks for your reply. I also have a CSS 11503 and an ASA 5540 ... would the ASA be better suited for QoS? I assume the answer is 'no' but I just thought I'd ask.

Which type of router would you recommend for shaping 120 - 200 Mbps of continuous traffic?

Thanks

paolo bevilacqua · ‎06-13-2011

Recommed an ISR G2, check attached performance document.

Please remember to rate useful posts clicking on the stars below.

Joseph W. Doherty · ‎06-13-2011

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

You note your link is "for most of the day, it's running at full capacity.".

It's not so much as doing anything wrong, per se, it's just understanding if you don't have sufficient bandwidth and/or queuing depth for some traffic, it will exceed your resources and packets will be dropped.

As to PQ being dropped, well it too can exceed available resources.

What's usually accomplished by QoS is how resources will be shared. Often this means some traffic will suffer resource depletion later at the expense of other traffic suffering resource depletion earlier.

Often many will attempt to avoid ever dropping any packets, but much traffic is very elastic and lost packets is actually often the primary feedback to a source to regulate its bandwidth consumption to bandwidth available.

Some traffic types do have hard bandwidth requirements, and for those, or to guarantee even elastic traffic certain service levels, you need more bandwidth (either physical, or logical [compression]).

Regarding Paolo's suggestion to replace your switch with a router, router's do generally provide a much, much richer feature set on how congestion might be managed, but even with all their features, you'll most likely still see drops.

As a rough rule of thumb, if bandwidth is plentiful/cheap use it (e.g LAN). If bandwidth is constrained/expensive (e.g. WAN), use advanced bandwidth management techniques.

Before making any upgrades, first determine if any of your production traffic is adversely impacted. If it is, you might "tune" your QoS model to adjust what traffic suffers drops first. Sometimes that's enough. If not, compare the price of equipment upgrades, and their expected benefit, vs. bandwidth upgrades, and their expected benefit.

eclipsefnd · ‎06-15-2011

Thanks for the feedback. I am definitely expecting packet drops since my traffic is exceeding the bandwidth I am allocating. I was simply not expecting drops in the PQ since the docs state "SRR services this (the expedite) queue until it is empty before servicing the other queues." [1]

At any rate, our current QoS setup functions adequately for our needs -- PQ packets do get out faster and throughput on the PQ is higher than other queues when bandwidth is saturated. I'll just accept these PQ packet drops as 'normal' since they don't seem to impact performance.

Thanks for answering my questions.

[1] Catalyst 2960 Switch Software Configuration Guide, p. 29-66, "Configuring the Egress Expedite Queue"

Joseph W. Doherty · ‎06-15-2011

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Yes PQ is serviced first, and I believe on a switch there's no rate limiter, but depending on the nature of your PQ traffic, it might burst beyond buffer allocations, if so, you'll see drops. Increase buffers a bit for that queue and see if drops diminish.