177200: Dec 20 06:13:54.681 SUR: %DUAL-3-SIA: Route 10.134.1.100/30 stuck-in-active state in IP-EIGRP(0) 134. Cleaning up
177201: Dec 20 06:13:54.681 SUR: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 134: Neighbor 10.96.63.193 (Tunnel200) is down: stuck in active
177202: Dec 20 06:13:56.749 SUR: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 134: Neighbor 10.96.63.193 (Tunnel200) is up: new adjacency
Why EIGRP resets neighbour on Tunnel200? it doesn't announce 10.134.1.100/30 route at all?
From what can be learned here, the neighbor 10.96.63.193 on the Tunnel200 received a query, obviously when a new route to 10.134.1.100/30 was being searched for. It does not matter that this router did not advertise that route - when a route is placed into Active state in EIGRP and a new path is being calculated, every neighbor receives a query.
Now, the problem is that the neighbor 10.96.63.193 did not reply in due time. Either its reply did not make it in enough time (which is, however, quite suspicious because the active timer is 3 minutes), or some of its own neighbors was not able to send a reply, and thus the 10.96.93.193 itself could not provide a definitive answer you were looking for. Perhaps during the recalculation, the Tunnel200 reachability to the 10.96.63.193 was impaired for some reason, and the tunnel was inoperational - all these are speculations, as your outputs do not provide more information about the issue.
Does this SIA event occur more often, or is this a rare incident?
If this happens again you can type the following command and try to trace the root of the problem'
'show ip eigrp topology active' This will show you the information you need to find the root of this problem.
Check that site out.
But as Peter said, when the router lost the route to 10.134.1.100/30, it didn't have a FS, so the route went into
ACTIVE state, and send a query to all of it's neighbors, and then the neighbors looked for a route, and if they
didn't have one they would send the query to their neighbors, etc etc. This basically happens for a maximum of 3
minutes (default), until the end of the network is reached, or until all replies have returned. So, something prevented
your routers from getting all replies. Running the prementioned command will help you out.
Thanks, guys, i've seen that article.
But there is some things a dont't understand.
When this thing happens, there is no problem with connectivity, at least other end got pinged without problem.
Second, there is a feature in EIGRP protocol, when router receive a lost route query it should reply immideately to indicate it's alive and then, after search send query result. It seems that initiating router doesn't get that "alive" reply or second router doesn't send one.
It doesn't happen constantly, maybe several times per day, i tried to check "sho ip eigrp topo active" several times but output was empty. Look like i need to schedule it and log into file.
I think what you're talking about is SIA-Retransmit timer. There are two timers when it comes
to SIA timers. The first one is the "Active" timer, which has a default run time of 3 minutes.
Now, this is configurable via "timers active-time x" I believe. Now I forget which IOS version,
but the SIA-retransmit timer is now included on most newer IOS versions since 12.2. I could be
wrong in the exact IOS version number, but I think it was 12.2 something. Anyway, With just
the Active timer, if you had a wide reaching topology, and it took longer than 3 minutes for
a reply to come back, by default all routers which don't receive a Active timer reply will kill
off the neighbor from which it did not receive a reply from. So, if you have RA and RA sent out
a query, after 3 minutes if it did not receive a query it will kill of the neighbor of that interface
that RA sent the query out of which did not receive the query. Now, even though RA could have sent
a query to RB, and RA still has connectivity, to RB, if way down the line, the actualy problem is,
ALL routers that do not receive a reply will kill off the neighbor connected to the interface from
which didn't receive a reply. Now with the SIA-retransmit timer, As soon as the Router starts to
send our a query which starts the Active timer, it will also start the SIA-retransmit timer at the
same time. The SIA-retransmit timer helps longer reaching topologies, that may not have enough time
(default 3 minutes) to receive a reply from. Basically, when RA sends a reply out to RB, which can
go all the way down to RZ, RA will send a SIA-retransmit to RB, which has a default time of 90
seconds, when RB receives this, it will send a ACK back to RA, which will restart the Active timer
which has a default timer of 3 minutes. Now, RA will only send a SIA-retransmit 3 times with
no active reply before it stops doing this. This gives a total time of 6 minutes before the neighbor
is reset, and not the default 3 minutes. LIke I said, this helps longer reaching networks from
replying to queries. ALSO, it helps troubleshooting. If down the line from RA to RZ, the actual
problem likes with RM, RL will not receive a SIA-retransmit ACK, and ONLY!!! this neighbor will
have its neighbor killed off, which makes troubleshooting that much easier. Without the SIA-retransmit
timer, you will have to go one by one down each router to find the problem router.
I hope I wrote that good enough for you to understand!! I'm not an English major by any means
Sorry for the late reply btw.
Turned active timer off on all routers in the network.
Found one point at which routes gets stuck:
there is two routers connected by two different channels.
one channel announces all routes without filtering, and other one has distribute list, filtering specific routes.
i've noticed what on one router there is stuck routes on interface which doesn't actually announce them.
router eigrp 1
distribute-list special_traffic out Tunnel1
ip access-list standart special_traffic
permit 10.10.10.0 0.0.0.255
router B has similar config
there is active routes on router A, not 10.10.10.0/24, wating for reply from router B, like
A 10.20.20.0/24 blah, blah
1 replies blah,blah
via blah, Tunnel 1
I wonder, must Router A ask Router B over Tunnel1 about network, which has never being anounced over that interface?
Could it be that Router B misbehave by not answering request or by sending replies through over Tunnel2?
if router A loses a route and has no FS then it will start actively querying for a successor route, and if there ain't no reply within the Active time then the neighbourship will get down. Now with the SIA-Query and SIA-Reply if you've got something like this:
A----B----C and C doesn't reply then A---B neighbourship will stay up and you'll lose connectivity to the prefix on router A
as it will get flushed from routing table on A and B.
Now to alleviate stuck in active you should use summarization and/or EIGRP stub feature. But me miss information to correctly try to provide a helpful answer to your problem.
We need the topology as well as where the problem resides and the configs of interesting devices.
Don't forget to rate helpful posts.
Consider A-B-C connected in triangle. I often got situations when routes got stuck in circle. And there was connectivity betwen each other at time of checking.
Also i've got two routers connected by two links. I'm absolutely sure this links were up. But still, every time any route gets active it got stuck over the same link. This link is very important, it is used for video and dropping neighbour on that link drives me crasy.