February 24, 2026

OSPF Troubleshooting: Nachbarschaften, Areas und Authentifizierung

OSPF Troubleshooting ist eine der wichtigsten Aufgaben im Layer-3-Betrieb, weil OSPF (Open Shortest Path First) in vielen Unternehmensnetzen als zentrales IGP (Interior Gateway Protocol) eingesetzt wird. Wenn OSPF-Nachbarschaften nicht hochkommen, Areas falsch gebaut sind oder die Authentifizierung nicht passt, wirken die Symptome schnell dramatisch: Standorte sind voneinander getrennt, neue VLANs sind „nicht routbar“, Failover funktioniert nicht oder Routing-Tabellen sehen plötzlich „leer“ bzw. unvollständig aus. Das Tückische dabei ist, dass OSPF-Probleme oft selektiv sind. Ein Link ist up, IP-Ping funktioniert sogar, aber die Nachbarschaft bleibt im Zustand INIT oder EXSTART hängen. Oder die Nachbarschaft ist FULL, aber bestimmte Routen fehlen, weil Area-Typen, Summaries oder Filter unerwartet wirken. In diesem Leitfaden lernen Sie praxisnah, wie Sie OSPF systematisch troubleshoot’en: zuerst die Nachbarschaftsbildung (Hello, Dead, Network Type, DR/BDR), dann Area-Design und LSA-Logik, und schließlich die Authentifizierung (klassisch und HMAC), inklusive klarer Checks und typischer Fehlermuster, die Sie im Betrieb immer wieder sehen.

Table of Contents

OSPF in der Praxis: Was Sie fürs Troubleshooting wirklich verstehen müssen

Für effektives Troubleshooting reicht ein solides Grundmodell: OSPF bildet Nachbarschaften, tauscht Link-State-Informationen (LSAs) aus, berechnet daraus eine Datenbank (LSDB) und erzeugt am Ende Routing-Tabelleneinträge. Wenn etwas schiefgeht, ist fast immer eine dieser Stufen betroffen: Nachbarschaft kommt nicht zustande, LSDB synchronisiert nicht, oder Routen werden aus Design-/Policy-Gründen nicht installiert.

Neighbor: Zwei Router „sehen“ sich und werden Nachbarn (Hello/Dead, Parameter-Match).
Adjacency: Nachbarn synchronisieren LSDB (DBD/LSR/LSU/LSAck) und werden FULL.
LSDB: Link-State Database enthält alle LSAs der Area (und ggf. Summary/External LSAs).
SPF/Routes: Aus der LSDB berechnet SPF die besten Pfade, Routen werden installiert.

Für eine normative Referenz eignet sich RFC 2328 (OSPFv2). Für OSPFv3 (IPv6/Modernisierung) ist RFC 5340 relevant.

Die wichtigsten OSPF-Zustände: Schnell erkennen, wo es klemmt

OSPF-Nachbarn durchlaufen definierte Zustände. Für Admins sind vor allem diese Zustände diagnostisch wertvoll, weil sie direkt auf die Ursacheklasse hinweisen:

DOWN: Keine Hellos empfangen (L1/L2, IP, Multicast/ACL, falsches Interface).
INIT: Hellos empfangen, aber die eigene Router-ID steht nicht im Hello des Gegenübers (unidirektional, Filter, MTU/Policy indirekt).
2-WAY: Bidirektionale Hello-Sicht; auf Broadcast/Non-Broadcast ist 2-WAY für Nicht-DR-Nachbarn normal.
EXSTART/EXCHANGE: Datenbankaustausch startet, bleibt aber hängen (MTU-Mismatch, DBD-Probleme, Instabilität).
LOADING: LSA-Requests laufen; hängt oft bei LSA-Fehlern oder Paketverlust.
FULL: Adjacency vollständig; wenn trotzdem Routen fehlen, liegt es eher an Area/LSA/Policy.

OSPF Nachbarschaften: Die Top-Checks, wenn Neighbor nicht hochkommt

Wenn eine OSPF-Nachbarschaft nicht zustande kommt, ist der schnellste Weg ein Parameter-Check. OSPF ist sehr strikt: Bestimmte Werte müssen übereinstimmen, sonst wird keine Adjacency aufgebaut. Die Kunst liegt darin, nicht „alles gleichzeitig“ zu ändern, sondern zuerst die klassischen Mismatches auszuschließen.

Hello/Dead Timer

