I do have QOS enabled on the 6504 with "mls qos". Here is the config of that port:

interface GigabitEthernet4/12

description ROC-7604-A G1/1

ip address xxx.xx.xxx.xx 255.255.255.252

ip wccp 61 redirect in

ip flow ingress

ip pim sparse-mode

load-interval 30

mls qos trust dscp

And here is the output of "show queueing int g4/12":

ROC-6504-DW-A#sh queueing int g4/12

Interface GigabitEthernet4/12 queueing strategy: Weighted Round-Robin

Port QoS is enabled

Trust state: trust DSCP

Extend trust state: not trusted [COS = 0]

Default COS is 0

Queueing Mode In Tx direction: mode-cos

Transmit queues [type = 1p3q8t]:

Queue Id Scheduling Num of thresholds

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

01 WRR 08

02 WRR 08

03 WRR 08

04 Priority 01

WRR bandwidth ratios: 100[queue 1] 150[queue 2] 200[queue 3]

queue-limit ratios: 50[queue 1] 20[queue 2] 15[queue 3] 15[Pri Queue]

queue tail-drop-thresholds

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

1 70[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7] 100[8]

2 70[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7] 100[8]

3 100[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7] 100[8]

queue random-detect-min-thresholds

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

1 40[1] 70[2] 70[3] 70[4] 70[5] 70[6] 70[7] 70[8]

2 40[1] 70[2] 70[3] 70[4] 70[5] 70[6] 70[7] 70[8]

3 70[1] 70[2] 70[3] 70[4] 70[5] 70[6] 70[7] 70[8]

queue random-detect-max-thresholds

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

1 70[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7] 100[8]

2 70[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7] 100[8]

3 100[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7] 100[8]

WRED disabled queues:

queue thresh cos-map

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

1 1 0

1 2 1

1 3

1 4

1 5

1 6

1 7

1 8

2 1 2

2 2 3 4

2 3

2 4

2 5

2 6

2 7

2 8

3 1 6 7

3 2

3 3

3 4

3 5

3 6

3 7

3 8

4 1 5

Queueing Mode In Rx direction: mode-cos

Receive queues [type = 1q8t]:

Queue Id Scheduling Num of thresholds

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

01 WRR 08

WRR bandwidth ratios: 100[queue 1]

queue-limit ratios: 100[queue 1]

queue tail-drop-thresholds

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

1 100[1] 100[2] 100[3] 100[4] 100[5] 100[6] 100[7] 100[8]

queue thresh cos-map

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

1 1 0 1 2 3 4 5 6 7

1 2

1 3

1 4

1 5

1 6

1 7

1 8

Packets dropped on Transmit:

BPDU packets: 0

queue dropped [cos-map]

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

1 91865 [0 1 ]

2 0 [2 3 4 ]

3 0 [6 7 ]

4 0 [5 ]

Packets dropped on Receive:

BPDU packets: 0

queue dropped [cos-map]

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

1 0 [0 1 2 3 4 5 6 7 ]

Do you think I should turn off "mls qos" or adjust, or adjust queue 1 somehow?

Are you using QoS in your network? If you're actively passing marked traffic (most likely Voice or video), I certainly wouldn't turn QoS off. The bulk of your data looks like it's being passed as either 0 or 1 traffic.

Do you have an active use for Cos0 (DSCP8?) Have you configured a scavenger class in your network? If so, you NEED to re-arrange your COS mappings so CoS1 gets less favorable treatment that CoS0- by default, CoS 1 actually gets slightly better treatment!

a 6748 has 1.3MB of buffer per port.

The setup you have (as indicated by Queue limit ratios) indicates that you've allocated half of that to queue 1- about 650KB. You're going to start doing WRED-based drops on CoS 0 traffic in that queue when the buffer hits 40% of that- 260KB, or ~2Mb.

Before poking around at anything, you need to consider what your QoS strategy is- what traffic are you passing, what markings are your honoring, and what volumes of that traffic are you planning to service (both now, and through your crystal ball, in the future).

