Re: [nsp] troubleshooting stuck in active routes

From: Stephen Sprunk (ssprunk@cisco.com)
Date: Mon Oct 08 2001 - 15:10:10 EDT


Thus spake "CLAEREBOUDT Elke" <ECLAEREB@mail.mobistar.be>
> We are experiencing a lot of stuck in actieve routes on our network,
not
> that bad problem, but it also causes clearing of eigrp neighbourships
> which is troubling is a bit more.

Actually, it is a bad problem. SIAs should *never* occur in a properly
operating network. Routes should never be active for more than a split
second, much less three minutes.

> I could trace the problem. The problem occurs when a router dials in
> on a pop with a fix ip address. Those addresses are know as rip
> routes which then are redistributed in the eigrp all over the network.

Is there any way you can summarize these routes or otherwise limit the
query domain? Static null routes for the individual IPs? Anything?
Without knowing more details, I can't suggest anything specific.

> When those routes dissapear, we sometimes have the SIA's and the
> clearing of neighbourships. It isn't always the same router which
isn't
> responding to the queries, there's really no line that is congested,
no
> trouble with cpu or memory.
> ...
> Is this a problem which we can solve, ( summarizing the flapping
> routes is not a solution for us) ?

If there is absolutely nothing you can do about the routes disappearing
(which I would question), you're going to continue to have this problem.

> I understand why the routes are going in SIA, but I don't get it why
all
> routers don't respond in time, it's not a big network, so a timeout of
3 min
> should cause not such a problem.

Based on the information you included, it appears that the query from RB
to RD got lost, or the response from RD to RB got lost. Since it also
appears that RD was the router that originally went Active for the
route, RD should be responding to RB immediately with Inaccessible.
Also, since there is a huge speed mismatch (DS3 vs DS1, or E3 vs E1)
between the links at RD and RB, it's likely there was a temporary link
overrun which caused the SIA.

Remember, the loss of a single EIGRP query or reply packet can cause an
SIA event. Not correctly configuring traffic shaping (either FR or ATM)
is the usual culprit, with lousy carrier service in second place.

S



This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:13:19 EDT