13.9 OSPF überprüfen und verifizieren auf Cisco-Geräten

Die Konfiguration von OSPF ist nur der erste Schritt. Im produktiven Netzwerkbetrieb ist es mindestens genauso wichtig, OSPF auf Cisco-Geräten korrekt zu überprüfen und zu verifizieren. Nur so lässt sich sicherstellen, dass Nachbarschaften sauber aufgebaut werden, LSAs korrekt ausgetauscht werden und die Routing-Tabelle tatsächlich den gewünschten Zustand abbildet. Gerade in Enterprise-Netzen mit mehreren Areas, redundanten Pfaden und unterschiedlichen Interface-Typen gehört die OSPF-Verifikation zu den zentralen Aufgaben eines Network Engineers. Wer die wichtigsten Cisco-Show-Befehle versteht und richtig interpretiert, kann Fehler schneller eingrenzen, Routing-Probleme systematisch lösen und die Stabilität der OSPF-Domain deutlich verbessern.

Warum OSPF-Verifikation so wichtig ist

OSPF ist ein Link-State-Routing-Protokoll. Das bedeutet: Router tauschen nicht einfach nur Routen aus, sondern bauen eine gemeinsame Sicht auf die Netzwerktopologie auf. Wenn bereits bei der Nachbarschaftsbildung, bei Interface-Parametern oder bei der LSA-Verteilung etwas nicht stimmt, können Routing-Probleme entstehen, obwohl die Grundkonfiguration auf den ersten Blick korrekt aussieht.

Genau deshalb reicht es nicht, nur die OSPF-Konfiguration einzutippen. Nach jeder Änderung sollte geprüft werden, ob OSPF den erwarteten Zustand erreicht hat. Dazu gehören insbesondere die Router-ID, die aktiven Interfaces, die Nachbarbeziehungen, die Link-State-Datenbank und die tatsächlich installierten Routen.

Typische Ziele der OSPF-Prüfung

• Kontrollieren, ob OSPF auf den richtigen Interfaces aktiv ist
• Prüfen, ob Neighbor-Adjazenzen vollständig aufgebaut sind
• Verifizieren, dass die Area-Zuordnung korrekt ist
• Sicherstellen, dass LSAs korrekt erzeugt und empfangen werden
• Kontrollieren, ob die Routing-Tabelle den Sollzustand abbildet
• Fehler bei Timer, MTU, Authentifizierung oder Netzwerktyp erkennen

Die OSPF-Basisprüfung auf Cisco-Routern

Bei der Verifikation sollte immer strukturiert vorgegangen werden. Bewährt hat sich eine Reihenfolge von unten nach oben: zuerst prüfen, ob das Interface funktioniert, dann OSPF auf dem Interface kontrollieren, anschließend die Nachbarschaften prüfen und erst danach die Routing-Informationen analysieren. So lässt sich ein Problem gezielt eingrenzen, statt unsystematisch in der OSPF-Datenbank oder Routing-Tabelle zu suchen.

Sinnvolle Prüfreihenfolge

• Interface-Status prüfen
• OSPF-Prozess und Router-ID kontrollieren
• OSPF-Interface-Zustand analysieren
• Neighbor-Status verifizieren
• Link-State-Datenbank prüfen
• Routing-Tabelle kontrollieren

OSPF-Prozess und Grundeinstellungen prüfen

Ein guter Einstieg ist immer die Kontrolle des Routing-Prozesses selbst. Damit lässt sich schnell erkennen, welche Netzwerke in OSPF eingebunden sind, welche Router-ID verwendet wird und welche Interfaces als passiv oder aktiv gelten.

show ip protocols

show ip protocols

Dieser Befehl ist einer der wichtigsten Startpunkte bei der OSPF-Verifikation. Er zeigt unter anderem:

• Welcher Routing-Prozess aktiv ist
• Welche Router-ID verwendet wird
• Welche Netzwerke per Network-Statement eingebunden wurden
• Welche Interfaces passiv sind
• Welche Routing-Informationen redistribuiert werden

Gerade bei Fehlern durch falsche Wildcard-Masks oder versehentlich passive Interfaces ist dieser Befehl sehr hilfreich.

show running-config | section router ospf

show running-config | section router ospf

Mit diesem Befehl lässt sich die laufende OSPF-Konfiguration direkt prüfen. Besonders relevant sind dabei:

• Process-ID
• Router-ID
• Network-Statements
• Area-Zuordnungen
• Passive Interfaces
• Default-Route-Origination
• Redistribution und Filterregeln

