OSPF-Neighbor Down: Root-Cause-Matrix fürs NOC

Ein „OSPF-Neighbor Down“-Alarm ist im NOC ein Klassiker – und gleichzeitig ein Musterbeispiel dafür, wie schnell man Zeit verliert, wenn die Ursachen nicht strukturiert eingegrenzt werden. OSPF (Open Shortest Path First) ist robust, aber empfindlich gegenüber bestimmten Abweichungen: Eine minimale MTU-Differenz, ein geänderter Timer, ein neues ACL-Template, ein Interface-Reset oder ein physischer Link-Flap kann die Nachbarschaft von „Full“ auf „Down“ ziehen – oft mit Kaskadeneffekten wie Route Flapping, Rekonvergenz und Paketverlust. In der Praxis ist die wichtigste Fähigkeit daher nicht, jede OSPF-Nachricht auswendig zu kennen, sondern in wenigen Minuten die richtige Fault Domain zu bestimmen: Ist es Layer 1/2 (Link, VLAN, LAG), Layer 3 (IP/MTU/Unicast), Security/Policy (ACL, uRPF), oder ein reines OSPF-Problem (Auth, Area, Network Type, Timers, DR/BDR)? Diese Root-Cause-Matrix fürs NOC liefert dafür ein wiederholbares Vorgehen: Sie zeigt typische Symptome pro Ursache, die schnellsten Checks, die stärksten Indikatoren (Leading Signals) und die wichtigsten Datenpunkte, die im Ticket dokumentiert werden sollten. So wird aus „Neighbor Down“ ein klarer, eskalierbarer Befund – statt einer langen, unsicheren Debugging-Schleife.

OSPF-Nachbarschaft kurz erklärt: Was „Down“ wirklich bedeutet

OSPF baut Nachbarschaften über Hello-Pakete auf. Wenn ein Router die Hellos des Nachbarn nicht mehr erhält oder die Parameter nicht kompatibel sind, kann die Adjacency nicht entstehen oder bricht ab. „Neighbor Down“ bedeutet deshalb nicht zwangsläufig „Link down“. Häufig ist der Link physisch stabil, aber OSPF kann auf logischer Ebene nicht zusammenkommen (z. B. Auth-Mismatch, MTU-Issue, Timer-Mismatch, falscher Network Type). Für NOC-Triage ist entscheidend: OSPF ist ein Kontrollprotokoll, das über IP (Protocol 89) arbeitet; alles, was IP-Connectivity, Multicast/Unicast, Interface-Status oder Paketfilter beeinflusst, kann OSPF indirekt „down“ machen.

• Physik/Interface: Link-Flaps, Fehlerzähler, LAG/MACSEC, Optik – OSPF verliert Hellos.
• L2/L3-Transport: VLAN/Trunk, IP-Adresse, Subnet, MTU – Hellos kommen nicht an oder Datenbank-Sync scheitert.
• OSPF-Parameter: Area, Auth, Timers, Network Type – Hellos werden verworfen.
• Policy/Security: ACLs, CoPP, uRPF – OSPF-Pakete werden gedroppt oder gedrosselt.

Als technische Referenzen sind RFC 2328 (OSPFv2) und für OSPFv3 RFC 5340 hilfreich.

OSPF-State-Maschine: Welche Zustände in der Praxis relevant sind

Für eine Root-Cause-Matrix reicht es, die Zustände zu kennen, die typische Fehlerbilder abbilden. Sie müssen nicht jede Transition im Detail auswendig lernen, aber Sie sollten wissen, was „stecken bleiben“ bedeutet.

• Down / Init: Hellos fehlen oder werden verworfen; bei „Init“ sieht man den Nachbarn, aber der Nachbar sieht einen selbst nicht korrekt (One-Way).
• 2-Way: Hellos sind gegenseitig; auf Broadcast/NBMA kann man hier bleiben, wenn keine Adjacency nötig ist (z. B. nicht DR/BDR).
• ExStart / Exchange: Datenbank-Synchronisation beginnt; hier dominieren MTU- und Paketgrößen-/Filter-Themen.
• Loading: LSA-Requests/Updates laufen; Drops, Rate-Limits oder fehlerhafte LSA-Weitergabe führen zu Hängern.
• Full: stabile Adjacency; „Down von Full“ deutet oft auf Transport-/Interface-Instabilität oder Policy-Änderungen hin.

