BGP flaps look mysterious until you apply a repeatable method. Here is the exact procedure we use in the field, in order.

Step 1 — Identify the Flap Signature

show bgp summary
show bgp neighbor 10.0.0.2 | match flap
show log messages | last 50 | match bgp

You are looking for why the session drops. HoldTimerExpired means control-plane or transport trouble; Connection reset often means a firewall or MTU issue between peers.

Step 2 — Check the Transport Path

ping 10.0.0.2 rapid count 100
ping 10.0.0.2 size 1472 do-not-fragment
traceroute 10.0.0.2
If a 1472-byte DF ping fails but small pings pass, you have an MTU black hole — a classic cause of BGP flapping exactly when large UPDATEs are sent.

Step 3 — CPU and DDoS Policers

On MX and EX9200 platforms, host-bound BGP traffic can be policed by DDoS-protection when a control burst occurs:

show ddos-protection protocols statistics
show ddos-protection parameters

Step 4 — Stabilize

set protocols bgp group PEERS multipath
set protocols bgp group PEERS family inet unicast
set protocols bgp group PEERS hold-time 30
set protocols bgp group PEERS keepalive 10
set protocols bgp group PEERS bfd-liveness-detection minimum-interval 150 multiplier 3
set groups BGP-DAMP protocols bgp damping
A clean log shows zero flap count increments over a 24-hour window.

Common BGP Flap Root Causes

  1. MTU black hole on underlay (1472-byte DF ping test solves this fast).
  2. Outbound ACL dropping the TCP session after a long idle.
  3. DDoS policer on MX family — high-rate control-plane traffic triggers the action.
  4. Inbound TCP RST from the peer.
  5. BFD instability due to hold-time mismatch.

Further Reading

For three-vendor interop that often exhibits BGP-like issues, see EVPN three-vendor interop guide. For an underlay to test against, see OSPF on MX. For hub-and-spoke that frequently runs into flap issues, see SRX IPSec hub-and-spoke.