Cisco Support Community
Community Member

Nested QoS Policy and Strict Priority Queue

Hi Group,

I am having an issue with applying nested QoS policy to an interface and not seeing the packets placed in the strict priority queue.

Here is my configuration:

class-map match-any WAN_Egress_Cisco_Voice_Signaling

match ip dscp cs3

class-map match-all WAN_Egress_Scavenger

match ip dscp cs1

class-map match-all WAN_Egress_Bulk_Data

match ip dscp af11 af12

class-map match-all WAN_Egress_Business_Applications

match ip dscp cs2 cs3 af31 cs6

class-map match-any WAN_Egress_VTC_Video_Conferencing

match ip dscp af42

class-map match-any WAN_Egress_VoIP_Media

match ip rtp 16384 16383

match ip dscp ef



class WAN_Egress_VoIP_Media

priority percent 15

class WAN_Egress_VTC_Video_Conferencing

bandwidth remaining percent 20

class WAN_Egress_Business_Applications

bandwidth remaining percent 35


class WAN_Egress_Bulk_Data

bandwidth remaining percent 14

class WAN_Egress_Scavenger

bandwidth remaining percent 1

class class-default

bandwidth remaining percent 30




class class-default

shape average 1544000

service-policy WAN_EGRESS_POLICY


interface s2/0

ip address

service-policy output WAN_EGRESS_POLICY_T1

I used extended ping with ToS of 0xb8 to generated EF traffic. I see the EF packets matching the VoIP Media class map but not to the priority queue (as seen in the output from "show policy-map int s2/0" command):

Service-policy output: WAN_EGRESS_POLICY_T1

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

1009 packets, 104126 bytes

5 minute offered rate 8000 bps, drop rate 0 bps

Match: any

Traffic Shaping

Target/Average Byte Sustain Excess Interval Increment

Rate Limit bits/int bits/int (ms) (bytes)

1544000/1544000 9650 38600 38600 25 4825

Adapt Queue Packets Bytes Packets Bytes Shaping

Active Depth Delayed Delayed Active

- 0 1000 104000 0 0 no

Service-policy : WAN_EGRESS_POLICY

Class-map: WAN_Egress_VoIP_Media(match-any)

1000 packets, 104000 bytes

5 minute offered rate 8000 bps, drop rate 0 bps

Match: ip rtp 16384 16383

0 packets, 0 bytes

5 minute rate 0 bps

Match: ip dscp ef

1000 packets, 104000 bytes

5 minute rate 8000 bps

Match: ip dscp cs5

0 packets, 0 bytes

5 minute rate 0 bps


Strict Priority

Output Queue: Conversation 72

Bandwidth 15 (%)

(pkts matched/bytes matched) 0/0

(total drops/bytes drops) 0/0

Any help regarding this would be highly appreciated. Thanks much!

- Kashif


Re: Nested QoS Policy and Strict Priority Queue


your problem with the class maps

change all class maps that has multiple matching such as

match ip dscp cs2 cs3 af31 cs6

change the class map matching

from match-all TO match-any

good luck

if helpful rate

Super Bronze

Re: Nested QoS Policy and Strict Priority Queue

Looks alright to me.

You might misunderstand the stats. If your concern is the zero matches for the PQ, that can indicate there wasn't enough congestion for that class's matched packets to be queued. It's common to see this stat, on any class that shows it, less than the class match stats. This might be confirmed by the fact your parent shaper shows zero delayed packets. (Only when the shaper delays packet should packets be queued into the child policy's queues.)


BTW, what kind of serial link is it that you needed to shape it to 1.5 Mbps?

Community Member

Re: Nested QoS Policy and Strict Priority Queue

Thanks much Joseph. I suspected that this is what the case is. The original policy is for a DS3 link on a customer's 7206VXR but I am simulating this for a serial interface in the lab environment. Personally, I think we don't need to shape a DS3 link unless we want it to be under utilized. What do you think?

Perhaps I should generated large datagrams on this 1.5Mbps link to saturate it and lower down the traffic shaping limit to see the packets in the strict priority queue. I will keep you posted if I get that working.

Marwan - Thanks for pointing out the match-any thing to. It would be a good idea for that class-map. However, the problem I suspected I was seeing was with the VoIP_Media class with already has match-any statement.

Thanks again for the replies!

- Kashif

Super Bronze

Re: Nested QoS Policy and Strict Priority Queue

As to seeing LLQ activate in a test situtation, I've found an easy method to do so is to use some kind of traffic generator to fill bandwidth with "background" traffic. I've also used your idea of setting a shaper slower to see the effect too.

CreatePlease to create content