BGP hold time

When two BGP speakers are configured to start peering with each other, they will start off setting up a TCP session. Right after this, both BGP speakers will begin the BGP peering session by exchanging an open message. One of the fields inside the open message is the hold time. This hold time field is populated by an integer. This integer indicates the proposed number of seconds the sending router wants the hold time to take. According to RFC 4271, both BGP speakers must use the smallest hold time value that was exchanged. This value can be zero or, otherwise, it should be at least 3 seconds.

A negotiated hold time of zero indicates a the BGP session will never time out. If the hold timer is something other than zero, a BGP speaker will determine that a time out occurred if that BGP speaker did not receive any message from its neighbor during the hold time period. If this is the case, a notification message is send to the peer. This notification message will contain the ‘hold timer expired’ error code.

In the absence of update or notification messages, the BGP speakers will need to exchange keepalive messages to keep the hold timer from expiring. RFC 4271 does not indicate how often BGP speakers should exchange a keepalive to prevent the hold timer from expiring. Different vendors can use different timers for this. The RFC only states that ´ A reasonable maximum time between KEEPALIVE messages would be one third of the Hold Time interval. KEEPALIVE messages MUST NOT be sent more frequently than one per second. An implementation MAY adjust the rate at which it sends KEEPALIVE messages as a function of the Hold Time interval. If the negotiated Hold Time interval is zero, then periodic KEEPALIVE messages MUST NOT be sent.´

Another thing worth noting is that it is allowed for a BGP speaker to respond to a proposed hold time with a notification messages stating that the proposed hold time is unacceptable.

The default hold time proposed by a Juniper router is 90 seconds. On a Juniper router, this hold time will lead to a keepalive interval of 30 seconds. Let's have a look at the following Juniper example with two routers;



scenario


The two routers are connected together via a point-to-point and I have applied a very basic BGP configuration to both routers:

AURELIUS:
set protocols bgp group ebgp neighbor 2.0.0.14 peer-as 65000
set routing-options autonomous-system 65001                    
                
TRAJAN:
set protocols bgp group ebgp neighbor 2.0.0.13 peer-as 65001
set routing-options autonomous-system 65000                    
                

After the two BGP speakers established a session, we can observe the following;


play@MX480-TEST:AURELIUS> show bgp neighbor 2.0.0.14
Peer: 2.0.0.14+179 AS 65000    Local: 2.0.0.13+55624 AS 65001
  Type: External    State: Established    Flags: <Sync>
  Last State: OpenConfirm   Last Event: RecvKeepAlive
  Last Error: None
  Options: <Preference PeerAS Refresh>
  Holdtime: 90 Preference: 170
  Number of flaps: 0
  Peer ID: 1.1.1.2         Local ID: 1.1.1.1           Active Holdtime: 90
  Keepalive Interval: 30         Peer index: 0
  BFD: disabled, down
  Local Interface: xe-0/3/0.4
  NLRI for restart configured on peer: inet-unicast
  NLRI advertised by peer: inet-unicast
  NLRI for this session: inet-unicast
  Peer supports Refresh capability (2)
  Restart time configured on the peer: 120
  Stale routes from peer are kept for: 300
  Restart time requested by this peer: 120
  NLRI that peer supports restart for: inet-unicast
  NLRI that restart is negotiated for: inet-unicast
  NLRI of received end-of-rib markers: inet-unicast
  NLRI of all end-of-rib markers sent: inet-unicast
  Peer supports 4 byte AS extension (peer-as 65000)
  Peer does not support Addpath
  Table inet.0 Bit: 10000
    RIB State: BGP restart is complete
    Send state: in sync
    Active prefixes:              0
    Received prefixes:            0
    Accepted prefixes:            0
    Suppressed due to damping:    0
    Advertised prefixes:          0
  Last traffic (seconds): Received 1    Sent 1    Checked 1
  Input messages:  Total 2      Updates 1       Refreshes 0     Octets 42
  Output messages: Total 3      Updates 0       Refreshes 0     Octets 120
  Output Queue[0]: 0                    
                

The three timers that are interesting are the Holdtime, the Active Holdtime and the Keepalive Interval. In Junos, the Holdtime represents the time that the router proposed to its peer. The Active Holdtime is the smallest of the hold times that were exchanged by the peers. The Keepalive interval is the value of the Active Hold time divided by three.

As soon as the configuration statement ‘set protocols bgp group ebgp neighbor 2.0.0.13 hold-time 24’ is applied to the TRAJAN router, the BGP session is torn down. When the BGP session is re-established, both routers will be using the newly proposed hold time of 24;


play@MX480-TEST:AURELIUS> show bgp neighbor 2.0.0.14
Peer: 2.0.0.14+56150 AS 65000  Local: 2.0.0.13+179 AS 65001
  Type: External    State: Established    Flags: <Sync>
  Last State: OpenConfirm   Last Event: RecvKeepAlive
  Last Error: None
  Options: <Preference PeerAS Refresh>
  Holdtime: 90 Preference: 170
  Number of flaps: 1
  Last flap event: RecvNotify
  Error: 'Cease' Sent: 0 Recv: 2
  Peer ID: 1.1.1.2         Local ID: 1.1.1.1           Active Holdtime: 24
  Keepalive Interval: 8          Peer index: 0
  BFD: disabled, down
  Local Interface: xe-0/3/0.4
  NLRI for restart configured on peer: inet-unicast
  NLRI advertised by peer: inet-unicast
  NLRI for this session: inet-unicast
  Peer supports Refresh capability (2)
  Restart time configured on the peer: 120
  Stale routes from peer are kept for: 300
  Restart time requested by this peer: 120
  NLRI that peer supports restart for: inet-unicast
  NLRI that restart is negotiated for: inet-unicast
  NLRI of received end-of-rib markers: inet-unicast
  NLRI of all end-of-rib markers sent: inet-unicast
  Peer supports 4 byte AS extension (peer-as 65000)
  Peer does not support Addpath
  Table inet.0 Bit: 10000
    RIB State: BGP restart is complete
    Send state: in sync
    Active prefixes:              0
    Received prefixes:            0
    Accepted prefixes:            0
    Suppressed due to damping:    0
    Advertised prefixes:          0
  Last traffic (seconds): Received 0    Sent 0    Checked 0
  Input messages:  Total 3      Updates 1       Refreshes 0     Octets 101
  Output messages: Total 3      Updates 0       Refreshes 0     Octets 120
  Output Queue[0]: 0                    
                

17-12-2014