13.10 OSPF-Fehlersuche einfach erklärt

OSPF gehört zu den wichtigsten Interior Gateway Protocols in IP-Netzwerken, ist in der Praxis aber auch eine häufige Fehlerquelle. Schon kleine Abweichungen bei Area-ID, Timern, Authentifizierung oder Interface-Typen können dazu führen, dass keine Nachbarschaft entsteht oder Routen fehlen. Genau deshalb ist eine systematische OSPF-Fehlersuche auf Cisco-Geräten so wichtig. Wer die typischen Fehlerbilder kennt und strukturiert prüft, kann Probleme deutlich schneller eingrenzen. Statt planlos einzelne Befehle auszuführen, sollte die Analyse immer logisch aufgebaut sein: zuerst die Basis, dann die Nachbarschaften, anschließend die Link-State-Datenbank und zuletzt die Routing-Tabelle.

Warum OSPF-Fehlersuche oft komplex wirkt

OSPF ist ein Link-State-Routing-Protokoll. Router tauschen nicht einfach nur Routen aus, sondern bauen gemeinsam eine konsistente Sicht auf die Topologie auf. Damit das funktioniert, müssen viele Parameter zusammenpassen. Ein Problem auf nur einem Interface kann dazu führen, dass keine Adjazenz entsteht, LSAs nicht korrekt verteilt werden oder SPF-Berechnungen unvollständig bleiben.

Die Fehlersuche wirkt deshalb oft komplex, weil OSPF auf mehreren Ebenen arbeitet:

• Auf Interface-Ebene müssen IP-Konnektivität, Netzwerktyp und OSPF-Aktivierung stimmen
• Auf Neighbor-Ebene müssen Hello-Pakete korrekt ausgetauscht werden
• Auf Datenbank-Ebene müssen LSAs vollständig und konsistent sein
• Auf Routing-Ebene müssen die berechneten Pfade korrekt in der Routing-Tabelle erscheinen

Wer diese Ebenen trennt, findet OSPF-Probleme wesentlich schneller.

Typische Symptome bei OSPF-Problemen

Bevor konkrete Befehle ausgeführt werden, sollte das Fehlerbild sauber eingeordnet werden. Nicht jedes OSPF-Problem äußert sich gleich. Manche Störungen betreffen nur eine einzelne Nachbarschaft, andere die Verteilung bestimmter Routen oder die komplette Area-Kommunikation.

Häufige Anzeichen für OSPF-Störungen

• Ein Router sieht keinen OSPF-Nachbarn
• Nachbarn bleiben in einem Zwischenstatus wie Init, ExStart oder Exchange hängen
• OSPF-Routen fehlen in der Routing-Tabelle
• Nur manche Netze aus anderen Areas sind nicht erreichbar
• Default Route wird nicht verteilt
• Nachbarschaften flappen regelmäßig
• Die OSPF-Datenbank unterscheidet sich zwischen Routern

Wichtige Grundfrage bei der Analyse

Der erste Schritt lautet immer: Liegt das Problem bei der Nachbarschaft, bei der LSA-Verteilung oder bei der Routeninstallation? Diese Einordnung spart viel Zeit, weil nicht sofort in allen Bereichen gleichzeitig gesucht werden muss.

Strukturierter Ablauf für die OSPF-Fehlersuche

In produktiven Netzwerken sollte OSPF nie planlos untersucht werden. Ein bewährter Troubleshooting-Ablauf beginnt immer unten und arbeitet sich schrittweise nach oben.

Empfohlene Prüfreihenfolge

• Physische und logische Interface-Funktion prüfen
• IP-Konnektivität kontrollieren
• OSPF-Grundkonfiguration verifizieren
• OSPF-Interfaces prüfen
• Neighbor-Status analysieren
• Link-State-Datenbank kontrollieren
• Routing-Tabelle prüfen
• Bei Bedarf gezielt Debugging einsetzen

Diese Reihenfolge ist wichtig, weil viele OSPF-Probleme eigentlich auf Interface-, Adressierungs- oder Layer-2-Themen zurückzuführen sind.

Schritt eins: Basis und IP-Konnektivität prüfen

Bevor OSPF selbst untersucht wird, muss sichergestellt sein, dass die zugrunde liegende Verbindung überhaupt funktioniert. OSPF kann keine Nachbarschaft aufbauen, wenn Interfaces down sind, IP-Adressen falsch konfiguriert wurden oder Layer-2-Probleme vorliegen.

Wichtige Basisbefehle

show ip interface brief
show interfaces GigabitEthernet0/0
ping 10.10.10.2

