OSPF-Troubleshooting: Nachbarbeziehungen, LSAs und Convergence-Probleme diagnostizieren

OSPF-Troubleshooting ist im Betrieb vor allem dann kritisch, wenn sich ein Fehler nicht als kompletter Ausfall zeigt, sondern als „mal geht’s, mal nicht“: Nachbarbeziehungen bleiben in einem Zwischenzustand hängen, einzelne Präfixe fehlen, oder die Convergence (Zeit bis zur stabilen Routenlage nach einer Änderung) ist deutlich länger als erwartet. OSPF (Open Shortest Path First) ist ein Link-State-Routingprotokoll: Router tauschen Zustandsinformationen (LSAs, Link-State Advertisements) aus und berechnen daraus lokal den kürzesten Pfad. Genau diese Mechanik liefert sehr gute Diagnosesignale – wenn man strukturiert vorgeht.

Dieser Beitrag ist als Runbook gedacht: erst Sicherheitsgeländer (Impact, Rückfall), dann eine klare Prüfsequenz für Nachbarbeziehungen, LSAs/LSDB und Convergence-Probleme. Wo Befehle gezeigt werden, sind sie bewusst generisch gehalten: Syntax unterscheidet sich je nach Plattform (Cisco IOS/IOS-XE, NX-OS, Juniper Junos, FRRouting, MikroTik u. a.), aber die Zustände, Zähler und Ursachenmuster sind in OSPF weitgehend identisch.

OSPF-Troubleshooting: 1) Vor dem Eingriff: Scope, Risiko und Rückfallstrategie

Bevor Sie „irgendetwas“ an OSPF ändern, klären Sie drei Punkte: Was ist betroffen (Scope), was ist der potenzielle Impact, und wie kommen Sie zurück (Rollback). OSPF reagiert auf Änderungen oft sofort; ein falsch gesetzter Parameter kann eine Nachbarschaft resetten, LSAs neu fluten und damit CPU/Control-Plane belasten – besonders auf zentralen Knoten.

Scope schnell eingrenzen

• Nur ein Link / ein Nachbar? Dann ist es häufig Interface-, MTU-, Auth- oder Timer-bezogen.
• Mehrere Nachbarn in einer Area? Dann sind Area-Typ, Filter, virtuelle Links, Netztyp oder DR/BDR-Konsens verdächtig.
• „Routen fehlen“ ohne Nachbarproblem? Dann eher LSA-Typen, Summarization, Filtering, Max-LSA, stub/NSSA-Logik oder Redistribution.
• Convergence langsam bei sonst korrekten Nachbarschaften: SPF/LSA-Throttling, LSA-Flapping, Interface-Fehler, CPU, oder zu große LSDB.

Rückfallstrategie (praktisch)

Im OSPF-Betrieb hat sich bewährt, jede Änderung so zu planen, dass sie ohne „große“ OSPF-Operationen zurückgenommen werden kann:

• Konfig-Backup (Versionierung, Change-Referenz, Zeitstempel).
• Ein Parameter pro Change (nicht Hello, Auth und Netztyp gleichzeitig).
• Wartungsfenster bei potenziellen Neighbor-Resets (Auth/MTU/Netztyp/Area-Change).
• Plan B: temporär statische Route, temporäre Kostenanpassung (OSPF cost), oder kontrolliertes Shutdown/No-Shutdown einzelner Links – aber bewusst als Eingriff, nicht als „Try & Error“.

2) OSPF-Nachbarbeziehungen: Zustände verstehen und gezielt testen

Die OSPF Neighbor States sind Ihr erster Kompass. Wichtig: Je nach Netzwerktyp ist nicht jede Nachbarschaft „FULL“. Auf Broadcast- und NBMA-Netzen ist oft nur die Nachbarschaft zum DR/BDR (Designated Router / Backup Designated Router) FULL; andere bleiben bei 2-WAY, was korrekt sein kann. Auf Point-to-Point ist FULL zwischen den beiden Routern normal.

Die Zustände und was sie im Betrieb bedeuten

• DOWN: keine Hellos gesehen. Ursache oft L2/L3/ACL/Multicast/Interface down.
• INIT: Hellos empfangen, aber eigene Router-ID wird im Hello nicht zurückgemeldet. Typisch bei unidirektionalem Traffic oder Filter/ACL.
• 2-WAY: bidirektional, aber (auf Broadcast/NBMA) nicht zum DR/BDR adjazent. Kann korrekt sein.
• EXSTART/EXCHANGE: Datenbankabgleich (DBD). Häufig MTU-Mismatch oder fehlerhafte Paketfragmentierung/Filter.
• LOADING: LSR/LSU (Link State Request/Update) laufen, aber nicht vollständig. Oft LSA-Filter, Paketverlust, MTU/Fragmentation, oder überlastete Control-Plane.
• FULL: LSDB synchron (für die adjazente Nachbarschaft).

