OSPF Neighbor Troubleshooting: MTU, Auth, Timers, Network Types

OSPF Neighbor Troubleshooting ist einer der häufigsten „Routing mit System“-Fälle im Enterprise- und Providerbetrieb, weil OSPF als IGP zwar robust ist, aber bei kleinen Inkonsistenzen sehr präzise scheitert: Nachbarschaften bleiben in INIT hängen, wechseln ständig zwischen FULL und DOWN, oder kommen gar nicht erst hoch, obwohl der Link physikalisch stabil ist. Genau hier entscheidet Methodik über Geschwindigkeit: Wenn Sie OSPF-Probleme planlos angehen, verlieren Sie Zeit mit zufälligen „clear ospf“-Aktionen oder diffusen Vermutungen („Firewall?“, „MTU?“, „Auth?“). Wenn Sie systematisch vorgehen, lässt sich in wenigen Minuten beweisen, welcher Parameter nicht passt: MTU, Authentifizierung, Timer, Network Type, Area/Stub-Flags oder Filterung von Multicast (224.0.0.5/224.0.0.6). In diesem Artikel lernen Sie ein praxisbewährtes Vorgehen, um OSPF Neighbor Issues sauber zu diagnostizieren: Sie verstehen den OSPF-Neighbor-State-Machine, erkennen State-spezifische Fehlerbilder, sammeln High-Signal Evidence (Hello-Details, DBD/LSR, MTU-Felder) und setzen Fixes so um, dass die Adjacency stabil bleibt – auch unter Last, bei Link-Flaps oder in komplexen Designs mit VLANs, LAGs und Virtualisierung.

OSPF in der Praxis: Was eine Neighbor-Adacency wirklich „hoch“ macht

OSPF baut eine Nachbarschaft (Neighbor Relationship) über OSPF Hello Pakete auf. Erst wenn beide Seiten kompatible Parameter haben, wird daraus eine vollwertige Adjacency, in der LSAs ausgetauscht werden und beide Router eine konsistente Link-State Database (LSDB) aufbauen. In vielen Umgebungen ist genau das Ziel: FULL (oder bei manchen Network Types 2-Way als „normal“, z. B. bei Broadcast, wenn nicht DR/BDR). Die Spezifikation von OSPFv2 finden Sie in RFC 2328, für OSPFv3 in RFC 5340.

• Hello: Discovery und Parameter-Abgleich (Area, Auth, Timers, Network Type, Options, MTU-Informationen indirekt)
• DR/BDR Wahl: bei Broadcast/NBMA entscheidet, wer mit wem FULL wird
• DBD/LSR/LSU/LSAck: Datenbank-Synchronisation, hier treten viele MTU-/Filter-Probleme auf
• LSDB Konsistenz: erst dann ist Routing stabil und konvergiert erwartbar

Der wichtigste Debugging-Ansatz: State-basierte Diagnose statt „alles prüfen“

OSPF liefert Ihnen selbst die beste Diagnosehilfe: den Neighbor State. Jeder State grenzt die Fehlerdomäne stark ein. Statt 20 Parameter „zu raten“, fragen Sie zuerst: In welchem State hängt die Adjacency fest?

• DOWN: keine Hellos empfangen (oder nicht als gültig akzeptiert) – oft L2/Multicast/ACL/VRF
• INIT: Hellos empfangen, aber eigene Router-ID nicht im Hello des Nachbarn – häufig Multicast-Return, DR/BDR, oder Filter
• 2-WAY: bidirektional, aber keine FULL (bei Broadcast kann das normal sein, wenn Sie nicht DR/BDR sind)
• EXSTART/EXCHANGE: DBD-Austausch; hier dominieren MTU, Duplicate Router IDs, oder fehlerhafte Network Types
• LOADING: LSR/LSU-Austausch; Filter, MTU/Fragmentation, oder Ressourcenlimits zeigen sich hier
• FULL: Adjacency steht – wenn es trotzdem flapped, schauen Sie auf Timer, Link-Flaps, CPU/Queueing, oder Mikro-Filter