Mit show ip interface brief lässt sich schnell erkennen, ob ein Interface administrativ oder physisch down ist. show interfaces zeigt zusätzliche Details wie Errors, Flaps oder Duplex-Probleme. Ein einfacher Ping zur Nachbar-IP bestätigt die Layer-3-Erreichbarkeit.

Typische Basisfehler

• Interface ist administrativ heruntergefahren
• Falsche oder fehlende IP-Adresse
• Falsche Subnetzmaske
• Layer-2-Fehler zwischen den Routern
• ACL blockiert OSPF oder ICMP

Wenn die Basis nicht stimmt, braucht die weitere OSPF-Analyse meist nicht fortgesetzt zu werden.

Schritt zwei: OSPF-Prozess und Grundkonfiguration kontrollieren

Als Nächstes sollte geprüft werden, ob OSPF auf dem Router überhaupt korrekt aktiviert ist. Besonders häufig sind Fehler in den Network-Statements, falsche Wildcard-Masks oder versehentlich passive gesetzte Interfaces.

Wichtige Show-Befehle

show ip protocols
show running-config | section router ospf
show ip ospf

Diese Befehle liefern die wichtigsten Basisinformationen zum OSPF-Prozess:

• Verwendete Router-ID
• Aktive Network-Statements
• Area-Zuordnungen
• Passive Interfaces
• Redistribution und Default-Route-Origination
• Status des OSPF-Prozesses

Typische Konfigurationsfehler

• Falsches Network-Statement aktiviert das Interface nicht
• Falsche Wildcard-Mask erfasst zu viele oder zu wenige Interfaces
• Interface wurde mit passive-interface blockiert
• Router-ID ist unerwartet oder doppelt vorhanden
• Area-Zuordnung stimmt nicht mit dem Nachbarn überein

Beispiel für ein Problem mit passive-interface

router ospf 1
 passive-interface GigabitEthernet0/0

Wird ein Transit-Link versehentlich passiv gesetzt, sendet der Router dort keine Hello-Pakete mehr. Die OSPF-Nachbarschaft kann dann nicht entstehen.

Schritt drei: OSPF-Interfaces analysieren

Wenn der OSPF-Prozess korrekt aussieht, sollten die Interfaces detailliert geprüft werden. OSPF arbeitet stark interfacebezogen. Viele Probleme entstehen durch Unterschiede bei Timer-Werten, Netzwerktyp oder Kosten.

Wichtige Befehle für die Interface-Analyse

show ip ospf interface brief
show ip ospf interface
show ip ospf interface GigabitEthernet0/0

Hiermit lässt sich pro Interface prüfen:

• Ob OSPF auf dem Interface aktiv ist
• Zu welcher Area das Interface gehört
• Welcher OSPF-Netzwerktyp verwendet wird
• Welche Hello- und Dead-Intervalle gesetzt sind
• Ob das Interface passiv ist
• Welche OSPF-Kosten gelten

Typische Interface-Probleme

• Area-Mismatch
• Hello/Dead-Timer stimmen nicht überein
• Unterschiedlicher Netzwerktyp, zum Beispiel Broadcast vs. Point-to-Point
• MTU-Probleme
• Falsche OSPF-Authentifizierung

Beispiel für unterschiedliche Timer

Wenn ein Router Hello 10 und Dead 40 verwendet, der andere aber Hello 30 und Dead 120, entsteht keine stabile Nachbarschaft.

interface GigabitEthernet0/0
 ip ospf hello-interval 10
 ip ospf dead-interval 40

Diese Werte müssen auf beiden Seiten zueinander passen.

Schritt vier: OSPF-Nachbarn gezielt untersuchen

Die Analyse der Nachbarn ist meist der wichtigste Teil des Troubleshootings. Ohne stabile OSPF-Adjazenz gibt es keinen vollständigen Datenbankabgleich und damit auch keine saubere Routenberechnung.

Zentrale Befehle

show ip ospf neighbor
show ip ospf neighbor detail

Die wichtigsten Felder in der Ausgabe sind:

• Neighbor Router-ID
• State der Nachbarschaft
• Dead Time
• Neighbor-IP
• Lokales Interface

Wichtige Neighbor-States richtig deuten

• Down: Kein Nachbar sichtbar
• Init: Hello empfangen, aber Router sieht sich selbst noch nicht im Hello des Gegenübers
• 2-Way: Gegenseitige Erkennung vorhanden, auf Broadcast-Netzen oft normal
• ExStart: Beginn des Datenbankabgleichs
• Exchange: Austausch der Datenbankbeschreibungen
• Loading: Fehlende LSAs werden nachgeladen
• Full: Vollständige Adjazenz aufgebaut

