BGP Fast Convergence: BFD, PIC, Add-Path – was bringt was?

BGP ist von Natur aus „sicher statt schnell“: Standard-Timer, Path-Exploration und Policy-Checks führen dazu, dass Failover im Worst Case Sekunden bis Minuten dauern kann. Für Enterprise-Edges, DC-Fabrics und WAN-Backbones ist das oft zu langsam. „BGP Fast Convergence“ bedeutet daher: (1) Ausfälle schneller erkennen (BFD), (2) Umschalten in der Forwarding-Ebene beschleunigen (PIC), und (3) im Control-Plane-Verhalten Wartezeiten reduzieren (Add-Path als gezieltes Werkzeug gegen Path-Exploration). Wichtig ist: Diese Mechanismen lösen unterschiedliche Teilprobleme – und werden häufig falsch erwartet.

Das Konvergenzproblem zerlegen: Detection, Control Plane, Data Plane

Fast Convergence funktioniert nur, wenn du weißt, was du beschleunigen willst. Die Failover-Zeit setzt sich aus Erkennung + Entscheidung + Forwarding-Update zusammen.

Denkmodell

$\text{FailoverTime}\approx \text{Detection}+\text{ControlPlane}+\text{DataPlane}$

• Detection: wann wird ein Link/Peer als down erkannt? (BFD)
• Control Plane: wann ist ein Alternativpfad bekannt/gewählt? (Add-Path, Policy)
• Data Plane: wann ist FIB umgeschaltet? (PIC)

BFD: schnelle Failure Detection (aber nicht automatisch schneller Best Path)

BFD beschleunigt die Erkennung, dass ein BGP-Neighbor oder der Underlay-Pfad tot ist. Dadurch wird die BGP-Session schneller geschlossen und die Route-Withdraws starten früher. BFD macht BGP jedoch nicht „intelligenter“: Wenn kein Backup-Pfad vorhanden ist, kann BFD nichts zaubern.

• Bringt: schnellere Peer-Down Erkennung (Sub-Second)
• Bringt nicht: bessere Pfadauswahl oder weniger Path-Exploration
• Pitfall: zu aggressive Timer → Flapping im WAN/Jitter

BFD am Interface (Beispiel)

interface gigabitEthernet0/0
 bfd interval 300 min_rx 300 multiplier 3

BFD + BGP Peer (typisches Pattern)

router bgp 65000
 neighbor 203.0.113.1 remote-as 64500
 neighbor 203.0.113.1 bfd

Verifikation

show bfd neighbors
show ip bgp summary
show logging | include BFD|BGP

PIC: schnelle Umschaltung in der Data Plane

PIC (Prefix Independent Convergence) beschleunigt das Umschalten in der Forwarding-Tabelle, indem Backup-Next-Hops/Paths so vorbereitet werden, dass ein Ausfall nicht erst eine komplette, langsame Rekalkulation und FIB-Programmierung pro Prefix auslöst. Das ist besonders wichtig bei vielen Prefixes (Full Table) – denn „viele Prefixes“ machen klassische Konvergenz langsam.

• Bringt: schnelleres FIB-Failover bei vielen Prefixes
• Bringt besonders: bei Full Table oder großen BGP-RIBs
• Pitfall: hilft nur, wenn es einen brauchbaren Backup-Pfad gibt

Indizien: Wann PIC relevant ist

• Viele Prefixes (tausende bis hunderttausende)
• Failover dauert lange, obwohl Alternate Paths existieren
• CPU ok, aber FIB-Update dauert sichtbar

Checks (operativ)

show ip bgp summary
show ip route summary
show processes cpu sorted

Add-Path: weniger Path-Exploration, schnellerer Backup-Pfad im Control Plane

Add-Path erlaubt es, mehrere Pfade für denselben Prefix an iBGP-Nachbarn (z. B. Route Reflector Clients) zu announcen. Dadurch kennt ein Router bei Ausfall des Best Path oft bereits einen alternativen Pfad, statt ihn erst durch Path-Exploration zu „finden“. Das kann Konvergenz und Stabilität verbessern – kostet aber mehr RIB/Update-Volumen.

• Bringt: mehr verfügbare Alternativpfade im iBGP
• Reduziert: Path-Exploration und „dancing routes“
• Trade-off: mehr Updates, mehr Memory, mehr Policy-Komplexität

Typischer Use-Case

• iBGP mit Route Reflectors, mehrere Edges, schnelle Failover-Anforderung
• Multipath/ECMP gewünscht oder schnelle Fallback-Pfade für viele Prefixes

Add-Path Konzeptkonfiguration (plattformabhängig)

router bgp 65000
 address-family ipv4
  bgp additional-paths send
  bgp additional-paths receive
  neighbor 10.255.0.2 additional-paths send

Was bringt was? Entscheidung nach Problemtyp

In der Praxis ist der schnellste Weg zur richtigen Lösung, das Problem korrekt zu klassifizieren. Die drei Mechanismen adressieren unterschiedliche Teile der Kette.

• Peer-Down dauert zu lang → BFD (Detection)
• Failover bei vielen Prefixes dauert zu lang → PIC (Data Plane)
• iBGP braucht zu lange, um Alternativen zu finden → Add-Path (Control Plane)

Synergie: BFD + PIC + (optional) Add-Path

Die stärkste Kombination ist oft: BFD für schnelle Erkennung, PIC für schnelles FIB-Failover, und Add-Path nur dann, wenn iBGP/Route-Reflection Path-Exploration ein echtes Problem ist. Wichtig: erst messen, dann aktivieren.

• Core/DC: BFD (selektiv) + PIC (bei großen Tables) sehr häufig sinnvoll
• Enterprise Edge: BFD konservativ + PIC je nach Table-Size
• Add-Path: gezielt in RR-Designs, nicht „überall“

Typische Pitfalls: Warum Fast Convergence scheitert

Fast Convergence wird oft an den falschen Stellen „zu schnell“ gemacht. Das führt zu Flapping und Instabilität, statt zu weniger Outages.

• BFD zu aggressiv im WAN → false positives und Session-Flaps
• Kein Backup-Pfad vorhanden → PIC/Add-Path können nicht helfen
• Policy inkonsistent → Backup-Pfade existieren nicht oder sind nicht erlaubt
• Asymmetrie/Stateful Firewalls → Failover führt zu Session-Abbrüchen trotz Routing

Verifikation: Fast Convergence messbar machen

Du brauchst einen reproduzierbaren Test: kontrollierter Link/Peer-Failure, Messung der Zeit bis Traffic wieder stabil ist, plus Nachweis über BFD/BGP Counters. Ohne Messung bleibt es „gefühlt schneller“.

Test- und Messkommandos

show clock
show bfd neighbors
show ip bgp summary
show ip bgp <prefix>
ping <dst> repeat 500
traceroute <dst>

Quick-Runbook: In 5 Minuten entscheiden, was du brauchst

Dieses Runbook führt dich vom Symptom zur passenden Technik: Detection vs. Control Plane vs. Data Plane.

show ip bgp summary
show ip route summary
show processes cpu sorted
show bfd neighbors
show ip bgp <prefix>
show logging | include BFD|BGP

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.