OSPF Troubleshooting: Nachbarn kommen nicht hoch – warum?

Wenn OSPF-Nachbarn nicht hochkommen, fühlt sich das Problem oft größer an, als es ist: Das Routing „funktioniert nicht“, Routen fehlen, und in der Routingtabelle taucht nichts Neues auf. In der Praxis steckt dahinter jedoch meist ein klarer, wiederkehrender Grund. Genau deshalb ist OSPF Troubleshooting bei „Nachbarn kommen nicht hoch“ ein Thema, das sich hervorragend systematisch angehen lässt. OSPF-Nachbarschaften (Adjacencies) entstehen nur, wenn bestimmte Parameter zwischen zwei Routern übereinstimmen und die Basis-Konnektivität (Layer 1 bis Layer 3) stimmt. Schon ein kleiner Mismatch – eine andere Area, eine abweichende Subnetzmaske, unterschiedliche Hello/Dead-Timer, falsche Authentifizierung oder ein Interface, das versehentlich als passive-interface konfiguriert ist – verhindert die Adjacency. Dieser Leitfaden zeigt Ihnen eine praxiserprobte Schritt-für-Schritt-Methode, mit der Sie das Problem schnell eingrenzen: Erst physische und IP-seitige Erreichbarkeit prüfen, dann OSPF-spezifische Parameter vergleichen, anschließend den Zustand der Nachbarschaft interpretieren und zuletzt gezielt korrigieren. Sie erhalten außerdem typische Symptom-Muster (z. B. Neighbor bleibt in EXSTART), die passenden Show-Befehle und konkrete Fixes für Cisco IOS/IOS XE – damit Sie nicht raten müssen, sondern nachvollziehbar zur Lösung kommen.

OSPF-Nachbarschaft in 30 Sekunden: Was muss stimmen?

Damit zwei Cisco Router (oder Layer-3-Switches) OSPF-Nachbarn werden, müssen mehrere Bedingungen gleichzeitig erfüllt sein. Sie müssen nicht alle Details auswendig lernen, aber Sie sollten wissen, welche Kategorien typischerweise Probleme verursachen:

• Basis-Konnektivität: Link up, IP korrekt, direkte Erreichbarkeit (Ping zum Nachbarn).
• Gleiche Area: Das Interface, über das sich die Router sehen, muss auf beiden Seiten derselben Area zugeordnet sein.
• Gleicher Netztyp/Masken-Kompatibilität: Subnetzmaske muss auf dem gemeinsamen Segment konsistent sein; OSPF muss den Link sinnvoll als gemeinsames Netzwerk erkennen.
• Hello/Dead-Timer: Timer müssen übereinstimmen, sonst keine stabile Adjacency.
• Authentifizierung: Wenn Auth aktiv ist, müssen Methode und Key identisch sein.
• MTU: Abweichende MTU ist ein häufiger Grund für EXSTART/EXCHANGE-Probleme.
• Keine Filter/Policies, die OSPF blockieren: ACLs, Firewall-Regeln oder CoPP können OSPF-Pakete verhindern.

Für Standardhintergrund zu OSPFv2 ist der Anchor-Text RFC 2328 (OSPFv2) eine gute Referenz. Cisco-spezifische Hinweise und Befehle finden Sie über den Anchor-Text Cisco OSPF Support & Dokumentation.

Die schnellste Diagnose: Die 8 wichtigsten Show-Befehle

Bevor Sie Konfigurationen ändern, verschaffen Sie sich mit wenigen Befehlen einen objektiven Zustand. Diese Kommandos sind im Alltag besonders nützlich:

• show ip interface brief (Interface up/up? richtige IP?)
• show ip ospf neighbor (Neighbor-Liste, State, Uptime)
• show ip ospf interface brief (welche Interfaces sprechen OSPF? in welcher Area?)
• show ip ospf interface <INTERFACE> (Timer, Area, MTU, Network Type, Auth-Info)
• show running-config | section router ospf (OSPF-Prozess, passive-interface, area settings)
• show running-config interface <INTERFACE> (Interface-spezifische OSPF-Optionen)
• show ip protocols (Routing-Protokoll-Status, Networks, Passive Interfaces)
• show logging (Hinweise auf Auth- oder Neighbor-Events)

Wenn Sie diese acht Befehle sauber auswerten, finden Sie bereits in sehr vielen Fällen die Ursache, ohne Debug-Kommandos nutzen zu müssen.

Schritt 1: Basis-Konnektivität prüfen (Layer 1 bis Layer 3)