Was die Zustände über das Problem verraten

• Kein Nachbar sichtbar: Oft Interface down, OSPF nicht aktiv, falsche Area, passive-interface oder Multicast wird nicht übertragen
• Init: Oft unidirektionale Kommunikation oder Hello-Mismatch
• ExStart/Exchange: Häufig MTU-Problem oder Datenbankabgleich schlägt fehl
• Loading: LSA-Anforderung nicht sauber abgeschlossen
• Flapping: Timer, Instabilität am Link oder CPU-Probleme

Schritt fünf: Die häufigsten OSPF-Fehlerursachen im Detail

Area-Mismatch

Wenn zwei Router auf demselben Link unterschiedliche Areas konfiguriert haben, entsteht keine Nachbarschaft.

interface GigabitEthernet0/0
 ip ospf 1 area 0

Auf der Gegenseite könnte fälschlicherweise Area 1 gesetzt sein. Das verhindert den Adjazenzaufbau direkt.

Authentifizierungsprobleme

OSPF-Authentifizierung muss auf beiden Seiten exakt zusammenpassen. Unterschiedliche Passwörter oder verschiedene Authentifizierungsarten führen dazu, dass Hellos verworfen werden.

interface GigabitEthernet0/0
 ip ospf authentication message-digest
 ip ospf message-digest-key 1 md5 Cisco123

Stimmt der Key oder der Authentifizierungsmodus nicht, bleibt die Nachbarschaft down.

MTU-Mismatch

Ein sehr typisches Problem ist ein MTU-Unterschied zwischen zwei Interfaces. Dann bleiben Nachbarn oft in ExStart oder Exchange hängen.

show interfaces GigabitEthernet0/0 | include MTU

Unterschiedliche MTU-Werte sollten angleichen werden. In Laboren wird manchmal mit ip ospf mtu-ignore gearbeitet, produktiv ist die saubere MTU-Anpassung meist sinnvoller.

Netzwerktyp-Mismatch

Wenn auf einem Interface Point-to-Point und auf dem anderen Broadcast konfiguriert ist, kann das zu unerwartetem Verhalten führen. Besonders bei Tunnel-, Serial- oder Ethernet-Designs sollte der Netzwerktyp bewusst kontrolliert werden.

interface GigabitEthernet0/0
 ip ospf network point-to-point

Passive Interface falsch gesetzt

Ein versehentlich passiv gesetztes Transit-Interface ist ein häufiger Praxisfehler. Das Netzwerk wird dann eventuell noch angekündigt, aber es entstehen keine Nachbarn.

show ip protocols

Dieser Befehl zeigt schnell, welche Interfaces passiv sind.

Schritt sechs: Link-State-Datenbank prüfen

Wenn Nachbarn korrekt aufgebaut sind, aber trotzdem Routen fehlen, sollte die LSDB untersucht werden. Hier zeigt sich, ob ein Router die erwarteten Topologieinformationen überhaupt erhalten hat.

Wichtige Befehle

show ip ospf database
show ip ospf database router
show ip ospf database network
show ip ospf database summary
show ip ospf database external

Mit diesen Befehlen lässt sich prüfen:

• Ob Router-LSAs korrekt vorhanden sind
• Ob Network-LSAs erzeugt wurden
• Ob Summary-LSAs aus anderen Areas eintreffen
• Ob externe Routen als Type-5-LSAs vorhanden sind

Typische LSDB-Probleme

• LSAs fehlen vollständig
• Summary-LSAs erscheinen nicht wegen fehlerhaftem Area-Design
• Externe LSAs fehlen wegen fehlender Redistribution
• Unterschiedliche Sicht auf die Topologie zwischen Routern

Wenn die LSDB unvollständig ist, liegt das Problem meist nicht in der Routing-Tabelle, sondern bereits in der OSPF-Topologieverteilung.

Schritt sieben: Routing-Tabelle kontrollieren

Erst wenn Nachbarn und LSDB korrekt aussehen, sollte die Routing-Tabelle analysiert werden. OSPF kann funktionierende Nachbarn und eine plausible Datenbank haben, aber durch Design, Metriken oder konkurrierende Protokolle landen trotzdem nicht die erwarteten Routen in der RIB.

Wichtige Befehle

show ip route ospf
show ip route 0.0.0.0
show ip route 10.20.30.0

Dabei sollte geprüft werden:

• Ist die erwartete Route überhaupt vorhanden?
• Ist sie als O, O IA, O E1 oder O E2 markiert?
• Stimmen Next Hop und Metrik?
• Wird vielleicht eine statische oder EIGRP-Route bevorzugt?