Prüfsequenz für „Neighbor wird nicht FULL“

Arbeiten Sie von außen nach innen: erst Connectivity und Interface, dann OSPF-Parameter, dann LSDB/Exchange.

Schritt A: Ist L3-Connectivity für OSPF überhaupt möglich?

OSPF nutzt IP-Protokoll 89 (nicht TCP/UDP). Auf Broadcast-Netzen werden Hellos an 224.0.0.5 (AllSPFRouters) und 224.0.0.6 (AllDRouters) gesendet. Auf Point-to-Point kann es ebenfalls Multicast sein, abhängig von Plattform/Netztyp. Firewalls, ACLs, Security-Groups oder CoPP (Control Plane Policing) müssen das erlauben.

Minimaler Capture-Ansatz (Linux-Host als Tap/Span-Auswertung; bei Routern gibt es oft integrierte Packet-Capture-Features):

# Auf einem Mirror-Port oder Capture-Host:
# OSPF-Protokoll 89 und Multicast-Ziele prüfen
sudo tcpdump -ni eth0 'ip proto 89 or (ip multicast and (host 224.0.0.5 or host 224.0.0.6))'

Was Sie sehen wollen: regelmäßige Hello-Pakete (Default 10s auf Broadcast, 30s auf NBMA – variiert). Wenn nur eine Richtung sichtbar ist, passt das zu INIT (unidirektional). Wenn gar nichts sichtbar ist: L2/VLAN, Interface, oder Filter.

Schritt B: Stimmen die „Must-match“-Parameter?

Für eine OSPF-Nachbarschaft müssen zentrale Parameter übereinstimmen. Welche genau, hängt vom Netzwerktyp und Feature-Set ab, aber diese sind die Klassiker:

• Area-ID: beide Seiten müssen im selben OSPF-Area-Kontext sprechen (z. B. Area 0 als Backbone).
• Hello/Dead-Interval: müssen übereinstimmen, sonst ignoriert der Nachbar die Hellos.
• Netztyp (Broadcast, Point-to-Point, NBMA): beeinflusst DR/BDR-Wahl und Erwartung an Nachbarschaften.
• Authentifizierung: Art (z. B. Simple/MD5/HMAC je nach Plattform) und Schlüssel müssen passen. Wichtig: Auth ist häufig „stillschweigend“ – falsche Keys führen zu Down/Init.
• Stub-Flag/Area-Typ: In Stub/NSSA-Areas müssen Area-Typen konsistent sein, sonst scheitert die Adjazenz.

Praxisstolperfalle: Änderungen am Area-Typ oder an der Authentifizierung führen oft zu sofortigen Neighbor-Resets. Planen Sie das als Betriebsereignis (Monitoring, Wartungsfenster).

Schritt C: MTU-Mismatch sauber abklären

MTU-Mismatch ist einer der häufigsten Gründe für EXSTART/EXCHANGE. OSPF verhandelt beim Datenbankabgleich Paketgrößen; wenn eine Seite größere Pakete sendet als die andere akzeptiert, sehen Sie Retransmits, Exchange-Loop oder stuck states. Das passiert oft nach VLAN-/MPLS-/Tunnel-Änderungen, wenn nur auf einer Seite die L2-MTU angepasst wurde.

• Indiz: Neighbor pendelt zwischen EXSTART und EXCHANGE oder bleibt dort stehen.
• Warum: DBD/LSU-Pakete werden verworfen oder fragmentiert/blocked.
• Risiko: „Schnellfix“ über MTU-Ignore kann Symptome kaschieren, aber echte Fragmentation-/Path-MTU-Probleme bleiben.

Operational sinnvoll: MTU auf beiden Seiten konsistent setzen und bei Bedarf Path-MTU entlang des Pfads prüfen (z. B. bei L3-Portchannels, QinQ, GRE/IPsec, VXLAN-Underlay).

Schritt D: DR/BDR und Netztyp als Fehlerquelle

