Now that the internetwork in Figure 4.3 is fully converged, how will it handle reconvergence when some
part of the topology changes? If network 10.1.5.0 goes down, the answer is simple enough—router D, in
its next scheduled update, flags the network as unreachable and passes the information along.
But what if, instead of 10.1.5.0 going down, router D fails? Routers A, B, and C still have entries in their
route tables about 10.1.5.0; the information is no longer valid, but there's no router to inform them of this
fact. They will unknowingly forward packets to an unreachable destination—a black hole has opened in
the internetwork.
This problem is handled by setting a route invalidation timer for each entry in the route table. For
example, when router C first hears about 10.1.5.0 and enters the information into its route table, C sets a
timer for that route. At every regularly scheduled update from router D, C discards the update's alreadyknown
information about 10.1.5.0 as described in "Routing by Rumor." But as C does so, it resets the
timer on that route.
If router D goes down, C will no longer hear updates about 10.1.5.0. The timer will expire, C will flag the
route as unreachable and will pass the information along in the next update.
Typical periods for route timeouts range from three to six update periods. A router would not want to
invalidate a route after a single update has been missed, because this event may be the result of a corrupted or lost packet or some sort of network delay. At the same time, if the period is too long,
reconvergence will be excessively slow.