[c-nsp] QoS problems on ATM pvc - IOS bug?

[Ben Steele]

Before applying the policy under your pvc specify the bandwidth in  
your ATM subint and make sure it's within the reserved range,  
otherwise use max-reserved-bandwidth x to accommodate it, I feel your  
pain as i've experienced the whole apply the policy it takes it then  
when you go to view it it's gone thing on the 7200's with ATM  
subint's, I found the give and take for me was due to it trying to  
reserve more than the default amount of bandwidth (75%), it just  
wouldn't error when applying the policy.

Also doesn't like LLQ using the percent command (slightly annoying but  
dealt with it via multiple policies)

Ben

On 27/03/2008, at 3:04 AM, neal rauhauser wrote:

>  This one is a real head scratcher for me. I've got two 7206s, both  
> running
> c7200-p-mz.123-22.bin, both with identical PAs. One is in  
> production, the
> other is a hot spare. I got frustrated enough with trying to get QoS  
> set up
> that I pulled this config line for line from an example on CCO:
>
> class-map match-all VoIP-Control
>  match ip precedence 3
> class-map match-all Video
>  match ip precedence 4
> policy-map WAN
>  class VoIP-Control
>   bandwidth 64
>  class Video
>   bandwidth 2000
>  class class-default
>   fair-queue
>
> And I'm applying it here:
>
> !test box PVC - this one works fine
> interface ATM2/0.666 point-to-point
> description Irritated Customer, LLC
> ip address 192.168.209.253 255.255.255.252
> pvc 5/54
>  protocol ip 192.168.209.254
>  broadcast
>  encapsulation aal5snap
>  service-policy output WAN
>
> !production box - will have nothing to do with a policy being placed  
> on the
> PVC
> interface ATM2/0.98004 point-to-point
> description Irritated Customer, LLC
> ip address 192.168.209.253 255.255.255.252
> pvc 5/54
>  protocol ip 192.168.209.254
>  broadcast
>  encapsulation aal5snap
> !many attempts to get the service policy right here, ain't put on an
> appearance yet
>
>    I've wrestled with this one quite a bit and even went so far as  
> getting
> a maintenance window and rebooting the darned thing - someone else  
> had been
> fooling with QoS stuff before they called me in and I was starting  
> to think
> maybe they'd managed to aggravate some seldom touched bits of the MQC.
>
>
>     The production machine has 32 subinterfaces which correspond to  
> frame
> T1 endpoints on the far side. There are 600+ DSL PPPoA sessions  
> terminating
> on this machine as well. The processor runs at a consistent 32%,  
> there are
> only a few hundred routes via OSPF. The engine is an NPE400 with 512  
> meg.
> The machine has been in production for quite some time and is stable  
> and
> trustworthy. There is no Smartnet on it.
>
>
>  So ... anyone have any ideas here?
>
>
>
>
> -- 
> mailto:Neal at layer3arts.com //
> GoogleTalk: nrauhauser at gmail.com
> IM: nealrauhauser
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/