Wichtig ist dabei zu verstehen: Die OSPF-Process-ID ist lokal bedeutend und muss nicht mit anderen Routern übereinstimmen. Entscheidend für die OSPF-Funktion sind Router-ID, Area, Timer, Authentifizierung und weitere Parameter auf den beteiligten Interfaces.

OSPF-Interfaces überprüfen

Nachdem der Prozess geprüft wurde, sollte der Fokus auf die Interfaces gehen. OSPF arbeitet interfacebezogen. Viele Probleme entstehen nicht im globalen Prozess, sondern direkt auf einem einzelnen Interface, etwa durch eine falsche Area, einen unpassenden Netzwerktyp oder inkonsistente Timer.

show ip ospf interface brief

show ip ospf interface brief

Dieser Befehl liefert eine kompakte Übersicht über alle OSPF-aktiven Interfaces. Typischerweise sieht man hier:

• Interface-Name
• Area-Zuordnung
• OSPF-Prozess
• Interface-Adresse
• Kosten
• Status des Interfaces

Das ist besonders nützlich, um schnell zu erkennen, auf welchen Interfaces OSPF tatsächlich läuft und ob ein Interface möglicherweise fehlt.

show ip ospf interface

show ip ospf interface

Dieser ausführlichere Befehl zeigt pro Interface zahlreiche Details, unter anderem:

• Area und Prozess-ID
• Netzwerktyp, zum Beispiel Broadcast oder Point-to-Point
• Hello- und Dead-Intervalle
• OSPF-Kosten
• DR- und BDR-Informationen
• Zahl der erkannten Neighbor
• Status als passive oder aktive Schnittstelle

Gerade wenn Nachbarschaften nicht entstehen, ist dieser Befehl extrem wertvoll. So lassen sich häufig Unterschiede bei Timern, Netzwerktypen oder Prioritäten schnell erkennen.

Interface gezielt prüfen

show ip ospf interface GigabitEthernet0/0

Bei Problemen auf einem bestimmten Link ist die gezielte Prüfung eines einzelnen Interfaces meist effektiver als die Analyse der Gesamtausgabe. So lässt sich schneller erkennen, ob genau dieser Port mit den erwarteten OSPF-Parametern arbeitet.

OSPF-Nachbarn verifizieren

Eine OSPF-Domain funktioniert nur dann korrekt, wenn benachbarte Router saubere Adjazenzen aufbauen. Deshalb gehört die Neighbor-Prüfung zu den wichtigsten Schritten überhaupt. Wenn hier etwas nicht stimmt, sind alle weiteren Routing-Analysen meist zweitrangig.

show ip ospf neighbor

show ip ospf neighbor

Dieser Befehl zeigt alle erkannten OSPF-Nachbarn und deren Status. Wichtige Informationen sind:

• Neighbor Router-ID
• Priorität des Nachbarn
• Adjacency-State, etwa Full, 2-Way, ExStart oder Loading
• Dead Time
• Nachbaradresse
• Lokales Interface

In stabilen Router-zu-Router-Verbindungen sollte der Zustand in vielen Fällen FULL sein. Auf Broadcast-Netzen kann es je nach Design auch 2-Way-Zustände mit nicht voll adjazenten Nachbarn geben, insbesondere bei Routern, die weder DR noch BDR sind.

Wichtige Neighbor-States verstehen

• Down: Kein gültiger Nachbar erkannt
• Init: Hello empfangen, aber noch keine bidirektionale Kommunikation
• 2-Way: Gegenseitige Erkennung, oft normal auf Broadcast-Segmenten
• ExStart: Beginn des Datenbankabgleichs
• Exchange: Austausch von Datenbankbeschreibungen
• Loading: Anfordern fehlender LSAs
• Full: Adjazenz vollständig aufgebaut

Bleibt ein Nachbar dauerhaft in ExStart, Exchange oder Loading hängen, deutet das oft auf Probleme mit MTU, Datenbankabgleich oder inkonsistenten Parametern hin.

Nachbarn im Detail prüfen

show ip ospf neighbor detail

Die Detailansicht liefert zusätzliche Informationen über die Adjazenz, Timer und den Verlauf des Neighbor-Zustands. Sie ist besonders nützlich bei instabilen oder flappenden OSPF-Nachbarschaften.

Die OSPF-Link-State-Datenbank prüfen

Wenn Nachbarn korrekt aufgebaut sind, sollte im nächsten Schritt die Link-State-Datenbank analysiert werden. OSPF funktioniert nur sauber, wenn die Router eine konsistente LSDB besitzen. Fehler in der LSDB führen direkt zu falschen SPF-Berechnungen und damit zu fehlerhaften Routen.