OSPF ist nicht der richtige Startpunkt, wenn die direkte Verbindung nicht funktioniert. Prüfen Sie zuerst, ob der Link steht und ob IP-Konnektivität zwischen den Nachbarn möglich ist.

Interface-Status und IP prüfen

show ip interface brief

• up/up: Interface und Line Protocol sind aktiv.
• administratively down: Interface ist per shutdown deaktiviert.
• down/down: physisches Problem (Kabel, SFP, Gegenstelle).
• up/down: häufig Konfig- oder Layer-2/Encapsulation-Probleme.

Direkt-Ping zum Nachbarn

ping <Nachbar-IP>

Wenn der Ping zum Nachbarn nicht funktioniert, ist OSPF-Troubleshooting meist zweitrangig. Dann prüfen Sie: VLAN/Trunk (bei L2-Underlay), falsche Masken, Duplex/Speed, ACLs oder falsches Default Gateway in Testumgebungen.

Schritt 2: Prüfen, ob OSPF überhaupt auf dem Interface aktiv ist

Ein häufiger Grund, warum Nachbarn nicht hochkommen, ist banal: OSPF läuft schlicht nicht auf dem Link. Das passiert durch zu enge network-Statements, falsche Wildcards oder weil das Interface versehentlich passiv ist.

OSPF-Interface-Übersicht

show ip ospf interface brief

Wenn das Transitinterface dort nicht auftaucht, ist es nicht in OSPF aktiv. Dann prüfen Sie die OSPF-Konfiguration:

show running-config | section router ospf

Typischer Fix: Netzwerk korrekt in OSPF aufnehmen

Beispiel (Transitnetz 10.0.12.0/30 in Area 0):

configure terminal
router ospf 1
network 10.0.12.0 0.0.0.3 area 0
end

Typischer Fix: Passive Interface korrigieren

Wenn Sie das Muster „passive-interface default“ nutzen, müssen Transitinterfaces explizit freigeschaltet werden:

configure terminal
router ospf 1
no passive-interface gigabitethernet0/0
end

Schritt 3: Area-Mismatch prüfen (der Klassiker)

Zwei Router können nur dann eine OSPF-Nachbarschaft aufbauen, wenn das gemeinsame Segment auf beiden Seiten derselben Area zugeordnet ist. Ein Area-Mismatch führt häufig dazu, dass Nachbarn gar nicht erscheinen oder in einem frühen Zustand hängen bleiben.

Prüfen

show ip ospf interface gigabitethernet0/0

Achten Sie auf die Zeile, die die Area zeigt (z. B. „Area 0“). Prüfen Sie das auf beiden Seiten. Wenn eine Seite Area 0 nutzt und die andere Area 10, kommt keine stabile Adjacency zustande.

Fix

Setzen Sie die Area auf beiden Seiten identisch. Beispiel: Interface soll in Area 0 sein:

configure terminal
router ospf 1
network 10.0.12.0 0.0.0.3 area 0
end

Schritt 4: Subnetzmaske und Netzwerktyp prüfen

OSPF erwartet, dass beide Seiten auf einem gemeinsamen Link „die gleiche Sicht“ auf das Subnetz haben. Wenn Router A 10.0.12.1/30 nutzt und Router B 10.0.12.2/29, kann das zu Problemen führen. Zusätzlich kann der OSPF-Netzwerktyp (broadcast, point-to-point, non-broadcast) eine Rolle spielen, vor allem in speziellen Umgebungen.

Prüfen

• show ip interface gigabitethernet0/0 (IP und Maske)
• show ip ospf interface gigabitethernet0/0 (Network Type)

Fix

Stellen Sie sicher, dass IP und Maske auf beiden Seiten konsistent sind. In typischen Punkt-zu-Punkt-Transitnetzen ist /30 oder /31 (je nach Design) verbreitet. In Ethernet-Transitnetzen kann „broadcast“ normal sein; wenn Sie bewusst point-to-point verwenden wollen, muss das ebenfalls konsistent geplant sein.

Schritt 5: Hello/Dead-Timer prüfen

OSPF-Nachbarn müssen identische Hello- und Dead-Intervalle verwenden, sonst akzeptieren sie sich nicht als vollwertige Nachbarn. Timer-Mismatches treten oft auf, wenn ein Router „optimiert“ wurde oder wenn ein Interface ein spezielles Profil nutzt.

Prüfen

show ip ospf interface gigabitethernet0/0

Achten Sie auf:

