BGP Timers Explained: Hold, Keepalive, MRAI and More

2026年8月31日 LOG admin

Every BGP session runs on a handful of timers that decide when a peer is declared dead, how often routes are re-advertised, and how quickly a session recovers after failure. Most engineers know the 60/180 keepalive/hold defaults, but fewer can explain ConnectRetry, MRAI or the graceful-restart delay timers. This guide walks through each timer in the BGP finite state machine, what it does, its default values, and the tuning rules that keep your network stable.

Fundamental Session Timers

Hold Down Timer

Sets how long the router waits for a keepalive from its peer before declaring the session failed. Default is typically 180 seconds — three times the keepalive interval. If the hold time expires, the BGP session is torn down.

The hold timer is the backstop of the whole peering relationship. Unlike an interface-down event or a TCP reset, nothing tells BGP when a neighbour stops speaking: the only proof of life is the periodic keepalive. When the hold time elapses with nothing received, BGP moves the neighbour to Idle, withdraws every prefix learned from it, and the router reconverges onto alternate paths. That reconvergence is deliberately expensive, which is exactly why the default is measured in minutes rather than seconds.

Bear in mind that the hold timer only fires on silence. A neighbour whose process is alive but whose data plane has stopped forwarding packets will happily keep resetting your hold timer every 60 seconds while black-holing traffic. BGP timers detect dead routers, not broken forwarding — protecting against the latter is what BFD is for.

Keepalive Timer

Controls how often keepalive messages are sent to maintain the session. Default is typically 60 seconds. If no keepalive arrives within the hold time, the connection is considered dead.

A keepalive is a 19-byte BGP message with no payload. It advertises nothing and exists purely to reset the peer's hold timer, so its cost is negligible; what matters is the ratio. Because the peer's hold timer must never legitimately expire between two keepalives, the keepalive interval should always be at most one third of the hold time. That ratio is why Cisco refuses to accept a nonsensical pair: type neighbor 10.0.0.2 timers 60 60 and the router silently ignores the hold value, leaving the session on 60/180. Any configured hold time below three times the keepalive is discarded at parse time.

How Keepalive and Hold Are Negotiated

Timer values are not configured locally and then used blindly — they are exchanged in the BGP OPEN message. Each speaker advertises the lowest of (its configured hold time, its preferred hold time), and both ends then operate on the smaller of the two advertised values. A router configured for 30/90 peering with one left at the 60/180 default converges on 30/90 on both sides. The values do not have to match, but the session always runs on the minimum.

There is a practical consequence here for anyone running a border router against sessions they do not manage. A customer or peer can force an aggressive hold time onto the session, and a 9-second hold time across an internet path flaps constantly. On Cisco IOS the third argument of the neighbor timers command exists to defend against exactly that: it sets a minimum acceptable hold time, and a neighbour advertising anything lower is rejected during session setup.

router bgp 65001
 neighbor 203.0.113.9 timers 30 90 90
!

On IOS XR the same protection is available on a session-group, neighbor-group or individual neighbour, where the third value is likewise the minimum hold-down:

router bgp 65001
 session-group EBGP-CUSTOMERS
  remote-as 65009
  timers 30 90 90
 !
 neighbor 203.0.113.9
  use session-group EBGP-CUSTOMERS
 !
!

If a neighbour simply refuses to establish while both sides look correctly configured, check for a minimum-hold-time restriction first. The rejection is logged, not silently ignored:

%ROUTING-BGP-5-ADJCHANGE : neighbor 203.0.113.9 Up (VRF: default) (AS: 65009)
%ROUTING-BGP-3-MIN_HOLD_TIME : neighbor 203.0.113.9 hold time 30 is less than the minimum 90

The BGP Finite State Machine and the ConnectRetry Timer

Before any keepalive is exchanged, a session has to walk the BGP finite state machine — Idle, Connect, Active, OpenSent, OpenConfirm, Established. Two timers drive the early states, and they are the ones you will be reading when a session is stuck.

ConnectRetryTimer governs how long the router waits between attempts to complete the TCP three-way handshake with a peer. On Cisco IOS the default is 120 seconds. When it expires while the session sits in Connect or Active, the router tears down any partial TCP connection, resets the timer, and tries again. That cadence is a useful diagnostic fingerprint: a neighbour bouncing between Connect and Active at a steady interval of roughly two minutes is being blocked at the transport layer, not rejected at the BGP layer.

The usual causes of a ConnectRetry loop are:

An ACL or firewall dropping TCP port 179 in one or both directions.
No route to the neighbour address — very common with loopback-based peering where the loopback is not advertised.
Asymmetric source addresses, so the returning SYN-ACK reaches a router with no matching session.
A neighbour configured with update-source pointing at an address unreachable from the peer.
A management-plane or CoPP policer rate-limiting BGP control traffic.

