JNCIP-ENT: OSPF Neighbor States & Troubleshooting

21.06.2026 · 4 Min. Lesezeit

OSPF‑Nachbarschaften erscheinen auf den ersten Blick simpel: Zwei Router sehen sich, tauschen Informationen aus und erreichen schließlich den Zustand „Full“. In der Praxis ist dieser Prozess jedoch eine klar definierte Abfolge von Zuständen, die jeweils sehr konkrete Voraussetzungen haben. Genau hier entstehen typische Probleme, denn jede Abweichung in den Rahmenbedingungen führt dazu, dass die Nachbarschaft in einem bestimmten Zustand „stecken bleibt“. Dieses Verhalten ist deterministisch und erlaubt eine sehr zielgerichtete Fehleranalyse – vorausgesetzt, man versteht die Zustände im Detail.

Der Aufbau einer OSPF‑Nachbarschaft beginnt immer mit dem Empfang von Hello‑Paketen. Diese enthalten grundlegende Parameter wie Area ID, Timer, Authentifizierung und die eigene Router-ID. Stimmen diese Parameter nicht überein, wird der Nachbar nicht akzeptiert. In diesem Fall kommt überhaupt keine Nachbarschaft zustande. Der Prozess bleibt faktisch im Zustand „Down“, auch wenn physikalische Konnektivität vorhanden ist. Besonders häufig ist hier ein Unterschied in der Area-Konfiguration oder bei den Hello- und Dead-Timern. OSPF ist in diesen Punkten strikt; schon kleine Abweichungen verhindern die Bildung einer Beziehung vollständig.

Sobald ein Router ein gültiges Hello empfängt, geht er in den Zustand „Init“. Dieser Zustand zeigt, dass eingehende Pakete verarbeitet werden, der Nachbar also prinzipiell erreichbar ist. Der entscheidende Punkt ist jedoch, dass die Kommunikation noch nicht bidirektional ist. Ein Router erkennt im Hello-Paket des Gegenübers, ob seine eigene Router-ID enthalten ist. Erst wenn dies der Fall ist, weiß er, dass der andere Router ihn ebenfalls gesehen hat. Fehlt diese Rückbestätigung, bleibt der Zustand bei „Init“. In der Praxis deutet dies fast immer auf ein einseitiges Kommunikationsproblem hin, etwa ein Filter, asymmetrisches Routing oder ein Interface-Problem auf einer Richtung.

Der Übergang zu „2-Way“ markiert den ersten stabilen Zustand der Nachbarschaft. Beide Router haben sich gegenseitig gesehen und erkennen sich ausdrücklich als Nachbarn. Ab hier entscheidet sich, ob eine vollständige Adjacency aufgebaut wird oder nicht. Dieser Punkt ist besonders wichtig, da viele Konstellationen bewusst keine vollständige Nachbarschaft benötigen. In Broadcast-Netzen wie Ethernet wird nicht zwischen allen Routern eine vollständige Datenbanksynchronisation durchgeführt. Stattdessen wählen die Router einen Designated Router (DR) und einen Backup Designated Router (BDR). Nur mit diesen beiden wird eine vollständige Adjacency aufgebaut, während alle anderen Router im Zustand „2-Way“ verbleiben. Dieser Zustand ist somit nicht automatisch ein Problem, sondern häufig das erwartete Verhalten.

Erst wenn eine vollständige Datenbanksynchronisation erforderlich ist, geht der Prozess weiter in die Zustände „ExStart“ und „Exchange“. In „ExStart“ wird zunächst geklärt, welcher Router die Rolle des Masters übernimmt und damit den Austausch initiiert. Dieser Schritt ist notwendig, um eine klare Reihenfolge und Struktur für die folgenden Datenbankbeschreibungen festzulegen. Der Übergang zu „Exchange“ bedeutet, dass die Router beginnen, ihre Link-State-Datenbanken in Form von sogenannten DBD-Paketen (Database Description) zu vergleichen.

Ein besonders häufiger Fehlerzustand tritt genau an dieser Stelle auf. Wenn die MTU auf den beteiligten Interfaces unterschiedlich ist, kommt der Austausch nicht zustande. OSPF prüft die MTU-Werte als Teil des Protokolls, und eine Abweichung führt dazu, dass die empfangenen Pakete verworfen werden. Die Folge ist, dass beide Router im Zustand „ExStart“ oder „Exchange“ verharren und die Nachbarschaft nicht weiter aufgebaut wird. Dieses Verhalten wirkt zunächst schwer nachvollziehbar, da grundlegende Konnektivität und sogar Hello-Pakete funktionieren, der vollständige Aufbau jedoch scheitert.

Nach erfolgreichem Austausch der DBD-Pakete wechseln die Router in den Zustand „Loading“. In dieser Phase werden fehlende Teile der Link-State-Datenbank nachgefordert. Dies geschieht über LSR‑ und LSU‑Pakete. Erst wenn beide Router sicher sind, dass sie über identische Daten verfügen, wird der letzte Zustand erreicht: „Full“. Dieser Zustand steht für eine vollständig aufgebaute Adjacency und synchronisierte Datenbanken. Erst jetzt ist garantiert, dass beide Router ein konsistentes Bild der Topologie haben und korrekte Routingentscheidungen treffen können.

Die Bedeutung dieser Zustände liegt nicht nur im Verständnis des Protokolls selbst, sondern insbesondere im Troubleshooting. Jeder Zustand liefert eine konkrete Aussage darüber, an welcher Stelle im Prozess ein Problem liegt. Bleibt eine Nachbarschaft bei „Down“, liegt die Ursache in grundlegenden Parametern oder fehlender Konnektivität. „Init“ deutet auf ein unidirektionales Problem hin. „2-Way“ ist entweder normal oder zeigt, dass keine vollständige Adjacency vorgesehen ist. „ExStart“ und „Exchange“ weisen dagegen sehr häufig auf MTU-Probleme oder Inkonsistenzen im Datenbankaustausch hin.

Dieses Modell erlaubt es, Probleme gezielt einzugrenzen, anstatt unspezifisch nach Fehlern zu suchen. Anstatt nur festzustellen, dass eine Nachbarschaft nicht vollständig aufgebaut wird, lässt sich anhand des Zustands genau bestimmen, welche Phase des Prozesses betroffen ist. Daraus ergibt sich unmittelbar, welche Parameter überprüft werden müssen.

Ein zentraler Aspekt ist dabei, dass OSPF nicht „versucht“, Probleme zu überbrücken. Das Protokoll ist deterministisch und konservativ. Stimmen wesentliche Parameter nicht überein, wird der Prozess abgebrochen oder nicht fortgesetzt. Diese Strenge ist notwendig, um Konsistenz in der Link-State-Datenbank zu gewährleisten, führt aber gleichzeitig dazu, dass kleine Konfigurationsfehler große Auswirkungen haben können.

In der Praxis zeigt sich, dass viele OSPF‑Probleme nicht aus komplexen Designfehlern entstehen, sondern aus kleinen Inkonsistenzen in genau diesen Parametern. Die Zustandsmaschine ist daher nicht nur ein theoretisches Modell, sondern ein direktes Werkzeug zur Analyse realer Netzwerke. Sobald man die Bedeutung der einzelnen Zustände verinnerlicht hat, lässt sich nahezu jedes Nachbarschaftsproblem systematisch und reproduzierbar auf seine Ursache zurückführen.