• Hello (z. B. 10 Sekunden)
• Dead (z. B. 40 Sekunden)

Fix

Konfigurieren Sie Timer konsistent. Beispiel:

configure terminal
interface gigabitethernet0/0
ip ospf hello-interval 10
ip ospf dead-interval 40
end

Best Practice: Timer nur dann verändern, wenn Sie einen klaren Grund und einheitliche Standards im Netz haben. Unkoordinierte Timer-Anpassungen sind eine häufige Ursache für schwer nachvollziehbare OSPF-Probleme.

Schritt 6: Authentifizierung prüfen (wenn aktiviert)

OSPF-Authentifizierung ist in produktiven Umgebungen sehr sinnvoll, aber sie ist auch eine typische Ursache für „Neighbor kommt nicht hoch“. Wenn Auth aktiv ist, müssen Methode (z. B. Plaintext oder MD5 je nach Plattform/Design) und Schlüssel auf beiden Seiten exakt übereinstimmen.

Prüfen

• show ip ospf interface gigabitethernet0/0 (zeigt oft Auth-Status)
• show running-config interface gigabitethernet0/0 (Auth-Commands am Interface)
• show logging (Hinweise auf Authentication failure)

Fix

Stellen Sie sicher, dass die Auth-Konfiguration identisch ist. Wenn Sie testweise eingrenzen müssen, können Sie Authentifizierung in einem kontrollierten Umfeld temporär deaktivieren, um zu prüfen, ob genau das der Blocker ist. In produktiven Netzen sollte das jedoch geplant und dokumentiert erfolgen.

Schritt 7: MTU-Mismatch (häufiger Grund für EXSTART/EXCHANGE)

Ein besonders typisches Fehlerbild: OSPF-Nachbarn erscheinen, aber die Adjacency kommt nicht in FULL, sondern bleibt in EXSTART oder EXCHANGE hängen. Sehr häufig ist die Ursache eine unterschiedliche MTU auf dem Link. OSPF tauscht Datenbank-Informationen aus; bei MTU-Unterschieden kann dieser Austausch scheitern.

Symptom

• show ip ospf neighbor zeigt State EXSTART oder EXCHANGE
• Neighbor ist sichtbar, aber wird nicht FULL

Prüfen

• show interfaces gigabitethernet0/0 (MTU)
• show ip ospf interface gigabitethernet0/0 (OSPF-Infos, MTU-related Hinweise)

Fix

Setzen Sie MTU auf beiden Seiten identisch. Beispiel:

configure terminal
interface gigabitethernet0/0
mtu 1500
end

In speziellen Szenarien (z. B. Tunnels, QinQ, MPLS-Underlay) sind abweichende MTUs üblich. Wichtig ist nur: Die beiden Nachbarn müssen übereinstimmen, sonst bleibt die Adjacency oft stecken.

Schritt 8: DR/BDR- und Netzwerktyp-Themen in Multi-Access-Netzen

Auf Broadcast-Netzen (z. B. Ethernet-Segmente mit mehreren Routern) werden ein Designated Router (DR) und ein Backup Designated Router (BDR) gewählt. Ein Problem in dieser Kategorie ist seltener als Area-/Timer-/MTU-Mismatches, kann aber in Shared VLANs oder Transit-VLANs mit mehreren Routern relevant sein. Beispiel: Falsche Prioritäten oder unklare Segmentierung führen dazu, dass ein Router unerwartet DR wird, oder dass Nachbarschaften nicht wie erwartet entstehen.

Prüfen

• show ip ospf neighbor (zeigt DR/BDR-States indirekt über Rollen/States)
• show ip ospf interface gigabitethernet0/0 (Network Type, DR/BDR Info)

Fix

Wenn Sie DR/BDR gezielt steuern wollen, setzen Sie OSPF-Prioritäten bewusst:

configure terminal
interface gigabitethernet0/0
ip ospf priority 100
end

Mit ip ospf priority 0 verhindern Sie, dass ein Router DR/BDR wird. Das kann sinnvoll sein, wenn ein Router zwar am Segment hängt, aber nicht die zentrale Rolle übernehmen soll.

Schritt 9: ACLs, Firewalls und Control-Plane-Policies

OSPF kann scheitern, obwohl IP-Ping funktioniert. Der Grund: OSPF nutzt eigene IP-Protokolle und Multicast-Adressen (z. B. 224.0.0.5 und 224.0.0.6 in IPv4-OSPF). Wenn Access-Lists, Firewall-Regeln oder Control-Plane-Policys OSPF-Pakete blockieren, bleiben Nachbarn aus.

