BGP Route Flap Damping in 2026 — RFC 7196 Operator Playbook

Date: 2026-03-27
Category: knowledge
Audience: Inter-domain network operators, peering engineers, NOC/SRE for ISP backbones

1) Why this still matters

Route Flap Damping (RFD) has a bad reputation for a good reason: classic defaults were often too aggressive and hurt normal convergence.

But disabling RFD everywhere leaves you exposed to a small set of chronic flap-heavy prefixes that can consume a disproportionate share of update churn.

The modern stance is not "always on" or "always off" — it is "usable, conservative, measured".

2) The short history (what changed)

• RFC 2439 (1998) introduced RFD to suppress unstable routes and reduce churn.
• Operational experience showed classic settings (notably low suppress thresholds) could punish otherwise healthy prefixes.
• RFC 7196 (2014) kept the mechanism but recommended safer parameters:
  • raise suppress threshold significantly,
  • raise maximum penalty ceiling,
  • optionally run in "calculate-but-don't-damp" mode first.

Key takeaway: RFD itself is not the bug; bad parameterization is.

3) Mental model: how RFD works

For each route, you maintain a penalty score:

• penalty increases on instability events (withdraw/re-advertise/attribute change),
• penalty decays exponentially over time,
• if penalty crosses suppress threshold, route is damped,
• route becomes eligible again when penalty falls below reuse threshold.

Typical knobs:

• Half-life (decay speed)
• Suppress threshold (when to damp)
• Reuse threshold (when to unsuppress)
• Max suppress time (hard cap)
• Maximum penalty (implementation ceiling)

Operationally, suppress threshold is the most critical risk knob.

4) What RFC 7196 recommends (practical profile)

Core recommendations

From RFC 7196:

1. Maximum penalty MUST be at least 50,000.
2. If you want damping with lower risk, set Suppress Threshold >= 6,000.
3. Conservative posture: Suppress Threshold >= 12,000.
4. Prefer a test phase where you calculate penalties but do not actually damp.

Why this helps

RFC 7196 cites measured results where higher suppress thresholds still cut meaningful churn while drastically reducing collateral damping of well-behaved prefixes.

5) Where to apply RFD (scope discipline)

RFD should be scoped carefully:

• Prioritize EBGP-learned instability handling.
• Avoid indiscriminate damping logic across IBGP propagation paths.
• Keep policy consistent with current BGP operational guidance (filtering/validation first, damping as a secondary stabilizer).

RFD is not a substitute for:

• prefix/AS-path hygiene,
• max-prefix limits,
• RPKI/IRR-based controls,
• robust session protection.

Think of RFD as a churn shock absorber, not a routing security control.

6) Rollout plan that won’t bite you

Phase 0 — Baseline

Collect 2–4 weeks of:

• update rate by peer / prefix,
• top-N flapping prefixes,
• convergence-time distribution,
• customer-visible impact during churn spikes.

Phase 1 — Dry-run mode

Enable penalty computation only (no damping if platform supports it).

Goal: identify what would be damped under candidate thresholds.

Phase 2 — Conservative activation

• start at suppress >= 12,000,
• maintain sane half-life/reuse/max-suppress values,
• confirm maximum penalty ceiling is not too low.

Phase 3 — Segment-specific tuning

Use stricter profiles only where justified (e.g., noisy edge zones), while keeping transit/core conservative.

Phase 4 — Continuous review

Monthly review:

• damped-prefix count,
• percent of total updates reduced,
• false-positive damping incidents,
• MTTR/convergence regressions.

7) Guardrails and failure modes

Guardrails

• Keep a rapid disable switch for emergency rollback.
• Alert on sudden growth in damped-prefix cardinality.
• Exempt mission-critical prefixes if business impact is high.
• Pair with good telemetry (BMP/streaming telemetry + route analytics).

Common failure modes

1. Too-low suppress threshold (legacy defaults)
2. RFD used as a security band-aid
3. No dry-run validation before activation
4. No per-domain policy differentiation
5. No rollback path during incident

8) Decision rubric (simple)

Use this quick rubric:

• If churn is low and convergence sensitivity is high → keep RFD off or ultra-conservative.
• If a small set of prefixes repeatedly drives update storms → enable conservative RFD.
• If you cannot observe/measure damping effects → do not enable yet.

In short: observability first, conservative thresholds second, selective activation third.

9) Bottom line

RFD is no longer "dead" — it is situational.

The modern safe path is:

1. deploy with RFC 7196-style conservative thresholds,
2. validate in calculate-only mode,
3. damp only chronic churn sources,
4. continuously verify that stability gains outweigh convergence penalties.

That gives you measurable churn reduction without repeating the early-2000s self-inflicted outages.

References

1. RFC 2439 — BGP Route Flap Damping
   https://www.rfc-editor.org/rfc/rfc2439
2. RFC 7196 — Making Route Flap Damping Usable
   https://www.rfc-editor.org/rfc/rfc7196
3. RFC 7454 — BGP Operations and Security (BCP 194)
   https://www.rfc-editor.org/rfc/rfc7454
4. RFC 4271 — A Border Gateway Protocol 4 (BGP-4)
   https://www.rfc-editor.org/rfc/rfc4271