RFC 3277 (rfc3277) - Page 2 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


   A simple interoperable mechanism to alleviate the offshoot associated
   with this deterministic behavior is discussed below.

2. Discussion

   This document describes a simple, interoperable mechanism that can be
   employed in IS-IS [1, 2] networks in order to avoid transition to a
   newly available path until other associated routing protocols such as
   BGP have had sufficient time to converge.

   The benefits of such a mechanism can be realized when considering the
   following scenario depicted in Figure 1.

                                 D.1
                                  |
                              +-------+
                              | RtrD  |
                              +-------+
                              /      \
                             /        \
                        +-------+    +-------+
                        | RtrB  |    | RtrC  |
                        +-------+    +-------+
                             \        /
                              \      /
                              +-------+
                              | RtrA  |
                              +-------+
                                   |
                                  S.1

                 Figure 1: Example Network Topology

   Host S.1 is transmitting data to destination D.1 via a primary path
   of RtrA->RtrB->RtrD.  Routers A, B and C learn of reachability to
   destination D.1 via BGP from RtrD.  RtrA's primary path to D.1 is
   selected because when calculating the path to BGP NEXT_HOP of RtrD,
   the sum of the IS-IS link metrics on the RtrA-RtrB-RtrD path is less
   than the sum of the metrics of the RtrA-RtrC-RtrD path.

   Assume RtrB becomes unavailable and as a result the RtrC path to RtrD
   is used.  Once RtrA's FIB is updated and it begins forwarding packets
   to RtrC, everything should behave properly as RtrC has existing
   forwarding information regarding destination D.1's availability via
   BGP NEXT_HOP RtrD.






McPherson                    Informational