No, that isn't true... Think of your typical dual homed remote router:
A---B---C---D
Assume that C is the remote router, B and D are the distribution (hub) routers, and A is some other router in the core of the network. Assume the links between B and C and D and C are low speed "dirty" links. A also has some link to D, so it's not really a straight line like this, but it's hard to draw using ascii here. :-)
What would normally happen when A loses its route to some destination, say a locally configured loopback? It would send a query to B, which would then send a query to C, and C would then send a query to D. If the two links to C are low speed dirty links, A would be waiting on the query from B to C, then on the query from C to D, to clear its active state.
However, if C is a stub, B will simply not send this query--it will reply to A's query stating it has no other way to reach the destination which has disappeared. Once A has received this reply, it will send a following update telling B that it has lost reachability to this destination. B will then send an update to C with this information, as well.
Now, let's look at what happens at C. The remote router may or may not have an alternate route to this loopback on A. Suppose it doesn't--it knows about D, but it doesn't know that the loopback on A is reachable through that neighbor. If the link from A to B has failed, rather than the loopback failing on A, then how would C ever know about this reachability? It has to send a query to D to find out if there is an alternate path.
By the way, the odds of C not knowing about an alternate path through D to A's loopback are pretty slim.... Split horizon is the primary reason that any router in an eigrp network doesn't know about some alternate path, and in this situation, if C is a stub, it will never advertise A's loopback to D, so D would never split horizon an advertisement for A's loopback to C (!). The only other options would be summarization at D towards C, in which case any query C sends to D is going to have a reply of not reachable this direction, or filtering at D towards C, which will have the same result. The only reason you're seeing the query here is because there is no alternate path.
Anyway, this is the query you are seeing. But go back to how stubs work, and consider this: Stubs can never be transits. So, D could not have ever heard about A's loopback through C, correct? Therefore, C couldn't have ever been a valid path to A's loopback at D. When you consider this, you realize that D could never go active because of this query from C. Either D is already active, looking for another path to A's loopback, in which case it will hold on to C's query until it receives the other responses it is waiting on (but it will never wait on a response from C), or it will know a good alternate path, and answer immediately, or it will not know about the destination at all, and will answer immediately.
In short, there's no way for D to go stuck in active waiting on C, and the dirty/slow C to D link, under any circumstances. The query is there, from C to D, and C could go stuck in active waiting on D, but this will have little to no impact on the network, since C doesn't transit any traffic between B and D. But it's impossible for the distribution layer to be impacted through a stuck in active because of problems at C.
I know it's complicated, it took us a lot of hours on the whiteboard to go through all of the situations, and decide to leave the stub to distribution queries in. In the lab, we see stubs allowing a router to have just about four times as many neighbors on a single link in most situations, and when stubs were introduced, the sia calls into tac fell considerably. With the sia rewrite rolling out, it's actually rare to see tac cases on sia's any longer.
Hope that helps.... If I can ever get my butt in gear on the eigrp white paper rewrite, I'll make certain this is all explained with real diagrams there.
Russ.W