Typische Gründe für fehlende OSPF-Routen

• Die Route wurde nie per LSA gelernt
• Eine bessere Route aus anderem Protokoll verdrängt OSPF
• Stub- oder NSSA-Design schließt bestimmte Routen aus
• Summarization oder Filter blockiert Netze
• Default Route wurde nicht korrekt verteilt

Default-Route-Probleme in OSPF erkennen

Ein häufiger Spezialfall ist die fehlende Standardroute. Viele Administratoren erwarten, dass OSPF eine lokal vorhandene statische Default Route automatisch verteilt. Das ist nicht so. Die Verteilung muss explizit aktiviert werden.

Prüfbefehle für Default-Route-Probleme

show ip route 0.0.0.0
show running-config | section router ospf
show ip ospf database external

Typische Ursachen

• Es gibt lokal keine Default Route
• default-information originate fehlt
• Die Route wird per Route-Map unerwartet beeinflusst
• OSPF-Nachbarschaften zum restlichen Netz sind instabil

Debugging in OSPF gezielt einsetzen

Wenn Show-Befehle nicht ausreichen, kann Debugging den entscheidenden Hinweis liefern. Es sollte aber gezielt und vorsichtig verwendet werden, besonders auf produktiven Geräten.

Nützliche Debug-Befehle

debug ip ospf adj
debug ip ospf hello
debug ip ospf events

Damit lassen sich wichtige Informationen erkennen:

• Warum eine Nachbarschaft nicht zustande kommt
• Ob Hello-Pakete gesendet und empfangen werden
• Welche OSPF-Ereignisse aktuell auftreten

Debug wieder deaktivieren

undebug all

Nach der Analyse sollte Debugging immer sauber beendet werden.

Praxisnahe Checkliste für die OSPF-Fehlersuche

Schnelle Standardprüfung

show ip interface brief
show ip protocols
show ip ospf interface brief
show ip ospf neighbor
show ip ospf database
show ip route ospf

Mit dieser Befehlsfolge lassen sich viele OSPF-Probleme bereits sehr schnell eingrenzen.

Worauf besonders geachtet werden sollte

• Ist das Interface up/up?
• Läuft OSPF wirklich auf diesem Interface?
• Stimmen Area, Timer und Authentifizierung?
• Ist der Nachbarstatus Full oder hängt er in einem Zwischenzustand?
• Sind die erwarteten LSAs vorhanden?
• Ist die resultierende Route in der Routing-Tabelle sichtbar?

Best Practices für saubere OSPF-Analyse

Professionelle OSPF-Fehlersuche bedeutet vor allem, Symptome nicht mit Ursachen zu verwechseln. Eine fehlende Route ist oft nur die Folge einer fehlenden Nachbarschaft. Eine instabile Nachbarschaft ist wiederum oft nur das Symptom eines Interface- oder MTU-Problems. Genau deshalb ist ein systematischer Blick auf alle Ebenen entscheidend.

Bewährte Vorgehensweisen

• Immer von Layer 1 und 3 nach oben arbeiten
• Show-Befehle zuerst, Debug nur gezielt einsetzen
• Neighbor-Status vor LSDB und Routing-Tabelle prüfen
• Änderungen schrittweise durchführen und sofort verifizieren
• Timer, Area-ID, Authentifizierung und MTU konsequent vergleichen
• Passive Interfaces und Default-Route-Verteilung bewusst kontrollieren

Wichtiger Praxisgedanke

Die beste OSPF-Fehlersuche ist nicht der einzelne Debug-Befehl, sondern ein sauberer Denkprozess. Wer prüft, wo OSPF scheitert – beim Hello-Austausch, beim Datenbankabgleich oder bei der Routeninstallation –, findet die eigentliche Ursache deutlich schneller und arbeitet in Cisco-Netzwerken wesentlich effizienter.

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3

Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.

Meine Leistungen umfassen:

• Professionelle Konfiguration von Routern und Switches

• Einrichtung von VLANs, Trunks, Routing, DHCP, NAT, ACLs und weiteren Netzwerkfunktionen

• Erstellung von Topologien und Simulationen in Cisco Packet Tracer

• Aufbau, Analyse und Fehlerbehebung von Netzwerk-Labs in GNS3 und EVE-NG

• Automatisierung von Netzwerkkonfigurationen mit Python, Netmiko, Paramiko, NAPALM und Ansible

• Erstellung von Skripten für wiederkehrende Netzwerkaufgaben

• Dokumentation der Konfigurationen und Bereitstellung nachvollziehbarer Lösungswege

• Konfigurations-Backups, Optimierung bestehender Setups und technisches Troubleshooting

Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.