BGP fast session deactivation also speeds up session establishment
You might have been there before: the BGP neighbor becomes reachable after you fix a fault in the network, but the BGP session takes “forever” to be established (actually, the hold off is less than a minute, but time is running slower when you are waiting for the network to recover). However, when testing the BGP fast peering session deactivation, I made an interesting discovery: the restart time is improved as well; as soon as the path to the BGP neighbor appears in the IP routing table, the BGP session is established. The debugging printouts from my router are included below (I've used neighbor 10.0.3.3 fall-over configuration command):
03:28:42: RT: add 10.0.3.3/32 via 10.2.0.2, ospf metric [110/75]
03:28:42: RT: NET-RED 10.0.3.3/32
03:28:44: RT: Try lookup less specific 10.0.3.3/32, default 1
03:28:44: RT: Found subnet on less specific 10.0.3.3/32
03:28:44: %BGP-5-ADJCHANGE: neighbor 10.0.3.3 Up
Is there a difference between the "(no) neighbor x.y.z fall-over" and the "(no) bgp fast-external-fallover" (except that the first one is for neighbors and the second one globally)?
I believe the "(no) neighbor x.y.z fall-over" applies to iBGP sessions (BGP sessions established to a neighbor in the same AS) and "(no) bgp fast-external-fallover" applies only to EBGP sessions (BGP sessions established to a neighbor with a different AS).
Q. What is the default BGP ConnectRetry timer, and is it possible to tune the BGP ConnectRetry timer?
A. The default BGP ConnectRetry timer is 120 seconds. Only after this time passes does the BGP process check to see if the passive TCP session is established. If the passive TCP session is not established, then the BGP process starts a new active TCP attempt to connect to the remote BGP speaker. During this idle 120 seconds of the ConnectRetry timer, the remote BGP peer can establish a BGP session to it. Presently, the Cisco IOS ConnectRetry timer cannot be changed from its default of 120 seconds.
The URL is here:
http://www.cisco.com/en/US/tech/tk365/technologies_q_and_a_item09186a00800949e8.shtml#twenty-two
i see the neighbor fallover command on my 7600 but not on my 6500. can anybody confirm this?
My BGP Fast Session Deactivation (with Selective Address Tracking) immediately detects loss of neighbor, but doesn't establishes session after BGP neighbor becomes reachable via alternate route.
Nov 26 13:10:49.747: %BGP-5-ADJCHANGE: neighbor 172.31.255.65 Down Route to peer lost
Nov 26 13:10:49.783: RT: add 172.31.255.65/32 via 172.31.255.33, isis metric [115/20]
Nov 26 13:10:49.787: RT: NET-RED 172.31.255.65/32
Nov 26 13:10:49.787: RT: add 172.31.255.65/32 via 172.31.255.33, isis metric [115/20]
Nov 26 13:10:49.787: RT: NET-RED 172.31.255.65/32
Nov 26 13:10:49.791: BGP- ATF: EVENT 172.31.255.65/32 RIB update UP
Nov 26 13:10:49.791: BGP- ATF: 172.31.255.65/32 (0) Adding route
...
Nov 26 13:11:23.124: BGP- ATF: EVENT 172.31.255.65/32 (0) Track start
Nov 26 13:11:23.128: BGP- ATF: 172.31.255.65/32 (0) Adding track
Nov 26 13:11:23.128: RT: Try lookup less specific 172.31.255.65/32, default 1
Nov 26 13:11:23.128: RT: Found subnet on less specific 172.31.255.65/32
Nov 26 13:11:23.128: BGP- ATF: EVENT Query 172.31.255.65/32 (0) found route
Session establishes after 30 seconds +/- 3 s jitter.
Also, I'm confused by follow messages:
ov 26 13:10:49.743: RT: Try lookup less specific 172.31.255.65/32, default 1
Nov 26 13:10:49.743: RT: Failed found subnet on less specific
Nov 26 13:10:49.743: RT: Found supernet on less specific 172.16.0.0/12
Nov 26 13:10:49.743: BGP- ATF: EVENT Query 172.31.255.65/32 (0) found route
Nov 26 13:10:49.743: BGP- ATF: 172.16.0.0/12 (0) Adding route
Nov 26 13:10:49.743: BGP- ATF: R 172.16.0.0/12 (0) -> Updating route
Nov 26 13:10:49.743: BGP- ATF: R 172.16.0.0/12 (0) -> Tu4 172.22.253.1 Notifying
Why BGP "adding" route? Is it specific for Cisco BGP implementation and it does not sence for this feature?