Auf Broadcast- oder NBMA-Segmenten wird ein DR/BDR gewählt. Das beeinflusst, zu wem eine volle Adjazenz aufgebaut wird. Wenn Sie erwarten, dass „alle zu allen FULL sind“, aber Sie sind auf Broadcast mit DR/BDR, ist 2-WAY zu Nicht-DR-Nachbarn normal. Problematisch wird es, wenn DR/BDR ständig wechselt (Flapping) oder der DR nicht erreichbar ist.

• Typische Ursachen: instabile L2-Domäne, Paketverlust, unterschiedliche Prioritäten, oder Neustarts von Gateways.
• Auswirkung: wiederholter LSDB-Abgleich, erhöhte LSA-Flut, Convergence-Probleme.

3) LSAs und LSDB: Wenn Routen fehlen oder „inkonsistent“ wirken

Wenn Nachbarn FULL sind, aber Routen fehlen oder falsch gewichtet sind, sind LSAs und die Link-State Database (LSDB, die OSPF-interne Topologiedatenbank) der nächste Fokus. OSPF rechnet nicht „aus dem Nichts“: Wenn eine Information nicht als LSA in der LSDB vorhanden ist, kann sie auch nicht in der Routingtabelle erscheinen.

LSA-Typen in der Praxis (kurz und betriebsnah)

• Type 1 (Router-LSA): beschreibt Links eines Routers innerhalb einer Area. Basis für SPF.
• Type 2 (Network-LSA): wird vom DR auf Broadcast/NBMA erzeugt und beschreibt das gemeinsame Netzsegment.
• Type 3 (Summary-LSA): von ABRs (Area Border Routers) für zusammengefasste oder weitergeleitete Netze zwischen Areas.
• Type 4 (ASBR-Summary): zeigt den Weg zu einem ASBR (Autonomous System Boundary Router), der externe Routen einspeist.
• Type 5 (External-LSA): externe Routen (Redistribution), nicht in Stub-Areas erlaubt.
• Type 7 (NSSA-External): externe Routen in NSSA-Areas; werden am ABR in Type 5 übersetzt.

Warum das wichtig ist: Wenn Sie z. B. in einer Stub-Area plötzlich Type-5-External erwarten, ist nicht „OSPF kaputt“, sondern das Design oder die Area-Definition passt nicht zur Erwartung.

Diagnosepfad: „Route fehlt“ in fünf Schritten

1. Ist das Präfix in der LSDB vorhanden? Wenn nein: Quelle/Redistribution/ABR/Filter prüfen.
2. Ist es im richtigen LSA-Typ vorhanden? Extern (Type 5/7) vs. intern (Type 1/3).
3. Kommt es aus der erwarteten Area? Area-Design und ABR-Pfade prüfen.
4. Wird es installiert? Administrative Distance, RIB-Failure, Route-Preference, oder Policy kann die Installation verhindern.
5. Wird es weiter annonciert? Filter, Summarization, NSSA-Übersetzung, oder Max-LSA/LSA-Refresh-Probleme.

Für die Datenerhebung ist es hilfreich, sich eine standardisierte „Show“-Sammlung pro Plattform anzulegen. Beispielhaft (als Platzhalter-Runbook, die konkreten Befehle passen Sie an Ihr OS an):

# Runbook: Daten sammeln (als Vorlage, Kommandos je nach Plattform ersetzen)
# 1) OSPF Nachbarn + Zustände
# 2) OSPF Interface-Details (Timer, Netztyp, MTU, Auth)
# 3) LSDB-Auszug: relevante LSA-Typen und betroffene Präfixe
# 4) Routingtabelle: Präfix vorhanden? über welchen Next-Hop?
# 5) Logs: Neighbor-Resets, Auth-Fehler, MTU/DBD-Hinweise

Typische Ursachen für fehlende oder „komische“ LSAs

• Area-Mismatch / falscher Area-Typ: Stub/NSSA inkonsistent, Backbone-Design verletzt, virtuelle Links nicht stabil.
• OSPF-Filter oder Route-Policies: Ein- oder Ausfilterung von Summary-/External-LSAs (plattformabhängig).
• Summarization: ABR fasst zusammen; einzelne Präfixe erscheinen nicht mehr granular. Das ist gewollt, kann aber Troubleshooting erschweren.
• Redistribution-Probleme: Externe Routen werden nicht eingespeist (z. B. fehlende Matching-Regeln) oder als falscher Typ (E1/E2) verteilt.
• Max-LSA / LSDB-Limits: Einige Plattformen können bei LSDB-Überlauf Nachbarschaften droppen oder LSAs ablehnen – relevant bei großen Domains.