Hello- und Dead-Intervalle müssen auf einem Link zueinander passen. Unterschiedliche Timer sind einer der häufigsten Gründe für „DOWN“ oder dauerhaftes Flapping. In vielen Umgebungen werden Timer bewusst beschleunigt (Fast Hellos), dann muss es konsequent überall gleich sein.

Stimmen Hello/Dead auf beiden Seiten überein?
Gibt es Profil-Mischungen (Standard vs. Fast) auf unterschiedlichen Links?
Flappen Nachbarn zeitlich exakt im Dead-Intervall? (starkes Indiz)

Area-ID und Area-Typ

Die Area-ID muss identisch sein. Zusätzlich müssen bestimmte Area-Eigenschaften kompatibel sein (z. B. Stub/NSSA-Flags). Ein Area-Mismatch führt zu Nachbarschaften, die gar nicht erst zustande kommen oder sofort wieder abbrechen.

Ist die Area-ID gleich (z. B. Area 0 vs. Area 10)?
Ist Stub/NSSA konsistent? (Ein Router „stub“, der andere „normal“ ist ein klassischer Fehler.)
Ist eine Virtual Link-Konfiguration beteiligt (heikel, oft Ursache)?

Network Type und DR/BDR-Verhalten

OSPF behandelt Links je nach Network Type unterschiedlich (Broadcast, Point-to-Point, NBMA, Point-to-Multipoint). Wenn die Seiten unterschiedliche Network Types verwenden, können Hellos zwar ankommen, aber die Adjacency verhält sich unerwartet (z. B. falsche DR-Wahl, fehlende Full-Adjacencies).

Ist der Link wirklich Broadcast (Ethernet) oder effektiv Point-to-Point (z. B. PPP)?
Bei NBMA: Sind Neighbor-Statements erforderlich und vorhanden?
Gibt es eine DR/BDR-Wahl, die nicht zum Design passt (z. B. Access-Router wird DR)?

Router-ID und Duplicate Router IDs

Eine doppelte Router-ID ist ein seltener, aber extrem schwerer Fehler: Nachbarschaften können instabil sein, LSAs überschreiben sich, und das Routing wird unberechenbar. Das passiert häufig nach Klonen von VMs oder bei automatisierten Deployments ohne eindeutige RID-Policy.

Ist die Router-ID eindeutig?
Wird RID stabil gewählt (Loopback) und nicht dynamisch über wechselnde Interfaces?
Gibt es Hinweise auf RID-Änderungen nach Reboots?

Multicast/ACL/Firewall: OSPF-Pakete werden gedroppt

OSPF nutzt IP-Protokollnummer 89 und arbeitet mit Multicast-Adressen (224.0.0.5/224.0.0.6 für OSPFv2). Wenn ACLs, Firewalls, Host-Firewalls oder Router-Policies diese Pakete blockieren, bleibt der Neighbor down oder instabil.

Ist IP-Protokoll 89 erlaubt (nicht nur TCP/UDP)?
Werden Multicast-Hellos im Segment weitergeleitet (kein VLAN/Trunk-Fehler)?
Gibt es Security-Policies, die 224.0.0.x filtern?

Wenn Nachbarn hängen bleiben: EXSTART/EXCHANGE und MTU-Mismatch

Eines der bekanntesten OSPF-Fehlerbilder ist „Neighbor stuck in EXSTART/EXCHANGE“. In der Praxis ist der häufigste Grund ein MTU-Mismatch: Die Router verhandeln DBD-Pakete und erwarten eine bestimmte MTU. Wenn die MTU auf dem Link nicht übereinstimmt, kann die Datenbanksynchronisation scheitern. Das tritt häufig bei Tunneln, VPNs, PPPoE, VLAN-Overheads oder Jumbo-Frame-Mischumgebungen auf.

MTU auf beiden Seiten identisch?
Gibt es Hinweise auf Fragmentierung oder Drops im Interface?
Ist ein Tunnel/Overlay beteiligt, der effektive MTU reduziert?

Wenn MTU/PMTUD relevant ist, hilft als Hintergrund RFC 1191 (Path MTU Discovery).

Areas richtig troubleshoot’en: Warum Routen fehlen, obwohl Nachbarn FULL sind

Eine FULL-Nachbarschaft ist nicht gleichbedeutend mit „Routing ist korrekt“. Es bedeutet nur, dass die LSDB zwischen Nachbarn synchron ist. Routen können trotzdem fehlen, wenn Area-Design, Summaries, LSA-Typen oder Filters greifen. Genau hier passieren häufige Fehler bei Multi-Area-Designs.

Backbone Area 0 und ABR-Logik