If 100% of your traffic is CoS 0, you could probably adjust your buffers to some ridiculously high value for this queue, and starve everything else. Keep in mind that even without your specifically using Cos 6/7, your routing traffic and STP and such tend to fall into those- so leave som room for those!

I suggest reading the Telepresence SRND- it's got the best descriptions of Switch-based IOS QoS configurations I've yet to read. The VOIP srnd focuses heavily on CatOS, and isn't as well written, IMHO.

Assuming you don't have any scavenger class traffic on your network (or something else using COS1),

you could use:

wrr-queue random-detect max-threshold 1 100 100 100 100 100 100 100 100

wrr-queue random-detect min-threshold 1 80 100 100 100 100 100 100 100

That'll effectively double your buffer for your CoS 0 traffic.

However, if the problem is that you're frequently experiencing "microcongestion" towards the 7604, bigger buffers may just mean that you'll start dropping traffic a split second later than you did before.

(Yes, bandwidth towards the 7604 is low on a per average basis, but if there's frequently multiple ports on yoru 6500 all ingressing traffic simultaneously destined to be egressed towards the 7604, something's got to give.)

[Note: in addition to all my blatant typos, I meant:

Are you actively using COS1 (DSCP8)? That significantly changes the meaning of what I was trying to convey.

Towards all my user ports, I'm applying a policer that marks all traffic over 10Mb from CS0 (default) to CS1. As a result, at any port where I'm managing QoS, I need to make sure that CS1 actively gets worse treatment than CS0. In my case, following the SRND, I moved CS1 to Queue 1 Threshold 1, and only allocated it 5% of the bandwidth. CS0 is now in Q2T1, all by itself. 2/3/6/7 are in Q3, all at separate thresholds. 4/5 are both mapped to the PQ. This is achieved through use of the "wrr-queue cos-map" commands.

IMPORTANT: If you change the cos-mappings on a port, these changes WILL affect multiple ports on the same ASIC.

When you update the cos-maps, you should also update the thresholds/bandwidth/queue-limits, or you'll end up with sub-optimal situations. These commands are NOT asic-based, and will not spill over to the other ports. So if you play with cos-mappings on one port, make sure you update all the rest of the parameters on every other port that's inadvertently touched, or you'll get some really unfavorable behavior.

My 1p3q8t standards (as suggested by the SRND, and seem to work for me) are:

wrr-queue bandwidth 5 35 30

priority-queue queue-limit 30

wrr-queue queue-limit 5 35 30

wrr-queue random-detect min-threshold 1 80 100 100 100 100 100 100 100

wrr-queue random-detect min-threshold 2 80 100 100 100 100 100 100 100

wrr-queue random-detect min-threshold 3 60 70 80 90 100 100 100 100

wrr-queue random-detect max-threshold 1 100 100 100 100 100 100 100 100

wrr-queue random-detect max-threshold 2 100 100 100 100 100 100 100 100

wrr-queue random-detect max-threshold 3 70 80 90 100 100 100 100 100

wrr-queue cos-map 1 1 1

wrr-queue cos-map 2 1 0

wrr-queue cos-map 3 1 2

wrr-queue cos-map 3 2 3

wrr-queue cos-map 3 3 6

wrr-queue cos-map 3 4 7

priority-queue cos-map 1 4 5

This config set is pretty difficult to read- but if you compare the output of show queueing before and after it's applied, it really starts to make a lot of sense. It's proving to be a decent baseline for my network, at any rate.

If you don't have any traffic other than CoS0, however- this isn't going to buy you a whole lot! That's why it's important to know what you're supporting (or intending to support) before tweaking any of the knobs. ]

I printed out the Telepresence SRND as you suggested and will spend some time digging through it. You're right about the QOS SRND (I've been using that up to this point) that it is centered around CatOS, thus making is difficult to use in a Native IOS environment.

