[c-nsp] Output drops on PPP multilink int

[Rodney Dunn]

I agree with the direction of putting QOS on the egress side but
rather than do "fair-queue" (if that's what you meant) please
use a MQC service-policy like this:


policy-map queueing
  class calss-default
    fair-queue

int multilink X
  service-policy out queueing

Then you can do "show policy map interface Multilink X" and see it.

There have been bugs before with how Cisco does a virtual tx ring
to make sure all proper queuing is done at the bundle level before
assigning the sequence number to the frame to reduce reorders downstream.

Other than that the most common problem we see if people feel a FE or
GE to a nxT1 bundle and the microburst cause the drops.

You can try tweaking the queue-limit in the default class to see if it
can help absorb those microburst.

To prove it's microburst in that default class put a policer at a rate
close to the nxT1 bundle speed and set transmit for conform,exceed,viloate.

Then watch the policy for exceed/violate. If you see them you know you
are microbursting coming off the LAN.

Rodney

On Mon, Sep 29, 2008 at 11:37:12AM +0930, Ben Steele wrote:
> As a test try putting some fair-queuing on your multilink interface and see
> if the problem lessens/goes away, play with the values until you find your
> sweet spot.
> 
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Church, Charles
> Sent: Monday, 29 September 2008 11:02 AM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] Output drops on PPP multilink int
> 
> Anyone,
>  
>     Seeing lots of output drops on ppp multilink interfaces across our
> network, all multiple T1s, on 2600s through 3800 routers.  The
> underlying T1 serial ints don't have many drops (maybe 0.1% of those
> found on the multilink int worst case).  Any idea what would cause drops
> on the interface?  There is no QOS or anything like that on the mu2 int,
> just an inbound ACL.  Google search didn't really turn up anything too
> useful.  CPU and memory on the routers look pretty good.  T1s seem
> pretty clean, the couple routers I watched closely didn't have any T1
> errors during the time frames when drops where occuring.  All are
> running recent 12.3 or 12.4 mainline releases.  Utilization on the
> multilink interface was low (under 25%), at least according to the 30
> second load interval.
>  
> Thanks,
>  
> Chuck
> _______________________________________________
> 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/
> 
> _______________________________________________
> 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/