cancel
Showing results for 
Search instead for 
Did you mean: 
cancel

"BGP Neighbor fall-over” Command Overview

21092
Views
30
Helpful
1
Comments

 

Introduction:

In this document you will learn about “Neighbor fall-over” command used to enable the BGP fast peering session deactivation.

 

Description:

When you configure BGP peering by default, the BGP hold timer is set to run every 180 seconds in Cisco IOS software. This timer value is set as default to protect the BGP routing process from instability that can be introduced by peering sessions with other routing protocols. BGP routers typically carry large routing tables, so frequent session resets are not desirable. In previous document we have seen “Bgp Fast-external-failover” command overview that relies only on directly connected neighbor whereas “neighbor fall-over” command neighbors don't need to be directly connected.

 

When you configured “Neighbor fail-over” command under BGP process, it monitors RIB and if route to peer is not present in routing table it will immediately deactivate peer session without waiting for hold down timer. This feature is also event driven and configured on a per-neighbor basis. We will see this feature using following configuration example.

 

Configuration Example:

 

In our topology we have R1-R2-R3 connected as shown in below diagram.

 

BGP_fastfallover.jpg

 

We are running OSPF as IGP in area 0.Routers interfaces and loopbacks IP address are preconfigured.R1 is forming IBGP Peering to router R3 in AS1 .

 

Basic Configuration of R1, R2 and R3:

 

R1R2R3

R1:

hostname R1

!

ip cef

!

interface Loopback0

ip address 1.1.1.1 255.255.255.255

!

interface FastEthernet0/0

ip address 10.1.1.1 255.255.255.252

!

router ospf 100

log-adjacency-changes

network 1.1.1.1 0.0.0.0 area 0

network 10.1.1.0 0.0.0.255 area 0

!

router bgp 1

no synchronization

bgp log-neighbor-changes

neighbor 3.3.3.3 remote-as 1

neighbor 3.3.3.3 update-source Loopback0

!

hostname R2

!

ip cef

!

interface Loopback0

ip address 2.2.2.2 255.255.255.255

!

interface FastEthernet0/0

ip address 10.1.1.2 255.255.255.252

!

interface FastEthernet0/1

ip address 10.1.1.5 255.255.255.252

!

router ospf 100

log-adjacency-changes

network 2.2.2.2 0.0.0.0 area 0

network 10.1.1.0 0.0.0.255 area 0

hostname R3

!

ip cef

!

interface Loopback0

ip address 3.3.3.3 255.255.255.255

!

interface FastEthernet0/0

ip address 10.1.1.6 255.255.255.252

!

router ospf 100

log-adjacency-changes

network 3.3.3.3 0.0.0.0 area 0

network 10.1.1.0 0.0.0.255 area 0

!

router bgp 1

no synchronization

bgp log-neighbor-changes

neighbor 1.1.1.1 remote-as 1

neighbor 1.1.1.1 update-source Loopback0

no auto-summary

 

Let verify IBGP peering between R1 and R3:

 

R1#sh ip bgp sum | beg Nei

Neighbor       V   AS MsgRcvd MsgSent   TblVer InQ OutQ Up/Down State/PfxRcd

3.3.3.3         4     1     33     37       1   0   0 00:03:44       0

R1#

 

Also Verifying hold down timer:

 

R1#sh ip bgp nei 3.3.3.3 | in hold

Last read 00:00:09, last write 00:00:09, hold time is 180, keepalive interval is 60 seconds

minRTT: 92 ms, maxRTT: 300 ms, ACK hold: 200 ms

R1#

 

Case1:  We will verify BGP default behavior that BGP process will down peer after hold down time expires.

We will shutdown R2s interface fa0/1 pointing to R3 will cause to remove 3.3.3.3 route on R1.To get close route deletion view we are turning IP routing debug on R1.

 

R1#sh ip route | in 3.3.3.3

O       3.3.3.3 [110/21] via 10.1.1.2, 00:12:10, FastEthernet0/0

R1#debug ip routing

IP routing debugging is on

R1#

 

 

R2#conf t

Enter configuration commands, one per line. End with CNTL/Z.

R2(config)#int fa0/1

R2(config-if)#sh

R2(config-if)#exit

R2(config)#

*Mar 1 02:06:55.223: %OSPF-5-ADJCHG: Process 100, Nbr 3.3.3.3 on FastEthernet0/1 from FULL to DOWN, Neighbor Down: Interface down or detached

R2(config)#

*Mar 1 02:06:57.211: %LINK-5-CHANGED: Interface FastEthernet0/1, changed state to administratively down

*Mar 1 02:06:58.211: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to down

R2(config)#

 