OSPF erwartet, dass alle Areas logisch an Area 0 (Backbone) angeschlossen sind. Area 0 ist das „Rückgrat“ für Inter-Area-Routing. Wenn eine Area nicht korrekt an Area 0 angebunden ist, fehlen Summary-LSAs oder Inter-Area-Routen. Virtual Links sind eine mögliche (aber fehleranfällige) Lösung.

Ist die Area korrekt an Area 0 angebunden?
Ist der ABR wirklich ABR (hat Interfaces in Area 0 und einer weiteren Area)?
Werden Inter-Area Routen als O IA sichtbar, wo sie erwartet werden?

Stub, Totally Stubby, NSSA: Area-Typen und typische Nebenwirkungen

Stub- und NSSA-Areas reduzieren LSA-Flut und vereinfachen Routing, aber sie haben Nebenwirkungen: Externals (Typ 5) sind in Stub-Areas nicht erlaubt, stattdessen gibt es Default Routes. In NSSA werden Externals als Typ 7 dargestellt und am ABR ggf. in Typ 5 übersetzt. Wenn hier Flags nicht übereinstimmen, fehlen Routen oder die Nachbarschaft kommt gar nicht hoch.

Stub-Flag konsistent? (Alle Router in der Area müssen stubfähig sein.)
NSSA korrekt? (Typ-7-LSAs vorhanden und Übersetzung am ABR erwartet?)
Default Route: Wird sie in Stub/NSSA wie geplant injected?

Summarization und Filter: Wenn das richtige Netz „wegoptimiert“ wird

Summaries (Zusammenfassungen) sind sinnvoll, können aber „zu breit“ oder „zu aggressiv“ sein. Ein klassischer Fehler: Summary existiert, aber die spezifischen Netze darunter fehlen oder werden gefiltert. Dann routen Geräte ins Leere oder zu einem Blackhole. Prüfen Sie, ob Summaries die realen Netze korrekt abdecken und ob es Null/Discard-Routen gibt, die unerwartet greifen.

Deckt die Summary die tatsächlichen Subnetze korrekt ab?
Gibt es Route-Maps/Distribute-Lists/Prefix-Lists, die bestimmte LSAs/Routes filtern?
Entstehen Blackholes durch Summary ohne spezifische Exit-Route?

Authentifizierung: Wenn OSPF sich nicht vertraut

OSPF unterstützt Authentifizierung pro Interface/Area. In der Praxis ist Auth einer der häufigsten Gründe, warum Nachbarschaften gar nicht erst zustande kommen. Wichtig: Authentifizierung muss auf beiden Seiten identisch sein – sowohl der Modus als auch die Schlüsselparameter.

Welche Auth-Varianten sind in der Praxis relevant?

Keine Auth: in sicheren, isolierten Netzen möglich, aber riskant.
Simple Password: klartextähnlich (nicht kryptografisch stark), heute eher Legacy.
Cryptographic Auth (MD5/HMAC): deutlich robuster; moderne Plattformen nutzen Key IDs und Hash-Algorithmen.

Für OSPFv2 sind die Auth-Mechanismen im Rahmen von RFC 2328 beschrieben; OSPFv3 nutzt andere Security-Mechanismen, u. a. in RFC 7166 (OSPFv3 Authentication Trailer) relevant.

Typische Auth-Fehler

Mode-Mismatch: Eine Seite Auth aktiviert, andere nicht.
Key-Mismatch: unterschiedliches Passwort/HMAC-Key oder falsche Key-ID.
Algorithmus-Mismatch: MD5 vs. SHA/HMAC-Variante je nach Plattform.
Key-Rollover ohne Plan: Schlüsselwechsel nicht synchron, Nachbarschaften flappen.
Falscher Scope: Auth auf Area vs. Interface unterschiedlich umgesetzt, inkonsistent über Links.

Praxis-Tipp: Auth sauber wechseln ohne Ausfall

In Umgebungen mit Key IDs ist ein „überlappender“ Wechsel möglich: Neuer Key wird zusätzlich konfiguriert, beide Keys sind kurz gültig, danach wird der alte entfernt. Ohne diesen Ansatz erzeugt ein simultaner Wechsel häufig unnötige Flaps.

Der schnelle OSPF-Runbook-Ablauf für Incidents

Wenn es brennt, brauchen Teams eine klare Reihenfolge. Dieser Ablauf ist bewusst pragmatisch: Er minimiert die Fehlersuche und hilft Ihnen, schnell festzustellen, ob es ein Neighbor-, Area- oder Auth-Thema ist.