show ip ospf database

show ip ospf database

Mit diesem Befehl wird die komplette OSPF-Datenbank angezeigt. Je nach Topologie können verschiedene LSA-Typen sichtbar sein, zum Beispiel:

• Router LSAs
• Network LSAs
• Summary LSAs
• ASBR Summary LSAs
• External LSAs

Damit lässt sich prüfen, ob ein Router die erwarteten Topologie-Informationen tatsächlich gelernt hat. Besonders bei Multi-Area-Designs oder Redistribution-Szenarien ist das sehr hilfreich.

Spezielle Datenbankbereiche gezielt anzeigen

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

Diese gefilterten Varianten sind in der Praxis oft deutlich übersichtlicher. So lässt sich gezielt prüfen, ob zum Beispiel externe Routen korrekt als Type-5-LSAs verteilt werden oder ob Summary-LSAs aus anderen Areas eintreffen.

Worauf in der LSDB geachtet werden sollte

• Sind die erwarteten LSA-Typen vorhanden?
• Stimmen Advertising Router und Link State ID?
• Gibt es Hinweise auf veraltete oder fehlende LSAs?
• Werden externe Netze korrekt angekündigt?
• Erhält der Router die Informationen aus anderen Areas wie erwartet?

Routing-Tabelle mit OSPF abgleichen

Die LSDB allein reicht nicht aus. Entscheidend ist, welche Routen nach der SPF-Berechnung tatsächlich in der Routing-Tabelle landen. Deshalb sollte nach der Datenbankprüfung immer auch die Routing-Tabelle kontrolliert werden.

show ip route ospf

show ip route ospf

Dieser Befehl zeigt nur die über OSPF installierten Routen. Das erleichtert die Analyse erheblich. Typische Kennzeichnungen sind:

• O für intra-area Routen
• O IA für inter-area Routen
• O E1 für externe Typ-1-Routen
• O E2 für externe Typ-2-Routen

Hier lässt sich direkt erkennen, ob die erwarteten Netzwerke tatsächlich über OSPF erreichbar sind und welcher Next Hop jeweils verwendet wird.

Einzelne Routen gezielt prüfen

show ip route 10.20.30.0
show ip route 0.0.0.0

Mit diesen Befehlen lässt sich gezielt kontrollieren, ob ein bestimmtes Zielnetz oder eine Standardroute vorhanden ist. Gerade bei Troubleshooting ist das oft schneller als die Analyse der gesamten Routing-Tabelle.

Wichtige Prüfpunkte in der Routing-Tabelle

• Ist die erwartete OSPF-Route vorhanden?
• Ist der Next Hop korrekt?
• Stimmt der OSPF-Typ der Route?
• Passt die Metrik zum Design?
• Wird vielleicht eine konkurrierende Route aus einem anderen Protokoll bevorzugt?

Typische OSPF-Probleme auf Cisco-Geräten erkennen

Viele OSPF-Fehlerbilder ähneln sich auf den ersten Blick. Deshalb ist es wichtig, typische Ursachen sauber zu kennen. Die meisten Probleme lassen sich auf wenige Kernbereiche zurückführen: Interface-Fehler, Area-Mismatch, Timer-Unterschiede, Authentifizierungsprobleme, MTU-Konflikte oder fehlerhafte Network-Statements.

Häufige Ursachen für fehlende Nachbarschaften

• Interfaces befinden sich in unterschiedlichen Areas
• Hello- und Dead-Intervalle stimmen nicht überein
• OSPF-Authentifizierung ist inkonsistent
• Unterschiedlicher Netzwerktyp auf den beteiligten Interfaces
• MTU-Probleme verursachen ExStart- oder Exchange-Fehler
• Ein Interface ist als passive-interface konfiguriert
• Falsche IP-Adressierung oder Layer-1/Layer-2-Probleme

Häufige Ursachen für fehlende Routen trotz bestehender Nachbarschaft

• LSAs werden nicht wie erwartet verteilt
• Area-Design verhindert bestimmte Routen
• Stub-, Totally-Stubby- oder NSSA-Konfiguration ist fehlerhaft
• Summarization oder Filter beeinflusst die Sichtbarkeit von Netzen
• Redistribution ist unvollständig oder fehlerhaft
• Eine Route aus anderem Protokoll verdrängt die OSPF-Route

Hilfreiche Zusatzbefehle zur OSPF-Verifikation

