Information Technology Reference
In-Depth Information
This quick fallover improves the speed at which the Adj-RIB-In for that peer is removed.
This feature is only for external peers. If the link to an internal peer fails, it is usually
possible to route around the failed link.
Tearing down iBGP peerings because the next-hop link failed can introduce significant
network instability. A network failure that severs connectivity to the iBGP peers typically
also results in loss of reachability to the next-hop addresses for prefixes learned from those
peers. The BGP Scanner process removes those prefixes from the BGP decision process.
Refer to Chapter 2, “Understanding BGP Building Blocks,” for an explanation of the
Scanner process.
The BGP fast external fallover feature is enabled globally, not on a per-peer basis. This
feature is enabled by default. To disable this feature, under the BGP router process,
configure the command
no bgp fast-external-fallover
.
The ability to apply greater granularity to this command is provided in Cisco IOS Releases
12.0ST and 12.1. The following interface configuration command was added. The default
setting is to comply with the global setting:
ip bgp fast-external-fallover [permit | deny]
When using BGP fast external fallover, a link that is flapping repeatedly can result in BGP
prefix dampening. The link stays down a couple of seconds and then comes back up. If
BGP fast external fallover is used, the BGP session is torn down every couple of minutes,
only to be restarted a couple of seconds later. It is even possible that the BGP session will
have difficulty fully reconverging before it is torn down again.
However, BGP fast external fallover is useful for a customer edge router with multiple
eBGP sessions to upstream providers. If the links are stable and the customer requires very
fast fallover, this feature triggers BGP to act at the moment of link failure. This feature does
not work with eBGP multihop, and the peering address must be the same as the physical
interface address.
IGP/BGP Convergence Time Deltas
In general, the return of a router to service is not considered a potential cause of traffic loss.
The common focus is on detecting the failure of a router and converging around the failed
router. However, in a BGP network, a newly recovered router can result in traffic loss for a
period equal to the BGP reconvergence time. Figure 3-4 shows the flow of traffic through
the BGP network from the customer in AS 65000 to a destination in AS 200.
