2013/11/27

WB1 7.55 BGP Fast Fallover

7.55 BGP Fast Fallover

Disable the BGP feature in R3 that allows for eBGP peering session deactivation when a physical interface goes down.
• Configure all R3’s BGP peering session for fast peering deactivation.


--------------------------------------------------

It is common to have eBGP peers directly connected across a physical interface.
With point-to-point links this allows for fast external session deactivation based
on the interface protocol state. That is, as soon as the interface connecting to an
external peer signals protocols down, the BGP process may deactivate the
peering session without waiting for the hold-down time to expire
. This feature is
enabled by default for eBGP sessions using the BGP process command bgp
fast-external-fallover
. Notice that this feature is only efficient when the
peering session is established across the non-shared link – using it on NBMA
and Ethernet interfaces might be inefficient.


A more advanced version of this feature is available in recent IOS release. The
new feature is called “fast peering session deactivation support” and could be
configured on a per-neighbor basis using the command neighbor <IP>
fall-over
. This feature applies to both iBGP and eBGP (mostly multi-hop)
sessions and does not depend on interface state. The IGP route used to reach
the peer configured for fast session deactivation is monitored by the BGP
process. Once the IGP route disappears, the BGP session gets immediately torn
down, unless there is a backup IGP route to reach the peer. Thus, the new
feature is event driven and allows for fast detection of peering issues even for
iBGP (non-direct) sessions. Notice that this feature has the same limitation as the
fast-external-fallover – if the peer is connected via a shared interface, the router
may not detect the loss of the directly connected IGP network. In situations like
this, you may use point-to-point NBMA subinterfaces or reliable static /32 routes
on the shared NBMA or Ethernet interfaces.

Keep in mind that convergence improvements result in less stable topology. In
order to minimize the impact of IGP instabilities on BGP tables, use event
dampening technologies (such as ip dampening) and prefix summarization.

--------------------------------------------------

R3:
router bgp 200
 no bgp fast-external-fallover
 neighbor 155.1.0.5 fall-over
 neighbor 155.1.13.1 fall-over
 neighbor 155.1.23.2 fall-over
 neighbor 155.1.37.7 fall-over
 neighbor 155.1.58.8 fall-over
 neighbor 155.1.108.10 fall-over


--------------------------------------------------

測試前,先關閉外面的AS

R3:
router bgp 200
 neighbor 155.1.13.1 shutdown
 neighbor 155.1.37.7 shutdown

R4:
router bgp 100
 neighbor 155.1.45.5 shutdown


--------------------------------------------------

Rack1R3#show ip bgp neighbors 155.1.108.10
BGP neighbor is 155.1.108.10,  remote AS 200, internal link
 Fall over configured for session
  BGP version 4, remote router ID 150.1.10.10
  BGP state = Established, up for 07:10:28

--------------------------------------------------

Rack1R3#debug ip bgp rib-filter
BGP Rib filter debugging is on


Rack1SW2(config)#
Rack1SW2(config)#interface port-channel 1
Rack1SW2(config-if)#shutdown


Rack1R3#show clock
*07:18:13.114 UTC Fri Mar 1 2002


Rack1R3#
*Mar  1 07:18:19.234: BGP- ATF: EVENT 155.1.108.0/24 RIB update DOWN
*Mar  1 07:18:19.238: BGP- ATF: T 155.1.108.10/32 (0) c=0x66C61040 Query pending
*Mar  1 07:18:19.238: BGP- ATF: R 155.1.108.0/24 (0) -> Se1/0.1 155.1.0.5 Deleting
*Mar  1 07:18:19.246: BGP- ATF: EVENT Query 155.1.108.0/24 (0) did not find route
*Mar  1 07:18:19.246: BGP- ATF: Notifying 155.1.108.0/24 (0)
*Mar  1 07:18:19.250: BGP- ATF: T 155.1.108.10/32 (0) c=0x66C61040 Adding to client notification queue
*Mar  1 07:18:19.250: BGP- ATF: EVENT 155.1.108.0/24 RIB update DOWN
*Mar  1 07:18:19.250: BGP- ATF: EVENT 150.1.10.0/24 RIB update DOWN
*Mar  1 07:18:19.250: BGP- ATF: EVENT 150.1.10.0/24 RIB update DOWN
*Mar  1 07:18:19.250: BGP- ATF: EVENT 155.1.10.0/24 RIB update DOWN
*Mar  1 07:18:19.250: BGP- ATF: EVENT 155.1.10.0/24 RIB update DOWN
*Mar  1 07:18:19.258: BGP- ATF: T 155.1.108.10/32 (0) c=0x66C61040 EVENT Track stop
*Mar  1 07:18:19.262: BGP- ATF: T 155.1.108.10/32 (0) c=0x66C61040 Removing
Rack
*Mar  1 07:18:19.262: %BGP-5-ADJCHANGE: neighbor 155.1.108.10 Down Route to peer lost
Rack1R3#

Notice that now BGP brings the peering session down because the route to reach the peer is lost.

沒有留言:

張貼留言