Die NOC-Root-Cause-Matrix: Symptome → Schnellchecks → wahrscheinlichste Ursachen

Die Matrix ist so aufgebaut, dass sie in einem Incident-Call funktioniert: Sie starten mit dem beobachteten OSPF-Neighbor-State und gehen dann die wahrscheinlichsten Fehlerklassen durch. Nutzen Sie die Matrix als Priorisierung: erst die „harten“ Ursachen (Link/Interface), dann die „stillen“ (MTU/Policy), zuletzt die selteneren Spezialfälle.

Fall A: Neighbor ist „Down“ oder wechselt schnell zwischen Up/Down

• Typische Symptome: gleichzeitige Interface-Logs, Link-Flaps, CRC/Errors, kurze Rekonvergenz, Route Flaps, CPU-Spikes.
• Schnellchecks:
  • Interface-Status und Flap-Historie prüfen (Admin/Oper, Counter, Last-Change).
  • LAG/Port-Channel-Member-Status und Hashing-Pfade prüfen (wenn relevant).
  • Optik-/Transceiver-Telemetrie (DOM/DDM) und Fehlerzähler auf beiden Seiten vergleichen.
• Wahrscheinlichste Ursachen: Layer-1-Instabilität, schlechtes Patchen/Optik, LAG-Misconfig, fehlerhafte Linecard/Port, Microburst/Discards auf Controlplane-Pfaden.

Fall B: Neighbor bleibt in „Init“ (One-Way Hellos)

• Typische Symptome: Router A sieht Router B, aber nicht umgekehrt; „Init“ statt „2-Way“; häufig nach ACL-/CoPP-Änderungen.
• Schnellchecks:
  • Prüfen, ob Hellos in beide Richtungen ankommen (Packet-Counter/Debug auf OSPF Hello).
  • Prüfen, ob OSPF Multicast (typisch 224.0.0.5/224.0.0.6) oder IP Protocol 89 gefiltert wird.
  • Auf Broadcast-Segmenten: Prüfen, ob L2 (VLAN/Tagging) wirklich symmetrisch ist.
• Wahrscheinlichste Ursachen: unidirektionaler Link, asymmetrische Filter/ACL, CoPP/Policing auf einer Seite, falsche VLAN-Zuordnung, falsche Subnet-Mask (Hellos werden verworfen).

Fall C: Neighbor bleibt in „2-Way“ (aber sollte Full sein)

• Typische Symptome: Auf Broadcast/NBMA bleibt man in 2-Way; Adjacency bildet sich nicht weiter, obwohl sie erwartet wird (z. B. p2p gedacht).
• Schnellchecks:
  • Network Type prüfen (Broadcast vs Point-to-Point vs NBMA).
  • Auf Multiaccess: DR/BDR-Wahl prüfen (Priorities, Interface-State).
  • Prüfen, ob die Nachbarschaft in diesem Topologietyp überhaupt „Full“ werden muss.
• Wahrscheinlichste Ursachen: falscher Network Type, DR/BDR-Missverständnis, NBMA-Konfiguration unvollständig (Neighbors statisch erforderlich), L2-Design inkonsistent.

Fall D: Neighbor hängt in „ExStart/Exchange“

• Typische Symptome: Adjacency startet, aber Database Description (DBD) Austausch kommt nicht durch; häufig nach MTU-Changes oder neuen Tunneln.
• Schnellchecks:
  • MTU auf beiden Interfaces vergleichen (inkl. Tunnel/Overlay-Overhead).
  • Prüfen, ob Fragmentierung/PMTUD beeinträchtigt ist (insbesondere bei Tunnelpfaden).
  • Prüfen, ob DBD-Pakete oder OSPF-Header von ACL/Policy gefiltert werden.
• Wahrscheinlichste Ursachen: MTU-Mismatch, PMTUD-Blackhole, Security-Filter, fehlerhafte OSPF-Paketverarbeitung durch Bug/Feature-Interaktion.

