QoS statement

[John Blakley]

Based off of the following configuration, do you think this will limit all NON-VOIP traffic to 768? If voice traffic isn't going across, will it allow all other traffic to use the full bandwidth of the link?

policy-map VOIP

class VOIP

priority 768

class class-default

fair-queue

random-detect dscp-based

Service-policy output: VOIP

Class-map: VOIP (match-any)

306 packets, 14019 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: access-group 110

306 packets, 14019 bytes

5 minute rate 0 bps

Queueing

Strict Priority

Output Queue: Conversation 264

Bandwidth 768 (kbps) Burst 19200 (Bytes)

(pkts matched/bytes matched) 25/1244

(total drops/bytes drops) 0/0

Class-map: class-default (match-any)

3743 packets, 393837 bytes

5 minute offered rate 11000 bps, drop rate 0 bps

Match: any

Queueing

Flow Based Fair Queueing

Maximum Number of Hashed Queues 256

(total queued/total drops/no-buffer drops) 0/0/0

exponential weight: 9

Thanks!

John

[Nicholas Matthews]

For what it's worth, I got in an argument with someone on this functionality, and we proved it in the lab.

I configured an 8kb (minimum) priority queue for voice, and put in on a WAN circuit. Then, placed a call over it.

The 'show policy-map interface' showed that we were getting the full 8kb/s on the priority queue, plus run-over into the class-default.

So to confirm - the LLQ priority keyword only drops traffic with congestion. When you have congestion and traffic is dropped, the priority keyword becomes a policer.

hth,

nick

[milan.kulik]

Hi,

I found this nice document on CCO confirming the LLQ priority keyword only drops traffic with congestion:

http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note09186a0080103eae.shtml

BR,

Milan