BGP Neighbor Flapping: Root Causes and Fixes - 夜莺博客

BGP Neighbor Flapping: Root Causes and Fixes

A flapping BGP session is never a local problem: every reset withdraws and re-advertises prefixes, triggering CPU spikes on every peer in the AS — and in iBGP route-reflector topologies, one unstable client can ripple across the whole network. This article breaks down the layered causes of BGP neighbor flapping (physical link issues, timer misconfiguration, hardware/software faults, authentication and policy problems), explains what each BGP state tells you, and provides a structured diagnosis and hardening checklist you can apply on any vendor.

Why BGP Sessions Flap

  • Network layer: intermittent interface flaps, packet loss on congested paths (three missed Keepalives expire the Hold Timer), route recursion breaking the next hop, MTU mismatches silently dropping large UPDATE packets, or WAN instability for eBGP peers.
  • Timer misconfiguration: mismatched Hold Timers, overly aggressive Keepalive intervals, short ConnectRetry timers that trigger remote route dampening, or sub-second BFD falsely declaring peers dead on high-latency links.
  • Hardware/software: saturated router CPU missing Keepalives, memory exhaustion on full-table feeds, BGP process bugs, marginal SFPs causing CRC errors, and stale sessions after NSF/NSR failovers.
  • Authentication & policy: MD5/TCP-AO password mismatch on one side, malformed outbound policies stripping mandatory attributes (AS_PATH, NEXT_HOP), exceeded maximum-prefix limits, and GTSM TTL mismatches.

Reading the BGP State Machine

State What it means
Idle Not connecting — often auth failure, policy error, or max-prefix exceeded
Connect TCP SYN sent — routing or firewall blocking port 179
Active Most common stuck state — IP unreachable, wrong peer IP, ACL blocking
OpenSent/OpenConfirm OPEN exchange failing — MTU, AS mismatch, auth mismatch
Established then drop Keepalive timing or link quality problem

Diagnosis Checklist

show bgp neighbors <peer-IP>          # Last Reset reason
ping <peer-IP> repeat 1000 source <local-IP>   # extended ping, any loss?
show logging | include BGP           # correlate timestamps

Then: verify Hold Timer/Keepalive match on both peers, inspect interface error counters for CRC, test path MTU with large DF-bit pings, confirm MD5/TCP-AO passphrases, check and raise max-prefix limits, and monitor CPU/memory during the flap. On high-latency or jittery links, relax BFD timers or disable BFD while isolating the issue.

Prevention Best Practices

Peer iBGP over loopbacks, enable Graceful Restart (RFC 4724) and NSR where supported, apply route dampening judiciously (RFC 7196), use default timers on stable links, test route policies in the lab before production, keep software patched, and monitor bgpBackwardTransition traps with real-time alerting. For related routing-protocol troubleshooting, see our OSPF neighbor stuck in INIT article, the Nexus vPC failover checklist, and the multi-vendor CLI cheat sheet.

原文链接:https://www.thenetworkdna.com/2026/03/bgp-neighbor-flapping-issues.html