RFC 3277 (rfc3277) - Page 3 of 6
Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance
Alternative Format: Original Text Document
RFC 3277 IS-IS Transient Blackhole Avoidance April 2002
Assume now that RtrB comes back online. In only a few seconds, IS-IS
neighbor state has been established with RtrA and RtrD and database
synchronization has occurred. RtrA now realizes that the best path
to destination D.1 is via RtrB, and therefore updates it FIB
appropriately. RtrA begins to forward packets destined to D.1 to
RtrB. Though, because RtrB has yet to establish and synchronize its
BGP neighbor relationship and routing information with RtrD, RtrB has
no knowledge regarding reachability of destination D.1, and therefore
discards the packets received from RtrA destined to D.1.
If RtrB were to temporarily set its LSP Overload bit while
synchronizing BGP tables with its neighbors, RtrA would continue to
use the working RtrA->RtrC->RtrD path, and the LSP should only be
used to obtain reachability to locally connected networks (rather
than for calculating transit paths through the router, as defined in
[1]).
However, it should be noted that when RtrB goes away, its LSP is
still present in the IS-IS databases of all other routers in the
routing domain. When RtrB comes back it establishes adjacencies. As
soon as its neighbors have an adjacency with RtrB, they will
advertise their new adjacency in their new LSP. The result is that
all the other routers will receive new LSPs from RtrA and RtrD
containing the RtrB adjacency, even though RtrB is still completing
its synchronization and therefore has not yet sent its new LSP.
At this time SPF is computed and everyone will include RtrB in their
tree since they will use the old version of RtrB LSP (the new one has
not yet arrived). Once RtrB has finished establishing all its
adjacencies, it will then regenerate its LSP and flood it. Then all
other routers within the domain will finally compute SPF with the
correct information. Only at that time will the Overload bit be
taken into account.
As such, it is recommended that each time a router establishes an
adjacency, it will update its LSP and flood it immediately, even
before beginning database synchronization. This will allow for the
Overload bit setting to propagate immediately, and remove the
potential for an older version of the reloaded routers LSP to be
used.
After synchronization of BGP tables with neighboring routers (or
expiry of some other timer or trigger), RtrB would generate a new
LSP, clearing the Overload bit, and RtrA could again begin using the
optimal path via RtrB.
McPherson Informational