OSPF Neighbor States verstehen

14.08.2026 · 6 Min. Lesezeit

Einleitung

Wer sich zum ersten Mal mit OSPF beschäftigt, konzentriert sich häufig auf Routingtabellen, Areas und Kostenwerte. In der Praxis entstehen die meisten OSPF-Probleme jedoch lange bevor überhaupt eine Route berechnet werden kann.

Bevor ein Router eine Route von einem anderen Router lernen kann, müssen beide Geräte zunächst eine stabile OSPF-Nachbarschaft aufbauen. Dieser Prozess ist deutlich komplexer, als viele Administratoren vermuten.

Wenn ein OSPF-Link nicht funktioniert, findet man die Ursache häufig in einem der sogenannten Neighbor States. Genau deshalb gehören die OSPF-Nachbarschaftszustände zu den beliebtesten Troubleshooting-Themen in der JNCIS-ENT-Prüfung.

Statt lediglich die Zustände auswendig zu lernen, ist es wesentlich sinnvoller zu verstehen, was in jeder Phase tatsächlich passiert. Wer den Ablauf nachvollziehen kann, erkennt Fehlerbilder später fast automatisch.

Warum OSPF überhaupt Nachbarn benötigt

OSPF basiert auf dem Konzept einer gemeinsamen Sicht auf die Netzwerktopologie.

Jeder Router erstellt eine Link-State Database (LSDB), die Informationen über Router, Verbindungen und Netzwerke enthält. Damit alle Router dieselbe Topologie kennen, müssen sie diese Informationen austauschen.

Ein Router vertraut dabei nicht blind jedem Gerät im Netzwerk.

Stattdessen wird zunächst geprüft:

• Spricht das Gegenüber überhaupt OSPF?
• Befindet es sich in derselben Area?
• Stimmen wichtige Parameter überein?
• Ist die Verbindung stabil?

Erst wenn diese Voraussetzungen erfüllt sind, beginnt der eigentliche Datenbankabgleich.

Die OSPF-Nachbarschaft als Prozess

Viele Kandidaten betrachten die Neighbor States als eine Liste von Begriffen:

Down
Init
2-Way
ExStart
Exchange
Loading
Full

Für die Prüfung ist es jedoch hilfreicher, sich diese Zustände als eine Art Kennenlernprozess zwischen zwei Routern vorzustellen.

Zwei Router treffen sich nicht sofort auf Augenhöhe und tauschen ihre komplette Datenbank aus.

Sie gehen schrittweise vor:

1. Erkennen des Nachbarn
2. Gegenseitige Bestätigung
3. Aushandlung der Kommunikation
4. Austausch von Datenbankinformationen
5. Synchronisierung
6. Vollständige Nachbarschaft

Jeder Zustand repräsentiert einen dieser Schritte.

State 1: Down

Der Down-State ist der Ausgangspunkt jeder OSPF-Nachbarschaft.

In diesem Zustand weiß ein Router noch nichts von seinem Nachbarn.

Router A

Keine Hello-Pakete empfangen
Keine Nachbarschaft

Ein Interface kann sich dauerhaft im Down-State befinden, wenn:

• OSPF nicht aktiviert wurde
• das Interface administrativ deaktiviert ist
• Layer 1 oder Layer 2 gestört sind
• ein Verkabelungsproblem vorliegt

In der Praxis beginnt jedes OSPF-Troubleshooting zunächst mit einer einfachen Frage:

Funktioniert die Verbindung überhaupt?

State 2: Init

Sobald ein Router ein Hello-Paket empfängt, wechselt er in den Init-State.

Das bedeutet:

„Ich habe einen OSPF-Router entdeckt.“

Wichtig ist jedoch:

Der Nachbar hat die Existenz dieses Routers möglicherweise noch nicht bestätigt.

Man spricht deshalb von einer einseitigen Kommunikation.

Beispiel:

Router A → Hello → Router B

Router B empfängt das Paket.

Router B befindet sich nun im Zustand:

Init

Er weiß, dass Router A existiert.

Router A weiß aber noch nicht zwingend, dass Router B existiert.

Typisches Troubleshooting

Bleibt eine Nachbarschaft dauerhaft im Init-State hängen, deutet dies häufig auf eine einseitige Kommunikation hin.

Mögliche Ursachen:

• Firewall-Regeln
• Multicast-Probleme
• Layer-2-Probleme
• Paketverluste

In der Praxis ist ein dauerhaftes Init fast immer ein Hinweis darauf, dass OSPF-Pakete nur in eine Richtung funktionieren.

State 3: 2-Way

Der 2-Way-State markiert den ersten wichtigen Meilenstein.

Nun hat jeder Router Hello-Pakete vom anderen empfangen und darin seine eigene Router-ID wiedergefunden.

Damit weiß jeder Router:

„Mein Nachbar hat mich gesehen.“

Es besteht nun eine bidirektionale Kommunikation.

Warum 2-Way nicht immer ein Problem ist

Eine der beliebtesten Prüfungsfallen besteht darin, dass Kandidaten glauben:

Full ist immer erforderlich.

Das stimmt nicht.

Auf Broadcast-Netzwerken verbleiben manche Nachbarn absichtlich im 2-Way-State.

Der Grund dafür liegt im Designated Router (DR) und Backup Designated Router (BDR)-Konzept.

Nicht jeder Router bildet mit jedem anderen Router eine vollständige Adjacency.

Viele Router benötigen lediglich eine 2-Way-Beziehung.

JNCIS-ENT Merksatz

2-Way bedeutet nicht automatisch ein Problem.

Diese Aussage taucht regelmäßig in Prüfungsfragen auf.

