Well it would depend. When a route is SIA EIGRP will clear the neighborship with the router that did not reply and then it will remove all routes it learnt from that neighbor.
So if the floating static is for a route that has been removed because of the above then yes, as long as the floating static had an nexxt-hop of a router that was up and running.
until the EIGRP route is in the routing table the floating static route cannot be used.
from EIGRP FAQ
When EIGRP returns a stuck in active (SIA) message, it means that it has not received a reply to a query. EIGRP sends a query when a route is lost and another feasible route does not exist in the topology table. The SIA is caused by two sequential events:
The route reported by the SIA has gone away.
An EIGRP neighbor (or neighbors) have not replied to the query for that route.
When the SIA occurs, the router clears the neighbor that did not reply to the query. When this happens, determine which neighbor has been cleared
So as soon as the EIGRP route is removed the routing table daemon will install and use the floating static route
Hope to help
This is what I get for not reading--try again.
If a route goes SIA, then EIGRP will pull the route from the routing table, because the SIA is treated as causing the route to go "passive." EIGRP will also reset the adjacency, in order to clear the outstanding queries against the route, but even if it didn't, EIGRP would pull the route from the table.
So, if you see an SIA, then you should see the route pulled from the table, then pushed back into the table once the adjacency is built, etc.
When the SIA timer expires the router would then clear all known routes from that neighbor - is that a correct assumption ?
Edit - sorry Russ i posted this before you had updated your post :-)
For any route which is active:
1. If the route goes SIA, the route is marked passive, and the route is removed from the local RIB (routing table).
2. The neighbor(s) which had not answered the query will be torn down.
3. Any routes for which the torn down neighbor is the successor will be marked active.
So, yes, the routes are removed, but it's not a result of the neighbor adjacency being taken down--it's a result of the SIA. Routes which are through the neighbor, will be marked active, not pulled from the table.
Just trying to disconnect the concept of taking the neighbor down for an SIA from the concept of pulling the SIA route from the local routing table.... I hope that makes sense....
Any time a route is pulled from the table, there is a callback to the other processes to see if some other route should replace the one just removed--it's at this point the static would be inserted into the table to replace the EIGRP route. You should be able to see the entire process if you use a debug eigrp events (or debug ip eigrp events).
Russ - the whole neighbor is torn down just for not answering a query?
It strikes me that no-hello-pkts-received-during-dead-interval is the only reason to tear down an entire neighborship. What if that neighbor didn't respond to the query but is still sending hello packets, as well as valid, passive routes (besides the route being queried) ?
So, to consider the classic query process:
1. A router marks a route active.
2. It determines there is no FS, so it puts the metric to infinity, and marks the route to be sent as a query.
3. A query is built including this route. When the query is transmitted, a timer is set--the SIA timer.
4. When the neighbor receives the query, it acknowledges receiving the query.
So, we know the neighbor has received the query. If they don't provide an answer to the query by the time the timer wakes up, the neighbor is marked SIA, and taken down. The original reason for this chain of events was:
1. We know the neighbor is still there.
2. We know we still have two way, reliable communication with the neighbor.
3. But, we know the neighbor isn't answering the query.
Hence, what we know is we've stepped outside the bounds of the state machine, as defined by DUAL. Once you step outside the state machine, the only reliable way to fix things is to restart the state machine--even though it's ugly.
EIGRP doesn't do this any longer. Instead, every so often, a router waiting on a reply to a query will send an "SIA-Query." If that packet is acknowledged, the timer is reset so we won't go SIA. _If_ you are in "new code," you shouldn't ever see SIAs, really--at least if you see one, you know something is _really_ wrong, it's not something you should see in "normal operation."
Remember, though, that the entire concept of resetting the neighbor when a route is marked SIA has nothing to do with the routing table--those are different things, in the code. The removal of the SIA route from the routing table and the neighbor reset are set off by the same event, but they are different parts of that process. The static route is called in because of the route removal on the route being marked SIA, not because of the neighbor being torn down.
No--because the router could still be running EIGRP, just not responding to queries correctly. This could actually be for many different reasons, which would still allow the router to respond to a multicast ping.
The only way to really know is to look at the EIGRP event log for the address of the neighbor the local router went SIA on, or to have neighbor logging on, and see the neighbor reset there. There is a section in the A-W book on EIGRP troubleshooting that shows how to follow an SIA through a network to the original source of the problem, I think.
You still not answer my question. Will the floating static route kick in?? Based on what Giuseppe said...It seems that yes, it will kick in after the eigrp route have been cleared from RT.