RFC 3277 (rfc3277) - Page 3 of 6

Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance

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