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:[EMAIL PROTECTED] // > GoogleTalk: [EMAIL PROTECTED] > IM: nealrauhauser > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
