Hi BRADLEY

As far as I understand the packets in this case are rtp packets being matched by the rtp class . whenever your link is congestion then you will see the matched packets in this paragraph.

Queueing

Output Queue: Conversation 265

Bandwidth 26 (kbps) Max Threshold 64 (packets)

(pkts matched/bytes matched) 0/0 // there is no match in this time.

If your link isn't congestion then you will only see the matched packets in this paragraph

Class-map: RTP (match-all)

4488 packets, 960432 bytes // Every packets are matched with ACL that you defined in the rtp class .No matter what your links are congestion.

Are you testing or your production? Can you do congestion on fastethernet? if not can you test software queuing on a serial interface and do something such as setting lower clock rate and transferring a hog file size and then calling your voice.

Let us know with "Show Policy-Map" again.

Hope this helps

Thot

Try matching pkts with dscp marking rather than acl. Or run ip nbar protocol discovery on router & match with RTP.

Hey Thot you got it right.

If an interface is able to process packets below its serialization rate then no qos mechanisms are needed as the packets will be able to exit fifo with no problems.

Once the interface hardware and software queue start filling up that is when the qos mechanisms kick in.

That policy map output won't show the RTP packets as matched because they never had to be processed through a priority queue.

Like you thought, once utilization picks up enough for priority queuing to take place then matching occurs.

To validate this I rate limited a T1 down to 64k and created a priority queue matching on ICMP. If I did a normal size ping I would see the offered rate increment by 104 bytes with each packet but with no increase to the (pkts matched/bytes matched output). After verifying this I started hammering the router with pings of a size to exceed 64kbs. These caused the (pkts matched/bytes matched)field to increment.

I might try it tomorrow with iperf just to see at what percentage of the interface utilization do the qos mechanisms kick in. Ive always been curious about that.

Thanks a lot for the information guys. This router port is connected to an Alvarion AP-10 radio that has 2 meg of bandwidth configured on it. Unfortunately, the radio has about a 200 to 300 pps limitation. From what i've seen, it is probably closer to 200 pps. I am constantly seeing output errors on the router port that the radio connects to. Not sure if prioritizing VOIP is the silver bullet here or not. Any input is always appreciated.

Hi Bradley,

Class-map: RTP (match-all)

4488 packets, 960432 bytes

30 second offered rate 14000 bps, drop rate 0 bps

The above traffic indicates "Number of packets identified as belonging to the class of traffic being displayed"

(pkts matched/bytes matched) 0/0

This above output indicates "Number of packets (also shown in bytes) matching this class that were placed in the queue. This number reflects the total number of matching packets queued at any time. Packets matching this class are queued only when congestion exists. If packets match the class but are never queued because the network was not congested, those packets are not included in this total"

Since you have enabled the policy-map on the Fa0/0 interface which is 100 Mbps, thats why i guess there are not pks matches because no queuing is occuring. If you are seeing drops for your Voip packets, try increasing the bandwidth allotted for Voip and monitor the drops then.

- Manoj