4) Convergence-Probleme: Wenn OSPF „zu lange“ braucht oder instabil wirkt

Convergence ist nicht nur „Routing kommt irgendwann wieder“. Im Betrieb zählt, ob Ihre Applikationen (VoIP, ERP, VDI, Storage, API-Gateways) innerhalb definierter Sekunden stabil sind. OSPF-Convergence setzt sich aus mehreren Zeiten zusammen: Erkennung des Events (Dead-Timer oder BFD), Flooding der LSAs, SPF-Berechnung, Installation in die Routingtabelle und ggf. FIB-Programmierung in Hardware.

Erst trennen: langsam vs. instabil

• Langsam: Nach Link-Event dauert es reproduzierbar „zu lange“, aber stabilisiert sich dann.
• Instabil: Nachbarn flappen, LSAs werden ständig neu geflutet, Routen wechseln häufig.

Häufige Ursachen für langsame Convergence

• Dead-Interval zu hoch: Event-Erkennung dauert zu lange (klassisch 40s). Abhilfe: Timer-Tuning oder BFD (Bidirectional Forwarding Detection; schneller Liveness-Check unterhalb von OSPF).
• Überlastete Control-Plane: SPF und LSA-Verarbeitung konkurrieren mit anderen Tasks; sichtbar als hohe CPU oder Queueing.
• Große LSDB: Viele LSAs bedeuten mehr Flooding und längere SPF-Rechenzeit.
• SPF/LSA-Throttling: Schutzmechanismen drosseln Berechnungen bei Event-Stürmen; gut gegen Instabilität, aber schlecht für „sofort“.
• L2-Probleme: Paketverlust/Jitter auf dem Link; OSPF muss retransmitten, adjacency re-synct.

Häufige Ursachen für instabile Convergence (Flapping)

• Physik: CRC-Fehler, Duplex/Speed-Mismatch, instabile Optiken, schwankende Funk-/WAN-Strecken.
• ECMP/Asymmetrie: Traffic nimmt unterschiedliche Pfade, Rückwege werden gefiltert (INIT-Symptom).
• DR/BDR-Wechsel auf Broadcast-Segmenten durch L2-Instabilität oder Prioritätskonflikte.
• Fehlkonfiguration: unterschiedliche Timer, Auth-Key-Rotation nur einseitig, MTU nach Change nicht überall angepasst.

Mess- und Beobachtungsstrategie (Monitoring-tauglich)

Für „Monitoraggio“ zählt, dass Sie Convergence nicht nur einmalig debuggen, sondern dauerhaft messbar machen:

• Neighbor-Uptime und Flap-Rate: Anzahl der State-Transitions pro Stunde/Tag.
• LSA-Churn: wie viele LSAs werden pro Zeit neu erzeugt/refresh/retransmitted.
• SPF-Runs: Häufigkeit und Dauer von SPF-Berechnungen (falls Plattform Metriken liefert).
• Interface-Error-Raten: CRC, input drops, queue drops, optical power (bei Fiber).
• Event-Korrelation: Link-Down/Up, OSPF neighbor change, CPU-Spike, danach Applikationsalarme.

Wenn Sie nur „Ping ist wieder da“ messen, übersehen Sie Mikro-Unterbrechungen, die z. B. TCP-Reset-Stürme oder Paketverluste verursachen.

5) Praxis-Checklisten: schnell sicherstellen, dass Sie nichts übersehen

Checkliste A: Neighbor kommt nicht hoch

• Interface up/up, korrekte VLAN/Tagging/Trunking
• IP-Adressierung / Subnetzmaske passend, kein Duplicate IP
• OSPF aktiviert auf dem richtigen Interface (passive-interface prüfen)
• Hello/Dead stimmen überein
• Area-ID und Area-Typ stimmen überein (Stub/NSSA)
• Authentifizierung: Methode + Key/Key-ID konsistent
• MTU beidseitig konsistent; Fragmentation/PMTUD nicht blockiert
• Netztyp konsistent (p2p vs broadcast); DR/BDR-Verhalten verstanden
• ACL/Firewall/CoPP erlaubt IP Proto 89 und Multicast

Checkliste B: Nachbarn FULL, aber Route fehlt

• Präfix in LSDB vorhanden? Wenn nein: Quelle/Redistribution/ABR/Filter
• LSA-Typ plausibel (intern vs extern; NSSA-Übersetzung)
• Summarization auf ABR aktiv? Erwartung an Detailrouten prüfen
• Routingtable/RIB installiert? Administrative Distance/Policy/Recursive Next-Hop
• Forwarding/FIB korrekt? (Hardware-Programmierung, VRF-Kontext)

