BFD mit OSPF/IS-IS: Sub-Second Failover richtig konfigurieren

Bidirectional Forwarding Detection (BFD) ist der Standardbaustein für Sub-Second Failover in modernen IGP-Designs. Statt auf OSPF/IS-IS Hello- und Dead-Timer zu warten, erkennt BFD Link- oder Nachbarprobleme deutlich schneller und signalisiert dem Routing-Protokoll sofort „Neighbor down“. Das Ergebnis: Konvergenz in Hunderten Millisekunden – vorausgesetzt, du dimensionierst Timer sauber, aktivierst BFD konsistent und vermeidest typische Pitfalls wie CPU-Overload oder BFD-Flapping. Dieses Tutorial zeigt ein praxistaugliches Setup für BFD mit OSPF und IS-IS inklusive Verifikation.

Was BFD leistet (und was nicht)

BFD ist kein Routing-Protokoll und ersetzt kein Design. Es ist ein schneller Failure-Detector. BFD erkennt Link-/Path-Ausfälle und „triggert“ OSPF/IS-IS, damit die Nachbarschaft sofort als down gilt.

• Leistet: schnelle Neighbor-Failure-Erkennung (Sub-Second)
• Leistet nicht: Pfad-Engineering, Loop-Vermeidung oder Policy
• Wichtig: BFD beschleunigt Erkennung, nicht SPF/LSA-Design

Wann BFD sinnvoll ist

BFD ist besonders wertvoll auf Punkt-zu-Punkt Links im Core/WAN, bei denen schnelle Konvergenz SLA-relevant ist (Voice/Video, kritische Services). Im Access ist BFD oft weniger nötig und kann unnötige Komplexität bringen.

• Core/WAN-Backbone Links (PtP): sehr sinnvoll
• Transit zu Provider/Peering: häufig sinnvoll
• Access/Edge mit vielen Interfaces: selektiv, um CPU/State zu begrenzen

BFD Timer verstehen: Intervall, Multiplier, Detection Time

Die zwei wichtigsten Parameter sind Sendeintervall und Multiplier. Die resultierende Detection Time ist näherungsweise Intervall × Multiplier. In der Praxis startest du konservativ und gehst nur so aggressiv, wie Stabilität und Plattform es zulassen.

Detection Time (Denkmodell)

DetectTime ≈ Interval × Multiplier

Praxiswerte als Startpunkt

• Core PtP: 50 ms / Multiplier 3 (≈ 150 ms) – nur wenn stabil
• WAN/Provider: 100–300 ms / Multiplier 3 (≈ 300–900 ms)
• Branch/Edge: 300–1000 ms / Multiplier 3 (≈ 0,9–3 s)

Pre-Checks: Bevor du BFD aktivierst

Sub-Second Failover bringt nur etwas, wenn der Link selbst stabil ist. Prüfe daher Errors/Drops, CPU und Neighbor-Stabilität. BFD auf einem flappenden Link macht alles nur schneller kaputt.

show interfaces | include CRC|drops|error
show ip ospf neighbor
show isis neighbors
show processes cpu sorted

BFD global und am Interface: Baseline-Konfiguration

Die genaue Syntax ist plattform- und IOS-XE-Version-abhängig, aber das Muster bleibt: BFD aktivieren, Timer definieren, dann auf den relevanten Interfaces/Protokollen einschalten.

BFD Interval/Multiplier am Interface setzen

interface gigabitEthernet0/0
 bfd interval 300 min_rx 300 multiplier 3

BFD Status prüfen

show bfd neighbors
show bfd neighbors details

BFD mit OSPF: Aktivierung und Best Practices

OSPF kann BFD nutzen, um die Neighbor-Dead-Erkennung zu beschleunigen. Du aktivierst BFD entweder global im OSPF-Prozess oder pro Interface. In Enterprise-Designs ist pro Interface oft klarer und kontrollierter.

OSPF pro Interface mit BFD (typisches Pattern)

interface gigabitEthernet0/0
 ip ospf 10 area 0
 bfd interval 300 min_rx 300 multiplier 3
 ip ospf bfd

Verifikation

show ip ospf neighbor
show bfd neighbors
show logging | include OSPF|BFD

BFD mit IS-IS: Aktivierung und Best Practices

Auch IS-IS kann BFD nutzen. Besonders auf PtP Links im L2-Backbone ist das ein Standardmuster für schnelle Failure Detection. Wie bei OSPF gilt: konsistent, selektiv und mit vernünftigen Timern.

IS-IS Interface mit BFD (typisches Pattern)

interface gigabitEthernet0/0
 ip router isis CORE
 isis network point-to-point
 bfd interval 300 min_rx 300 multiplier 3
 isis bfd

Verifikation

show isis neighbors
show bfd neighbors
show logging | include ISIS|BFD

Sub-Second Failover richtig testen (ohne Produktion zu gefährden)

Teste BFD-Failover kontrolliert: im Maintenance Window, auf einem nichtkritischen Link oder im Pilot-Cluster. Miss die Zeit und prüfe, ob Routing sauber umschwenkt, ohne Flapping.

• Test: Interface administrativ down/up (kurz)
• Messung: OSPF/IS-IS Neighbor down/up Zeit
• Validierung: Traffic-Tests (Ping/Traceroute) und Logs

Test-Kommandos (Beispiel)

show clock
show bfd neighbors
show ip ospf neighbor
show isis neighbors
ping <remote-ip> repeat 100
show logging | last 100

Typische Pitfalls: Warum BFD flapt

BFD ist sensibel, weil es schnell ist. Flaps entstehen häufig durch Queueing/Jitter, CPU-Überlast oder inkonsistente Timer. In WAN-Umgebungen ist zu aggressives Tuning der Klassiker.

• Timer zu aggressiv für WAN/Jitter → false positives
• CPU hoch → BFD-Pakete werden verzögert, Session fällt
• Asymmetrie/Policing → BFD-Pakete werden gedroppt
• Inkonsequente Aktivierung → nicht alle Links profitieren, Debug wird schwer

Dimensionierung: BFD so einstellen, dass es stabil bleibt

Ein praxistauglicher Ansatz ist: starte konservativ (300/3), beobachte 1–2 Wochen, dann optimiere selektiv im Core. Das senkt das Risiko von Flapping und macht das Verhalten vorhersehbar.

• Start: 300 ms / 3 (≈ 900 ms) als sichere Baseline
• Core-Optimierung: 100 ms / 3 (≈ 300 ms), wenn stabil
• Nur bei Bedarf: 50 ms / 3 (≈ 150 ms) im sehr stabilen Core

Quick-Runbook: BFD + IGP in 5 Minuten verifizieren

Diese Kommandos liefern dir schnell: BFD Sessions up, IGP Neighbors up, und keine Flap-Indizien in Logs.

show bfd neighbors
show bfd neighbors details
show ip ospf neighbor
show isis neighbors
show processes cpu sorted
show logging | include BFD|OSPF|ISIS

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.