FSM Timers

ConnectRetryTimer — the interval between successive attempts to establish the TCP connection to a peer.
MinASOriginationInterval — minimum time between advertisements of routes with the same AS path; limits update frequency from originating routers.
MinRouteAdvertisementIntervalTimer (MRAI) — minimum spacing between route advertisements to a specific peer, for both eBGP and iBGP. This is the timer that prevents update storms.

MinASOriginationInterval defaults to 15 seconds on Cisco IOS. It only gates updates the local router originates for the same AS path — a flapping redistributed OSPF or static route, for example — so it protects every peer from a locally unstable source without slowing down the propagation of routes received from elsewhere. If you have ever seen a redistributed route produce a burst of UPDATEs, this is the timer that was supposed to be smoothing it.

MRAI: eBGP, iBGP and the "Slow Convergence" Complaint

MRAI causes more confusion than any other BGP timer. On Cisco IOS the default is 30 seconds for eBGP peers and 0 seconds for iBGP peers, which mirrors RFC 4271. In practice this means:

A routing change received from one external peer is not sent to other external peers the instant it is processed; it is queued until the MRAI window for that peer expires. A prefix that only becomes visible after a path failure can therefore take up to 30 seconds to be advertised onward.
A change that withdraws reachability is not held back — withdrawals are sent immediately, because holding them would black-hole traffic. MRAI delays announcements, not failures.
iBGP peers see changes immediately (MRAI 0), which is why a route reflector's clients usually converge faster than a full-mesh eBGP edge.

Lowering MRAI to a few seconds speeds up convergence at the cost of more UPDATE churn, more CPU and more control-plane load on your peers. Most operators keep 30 seconds at the edge and treat sub-second convergence as a BFD design problem rather than a timer problem. To change it on IOS:

router bgp 65001
 neighbor 203.0.113.9 advertisement-interval 10
!

On IOS XR the same knob lives under the neighbour address family:

router bgp 65001
 neighbor 203.0.113.9
  address-family ipv4 unicast
   advertisement-interval 10
  !
 !
!

Feature Timers

Route Refresh Timer

Associated with the Route Refresh capability (RFC 2918) — requests re-advertisement of routes to clear routing table inconsistencies without resetting the session. When a policy changes in the inbound direction, a soft reset asks the peer to re-send its entire Adj-RIB-Out rather than tearing the session down:

R1# clear ip bgp 10.0.0.2 soft in
R1# clear ip bgp 10.0.0.2 soft out

An inbound soft reset is cheap for the local router but expensive for the peer, which has to walk and re-send its full table. Both ends validate their initial routing table with the End-of-RIB marker, so a soft reset also creates a useful point at which to measure convergence.

Route Flap Damping Timers

Damping uses penalty, suppress limit, reuse limit, maximum suppress time and half-life timers to suppress flapping routes. See our route flap damping explained and Junos damping parameters articles for details. The Cisco IOS defaults are worth memorising because the half-life dominates behaviour:

router bgp 65001
 bgp dampening 15 750 2000 60
! half-life 15 min, reuse 750, suppress 2000, max-suppress-time 60 min

Graceful Restart Timers

The delay timer controls how long BGP waits before re-establishing sessions after a restart; the idle timer defines how long to wait for End-of-RIB markers signaling the completion of the initial routing table transfer.

On IOS these are configured as a restart time and a stale-path time, and they only matter when the neighbour has also negotiated the graceful-restart capability — check the capability lines in show ip bgp neighbors before expecting a restart to preserve forwarding:

router bgp 65001
 bgp graceful-restart
 bgp graceful-restart restart-time 120
 bgp graceful-restart stalepath-time 360
!

The restart-time tells the peer how long it should hold your stale routes; stalepath-time bounds how long you will hold routes from a restarting peer while waiting for its End-of-RIB. If the peer never complies, stale routes are aged out when this timer expires, which is why a graceful restart that goes wrong can extend an outage rather than shorten it.

Adjusting BGP Timers: IOS and IOS XR Examples

Timers can be set globally and then overridden per neighbour. The IOS command takes keepalive, hold time and an optional minimum hold; IOS XR splits the global default from the per-neighbour override.

! Cisco IOS - global default, then a per-neighbour override
router bgp 65001
 bgp log-neighbor-changes
 neighbor 10.0.0.2 timers 60 180
 neighbor 203.0.113.9 timers 10 30 30
 neighbor 203.0.113.9 advertisement-interval 30
 bgp scan-time 60
 bgp graceful-restart restart-time 120