Fall E: Neighbor kommt auf „Full“, fällt aber bei Traffic/Last wieder ab

• Typische Symptome: Stabil in ruhigen Zeiten, instabil bei Peaks; Drops/CPU/Controlplane; häufig bei CoPP zu streng oder bei überlasteten Links.
• Schnellchecks:
  • Controlplane-Policer/CoPP-Stats prüfen (Drops speziell für OSPF/Protocol 89/Multicast).
  • Interface Discards/Queue Drops prüfen (insb. auf Links mit Congestion).
  • CPU/Memory/Process-Stats auf beiden Routern vergleichen.
• Wahrscheinlichste Ursachen: CoPP/Policing zu aggressiv, Congestion auf Controlplane-relevanten Queues, CPU-Overload, LSA-Storm durch Topologieinstabilität.

Parameter-Mismatches: Die häufigsten „stillen Killer“

Viele OSPF-Probleme entstehen durch kleine Konfigurationsdrifts, besonders nach Templates, Rollouts oder Migrationen. Das Gemeine: Der Link ist up, IP ist korrekt, aber OSPF verwirft Hellos. Deshalb sollte die NOC-Matrix eine feste Liste an Parametern enthalten, die immer geprüft werden.

• Area-ID: Muss exakt matchen (z. B. Area 0 vs Area 1).
• Authentication: Key/Type mismatch führt zu verworfenen Hellos.
• Hello/Dead-Interval: Timer müssen übereinstimmen; sonst kein Neighbor-Full.
• Network Type: Broadcast vs P2P beeinflusst Adjacency-Logik.
• MTU: relevant bei DBD/LSA-Sync (ExStart/Exchange).
• Stub/NSSA Flags: area capabilities müssen kompatibel sein.

Timer-Check als schnelle Plausibilitätsprüfung (MathML)

$\mathrm{NachbarGültig}=\mathrm{EmpfangeneHellos}>=\frac{\mathrm{\Delta t}}{\mathrm{HelloInterval}}\wedge \mathrm{\Delta t}<\mathrm{DeadInterval}$

Operativ heißt das: Wenn Hellos nicht im erwarteten Rhythmus eintreffen oder die Zeit seit dem letzten Hello größer als das Dead Interval ist, fällt der Neighbor. Das kann physisch (Drops) oder logisch (Filter, Mismatch) bedingt sein.

Traceroute/Ping helfen nur begrenzt: OSPF-spezifische Connectivity prüfen

Ein häufiger Fehler in Incidents: „IP-Ping geht, also muss OSPF gehen.“ OSPF nutzt IP Protocol 89 und auf vielen Segmenten Multicast. Ein Netz kann ICMP erlauben, aber OSPF filtern. Umgekehrt kann Unicast-Ping funktionieren, aber Multicast/Protocol 89 wird gedrosselt oder gedroppt. Deshalb ist es wichtig, OSPF-spezifisch zu denken.

• Protocol-Spezifik: Prüfen, ob IP Protocol 89 erlaubt ist (ACLs, Firewalls, Security Zonen).
• Multicast: Auf Multiaccess-Segmenten muss 224.0.0.5/224.0.0.6 funktionieren (L2/IGMP-Snooping-Interaktionen beachten).
• Controlplane: CoPP/Policer können OSPF stärker treffen als ICMP oder TCP.

OSPF-Neighbor Down nach Changes: Häufige Change-Induzierte Ursachen

Für ein NOC ist es extrem hilfreich, Ursachen nicht nur technisch, sondern auch prozessual einzuordnen. Die meisten echten Vorfälle hängen mit Änderungen zusammen – selbst wenn der Change „klein“ war.

• Interface-MTU geändert: häufig nach Underlay/Overlay-Anpassungen oder neuen Encapsulation-Features.
• ACL/Firewall-Template ausgerollt: Protocol 89 oder Multicast „aus Versehen“ blockiert.
• CoPP/Policing angepasst: OSPF Hellos/DBD werden gedroppt, besonders bei Peaks.
• VLAN/Trunk/Port-Profile geändert: OSPF läuft auf einem SVI/Subinterface, VLAN driftet oder Tagging ändert sich.
• Timer-Standardisierung: ein Gerät bleibt auf Default, das andere wurde auf Fast-Hellos gestellt.
• Auth-Rotation: Key geändert, aber nicht auf beiden Seiten oder nicht im selben Zeitfenster.

