BGP Dampening: Warum es selten sinnvoll ist – und wann doch

BGP Dampening wurde entwickelt, um instabile Prefixes („route flaps“) zu bestrafen und dadurch die globale Stabilität zu erhöhen. In der Praxis ist Dampening heute aber selten sinnvoll, weil es häufig genau das Gegenteil bewirkt: Es verlängert Ausfälle durch „suppressed routes“, maskiert Root Causes und kann bei modernen Anwendungen zu minutenlangen Blackholes führen – selbst wenn die eigentliche Störung längst vorbei ist. Trotzdem gibt es Nischen, in denen Dampening gezielt helfen kann. Der Schlüssel ist: nicht „Dampening an“, sondern „Dampening extrem bewusst, sehr selektiv und messbar“.

Was BGP Dampening eigentlich macht

Dampening vergibt bei jedem Flap „Penalty-Punkte“ für ein Prefix. Überschreitet die Penalty einen Suppress-Schwellenwert, wird das Prefix für eine Zeit unterdrückt und nicht weiterverwendet. Danach fällt die Penalty exponentiell ab (Decay), bis das Prefix wieder nutzbar wird.

Denkmodell

$\text{Penalty}\nearrow \text{bei Flap}, \text{Penalty}\searrow \text{über Zeit}, \text{Penalty > Threshold} \to \text{Suppress}$

• Penalty: „Strafpunkte“ pro Prefix
• Decay: Abklingen über Zeit (Half-Life)
• Suppress: Prefix wird temporär unterdrückt

Warum Dampening selten sinnvoll ist

Moderne Netze sind schneller, dynamischer und stärker automatisiert. Dampening erzeugt dabei oft lange Recovery-Zeiten, obwohl die eigentliche Störung bereits behoben ist. Das ist operativ schwer zu erklären und für Nutzer sehr schädlich.

• Verlängert Ausfälle: Prefix bleibt suppressed, obwohl Link wieder stabil ist
• Maskiert Root Cause: „es geht nicht“ ohne sichtbaren Fehler, weil Dampening wirkt
• Unvorhersehbar: Flap-Muster + Penalty/Decay ergibt schwer planbare Zeiten
• Schlecht für Failover: kurzzeitige Flaps werden „bestraft“, Backup kann nicht greifen

Der größte Praxisfehler: globales Dampening

Global aktiviertes Dampening trifft alle Prefixes, auch kritische. Das ist der häufigste Grund für Self-Inflicted Outages. Wenn Dampening, dann selektiv: nur bestimmte Prefix-Klassen, nur in kontrollierten Bereichen, und mit nachvollziehbaren Parametern.

• Niemals „einfach global einschalten“
• Wenn überhaupt: nur für „laute“ Edge-Prefixes oder Problemkunden
• Immer: Monitoring auf suppressed routes

Wann Dampening doch sinnvoll sein kann

Es gibt Szenarien, in denen Dampening gezielt hilft: Wenn einzelne Prefixes extrem häufig flappen und dadurch CPU/Update-Last erzeugen oder wenn du als Provider bestimmte „schlechte“ Kundenrouten stabilisieren musst. Auch dann ist es eher ein temporäres Mitigation-Werkzeug als eine Dauerlösung.

• Provider/Carrier: Kundenprefix flapt massiv und beeinflusst viele Router
• Enterprise Edge: einzelnes, nichtkritisches Prefix flapt und stört Stabilität
• Temporär als Mitigation, bis Root Cause behoben ist

Alternative Maßnahmen, die meist besser sind

In Enterprise-Umgebungen sind Alternativen fast immer besser: Sie lösen das Problem an der Ursache oder begrenzen Impact ohne lange Blackholes.

• Root Cause fix: Interface/Optik/Errors, IGP/BFD Timer, Provider-Link
• Prefix-Limits/Max-Prefix: Schutz gegen Route Explosion
• Policy: nur Default statt Full Table, wenn möglich
• BFD/PIC/Add-Path: schnelle, deterministische Konvergenz statt „Strafen“
• Stabilitäts-Guardrails: CoPP, Queueing, LDP/IGP Sync im MPLS

Dampening Parameter verstehen: Warum „falsche Werte“ gefährlich sind

Dampening lebt von Parametern. Zu aggressive Werte führen zu langen Suppress-Zeiten bei kurzen Flaps. Zu lockere Werte bringen keinen Effekt. Das ist der Hauptgrund, warum Dampening in der Praxis oft enttäuscht.

• Half-Life: wie schnell Penalty abklingt
• Reuse: Schwelle, ab der Route wieder genutzt wird
• Suppress: Schwelle, ab der Route unterdrückt wird
• Max-Suppress-Time: Obergrenze der Unterdrückung

Merker

$\text{Zu aggressiv} \to \text{lange Blackholes}, \text{zu locker} \to \text{kein Nutzen}$

Selektives Dampening: Der einzige sinnvolle Ansatz

Wenn du Dampening nutzt, dann selektiv: Du begrenzt es auf bestimmte Prefixes oder auf bestimmte Nachbarn, idealerweise mit klarer Begründung und Zeitlimit. Ziel ist, die globale Routing-Stabilität zu schützen, ohne kritische Dienste zu gefährden.

Selektiv per Route-Map (Konzeptpattern)

ip prefix-list PL_FLAPPY seq 10 permit 203.0.113.128/25
route-map RM_DAMPEN permit 10

match ip address prefix-list PL_FLAPPY

Dampening aktivieren (Pattern, plattformabhängig)

router bgp 65000
 bgp dampening

Verifikation: Wie du suppressed routes erkennst

Der wichtigste Betriebscheck ist: Welche Prefixes sind suppressed und warum? Ohne diese Sichtbarkeit wirst du im Incident lange suchen, weil „die Route ist weg“ nicht wie ein Link-Down aussieht.

Checks

show ip bgp dampening
show ip bgp <prefix>
show logging | include BGP|DAMP|SUPPRESSED

Operational Best Practices: Wenn Dampening, dann als Prozess

Dampening gehört in ein Runbook: klarer Scope, klare Parameter, Monitoring, und ein Ablauf zum Abschalten, sobald die Ursache behoben ist. Sonst bleibt es als „unsichtbarer Fehlergenerator“ im Netz.

• Scope dokumentieren: welche Prefixes/Peers
• Zeitlimit setzen: Dampening nicht dauerhaft „vergessen“
• Monitoring: suppressed count und Top-Prefixes
• RCA parallel: Dampening ist Mitigation, nicht Lösung

Quick-Runbook: Entscheidung „Dampening ja/nein“

Diese Checkliste hilft, schnell zu entscheiden, ob Dampening die richtige Maßnahme ist oder ob du besser an anderen Stellschrauben drehst.

• Flappen wirklich Prefixes (nicht nur Session)?
• Sind es wenige, klar identifizierbare Prefixes?
• Ist der Impact der Flaps größer als das Risiko von Suppression?
• Gibt es eine schnellere Root-Cause-Lösung (L1/L2/IGP)?

Command Pack

show ip bgp summary
show ip bgp <prefix>
show ip bgp dampening
show logging | include BGP|DAMP|SUPPRESSED
show interfaces | include CRC|error|drops

Konfiguration speichern

Router# copy running-config startup-config

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.