From the below output taken on R1 console , you can see that even peer routes to R3 i.3.3.3.3 is deleted from routing table, BGP neighborship was not down till hold down timer expires( you can see the logs timer).

 

R1#

*Mar 1 02:07:02.035: RT: del 10.1.1.4/30 via 10.1.1.2, ospf metric [110/20]

*Mar 1 02:07:02.039: RT: delete subnet route to 10.1.1.4/30

*Mar 1 02:07:02.039: RT: NET-RED 10.1.1.4/30

*Mar 1 02:07:02.039: RT: del 3.3.3.3/32 via 10.1.1.2, ospf metric [110/21]

*Mar 1 02:07:02.043: RT: delete subnet route to 3.3.3.3/32

*Mar 1 02:07:02.043: RT: NET-RED 3.3.3.3/32

*Mar 1 02:07:02.043: RT: delete network route to 3.0.0.0

*Mar 1 02:07:02.047: RT: NET-RED 3.0.0.0/8

R1#

R1#

*Mar 1 02:09:15.079: %BGP-5-ADJCHANGE: neighbor 3.3.3.3 Down BGP Notification sent

R1#

*Mar 1 02:09:15.079: %BGP-3-NOTIFICATION: sent to neighbor 3.3.3.3 4/0 (hold time expired) 0 bytes

 

Case 2: Now we will configure “neighbor fallover” command on R1.

 

I have “no shut” R2s interface pointing to R3 .R1 is again forming IBGP neighborship with R3.

 

R1#conf t

Enter configuration commands, one per line. End with CNTL/Z.

R1(config)#router bgp 1

R1(config-router)#nei 3.3.3.3 fall-over

*Mar 1 02:22:51.059: RT: Try lookup less specific 3.3.3.3/32, default 1

*Mar 1 02:22:51.063: RT: Found subnet on less specific 3.3.3.3/32

R1(config-router)#end

R1#

 

Now let’s shutdown R2 interface fa0/1 and verify output on R1's console:

 

R2(config-if)#sh

R2(config-if)#

*Mar 1 02:24:08.659: %OSPF-5-ADJCHG: Process 100, Nbr 3.3.3.3 on FastEthernet0/1 from FULL to DOWN, Neighbor Down: Interface down or detached

R2(config-if)#

*Mar 1 02:24:10.647: %LINK-5-CHANGED: Interface FastEthernet0/1, changed state to administratively down

*Mar 1 02:24:11.647: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to down

R2(config-if)#

 

R1#

*Mar 1 02:24:15.455: RT: del 10.1.1.4/30 via 10.1.1.2, ospf metric [110/20]

*Mar 1 02:24:15.459: RT: delete subnet route to 10.1.1.4/30

*Mar 1 02:24:15.459: RT: NET-RED 10.1.1.4/30

*Mar 1 02:24:15.459: RT: del 3.3.3.3/32 via 10.1.1.2, ospf metric [110/21]

*Mar 1 02:24:15.463: RT: delete subnet route to 3.3.3.3/32

*Mar 1 02:24:15.463: RT: NET-RED 3.3.3.3/32

*Mar 1 02:24:15.463: RT: delete network route to 3.0.0.0

*Mar 1 02:24:15.467: RT: NET-RED 3.0.0.0/8

*Mar 1 02:24:15.475: RT: Try lookup less specific 3.3.3.3/32, default 1

*Mar 1 02:24:15.479: RT: Failed found major net on less specific

*Mar 1 02:24:15.479: RT: return NULL

R1#

*Mar 1 02:24:15.483: %BGP-5-ADJCHANGE: neighbor 3.3.3.3 Down Route to peer lost

 

From the above output we can see that the IBGP session is terminated as soon as the IP route towards the IBGP peer is lost.

 

Sometime you might have default route configure on router, then the withdrawn of the route to BGP peer's address will not trigger the BGP session deactivation.

 

To address this issue, you can use "Selective Address Tracking" along with the "neighbor fall-over" command.

 

Here is sample example:

 

1st Configure prefix list then apply it in route-map and attached in "neighbor fall-over" command.

R1(config)#ip prefix-list R3_ROUTE permit 3.3.3.3/32

R1(config)#route-map Track_R3_l0

R1(config-route-map)#match ip address prefix-list R3_ROUTE

R1(config)#router bgp 1

R1(config-router)#neighbor 3.3.3.3 fall-over route-map Track_R3_l0

 

Note:
Only match ip address and match source-protocol commands are supported in the route map. No set commands or other match commands are supported.
 

Related Information:

BGP Support for Fast Peering Session Deactivation

BGP Support for Next-Hop Address Tracking

Understanding BGP nexthop trigger function use for Nexthop Tracking

Comments

Hi,

Could you please share command on IOS XR?

Thank you very much.