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

8 comments:

  1. Hi!

    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)?
  2. sebastian,

    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).
  3. That's an interesting discovery, Ivan. I looked at a RFC before (didn't remember the number) and it said it normally would take 60 seconds to initiate the BGP session to a peer. I will post again after I found the RFC...
  4. Okay, my memory was fading. It was actually 120 seconds as per RFC 1771. The BGP timer name was "BGP ConnectRetry timer" and it's set to 120 seconds by default in the IOS and cannot be changed. See the below exceprt taken from CCO:

    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
  5. Thanks for all the comments ... it looks I've opened another can of worms. Obviously a good topic for another IP Corner article ;)
  6. hi,

    i see the neighbor fallover command on my 7600 but not on my 6500. can anybody confirm this?
  7. Whenever you want to know which trains include a specific command (6500 and 7600's have dedicated release trains), check the command reference. Here's the one for the neighbor fall-over command.
  8. Hi!

    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?
Add comment
Sidebar