Vorarbeit: 5 Checks, die 80% aller OSPF Neighbor Probleme abräumen

Bevor Sie in Protokoll-Details gehen, klären Sie die „Betriebsrealität“ des Links. Diese Checks sind schnell und liefern hohe Trennschärfe.

• Interface up/up und im richtigen VRF/VLAN: falsches VLAN/Trunk oder falsche VRF verhindert Hellos zuverlässig
• IP/Mask korrekt, kein Duplicate IP: OSPF „geht“ nicht sauber bei inkonsistenter L3-Basis
• Multicast Reachability: OSPF nutzt 224.0.0.5 (AllSPFRouters) und 224.0.0.6 (AllDRouters) – Filter/Storm-Control kann das brechen
• Router-ID eindeutig: Duplicate Router IDs führen zu EXSTART/EXCHANGE Chaos
• Zeitsynchronität nicht kritisch, aber Logs helfen: korrekte Zeitstempel beschleunigen Root Cause (NTP ist Betriebshygiene)

MTU-Probleme: Der häufigste Grund für EXSTART/EXCHANGE

MTU-Mismatch ist ein Klassiker: Hellos kommen durch, Nachbarn sehen sich, aber beim DBD-Austausch scheitert die Datenbank-Synchronisation. Das Problem tritt besonders häufig in Umgebungen mit VLAN-Tagging, QinQ, Tunneln, LAGs oder gemischten Plattformen auf. Wichtig: OSPF kann „bis 2-Way“ kommen und dann hängen bleiben – das wirkt wie „random“, ist aber hoch systematisch.

Wie MTU-Mismatch sich typischerweise äußert

• State: EXSTART oder EXCHANGE (manchmal alternierend)
• Logs: Hinweise auf DBD issues, MTU mismatch, oder „too large packet“ (plattformabhängig)
• Capture: DBD-Pakete werden gesendet, aber nicht akzeptiert; Fragmentation/Drop möglich

Warum MTU bei OSPF so kritisch ist

DBD/LSU-Pakete können größer werden, insbesondere bei vielen LSAs. Wenn der Link eine kleinere MTU hat als erwartet, entstehen Drops oder Fragmentation. In manchen Designs verhindert Policy/Firewall ICMP, was PMTUD stört. Für IP/MTU-Grundlagen ist RFC 791 (IPv4) hilfreich, für PMTUD unter IPv4 RFC 1191 und unter IPv6 RFC 8201.

MTU-Checks, die im Incident funktionieren

• MTU beidseitig auf Interface-Ebene vergleichen (inkl. Subinterfaces/Port-Channel)
• VLAN/QinQ/Overlay-Overhead berücksichtigen (L2 MTU vs. IP MTU)
• Wenn möglich: gezielte Tests mit großen Paketen (nicht nur Ping default)
• PCAP: DBD/LSU Größen und Fragmentation sichtbar machen

Auth-Probleme: Wenn Hellos „da“ sind, aber nicht als gültig gelten

OSPF Authentication ist ein häufiges Missverständnis: Oft sieht man „irgendwelche OSPF Pakete“ auf dem Wire, aber die Nachbarschaft bleibt DOWN, weil die Hellos verworfen werden. Auth-Mismatches sind meist sofort lösbar – wenn man sie korrekt erkennt.

Typische Auth-Fehlerbilder

• State: DOWN (weil Hellos verworfen werden) oder sporadisches Flapping bei Key-Rollovers
• Logs: Authentication failure, mismatch, bad digest (plattformabhängig)
• Symptom: Einseitiges „ich sehe dich“ ist selten; meist sieht keiner den anderen als Neighbor

Was Sie prüfen sollten