Neben den klassischen Standardbefehlen gibt es auf Cisco-Geräten weitere Kommandos, die bei der Analyse sehr nützlich sind. Diese helfen vor allem dann, wenn die Basisausgaben noch keine eindeutige Ursache zeigen.

show ip ospf

show ip ospf

Dieser Befehl liefert Informationen zum OSPF-Prozess selbst, etwa:

• Router-ID
• SPF-Laufzeit und SPF-Zähler
• Zahl der Areas
• Zahl der LSAs
• Status des Routing-Prozesses

Das ist besonders nützlich, um ein Gesamtbild des OSPF-Zustands zu erhalten.

show ip cef exact-route

show ip cef exact-route 10.10.10.1 8.8.8.8

Dieser Befehl ist zwar kein reiner OSPF-Befehl, aber in der Praxis sehr hilfreich. Er zeigt, welchen tatsächlichen Forwarding-Pfad ein Paket nimmt. So lässt sich kontrollieren, ob die OSPF-Route auch wirklich in die Datenebene übernommen wurde.

show interfaces

show interfaces GigabitEthernet0/0

OSPF-Probleme sind nicht immer echte Routing-Probleme. Oft liegt die Ursache im Interface selbst, etwa bei Errors, Flaps oder Duplex-/Speed-Problemen. Deshalb sollte bei Auffälligkeiten immer auch das physische oder logische Interface geprüft werden.

OSPF mit Debug vorsichtig analysieren

Wenn Show-Befehle nicht ausreichen, kann ein Debug helfen. Allerdings sollte Debugging auf produktiven Routern mit Bedacht eingesetzt werden, weil es CPU-Last erzeugen kann. In Wartungsfenstern oder Laborumgebungen ist es jedoch ein sehr wertvolles Werkzeug.

Wichtige Debug-Befehle

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

Diese Befehle zeigen unter anderem:

• Aufbau und Abbruch von Nachbarschaften
• Hello-Paket-Aktivität
• Wichtige OSPF-Ereignisse im Prozess

Debug sauber wieder deaktivieren

undebug all

Nach Abschluss der Analyse sollte Debugging immer sauber deaktiviert werden. In produktiven Netzen ist das besonders wichtig.

Praktischer Prüfablauf für Troubleshooting

In der Praxis ist es hilfreich, bei OSPF-Problemen immer nach einem festen Schema vorzugehen. Das spart Zeit und reduziert Fehldiagnosen.

Empfohlener Ablauf

• Physische und logische Interfaces prüfen
• Mit show ip protocols und show running-config die OSPF-Grundkonfiguration verifizieren
• Mit show ip ospf interface die Interface-Parameter kontrollieren
• Mit show ip ospf neighbor den Adjazenzstatus prüfen
• Mit show ip ospf database die LSDB analysieren
• Mit show ip route ospf die installierten Routen verifizieren
• Falls nötig, mit Debug gezielt weiter eingrenzen

Beispiel für eine kompakte Verifikationssequenz

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

Mit dieser Befehlsfolge lässt sich in sehr vielen Fällen bereits zuverlässig erkennen, wo ein OSPF-Problem liegt.

Best Practices für die OSPF-Verifikation auf Cisco-Geräten

Gute Verifikation bedeutet nicht nur, Befehle auswendig zu kennen, sondern Ergebnisse im Kontext des Netzwerkdesigns zu interpretieren. Ein Router kann technisch funktionierende Nachbarschaften haben und trotzdem falsche Routen installieren, wenn etwa Area-Design, Summarization oder Redistribution nicht sauber geplant wurden.

Bewährte Empfehlungen

• Immer zuerst die OSPF-Nachbarn prüfen, bevor tiefer in die LSDB gegangen wird
• Show-Befehle nicht isoliert, sondern im Zusammenspiel interpretieren
• Bei Multi-Area-Designs besonders auf Intra-Area-, Inter-Area- und External-Routen achten
• Passive Interfaces gezielt kontrollieren
• Änderungen nach jeder Konfigurationsanpassung erneut verifizieren
• Bei Redundanzszenarien Metriken, DR/BDR und Default-Route-Verhalten prüfen

Praxisorientierter Denkansatz

Die wichtigste Frage bei jeder OSPF-Verifikation lautet nicht nur „Ist OSPF aktiv?“, sondern „Erzeugt OSPF genau das Routing-Verhalten, das das Design vorgibt?“. Genau diese Sichtweise trennt reine Befehlskontrolle von professionellem Netzwerkbetrieb auf Cisco-Geräten.

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.