OSPF Troubleshooting Masterclass: LSA-Debugging ohne Produktion zu gefährden

LSA-Debugging ist die Königsdisziplin im OSPF-Troubleshooting: Wenn Routen fehlen, unerwartete Pfade entstehen oder Konvergenz „laut“ wird, liegt die Wahrheit fast immer in der LSDB und im Flooding-Verhalten. Gleichzeitig ist klassisches debug ip ospf in Produktion riskant, weil es CPU und Logs fluten kann. Die Masterclass-Strategie lautet daher: erst read-only Beweise sammeln (LSDB, Neighbor, SPF/LSA-Stats), dann Hypothesen per gezielten Show-Befehlen testen, und Debug nur kurz, gefiltert und mit Kill-Switch einsetzen. So findest du Root Causes, ohne die Produktion zu gefährden.

Safety First: Debug-Disziplin für Produktionsnetze

OSPF-Debugs können bei großen LSDBs sehr laut sein. Bevor du irgendetwas debugst, stellst du sicher, dass du die Situation nicht verschlimmerst: CPU prüfen, Logging kontrollieren und ein kurzes Messfenster planen.

• CPU-Check: Debug nur, wenn CPU nicht kritisch ist
• Kill-Switch bereit: undebug all
• Kurze Fenster: 20–60 Sekunden statt „laufen lassen“
• Prefer read-only: 80% der Fälle lösen sich ohne Debug

Minimaler Safety-Check

show processes cpu sorted
show logging | last 50
undebug all

OSPF LSA-Grundlagen: Welche LSAs sind für Troubleshooting wirklich relevant?

Für Produktion brauchst du keine vollständige LSA-Enzyklopädie, aber du musst wissen, wo welche Information herkommt: Intra-Area (Typ 1/2), Inter-Area (Typ 3/4) und Externals (Typ 5/7). Daraus folgt direkt, wo du suchen musst: auf dem Originator, am ABR oder am ASBR.

• Type 1/2: Intra-Area Topologie (Router/Network LSAs)
• Type 3/4: Inter-Area Summaries (ABR erzeugt sie)
• Type 5: Externals (ASBR, in Stub blockiert)
• Type 7: NSSA Externals (ASBR in NSSA, ABR kann übersetzen)

Master-Workflow: LSA-Debugging in 6 Schritten (ohne Risiko)

Dieses Vorgehen ist für echte Incidents optimiert: Du gehst vom Symptom zur LSA-Quelle, isolierst den Punkt, an dem die Information „verschwindet“, und verifizierst dann Flooding/Timers – ohne große Debugs.

• Symptom konkretisieren: welche Route fehlt/ist falsch?
• OSPF Route-Quelle bestimmen: intra, inter, external?
• LSA in der lokalen LSDB suchen (gibt es sie überhaupt?)
• Pfad der LSA prüfen: Originator/ABR/ASBR, Area-Grenzen
• Flooding/Spf-Statistiken prüfen (Stürme, Throttle)
• Nur wenn nötig: kurzer, gefilterter Debug

Step 1: Symptom sauber beschreiben (Route, Area, Typ)

Bevor du in LSAs gehst, kläre: Welche Prefix-Route fehlt? In welcher Area sollte sie auftauchen? Ist sie als OSPF intra/inter/external sichtbar? Das entscheidet, ob du beim ABR oder ASBR suchen musst.

Route-Typ bestimmen

show ip route <prefix>
show ip route ospf

Interpretation

• O (intra): Quelle ist innerhalb der Area (Type 1/2)
• O IA (inter): Quelle kommt über ABR (Type 3)
• O E1/E2: External (Type 5) vom ASBR
• O N1/N2: NSSA External (Type 7) innerhalb NSSA

Step 2: Neighbor- und Interface-Basics (ohne das ist jedes LSA-Debug sinnlos)

Wenn die Nachbarschaft nicht stabil ist, ist die LSDB nicht stabil. Prüfe daher zuerst Neighbor-Status, Area-ID, MTU und Authentication – die klassischen Ursachen für „LSA kommt nie an“.

show ip ospf neighbor
show ip ospf interface brief
show ip ospf interface <int>

Step 3: LSDB gezielt durchsuchen (statt „alles anzeigen“)

Die effizienteste Frage lautet: „Sehe ich die LSA für diesen Prefix/Router überhaupt?“ Wenn nein, ist der Fehler upstream (Originator/ABR/ASBR). Wenn ja, ist der Fehler downstream (Routing-Installation, Filtering, Summaries, Preference).

LSDB Größe und Überblick

show ip ospf database | count
show ip ospf database summary