• Auth-Typ konsistent (none vs. simple vs. cryptographic)
• Key-ID und Key-String/Hash konsistent
• Rollover-Plan: Überlappende Keys, um Flaps zu vermeiden
• OSPFv3 nutzt andere Mechaniken (IPsec/Authentication je nach Implementierung); State-Muster bleibt dennoch ähnlich

Timer-Probleme: Hello/Dead – schnell erkannt, oft unterschätzt

Hello- und Dead-Interval müssen auf einem Link übereinstimmen. Timer-Mismatch führt typischerweise dazu, dass Nachbarschaften gar nicht erst entstehen oder ständig flappen. In WANs werden Timer manchmal aggressiv gesetzt, um schneller zu konvergieren, aber auf instabilen Links führt das zu Flapping.

Typische Timer-Fehlerbilder

• State: INIT/2-WAY, manchmal gar kein Neighbor (je nach Plattformverhalten)
• Symptom: Nachbar kommt kurz hoch, fällt wieder (Dead Timer Expired)
• Root Cause: inkonsistente Konfig, Template-Drift, oder unterschiedliche Profile auf Subinterfaces

Stabile Timer-Strategie

• Timer nur dort aggressiv, wo Linkqualität und CPU-Headroom es zulassen
• BFD (wenn im Design) kann schnelleres Failure-Detection liefern, ohne OSPF Timer extrem zu verkürzen
• Bei Flapping zuerst physische Instabilität (Errors/Flaps) ausschließen, bevor Timer „hochgedreht“ werden

Network Types: Broadcast, Point-to-Point, NBMA – der häufige Hidden Mismatch

OSPF Network Type beeinflusst DR/BDR-Wahl, Multicast-Verhalten und die Erwartung, wie Nachbarn entdeckt werden. Ein Mismatch ist besonders tückisch, weil Hellos teilweise funktionieren, aber Adjacencies unerwartet hängen bleiben oder nur mit manchen Routern FULL werden.

Typische Network-Type-Fallen

• Broadcast vs. Point-to-Point: DR/BDR-Logik vs. direkte FULL; falscher Type kann zu „2-WAY only“ führen
• NBMA: häufig bei Frame Relay/älteren WANs; benötigt Neighbor-Statements oder spezifische Discovery
• Point-to-Multipoint: sinnvoll bei Hub-and-Spoke; falsche Wahl kann zu suboptimalen Adjacencies führen

Wie Sie Network-Type-Probleme erkennen

• State-Muster: viele Nachbarn bleiben 2-WAY, aber nicht FULL (bei Broadcast normal, wenn nicht DR/BDR)
• DR/BDR Anomalien: unerwartete DR-Wahl auf Links, die eigentlich p2p sein sollten
• Multicast vs. Unicast: auf manchen WAN-Technologien ist Multicast nicht sauber unterstützt; dann muss Design angepasst werden

INIT vs. 2-WAY vs. FULL: Die häufigsten State-Interpretationsfehler

Viele Incidents entstehen, weil Teams „2-WAY ist schlecht“ oder „INIT ist fast gut“ falsch interpretieren. Gerade in Broadcast-Netzen ist 2-WAY für Nicht-DR/BDR völlig normal. INIT hingegen bedeutet: Sie sehen Hellos, aber es ist nicht bidirektional bestätigt.

• INIT: Ihr Router sieht den Nachbarn, aber der Nachbar bestätigt Sie nicht (Ihre Router-ID fehlt in dessen Hello). Häufig Multicast-Rückweg, ACL, oder falsches VLAN.
• 2-WAY: Bidirektional bestätigt. In Broadcast ist FULL nur mit DR/BDR, nicht mit allen.
• FULL: vollständige LSDB-Synchronisation (Adjacency). Erwartet bei p2p oder DR/BDR Beziehungen.

OSPF Neighbor flaps: Wenn es „eigentlich geht“, aber nicht stabil ist