Checkliste C: Convergence zu langsam

• Event-Erkennung: Dead-Interval vs. BFD
• LSA-Flooding: Paketverlust, Retransmits, Interface-Errors
• SPF: CPU/Memory, SPF-Throttling-Parameter, LSDB-Größe
• Design: zu große Areas, zu viele ABRs/ASBRs, unnötige Redistribution
• Change-Quelle: instabile Links, flappende Portchannels, fehlerhafte Optiken

6) Umsetzung: typische Fixes – und wann sie scheitern

Im Troubleshooting ist es verführerisch, „schnelle“ Workarounds zu setzen. Besser ist: Ursache isolieren, dann Fix mit klarer Nebenwirkungsanalyse.

Timer-Tuning und BFD

Timer-Tuning (Hello/Dead reduzieren) kann Convergence beschleunigen, erhöht aber die Empfindlichkeit gegenüber Jitter und kurzen Paketverlusten. BFD ist oft die sauberere Variante: Es liefert schnelle Link-/Pfad-Erkennung, während OSPF die Topologie-Logik behält. Scheitern kann BFD an asymmetrischen Pfaden, Hardware-Offload-Bugs oder zu aggressiven Intervallen im WAN.

MTU- und Path-MTU-Probleme beheben

Die nachhaltige Lösung ist Konsistenz: gleiche MTU, gleiche Encapsulation, und keine Blockade von ICMP, sofern PMTUD (Path MTU Discovery) gebraucht wird. „MTU Ignore“ kann kurzfristig helfen, ist aber riskant: große LSUs oder Applikationstraffic können weiterhin fragmentieren oder droppen.

Area-Design glätten

Viele Convergence- und LSA-Probleme sind Designfolgen: zu große Flooding-Domänen, unnötige Externals, oder unklare Area-Grenzen. Eine saubere Area-0-Planung, begrenzte Redistribution und sinnvolle Summarization reduzieren LSA-Churn. Scheitern kann das organisatorisch (Change-Aufwand) oder an Abhängigkeiten, wenn Applikationen „harte“ IP-Pfade erwarten.

DR/BDR stabilisieren

Wenn DR/BDR-Flapping ein Thema ist, helfen klare Prioritäten und stabile L2-Segmente. In manchen Designs ist Point-to-Point (wo möglich) einfacher zu betreiben als große Broadcast-Domänen. Scheitern kann das, wenn das L2-Design (z. B. Campus-VLANs) nicht ohne Weiteres änderbar ist.

7) Dokumentation und Betriebsroutine: aus Troubleshooting wird Stabilität

OSPF-Probleme tauchen wieder auf, wenn Betriebswissen nicht „in den Prozess“ wandert. Zwei einfache Bausteine haben sich bewährt:

• Standardisiertes Diagnosepaket: Welche Ausgaben sammeln Sie bei Neighbor-/LSA-/Convergence-Events? Wo werden sie abgelegt? Wer wertet sie aus?
• Change-Guardrails: Für Auth-Key-Rotation, MTU-Änderungen, Area-Änderungen und Redistribution gibt es ein kurzes Runbook mit Vorher/Nachher-Checks und Rollback.

Planen Sie außerdem Kapazitätsgrenzen: Wenn die LSDB wächst (Standorte, VRFs, neue Externals), steigt nicht nur der Speicherbedarf, sondern auch die Rechen- und Flooding-Last. Frühzeitige Trends sind hier mehr wert als ein einmaliges „Nach dem Ausbau war alles langsam“.

Fazit: Mit einer festen Prüfsequenz werden OSPF-Probleme beherrschbar

OSPF-Troubleshooting wird deutlich einfacher, wenn Sie die Diagnose konsequent in drei Ebenen trennen: Nachbarbeziehungen (States und Must-match-Parameter), LSAs/LSDB (Ist die Information überhaupt vorhanden und im richtigen Typ?), und Convergence (Event-Erkennung, Flooding, SPF, Installation). Mit einem klaren Runbook, reproduzierbaren Captures und Monitoring auf Flaps, LSA-Churn und Interface-Errors finden Sie Ursachen schneller – und vermeiden Fixes, die nur Symptome verschieben.

Für dieses Thema sind auch Ospf Nachbarbeziehung und Ospf Lsas wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.