I do have a lot of traffic that is not just Cos-0, and now it's time for me to get serious about the correct QOS on my 6500s. UP to now I have only trusted the markings going through the 6500s, but as can be seen by the 'sh queueing...' output, my traffic levels are at the point of dropping packets.

My requirements on int g4/12, where the drops are occurring, are:

300 VoIP G-711 calls = roughly 30mb, DSCP EF

20 video conference streams = roughly 30 mbs for high-def streams, DSCP AF4 or CS3.

I haven't set up a scavenger class yet, but intend to after I get the correct voice and video classes taken care of.

With the above voice and video requirements, what would be your recommendation on the wrr parameters?

Also, if you don't mind, what traffic types did you put in your scavenger class?

In my network, voice and video are the only defined applications that require any QoS at the current time. However, I didn't want to design myself into a box for if/when a broader strategy is decided upon.

My preferred solution:

I don't want to be responsible for marking traffic at the switch. Traffic ingressed into the network should be marked appropriately by the application that's requesting it.

This is my stance mainly because the first applications that people are asking to be marked are voice and video- and writing an ACL to effectively match any port from 16,000 - 32000 udp kind of makes it difficult to ensure that I'm accurately marking voice and only voice traffic to up to EF.

Secondly, I don't like to trust edge ports!

Trusting towards an end user means that if some enterprising user finds the QoS settings in windows, they've got free reign to destroy my PQ. Conditional trust towards a cisco phone mitigates my concerns a little bit- but it only works with cisco phones, and it's not available on a 6500.

I've implemented policers at the edge. I've got a policy map applied to every user port on my campus that gives 128K worth of bandwidth to incoming EF traffic, 32K to CS3, and 32K of CS0 traffic on my Voice VLAN. I drop excess EF, and mark CS0 and CS3 excess traffic to CS1. (scavenger.) This is done to ensure that somebody doesn't use a vlan hopping tool to get into the Voice VLAN and send data above and beyond what's expected.

On the Data VLAN, I accept 10Mb of traffic, and set it to CS0- and anything above that, I set to CS1.

This means that legitimate chatty traffic may get marked down to CS1, but it's important to remember that it won't get dropped unless there's congestion! And the people you're 'punishing' are the high-volume users that are probably contributing to the congestion in the first place.

This isn't so much a method to make sure people aren't regularly using FTP or whatnot- it's done mainly to ensure that if Slammer were ever to occur again, I don't simultaneously have every choke point in my user domains completely starved out- it's most likely worm or viral traffic that would cause high-volume sustained traffic rates.

My Video deploys are relatively minimal right now, so I have another policy map on a per-port basis that allows for 18Mb of CS4 traffic. Excess is dropped. Depending on how widespread and 'mobile' your video solutions are, you may elect to make that a part of your default user stance.

It sounds like you could tweak your PQ down to 100MB or 10% right now- but as soon as video becomes more prevalent and you hit the 100Mb threshold, you're forced to re-deploy to your entire infrastructure. That's why my pilot started out with 300Mb and I figured I'd tweak around from there. Voice and Video are going to be a lot less forgiving than the TCP traffic that WRED is going to pick on in the CS0 queue.

I haven't noticed any excessive drops from this tuning in my environment after following the SRND, so I've pretty much left it as-is for now. I _did_ experience a significant amount of excess drops when I modified the queue-mappings but not the buffer/thresholds/etc parameters as well. Tuning those to the suggested configs made the drops disappear as well.

I'd probalby start just by upping the WRED threshold on that port to 100max/80min and start figuring out your long term goals from there. Once you have an idea, you can start playing with cos mappings and more in-depth values for the other

(In this case you'll have to modify Max first, then min- otherwise the switch complains that min is greater than max, and doesn't take the config. Be aware of any of these types of errors when you're updating configs!)

You've been extremely helpful - Thank you!! Now it's time for me to dig into the SRND and bone up on all the WRR queue/threshold theory and jargon.