Intermediate System to Intermediate System (IS-IS) Transient Blackhole Avoidance
RFC 3277
|
Document |
Type |
|
RFC - Informational
(April 2002; No errata)
|
|
Author |
|
Danny McPherson
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
|
This information refers to IESG processing after the RFC was initially published: |
IESG |
IESG state |
|
RFC 3277 (Informational)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Bill Fenner
|
|
IESG note |
|
Responsible: RFC Editor
|
|
Send notices to |
|
<tli@procket.com>, <prz@xebeo.com>
|
Network Working Group D. McPherson
Request for Comments: 3277 TCB
Category: Informational April 2002
Intermediate System to Intermediate System (IS-IS)
Transient Blackhole Avoidance
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document describes a simple, interoperable mechanism that can be
employed in Intermediate System to Intermediate System (IS-IS)
networks in order to decrease the data loss associated with
deterministic blackholing of packets during transient network
conditions. The mechanism proposed here requires no IS-IS protocol
changes and is completely interoperable with the existing IS-IS
specification.
1. Introduction
When an IS-IS router that was previously a transit router becomes
unavailable as a result of some transient condition such as a reboot,
other routers within the routing domain must select an alternative
path to reach destinations which have previously transited the failed
router. Presumably, the newly selected router(s) comprising the path
have been available for some time and, as a result, have complete
forwarding information bases (FIBs) which contain a full set of
reachability information for both internal and external (e.g., BGP)
destination networks.
When the previously failed router becomes available again, it is only
seconds before the paths that had previously transited the router are
again selected as the optimal path by the IGP. As a result,
forwarding tables are updated and packets are once again forwarded
along the path. Unfortunately, external destination reachability
information (e.g., learned via BGP) is not yet available to the
router, and as a result, packets bound for destinations not learned
via the IGP are unnecessarily discarded.
McPherson Informational [Page 1]
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 [Page 2]
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
Show full document text