Hi there,

Thanks for your suggestion.

HOw would you suggest we configure QoS on this link. We are running both voice and data on the same link. Please can you advise of the config required.Also pls elobarate on the pre allocated cRTP sessions config.

Many thanks.

See:

http://cisco.com/en/US/products/sw/iosswrel/ps1830/products_feature_guide09186a0080087b13.html

In the configuration, assuming the voice endpoint are marking RTP with DSCP EF, you do not need to use IP address or anything. Just configure to match DSCP EF and put it in the LLQ.

Hope this helps, please rate all useful posts!

Hi There,

Much appreciate the response.

Just an update, we have now separated the voice and data traffic on two different serial interfaces.

The utilization on the Voice link is around 40% max, however we are still observing these output drops.

Any suggestions.Config of interface is attached-

interface Serial0/0/1

description ****link Connected to Chennai****

ip address x.x.x.x y.y.y.y

no ip redirects

no ip unreachables

no ip proxy-arp

ip tcp header-compression iphc-format

ip tcp compression-connections 256

no ip mroute-cache

no fair-queue

no cdp enable

ip rtp header-compression iphc-format

ip rtp compression-connections 1000

Also if it helps, this is a cisco 2821 router with Version 12.3(8)T11 IOS.

Is cef enabled on the router ?

You can increate the output queue a little bit, and monitor it together with router cpu, buffer utilization, etc.

If you have a link that is frequently in a congestive state then neither a QoS policy nor CEF is going to help. In fact, although you use a QoS policy to insure a certain level of service for specific traffic/applications that would only make the problem worse for other traffic flows. QoS is not a solution for a congested link; it?s more like a safety net for what should be rare occurrences of congestion. Also, increasing the output queue size can be dangerous. If packets sit in the queue too long its as good as if they had been dropped altogether.

griffijo, all what you said is correct, however in certain cases the router can exhibit drops not directly related to congestion, one typical case is buffer exhaustion. This is why the TAC has published literature on-line on how to diagnose and address 'strange' output drops cases.

That is interesting, I had not heard that. I'd be interested in reading the literature on that.

Here you go:

http://www.cisco.com/en/US/products/hw/routers/ps133/products_tech_note09186a0080094791.shtml

True however that most 'strange' problems will be input queue drops, not output.