[nsp] ATM problems (DSL)

Chris Roberts croberts at bongle.co.uk
Fri Apr 4 23:22:30 EST 2003


> On Fri, 4 Apr 2003, Temkin, David wrote:
>
> > What's the CPU like on the router?
>
> Looking at cricket, about 40% peak time and down to about 20% overnight
> and weekends.  Packet loss remains about the same.

What routing protocols is this router running (if any?). Look for CPU spikes
on the router with 'sh proc cpu' run a good few times over a five minute
period. This can happen when the router receives OSPF or BGP updates if you
have a particularly large or complex OSPF topology and with BGP generally
and I've seen it a lot. Usually the timing of the packet loss is during a
BGP update or OSPF flood. You may wish to consider moving your DR to another
router if it's on this router, or if not simplifying your OSPF
topology/moving this router into an NSSA area. If it's running BGP, you may
wish to look at that seriously and see if it needs to. This is better on the
7500's due to the distributed architecture, however not perfect as large BGP
updates/OSPF floods can still cause the router to stall allocating MEMD
buffers which it still needs to do to pass packets across the CyBus.

This doesn't explain why it may only affect some customers. I'm guessing
that only certain customers have complained (e.g. those trying to run gaming
or time/packet loss sensitive applications).

>
> > If I were you I'd up the hold-queue to 150 just for giggles (hold-queue
150
> > on the interface)
>
> I'll give it a shot and see what happens...
>

Increasing the hold queue may alleviate the problem temporarily if it is
this, however long term I would look at either moving this router into an
NSSA area if it isn't already or removing BGP from the router if it doesn't
really need to run it if it is this problem. I've run into a lot of problems
with routers doing this, and if you're running particularly time sensitive
applications (game servers, etc being DSL customers) increasing the hold
queue may not alleviate the perceived problems as you trade loss for (bad)
jitter.

Also, if it is running OSPF, 'sh ip ospf stat' can be your best friend.

Cheers,
Chris.



More information about the cisco-nsp mailing list