06-21-2007 02:01 PM - edited 03-03-2019 05:32 PM
Hey there,
I've pasted the output from a router interface that has a policy map prioritizing VOIP and signalling. I am puzzled why I see no packets/bytes matched when my offered rate is at 14000 bps. See below,
FastEthernet0/0
Service-policy output: VOIP_Prioritization
Class-map: RTP (match-all)
4488 packets, 960432 bytes
30 second offered rate 14000 bps, drop rate 0 bps
Match: access-group 101
Queueing
Output Queue: Conversation 265
Bandwidth 26 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
Class-map: Call_Control (match-all)
65 packets, 3858 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: access-group 112
Queueing
Output Queue: Conversation 266
Bandwidth 8 (kbps) Max Threshold 64 (packets)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
Class-map: class-default (match-any)
1753 packets, 301671 bytes
30 second offered rate 1000 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
06-21-2007 02:22 PM
I confused, I see packets being matched by the class-map RTP. Currently that class map is allocating 14kbps. Once it goes over 26kbps, the surplus will go to the class-default class-map where bandwidth isn't guaranteed.
06-21-2007 10:47 PM
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
06-21-2007 11:00 PM
Try matching pkts with dscp marking rather than acl. Or run ip nbar protocol discovery on router & match with RTP.
06-22-2007 02:51 AM
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.
06-22-2007 05:33 AM
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.
06-22-2007 04:50 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide