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.
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
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
