[nsp] QoS not working

Volodymyr Yakovenko vovik at dumpty.org
Wed Mar 5 03:20:21 EST 2003

On Tue, Mar 04, 2003 at 06:48:33PM -0500, jlewis at lewis.org wrote:
>I've got a number of problems here.  On my end, IOS will let me put a 
>'service-policy output cust-VOIP' in the pvc section of the customer's 
>ATM3/0.45 interface, but the command doesn't show up in a show run...so 
>I'm guessing that even though there was no error, it's not actually being 
>accepted.  Can I do this or another type of prioritization without 
>involving virtual templates?

If you can configure fair-queue on ATM subinterface than 'ip rtp priority'
will be enough (it actualy creates priority queue for RTP traffic).

>On the customer end, I put the service-policy on the s1 interface (IP is
>configured on s1.1, but the subinterface won't accept a service-policy).
>It's accepted and seems to function.  At least the counters show
>packets matching the priority queue, but when large files are uploaded
>from a PC connected to the 1600's ethernet, VOIP quality noticably

Which codecs are you using? 

What is the actual bandwith between 1600 and 7206?

You may need to lower MTU or perform some sort of RTP/data packets 

>Here's part of the config from the 1600.
>class-map cust-voice
>  match access-group 150
>policy-map cust-VOIP
>  class cust-voice
>    priority 1158
>  class class-default
>   fair-queue 
>access-list 150 permit ip host any
> is the IP of the VOIP device.  I started with lower priorities 
>and ended up at 1158 (the max) with no improvement.

Too complicated, I guess 

int X
 ip rtp priority 1634 32767 NUM

 where NUM - bandwith reserved for priority queuing RTP packets 

will be enough in most cases.

>Only by using CAR on the 1600 (I was surprised it was supported) was I
>able to guarantee bandwidth for the VOIP traffic by limiting everything
>else.  That's not going to work for the customer's central site though,
>where lots of people will be working from home and doing both VOIP and
>file transfers and other traffic.
>Is this a bug in LLQ, or am I not configuring it properly?  Ideally, I 
>need some way of doing this that will scale to doing a bunch of customers 
>on our 7206.

It could be easier to understand if you show your 7206 config.
Detailed 1600 config, and 'sh queue' on approriate interfaces from
1600 and 7206 also would be usefull.


More information about the cisco-nsp mailing list