Tracing Confidence Collapse During Route Flaps

Introduction to BGP Flapping

Definition and Causes of BGP Flapping

BGP flapping is the rapid, repeated transition of a BGP peer session between the Established state and one of the non‑established states (Idle, Connect, Active, OpenSent, OpenConfirm). Each transition generates a BGP NOTIFICATION (or a TCP reset) and causes the peer to withdraw and re‑advertise its routes. Common causes include:

• Link‑layer instability – intermittent physical faults, transceiver errors, or port flaps that drop the underlying TCP session.
• Mis‑configured timers – hold time or keepalive values too low for the observed RTT, causing premature hold‑timer expiry.
• CPU overload – the BGP process cannot keep up with keepalive transmission or update processing, leading to missed keepalives.
• Policy‑induced route withdrawals – inbound/outbound route‑map changes that trigger immediate withdrawals and re‑advertisements of the same prefix.
• Route reflector or confederation mis‑behavior – a reflector client repeatedly sending updates that are rejected by the reflector, causing the client to reset.
• Security events – TCP MD5 authentication failures, BGPsec validation errors, or deliberate attack traffic that forces session resets.

Impact of BGP Flapping on Network Stability

When a BGP session flaps, the control plane experiences:

• Repeated RIB withdrawals and advertisements – each flap generates UPDATE messages that every BGP speaker in the propagation path must process.
• Increased BGP update churn – consumes CPU and memory, especially on route reflectors and aggregation points.
• Potential FIB instability – if the flapping prefix is used for forwarding, repeated withdrawals can cause temporary blackholing or sub‑optimal path selection until the FIB reconverges.
• Control‑plane overload – high rates of NOTIFICATIONs and TCP resets can destabilize the underlying TCP stack, leading to further session drops.
• Secondary effects – route‑flap damping penalties may accumulate, suppressing legitimate advertisements and causing reachability loss if not tuned correctly.

Understanding the exact control‑plane state transitions is essential to decide whether to suppress the flapping automatically or to escalate for manual investigation.

Understanding Control-Plane State Changes

BGP Session States and Transitions

A BGP peer follows the finite‑state machine defined in RFC 4271:

A flap is observed when the session moves from Established → Idle/Connect/Active/OpenSent/OpenConfirm → Established within a short interval (typically seconds to a few minutes). Each transition generates a NOTIFICATION (or TCP reset) that is logged by the router.

Role of Keepalives and Hold Timers in BGP Sessions

• Keepalive timer – determines how often a BGP speaker sends a KEEPALIVE message (default 60 s on Cisco IOS, 30 s on Juniper Junos). The timer is restarted upon receipt of any BGP message (KEEPALIVE, UPDATE, NOTIFICATION).
• Hold timer – the maximum interval allowed between receipt of successive KEEPALIVE or UPDATE messages before the session is considered dead (default 180 s on Cisco, 90 s on Juniper). When the hold timer expires, the speaker sends a NOTIFICATION with error code Hold Timer Expired and transitions to Idle.

If the underlying link experiences intermittent loss, the TCP stack may not deliver KEEPALIVEs in time, causing the hold timer to expire and triggering a transition to Idle. Conversely, if the local BGP process is CPU‑starved, it may fail to transmit KEEPALIVEs, also leading to hold‑timer expiry.

Detecting State Changes in BGP Sessions

Operators can observe state changes via:

• SNMP traps – bgpBackwardTransition and bgpEstablished (RFC 4273 MIB).
• Syslog messages – %BGP-5-ADJCHANGE: neighbor <ip> Up / %BGP-5-ADJCHANGE: neighbor <ip> Down.
• CLI show commands – show ip bgp neighbors <ip> (Cisco) or show bgp neighbor <ip> (Juniper) display the current state, flap count, and timestamps of the last state change.
• Debugging – debug ip bgp events (Cisco) or monitor start bgp (Juniper) provides real‑time notifications of state transitions, keepalive timeouts, and NOTIFICATIONs sent/received.

A typical log entry for a flap caused by hold‑timer expiry:

%BGP-5-ADJCHANGE: Neighbor 10.0.0.5 Down Hold timer expired
%BGP-5-ADJCHANGE: Neighbor 10.0.0.5 Up

The timestamp difference between the Down and Up messages quantifies the flap duration.

Automated Suppression of BGP Flapping

Principles of Automated Suppression

Automated suppression aims to dampen the propagation of unstable BGP information without disabling the underlying session. Two complementary mechanisms exist:

1. BGP Route Flap Dampening (RFC 2439) – applies a penalty to each route withdrawal/advertisement; when the penalty exceeds a suppress limit, the route is temporarily suppressed from advertisement. Penalties decay exponentially with a configurable half‑life. When the penalty falls below a reuse limit, the route is unsuppressed.
2. BGP Peer Session Flap Suppression – some vendors (Cisco, Juniper, Nokia) allow configuration of a flap‑damping policy on the BGP peer itself: after N state changes within a monitoring window, the peer is placed in a suppressed state where further KEEPALIVE/UPDATES are still exchanged but the router refrains from sending NOTIFICATIONs or generating syslog alerts for a configurable period. This prevents the control plane from being flooded with flap‑related notifications while still allowing the session to recover.

Both mechanisms operate purely in the control plane: they monitor state transitions or update streams, compute penalties, and decide whether to forward updates to peers or to install routes in the RIB/FIB. They do not alter the forwarding plane directly; any forwarding impact stems from whether a route is present in the RIB and subsequently programmed into the FIB.

Configuring Automated Suppression Mechanisms

Configuration varies by vendor. Below are representative snippets; timer values and parameter names are vendor‑specific and must be tuned to the observed flap characteristics.

Cisco IOS/IOS‑XR

router bgp 65000
  bgp dampening 15 750 2000 60   ! half-life reuse suppress max-suppress-time

Juniper Junos

set protocols bgp group <group-name> damping half-life 15 reuse 750 suppress 2000 max-suppress 60

Adjust the values according to network stability requirements and observed flap patterns. Proper tuning ensures that transient noise is suppressed while persistent instability triggers escalation for manual review.