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

[Gary Roberton]

Check the TX Ring limit.  The TX Ring is the number of particles/packets
that queue in the hardware queue before being transmitted out of the
interface.  If this is set too big you can experience problems with packets
seeming to be placed and process through the Priority queue, when in fact
they are now sat in a hardware queue.

Under the interface;

interface ATM0

pvc 0/38

tx-ring-limit 3

Hope it helps - or at least rules out that this isn't the problem.

Gary



On Wed, Mar 26, 2008 at 4:34 PM, neal rauhauser <nrauhauser at gmail.com>
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/
>