Schritt: Scope festlegen

Ist nur ein Link/Nachbar betroffen oder eine ganze Area?
Fehlen Routen oder ist die Konnektivität vollständig weg?
Ist es nach einem Change passiert (Timer, Auth, MTU, Area-Änderung)?

Schritt: Neighbor-Status prüfen und Zustand interpretieren

DOWN/INIT → Hello/ACL/Multicast/Layer2/Area-ID/Auth checken.
EXSTART/EXCHANGE → MTU, Instabilität, Paketverlust, DBD-Probleme priorisieren.
FULL aber Routen fehlen → Area-Typen, LSAs, ABR/Backbone, Filter/Summaries prüfen.

Schritt: Parameter-Matrix abarbeiten

Area-ID, Hello/Dead, Network Type, Auth-Mode/Key, MTU, Router-ID eindeutig.
Interface up/up, IP korrekt, keine Paketdrops/Errors.

Schritt: LSDB/LSA-Prüfung (wenn FULL)

Sind die erwarteten LSAs vorhanden (Intra-Area, Summary, External/NSSA)?
Ist der ABR/ASBR an der erwarteten Stelle?
Gibt es Filter, die LSAs oder Routen unterdrücken?

Schritt: Routing-Tabelle und Rückweg prüfen

Ist die Route installiert (O, O IA, O E1/E2, O N1/N2 je nach Typ)?
Ist der Next Hop erreichbar (ARP/Neighbor)?
Gibt es asymmetrisches Routing mit stateful Geräten im Pfad?

Typische Praxisfälle und schnelle Diagnose

Fall: Nachbarschaft bleibt in INIT

Wahrscheinlich: Unidirektionale Hellos (Filter/ACL), Multicast wird gedroppt, falsches Network Type Verhalten.
Check: Sieht der Peer Ihre Router-ID im Hello? (Hello-Listen), ACL für IP Proto 89.
Fix: Filter/Multicast/Interface-Policy korrigieren, Network Type konsistent.

Fall: Nachbarschaft hängt in EXSTART/EXCHANGE

Wahrscheinlich: MTU-Mismatch oder DBD-Probleme durch Paketverlust.
Check: MTU beidseitig, Interface Drops, Tunnel-Overhead, Fragmentierung.
Fix: MTU angleichen, Pfad stabilisieren, ggf. MSS/MTU sauber designen.

Fall: Nachbarschaft FULL, aber Inter-Area-Routen fehlen

Wahrscheinlich: Area nicht korrekt am Backbone, ABR/Area-Design falsch, Stub/NSSA Mismatch oder Filter.
Check: Area 0 Anbindung, ABR-Status, Summary LSAs, Stub-Flags konsistent.
Fix: Area-Design korrigieren, Stub/NSSA einheitlich, Virtual Links nur als letzte Option.

Fall: Nachbarschaften flappen nach Auth-Key-Change

Wahrscheinlich: Key-Mismatch oder Rollout nicht synchron.
Check: Auth-Mode, Key-ID, Algorithmus, Zeitpunkt der Änderungen.
Fix: Geplanter Key-Rollover mit überlappendem Key (wenn möglich), danach Cleanup.

Outbound-Links zur Vertiefung

Checkliste: OSPF Troubleshooting bei Nachbarschaften, Areas und Authentifizierung

Neighbor-Zustand bestimmen: DOWN/INIT vs. EXSTART/EXCHANGE vs. FULL.
Hello/Dead prüfen: Timer beidseitig identisch, kein Flapping im Dead-Intervall.
Area prüfen: gleiche Area-ID, Stub/NSSA konsistent, Backbone-Anbindung korrekt.
Network Type prüfen: Broadcast/P2P/NBMA konsistent, DR/BDR-Verhalten plausibel.
Auth prüfen: Mode/Algorithmus/Key-ID/Key identisch, Key-Rollover sauber.
MTU prüfen: beidseitig gleich, Tunnel/Overhead berücksichtigt, Drops/Fragmentierung ausgeschlossen.
Router-ID prüfen: eindeutig, stabil (Loopback), keine Duplicate RIDs.
LSDB/LSAs prüfen (wenn FULL): erwartete Summary/External/NSSA-LSAs vorhanden, keine Filter-Überraschungen.
Routing-Tabelle prüfen: O/O IA/O E1/E2/N1/N2 wie erwartet, Next Hop erreichbar.
Beweise dokumentieren: Zustände, Timer, Auth-Parameter, Logs/Counter, Vorher/Nachher nach Fix.

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.