Hold and Keepalive tuning

Each BGP-LS peer in Prelude TE carries three timers:

• Hold time — how long Prelude TE waits without hearing from the peer before tearing down the session. Default 90 s.
• Keepalive time — how often Prelude TE sends keepalive messages to the peer. Default 30 s.
• Connect retry — how long Prelude TE waits before retrying after a connection failure. Default 30 s.

The defaults match the BGP specification and work for the vast majority of deployments. Adjust them only when you have a documented reason.

Constraints

The engine enforces two hard rules in the form:

• Hold time ≥ 3 seconds. Lower values are rejected.
• Keepalive ≤ Hold time / 3. If you push Keepalive higher the session has no time to recover from a single lost message before the Hold timer fires.

Both timers are negotiated at session establishment: the lower of the two ends wins. If your router is configured with shorter timers, Prelude TE will adopt them.

When to lower the timers

• Faster failure detection on a link known to flap, or in a lab where you want quick feedback. A common tighter setup is Hold 30 s / Keepalive 10 s. Going much below that buys little in practice and increases CPU and bandwidth use on both ends.

When to raise the timers

• Lossy WAN paths between Prelude TE and a remote route reflector. If the session keeps flapping with the defaults, raise Hold to give recovery a wider window — for example Hold 180 s / Keepalive 60 s.
• Idle session through a NAT or load balancer with a short idle timeout. Keepalives reset the timer on path; pick a Keepalive comfortably below the device's idle timeout.

Connect retry

The connect-retry timer governs how often Prelude TE attempts to reconnect after a failure. Keep it short enough for a quick recovery after a transient outage, long enough not to log-spam during a prolonged one. Default 30 s is a sane middle ground.

To force a reconnect now without waiting for the timer, disable and re-enable the peer from the UI. See Peers.