[c-nsp] QoS ATM sub interface

[Jason Berenson]

Nathan, et al,

It turns out this may be a cisco bug.  I have a ticket opened with TAC 
and will send an update when this is fixed in case anyone cares.

-Jason

Nathan wrote:
> On Fri, May 23, 2008 at 2:31 PM, Robert Blayzor <rblayzor.bulk at inoc.net> wrote:
>   
>> On May 22, 2008, at 6:06 PM, Jason Berenson wrote:
>>     
>>> 7206 NPE-G1
>>> PA-A3-OC3MM
>>> c7200-is-mz.124-19.bin
>>>       
>
> I usually use IOS-es with a j instead of i, but I hope any 12.4 has QoS...
>
>   
>> Been down this path several times, so hopefully this helps.
>>
>> Have you tried using a hierarchal QoS policy?  Also you may want to
>> set your tx-ring-limit to the minimum, ie: 3 or you might have some
>> jitter issues.
>>
>> That being said, you need to use a nested QoS policy, something like:
>>     
>
> This should not be necessary, since the ATM definition provides the
> bandwidth. Maybe for the fair-queue, but... Jason, test without that
> :-)
>
> Here's what works for me (very slightly edited):
>
>  class-map match-any routing
>   match  dscp cs6  cs7
>  class-map match-any voice
>   match  dscp cs5  ef
>   match ip dscp 4
>  class-map match-any af43
>   match ip dscp af43
>
>  policy-map outgoingaf
>   class voice
>    priority percent 50
>   class af43
>    bandwidth percent 20
>   class routing
>    bandwidth percent 1
>   class class-default
>
> vc-class atm DSL-1
>   vbr-nrt 1280 1280 94
>   encapsulation aal5snap
>
> interface ATM3/0.xxx point-to-point
>  ip address x.x.x.x x.x.x.x
>  ip verify unicast reverse-path
>  pvc 1/xxx
>   class-vc DSL-1
>   service-policy output outgoingaf
>
> But I've often used access-lists and ISTR fair-queue without any
> problems (or when there was a problem I always had something in the
> logs).
>
>