Thursday 23 October 2008

WTF??? Policing a Priority Queue

I was looking at how QoS on our routers at work is configured and I came across the following:

Policy Map QOS-OUT
Class VOICE-OUT
Strict Priority
Bandwidth 2700 (kbps) Burst 337500 (Bytes)
police cir 2712000 bc 339000 be 339000
conform-action set-dscp-transmit ef
exceed-action drop


Now I was confused I had always thought that you did not need to police on a priority queue because policing was built in to the priority command. The way I understood it was that as soon as you typed priority and then the bandwidth, that was the maximum bandwidth that would be allocated to the priority queue and so there was no need for a policer. Am I wrong has anyone else seen this configuration before? Is it normal and a case of what is actually used in the real world rather than what you learn from Ciscopress? Also which command would take precedence the police or the priority command if you set them to different rates?

When I asked why it was setup this way, I was told the police command was better for producing logging as the priority command just dropped packets and did not tell you if your priority traffic was exceeding the bandwidth you had provisioned. Therefore you would not know if you needed to increase your priority queue bandwidth. At first I accepted this explanation but then when I thought about it a bit more and did a show policy-map interface I got the information below.

Class-map: VOICE-OUT (match-any)
151522 packets, 13014864 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: ip dscp ef (46)
151140 packets, 13001580 bytes
30 second rate 0 bps
Match: access-group name VOICE-OUT
382 packets, 13284 bytes
30 second rate 0 bps
Queueing
Strict Priority
Output Queue: Conversation 264
Bandwidth 2700 (kbps) Burst 337500 (Bytes)
(pkts matched/bytes matched) 25068/1912731
(total drops/bytes drops) 0/0
police:
cir 2712000 bps, bc 339000 bytes
conformed 151522 packets, 13014864 bytes; actions:
set-dscp-transmit ef
exceeded 0 packets, 0 bytes; actions:
drop
conformed 0 bps, exceed 0 bps


Which to me showed that the priority command does show how many packets/bytes have been dropped. So I do not think logging would be the reason for adding the police command as well. I am leaning towards misconfiguration at the moment, but I would love to hear from people with more QoS experience than me to explain what is going on here.

3 comments:

Anonymous said...

You are correct there is no need to police the queue once you add the priority command. The bandwidth you enter in the priority queue will police that queue for you.

I am not sure what the Cisco Press book says about adding both commands but if your priority queue has both configured. The lower of the two values would take precedence.


In the real world I never setup the police command on a Priority Queue.

You can see packets dropped with the show policy map command.

Ronnie
CCIE 13834

Anonymous said...
This comment has been removed by a blog administrator.
The Ferret said...

thanks for this just wanted to check this out as I thought it was a silly configuration, but was a bit unsure of myself. I also read recently that in newer versions of the IOS the priority command only policies when there is congestion on the link where as in older versions of the IOS it is an absolute policer.