Designated Router (DR) und Backup Designated Router (BDR)

Bevor wir die nächsten States betrachten, müssen wir einen wichtigen Mechanismus verstehen.

Stellen wir uns ein Ethernet-Netz mit zehn Routern vor.

Ohne Optimierung müsste jeder Router mit jedem anderen Router eine vollständige Nachbarschaft aufbauen.

Die Anzahl der Verbindungen würde exponentiell steigen.

OSPF löst dieses Problem durch:

• Designated Router (DR)
• Backup Designated Router (BDR)

Der DR fungiert als zentrale Austauschstelle.

Alle anderen Router kommunizieren primär mit ihm.

Dadurch reduziert sich die Anzahl der notwendigen Adjacencies erheblich.

State 4: ExStart

Ab diesem Punkt beginnt die eigentliche Synchronisation.

Die Router müssen zunächst festlegen:

Wer übernimmt die Rolle des Masters?

Dies geschieht während des ExStart-States.

Zusätzlich wird die Reihenfolge der Datenbankpakete ausgehandelt.

Warum ExStart häufig Probleme verursacht

Viele OSPF-Probleme entstehen genau hier.

Besonders bekannt sind:

• MTU-Mismatches
• Software-Inkompatibilitäten
• beschädigte Datenbankinformationen

Ein klassisches Beispiel:

Router A:

MTU 1500

Router B:

MTU 9000

In vielen Implementierungen kann dies dazu führen, dass die Nachbarschaft dauerhaft im ExStart-State hängen bleibt.

Prüfungsrelevanz

Wenn in einer Aufgabe steht:

Nachbarschaft bleibt bei ExStart stehen

solltest du sofort an MTU-Probleme denken.

State 5: Exchange

Nachdem die Rollen geklärt wurden, beginnt der eigentliche Austausch der Datenbankübersichten.

Wichtig:

Zu diesem Zeitpunkt werden noch keine vollständigen LSAs übertragen.

Die Router tauschen zunächst nur eine Art Inhaltsverzeichnis aus.

Sinngemäß lautet die Kommunikation:

Router A:
"Ich kenne diese LSAs."

Router B:
"Ich kenne diese LSAs."

Nun erkennen beide Seiten, welche Informationen fehlen.

State 6: Loading

Im Loading-State werden die fehlenden Informationen nachgeladen.

Der Router fordert gezielt LSAs an, die ihm noch fehlen.

Beispiel:

Router A:
"Eintrag Nummer 15 fehlt mir."

Router B sendet den entsprechenden Datensatz.

Dieser Prozess wird wiederholt, bis beide Datenbanken identisch sind.

State 7: Full

Der Full-State ist das Ziel jeder OSPF-Adjacency.

Nun gilt:

• Datenbanken synchronisiert
• LSDB identisch
• Routing-Berechnung möglich

Erst jetzt kann der SPF-Algorithmus vollständig arbeiten.

Wenn du folgenden Output siehst:

show ospf neighbor

und der Nachbar befindet sich im Zustand:

Full

ist die OSPF-Beziehung erfolgreich aufgebaut.

Der gesamte Ablauf auf einen Blick

Down
 ↓
Init
 ↓
2-Way
 ↓
ExStart
 ↓
Exchange
 ↓
Loading
 ↓
Full

Für die Prüfung solltest du diesen Ablauf nicht auswendig aufsagen, sondern verstehen, was in jeder Phase passiert.

Typische JNCIS-ENT Troubleshooting-Szenarien

Nachbarschaft bleibt in Init

Wahrscheinliche Ursache:

• Einseitige Kommunikation
• Multicast-Probleme
• Paketfilter

Nachbarschaft bleibt in ExStart

Wahrscheinliche Ursache:

• MTU-Mismatch

Dies ist eine der häufigsten Prüfungsantworten.

Nachbarschaft bleibt in Exchange

Mögliche Ursachen:

• Datenbankprobleme
• Ressourcenprobleme
• Software-Inkompatibilitäten

Nachbarschaft erreicht nie Full

Prüfen:

• Area-ID
• Hello-Timer
• Dead-Timer
• Authentifizierung
• MTU

Wichtige Junos-Kommandos

Nachbarn anzeigen:

show ospf neighbor

OSPF Interfaces:

show ospf interface

OSPF Datenbank:

show ospf database

Detailinformationen:

show ospf neighbor detail

Was die JNCIS-ENT wirklich prüft

Die Prüfung erwartet normalerweise nicht, dass du jedes einzelne OSPF-Paket im Detail analysieren kannst.

Viel wichtiger ist:

• den Ablauf der Nachbarschaftsbildung zu verstehen
• typische Fehlerbilder zu erkennen
• Neighbor States interpretieren zu können
• die häufigsten Ursachen für einen fehlerhaften Adjacency-Aufbau zu kennen

Insbesondere die Zustände 2-Way, ExStart und Full tauchen überdurchschnittlich häufig in Prüfungsfragen auf.

Fazit

Die OSPF Neighbor States bilden das Fundament jeder OSPF-Kommunikation. Ohne stabile Nachbarschaften können keine LSAs ausgetauscht, keine Datenbanken synchronisiert und keine Routen berechnet werden.

Wer die Zustände lediglich auswendig lernt, wird Schwierigkeiten beim Troubleshooting haben. Wer hingegen versteht, was in jeder Phase geschieht, kann Netzwerkprobleme deutlich schneller eingrenzen und lösen.

Für die JNCIS-ENT solltest du insbesondere verstehen:

• die Reihenfolge der Neighbor States,
• die Bedeutung von 2-Way und Full,
• die Rolle von DR und BDR,
• sowie typische Fehlerursachen in ExStart und Exchange.