Symptome

• Ping zum Nachbarn geht, aber OSPF-Nachbar erscheint nicht
• Neighbor ist instabil oder verschwindet immer wieder

Prüfen

• show running-config | include access-list (wo sind ACLs aktiv?)
• show running-config interface <INTERFACE> (in/out ACLs?)
• show logging (Hinweise auf Drops, Policy Events)

Fix bedeutet hier nicht „alles erlauben“, sondern gezielt OSPF-Traffic auf den Transitlinks zuzulassen. In Enterprise-Umgebungen sollte das in ein Security-Konzept eingebettet sein.

OSPF-Neighbor-States richtig interpretieren (und was sie Ihnen sagen)

Der Neighbor-State ist ein sehr guter Hinweis, an welcher Stelle der Prozess scheitert. Einsteiger profitieren enorm davon, diese Zustände grob einordnen zu können.

• DOWN: Kein Austausch. Häufig Link/ACL/OSPF nicht aktiv oder Timer/Area-Mismatch.
• INIT: Hellos werden empfangen, aber Gegenseite sieht uns nicht als Nachbarn (häufig Unidirectional Issue, ACL/Multicast/Filter).
• 2-WAY: Bidirektionale Hellos; in Multi-Access-Netzen bleiben manche Router absichtlich 2-WAY (nicht jeder wird FULL mit jedem, DR/BDR-Konzept).
• EXSTART/EXCHANGE: Datenbank-Austausch beginnt, bleibt aber hängen (häufig MTU-Mismatch).
• FULL: Adjacency steht, LSDB synchron, Routen können gelernt werden.

Praxisregel: Wenn Sie EXSTART/EXCHANGE sehen, prüfen Sie MTU und ggf. weitere Parameter zuerst. Wenn Sie INIT sehen, denken Sie an Einweg-Probleme, ACLs und Multicast.

Praxis-Workflow: OSPF Neighbor kommt nicht hoch – Checkliste in Reihenfolge

• 1) show ip interface brief (Interface up/up? richtige IP?)
• 2) Ping zum Nachbarn (direkte Erreichbarkeit)
• 3) show ip ospf interface brief (OSPF läuft auf dem Interface?)
• 4) Area prüfen: show ip ospf interface <IF>
• 5) Timer prüfen (Hello/Dead): gleicher Output-Bereich
• 6) Auth prüfen: Interface-Konfig und OSPF-Interface-Output
• 7) MTU prüfen (bei EXSTART/EXCHANGE): show interfaces
• 8) ACL/Policy prüfen: Interface ACLs, CoPP, Firewall-Regeln
• 9) Danach erst tiefer: LSDB, DR/BDR, spezielle Network Types

Diese Reihenfolge verhindert „Konfigurations-Pingpong“ und sorgt dafür, dass Sie zuerst die häufigsten Ursachen ausschließen.

Best Practices: Damit OSPF-Nachbarn stabil bleiben

• Router-ID fest setzen: vermeidet überraschende Änderungen nach Interface-Änderungen.
• Network Statements präzise: verhindert, dass OSPF auf unerwünschten Interfaces aktiv wird.
• Passive Interfaces als Standard: OSPF nur auf Transitlinks sprechen lassen.
• Timer nicht „wild“ optimieren: nur mit klaren Standards und konsistent im Segment.
• MTU konsistent planen: besonders bei Tunnels, VLAN-Overheads, QinQ.
• Authentifizierung dokumentieren: Keys und Methoden sauber verwalten.
• Change-Disziplin: OSPF-Änderungen in Wartungsfenstern verifizieren und loggen.

Als ergänzende Cisco-Referenz für OSPF-Konfiguration und Troubleshooting eignet sich der Anchor-Text Cisco OSPF Support & Dokumentation. Für die Protokoll-Details und Zustandslogik bleibt der Anchor-Text RFC 2328 besonders hilfreich.

Konfiguration speichern und nachvollziehbar machen

Wenn Sie die Ursache behoben haben und die Nachbarschaft stabil in FULL steht, speichern Sie die Konfiguration, damit der Fix nach einem Neustart erhalten bleibt:

copy running-config startup-config

Gerade bei OSPF-Störungen ist es außerdem sinnvoll, die Ursache kurz zu dokumentieren (Area-Mismatch, Timer, MTU, Auth), damit ähnliche Fehler in Zukunft schneller erkannt werden.

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.