OSPF-Neighbor Down in VRF/Mehrinstanzen-Setups

In modernen Umgebungen laufen OSPF-Prozesse oft pro VRF oder in mehreren Instanzen. Das erzeugt typische Fehlerbilder: IP-Connectivity existiert in VRF A, der OSPF-Prozess läuft aber in VRF B oder auf einem anderen Interface-Context. Das wirkt wie „mysteriöses Down“, obwohl es ein Zuordnungsproblem ist.

• Interface-Bindung: Ist das OSPF wirklich auf dem richtigen Interface und in der richtigen Instanz aktiviert?
• VRF-Routing: Stimmen die Routen für den Next Hop/Neighbor in der richtigen VRF?
• Policy zwischen VRFs: VRF-Leaks oder Service-Chaining können Kontrolltraffic anders behandeln als erwartet.

Evidence-Standard fürs Ticket: Was immer dokumentiert werden sollte

Damit Eskalationen schnell und ohne Rückfragen laufen, braucht jedes „OSPF-Neighbor Down“-Ticket eine Mindestmenge an Daten. Das ist besonders wichtig, wenn mehrere Teams beteiligt sind (Transport, Routing, Security, DC Ops).

• Betroffene Nachbarschaft: Device A/B, Interface(s), VRF/Instanz, Area.
• Neighbor-State und Verlauf: aktueller State, Zeitpunkt letzter Up/Down, Flap-Frequenz.
• Interface-Status: Admin/Oper up/down, Last-Change, Error-Counter, Drops/Discards.
• OSPF-Parametervergleich: Area, Auth, Timers, Network Type, MTU.
• Controlplane/Policy: CoPP/Policer-Drops, ACL-Hits für Protocol 89/Multicast.
• Change-Korrelation: letzter Change auf Interface, VLAN, ACL, CoPP, MTU, Auth.
• Blast Radius: nur eine Adjacency oder mehrere? Gleiche Linecard/gleicher Linktyp betroffen?

Präventive NOC-Maßnahmen: Wie Sie Neighbor-Down seltener und schneller werden

Eine Root-Cause-Matrix ist am wertvollsten, wenn sie nicht nur Incidents löst, sondern auch die Basis für Prävention ist. Viele wiederkehrende Neighbor-Down-Fälle lassen sich durch Standardisierung und Monitoring reduzieren.

• Konfig-Drift-Checks: regelmäßiger Vergleich von OSPF-Parametern auf Linkpaaren (Timers, Auth, MTU, Network Type).
• Pre-/Post-Change-Checks: nach ACL/CoPP/MTU-Changes explizit OSPF-Protokolltraffic validieren.
• Telemetry auf Controlplane: Drops für Protocol 89, CPU-Spikes, Interface-Queue Drops.
• Störsignale früh alarmieren: Link-Flap-Raten, CRC/Errors, DOM/DDM-Degeneration, bevor OSPF kippt.
• Saubere Fault Domain: Underlay/Overlay trennen, OSPF im Underlay stabil halten, Overlays davon entkoppeln.

Outbound-Links für Standards und vertiefende Grundlagen

• RFC 2328 (OSPFv2) für OSPF-Nachbarschaft, States und Parameterkompatibilität.
• RFC 5340 (OSPFv3) für OSPF in IPv6-Umgebungen und Instanzkonzepte.
• RFC 1812 (Requirements for IPv4 Routers) für Forwarding- und ICMP-Verhalten, das Troubleshooting beeinflusst.
• RFC 792 (ICMP) als Referenz für grundlegende Connectivity-Signale und deren Grenzen.
• RFC 1191 (Path MTU Discovery) für MTU/PMTUD-Blackholes, die OSPF-Sync in ExStart/Exchange beeinflussen können.

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.