Nachbarschaften, die von FULL auf DOWN fallen, sind meist keine „Protokollprobleme“, sondern Stabilitätsprobleme auf dem Link oder in der Plattform. Der Klassiker: Physische Errors, Microbursts, CPU-Pressure oder Control-Plane-Policing, die Hellos oder LSAs verzögert.

• Dead Timer Expired: Hellos kommen nicht rechtzeitig an (Loss/Delay)
• Interface Flaps: Link up/down, Optics/Kabel, Autoneg/CRC
• Control-Plane Overload: CPU hoch, CoPP/PPPoE/ACLs, die OSPF-Pakete drosseln
• LAG/ECMP Issues: OSPF über Port-Channel mit inkonsistenten Members, MTU-Drift oder Errors auf einem Member

PCAP und Forensik: Wenn Sie den Beweis brauchen

Wenn Logs nicht reichen oder Sie eine Root Cause sauber dokumentieren müssen, ist ein gezielter Capture extrem wirkungsvoll. Sie sehen Hellos, Options, Router IDs, DR/BDR Felder, DBD/LSU Größen und Timing. Nutzen Sie kurze Zeitfenster und filtern Sie auf OSPF (IP-Protokoll 89). Für Praxis-Workflows eignen sich die Wireshark-Dokumentation und die tcpdump-Manpage.

• Hellos: Area ID, Timers, Options, Router Priority, DR/BDR
• DBD: MTU/Exchange-Pattern, Master/Slave Negotiation
• LSU/LSAck: Größe, Fragmentation, Drops/Timeouts

Runbook-Baustein: OSPF Neighbor Troubleshooting in 15 Minuten

• Minute 0–3: Neighbor State feststellen (DOWN/INIT/2-WAY/EXSTART/EXCHANGE/LOADING/FULL) und betroffenen Link/VRF/VLAN identifizieren.
• Minute 3–6: Basis prüfen: Interface up/up, IP/Mask, Multicast nicht gefiltert, Router-ID eindeutig, Area korrekt.
• Minute 6–9: State-spezifisch: DOWN/INIT → Filter/Multicast/ACL/VLAN; EXSTART/EXCHANGE → MTU/Duplicate RID/Network Type; LOADING → Drops/Fragmentation/Policy.
• Minute 9–12: Parameter prüfen: MTU beidseitig (inkl. Subinterfaces/Port-Channel), Auth, Hello/Dead Timers, Network Type, DR/BDR Verhalten.
• Minute 12–15: Low-Risk Fix und Verifikation: Konfig konsistent machen (MTU/Auth/Timers/Type), ggf. fehlerhaften LAG-Member drainen; danach Adjacency stabilisieren und Logs/Counter beobachten.

Best Practices: Damit OSPF Neighbors stabil bleiben

• Templates und Drift-Kontrolle: MTU/Auth/Timers/Type pro Link-Klasse standardisieren
• MTU sauber planen: L2/L3 MTU in VLAN/QinQ/Tunnel-Designs konsistent
• Auth-Rollovers planen: Keys überlappend einführen, um Flaps zu vermeiden
• Timer nicht überaggressiv: Stabilität vor „Schnelligkeit“; BFD als Alternative prüfen
• Monitoring auf State und Flaps: Neighbor-Changes, Dead Timer Events, TCN/Interface Flaps korrelieren

Weiterführende Quellen für Standards und Praxis

• RFC 2328 für OSPFv2 (Neighbor State Machine, Timers, Network Types)
• RFC 5340 für OSPFv3 (IPv6-Deployments, ähnliche Troubleshooting-Logik)
• RFC 791 für IP-Grundlagen (Fragmentation-Kontext bei MTU-Problemen)
• RFC 1191 für PMTUD unter IPv4 (wenn MTU-Blackholes OSPF/LSU beeinflussen)
• RFC 8201 für PMTUD unter IPv6
• Wireshark Dokumentation für OSPF Hello/DBD/LSU Analyse und Timing-Korrelation
• tcpdump Manpage für effiziente Captures (IP-Protokoll 89) in produktiven Umgebungen

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.