Juniper BGP, Configuration Manual

Page: 165 / 748

By waiting for all restarted peers to send the End-of-RIB marker, BGP risks delaying
the initiation of the best path decision process indefinitely due to a single very slow
peer. For a specific peer, you can avoid this delay by hard clearing the peer or issuing
the
clear ip bgp wait-end-of-rib command. Either method removes that peer from
the set of peers for which BGP is awaiting an End-of-RIB marker. Alternatively, you
can minimize this effect by using the
bgp graceful-restart
path-selection-defer-time-limit command to specify a maximum period that the
restarted peer waits for the marker from its peers.
Note that the receiving peer does not defer its best-path selection process while
waiting for a restarted peer to reestablish a session. The receiving peer continues to
use the stale routes from the restarted peer in the decision process. When it flushes
stale routes, the receiving peer then uses the freshly updated routes.
A restarting peer must bring the session back up and refresh its routes within a
limited period, or BGP on the receiving peer will flush all the stale routes. When a
BGP speaker advertises the graceful restart capability, it also advertises how long it
expects to take to reestablish a session if it restarts. If the session is not reestablished
within this restart period, the speaker’s peers flush the stale routes from the speaker.
You can use the
bgp graceful-restart restart-time command to modify the restart
period advertised to all peers; the neighbor graceful-restart restart-time command
modifies the restart period advertised to specific peers or peer groups. A receiving
peer starts the timer as soon as it recognizes that the session with the restarting peer
has transitioned to down.
The receiving peer also has a configurable timer that starts when it recognizes that
the session with the restarting peer has gone down. The
bgp graceful-restart
stalepaths-time command determines how long a receiving peer is willing to use
stale paths from any restarted peer; the neighbor graceful-restart stalepaths-time
command does the same for a specified restarted peer or peer group. If the receiving
peer does not receive an End-of-RIB marker from the restarted peer before the
stalepaths timer expires, the receiving peer flushes all stale routes from the peer.
In this release, BGP supports the graceful restart capability to inform peers that the
forwarding state for IPv6 address families, namely unicast, multicast, VPN unicast,
and unicast labeled subsequent address family identifiers (SAFIs), can be preserved
during a stateful SRP switchover. MPLS also provides high availability support for
IPv6 by preserving the MPLS state for IPv6 interfaces during a stateful SRP switchover.
This capability of MPLS enables BGP to support graceful restart for IPv6 labeled
address families. During a restart, BGP acts as a restarting speaker for the IPv6
unlabeled and labeled address-families. The function of BGP as a graceful restart
helper for both IPv4 and IPv6 address families had been available in lower-numbered
releases, and there is no change to this functionality in this release.
NOTE: The function of BGP as a graceful restart helper for both IPv4 and IPv6 address
families had been available in lower-numberered releases, and there is no change
to this functionality in this release.
bgp graceful-restart
Selecting the Best Path
■ 129
Chapter 1: Configuring BGP Routing