! Cisco IOS XR - global default, per-neighbour override
router bgp 65001
 timers bgp 30 90
 neighbor 172.16.40.24
  remote-as 65002
  timers 60 220
 !
!

Two rules keep you out of trouble when you change these values. First, keep every neighbour inside the same peer group on identical timers — mismatched groups make flapping behaviour impossible to compare. Second, if you lower timers on one side only, remember the session settles on the minimum of the two advertised values, so the side with the shorter hold time decides for both.

Verifying Timer Values on a Live Session

Never assume a timer change took effect; the configured value and the negotiated value can differ. Read both.

R1# show ip bgp neighbors 10.0.0.2
R1# show ip bgp neighbors 10.0.0.2 | include hold time
R1# show ip bgp neighbors 10.0.0.2 | include keepalive
R1# show ip bgp summary | include 10.0.0.2
R1# show ip bgp dampening flap-statistics
R1# show ip bgp dampening parameters

On IOS XR:

RP/0/0/CPU0:router# show bgp neighbor 10.0.0.2
RP/0/0/CPU0:router# show bgp neighbor 10.0.0.2 | include timer
RP/0/0/CPU0:router# show bgp summary
RP/0/0/CPU0:router# show bgp process performance-statistics

The line to read carefully in show ip bgp neighbors is the keepalive/hold pair along with Last read. If Last read is growing past the hold time while the state still shows Established, you are looking at a stale display or a session that is about to drop. If the negotiated hold time is not what you configured, the peer forced the session down to its own smaller value — go back and add a minimum hold time.

Troubleshooting Timer-Related Symptoms

Timer problems show up as a small number of recurring symptoms. Match the symptom to the timer before you touch any configuration.

Session drops at a suspiciously regular interval. The interval is the timer. Roughly 180 seconds points at keepalive loss across a lossy or policed path; roughly 120 seconds points at the ConnectRetry loop; a drop minutes after a routing change points at graceful restart or a scan-time interaction.
Sessions flap only under load. BGP control traffic is competing with data for the same link. Look at queueing and CoPP, not at the timers, and consider raising the hold time rather than lowering it.
Peer stays in Active or Connect forever. This is transport, not timers: verify TCP 179 reachability with telnet 10.0.0.2 179 from the router, then check routing to the peer address and the source address used.
Routes take 30 seconds to appear on the far side. That is MRAI doing its job. Confirm by checking whether advertisement-interval is non-default.
A route stays suppressed long after the network settles. That is route flap damping with a long half-life, not a BGP timer. Inspect show ip bgp dampening flap-statistics.

For session-level debugging, enable only what you need and remember to turn it off:

R1# debug ip bgp keepalives
R1# debug ip bgp updates
R1# undebug all

debug ip bgp keepalives prints every keepalive sent and received along with the hold timer countdown, which makes a genuinely lossy path obvious in seconds. On a production router with hundreds of peers this output is enormous — scope it to a single neighbour with an ACL-referenced debug or accept that you may need to restart the BGP process afterwards.

BGP Timer Best Practices

Understand your network requirements before adjusting anything.
Avoid overly short keepalive/hold timers — minor interruptions cause session resets and instability.
Balance stability against responsiveness: short enough to detect failures, long enough to avoid flapping.
Use different settings for eBGP vs iBGP peers where network conditions differ.
Keep settings consistent between peers and make incremental changes, monitoring the impact.
Prefer defaults in production; tune only when necessary.
Set a minimum hold time on externally managed peers so a third party cannot force an aggressive value onto your session.
If you need sub-second failure detection, reach for BFD rather than shrinking the BGP timers — see our BFD liveness detection and timer integration guide.

Frequently Asked Questions

Can the keepalive and hold timers differ on the two ends of a session? Yes. Both speakers advertise a hold time in the OPEN message and the session uses the smaller value; the keepalive interval stays local, but it must be at most one third of the negotiated hold time.

What happens if I configure a hold time lower than three times the keepalive? Cisco discards the value and the session keeps the previous setting. There is no error message on IOS, which is why the command appears to "do nothing".

Does lowering MRAI improve failover time? Only for announcements. Withdrawals are not delayed by MRAI, so if the goal is faster failover, fix the withdrawal path and consider BFD for faster detection.

Do hold timers protect against a router that is up but not forwarding? No. A live control plane keeps sending keepalives while the data plane is broken. Use BFD for forwarding-plane liveness.

What is a sane hold time for an internet eBGP session? The 60/180 default is a good starting point. Some operators run 30/90 on well-provisioned links; anything below that tends to flap on lossy paths.