BGP timers and advertisement intervals

BGP uses timers for two different jobs. The keepalive and hold-time contract answers “is this session still alive?” The advertisement interval and MRAI answer “how often may this prefix be sent again?” ConnectRetry answers “when should a failed session be tried again?” Treating those timers as one convergence dial is a common source of production incidents.

The defaults are deliberate: keepalive 60 seconds and hold time 180 seconds. They provide a wide safety margin for ordinary wide-area paths. Faster detection can improve convergence, but only after the transport, route policy, and failure domain are understood. BFD is often the right tool when sub-second detection is required; shortening every BGP timer merely moves failure detection into a noisier control plane.

The keepalive and hold-time contract

Each BGP speaker advertises a hold time in OPEN. The two speakers negotiate the lower offered value, so a local change of 180 does not force a remote router to accept 180 if it advertises 90. After the session is Established, KEEPALIVE or UPDATE traffic resets the local hold timer. If no acceptable message arrives before the negotiated time expires, the session is declared down and the neighbor returns through the FSM toward Idle.

The current VyOS 1.5 LTS tree configures the process-wide values as separate settings:

configure
set protocols bgp system-as 65000
set protocols bgp timers keepalive 60
set protocols bgp timers holdtime 180
commit
save

A neighbor override takes precedence over the process-wide setting:

set protocols bgp neighbor 192.0.2.2 timers keepalive 10
set protocols bgp neighbor 192.0.2.2 timers holdtime 30
commit
save

A 30-second hold time means the peer proposes or accepts a 30-second contract, not that the router automatically sends a keepalive every 10 seconds. The peer must agree, and the keepalive value must be valid for the negotiated hold time. The usual 60/180 relationship is easy to reason about: the keepalive interval is one third of hold time.

Hold time zero and the exception

A hold time of zero disables the hold timer and KEEPALIVE exchange. BGP can still use UPDATE traffic and TCP, but the operational contract is different: the session has no periodic liveness proof. Some teams use a non-zero hold time plus a fast BFD detector; others use zero only when a separate control-plane mechanism is proven and documented. Never set zero merely because a keepalive timer is inconvenient.

ConnectRetry

ConnectRetry is the interval between connection attempts while a neighbor is not Established. VyOS exposes the per-neighbor setting as timers connect:

configure
set protocols bgp neighbor 192.0.2.2 timers connect 5
commit
save

The default is appropriate for most WAN peers. A smaller value helps recovery after a short interface event but can create repeated SYNs, log noise, and CPU work if the remote peer is permanently absent. A larger value reduces retry traffic but lengthens the time until BGP tries again after a remote process restart.

Use a fast retry only when the link is stable and the failure domain is expected to recover quickly. Keep the peer ACL and source address stable; otherwise the router is simply retrying the same invalid transaction more often.

TCP keepalive probes

BGP keepalives are protocol messages after session establishment. The Linux TCP layer can also send TCP keepalive probes when no bytes have moved on a socket. VyOS exposes the related values as a group:

configure
set protocols bgp parameters tcp-keepalive idle 60
set protocols bgp parameters tcp-keepalive interval 10
set protocols bgp parameters tcp-keepalive probes 5
commit
save

These values must be configured together. They are not a replacement for BGP KEEPALIVE and they do not change the BGP state machine. They are useful transport diagnostics, especially for a path that appears alive at one layer and dead at another. Avoid enabling many probes on a large peer estate without measuring control-plane and CPU impact.

Advertisement interval and MRAI

MRAI means Minimum Route Advertisement Interval. It limits how often one router advertises a particular route to a particular peer. The VyOS CLI exposes the per-neighbor advertisement-interval setting:

configure
set protocols bgp neighbor 192.0.2.2 advertisement-interval 5
commit
save

The setting is a minimum, not a forced fixed schedule. If a route changes once, it is sent when policy and the interval allow it. If a route flaps repeatedly, the interval can coalesce updates and reduce control-plane load. It can also make convergence appear slower during a rapidly changing incident.

Common FRR defaults often use a shorter eBGP MRAI than iBGP, but the operator should validate the live build and the peer contract. A provider may require a specific interval or may use a different implementation. Do not tune MRAI by guess; measure update rate, outbound queue depth, prefix counts, and peer flap history.

sequenceDiagram
  participant L as Local bgpd
  participant P as Peer
  L->>P: route advertisement
  Note over L,P: advertisement interval limits repeats
  L->>P: withdrawal
  P-->>L: ACK or update response
  L->>L: reset BGP hold timer on valid traffic
  L->>L: retry timer counts down while not Established

Choosing a production profile

A sensible profile is tiered:

• Keep 60/180 defaults on ordinary stable WAN peers unless the recovery objective and measurement justify a change.
• Use BFD for sub-second failure detection on links where the transport and hardware can support it.
• Use a shorter hold time only when the peer agrees, the path is monitored, and the extra control-plane load is accepted.
• Use ConnectRetry to control retry noise, not to make a broken peer look healthy.
• Use advertisement-interval to shape bursts and protect a peer from route churn, while measuring real convergence.
• Use route aggregation and prefix stability to reduce the number of changes that any timer must process.

Validation

The detailed neighbor output is the canonical evidence:

show bgp neighbor 192.0.2.2
show bgp summary

Look for the negotiated hold time, keepalive value, timers, update activity, last reset reason, and prefix counts. A session can be Established while a timer is mismatched if the remote accepts the local proposal; a later reset then reveals the contract. Pair the output with:

show log protocol bgp
ss -tnp | grep ':179'
tcpdump -ni any host 192.0.2.2 and tcp port 179

How it fails

• One side advertises 30 seconds and the other advertises 90; the session negotiates 30, and the operator believes 90 is active.
• Keepalive packets are sent but the return path drops them, causing a hold expiry even though local counters look healthy.
• ConnectRetry is five seconds during a persistent configuration error, creating log and CPU noise without improving recovery.
• Advertisement interval is increased to stop a flap, but the route still leaves the router and the return path is the actual problem.
• BFD is one-sided, so the interface appears down and up every few seconds while the peer believes the link is healthy.
• TCP keepalive probes are mistaken for BGP KEEPALIVE, leading to two teams changing different timers.

Rollback

Restore one timer family at a time and observe the negotiated value:

configure
set protocols bgp timers keepalive 60
set protocols bgp timers holdtime 180
set protocols bgp neighbor 192.0.2.2 advertisement-interval 0
commit
save

The exact value of zero for advertisement interval is a deliberate choice; use the vendor and peer contract for the installation. If a per-neighbor override was the problem, delete the override rather than changing the global policy. After rollback, verify the peer summary, negotiated hold time, update rate, and CPU.

Cross-course references

XXIII-VyOS-BGPFund covers the BGP lifecycle and best path. XXXII-VyOS-BFD covers sub-second failure detection, while XVII-VyOS-RoutingFund covers the broader distinction between protocol timers and the forwarding plane. XXXI-VyOS-BGPTroubleshoot uses the timer evidence during session incidents, and XXVIII-VyOS-BGPPrefixFilters helps reduce the update load that MRAI and aggregation are intended to control. The Linux course covers the TCP state and keepalive mechanism below bgpd.

Quiz