Inter-Area (Type 3) gezielt prüfen

show ip ospf database summary | include <prefix>

External (Type 5) gezielt prüfen

show ip ospf database external | include <prefix>

NSSA External (Type 7) gezielt prüfen

show ip ospf database nssa-external | include <prefix>

Step 4: „Wo verschwindet die Information?“ – ABR/ASBR Pfad prüfen

Jetzt arbeitest du entlang des LSA-Pfads: Wenn es eine O IA Route sein sollte, prüfst du ABR und Summarization. Wenn es eine External Route ist, prüfst du ASBR/Redistribution und Area-Typ (Stub/NSSA). Das ist der häufigste „Leakage“-Fehlerpunkt.

ABR-Checks (Inter-Area)

show ip ospf border-routers
show running-config | section router ospf
show running-config | include area|range

ASBR/Redistribution-Checks (External)

show running-config | include redistribute
show ip ospf database external
show ip route | include <redistributed-prefix>

Stub/NSSA Wirkung prüfen

show ip ospf
show ip ospf database external
show ip ospf database nssa-external

Step 5: Flooding, SPF und Throttling ohne Debug bewerten

Viele „OSPF ist instabil“-Incidents sind Flooding-/SPF-Stürme, ausgelöst durch Flaps. Du willst wissen: Wie oft laufen SPF und welche LSA-Events passieren? Das geht meist über Statistik-Outputs und Logs, ohne live zu debuggen.

SPF/LSA Statistik

show ip ospf statistics
show logging | include OSPF|SPF|ADJCHG

Interpretation

• Viele SPF Runs in kurzer Zeit: Flap oder „laute“ Redistribution
• Viele Neighbor-Resets: MTU/Auth/Link-Instabilität
• LSDB wächst schnell: fehlende Summarization, zu viele Externals

LSA-Debugging ohne Risiko: „Debug nur, wenn Show nicht reicht“

Wenn du wirklich sehen musst, welche LSAs gesendet/empfangen werden, debugge gezielt und kurz. Nutze möglichst spezifische Debugs (Adjacency/Events) statt „alles“. Stoppe sofort, sobald du das relevante Event gesehen hast.

Short Debug Window (Beispiel)

terminal monitor
debug ip ospf adj
debug ip ospf events
! 20-60 Sekunden laufen lassen
undebug all

Praxisregel

• Debugs nur in Wartungsfenster oder bei stabiler CPU
• Wenn Logs explodieren: sofort undebug all
• Debug-Ergebnisse immer mit Zeitstempel sichern

„Missing Route“ Casebook: 5 klassische LSA-Ursachen

Diese fünf Muster decken den Großteil der produktiven OSPF-Probleme ab. Wenn du sie systematisch prüfst, brauchst du selten tiefe Debugs.

• Neighbor nicht FULL: Auth/MTU/Area mismatch → keine LSAs
• Stub blockt Externals: Type-5 fehlt (Designfehler oder Erwartung falsch)
• ABR Summarization/Range falsch: Type-3 fehlt oder Summary blackholet
• Redistribution fehlt/Filter falsch: ASBR erzeugt kein Type-5/7
• RIB/FIB Installation: Route da, aber nicht gewählt (AD, tie-break, PBR)

Checks pro Muster (kompakt)

show ip ospf neighbor
show ip ospf interface
show ip ospf database summary
show ip ospf database external
show ip ospf database nssa-external
show ip route <prefix>

Evidence Capture für RCA/TAC: Was du nach dem Incident speicherst

Wenn du einen wiederkehrenden OSPF-Fall hast, sammle Beweise, bevor sie verschwinden. Das beschleunigt RCA und hilft bei TAC-Cases, ohne dass du im Produktionsnetz dauerhafte Debugs laufen lässt.

show clock
show ip ospf neighbor
show ip ospf interface brief
show ip ospf database | count
show ip ospf database summary
show ip ospf statistics
show logging | last 300
show running-config | section router ospf
show tech-support

Quick-Runbook: LSA-Debugging in 10 Minuten (ohne Risiko)

Dieser Block ist als Copy-&-Paste-Ablauf gedacht, um „Route fehlt“ systematisch zu lösen und dabei stabil zu bleiben.

show processes cpu sorted
show ip ospf neighbor
show ip ospf interface brief
show ip route <prefix>
show ip ospf database summary | include <prefix>
show ip ospf database external | include <prefix>
show ip ospf database nssa-external | include <prefix>
show ip ospf statistics
show logging | include OSPF|SPF|ADJCHG
show running-config | section router ospf

Konfiguration speichern

Router# copy running-config startup-config

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.