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.

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.

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.

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.

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.

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.

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.