OSPF Neighbor Down: Ursachen, Checkliste und Recovery-Schritte

Ein „OSPF Neighbor Down“ ist im Routing-Betrieb eines der wichtigsten Alarmsignale, weil es meist nicht nur eine einzelne Verbindung betrifft, sondern unmittelbar die Topologie-Sicht (LSDB), die Routenberechnung und damit den Traffic-Pfad verändert. Je nach Design führt ein OSPF Neighbor Down zu kurzfristigen Micro-Outages (Neuberechnung, Rekonvergenz) oder zu einem echten Produktionsincident, wenn Redundanz fehlt oder mehrere Nachbarschaften gleichzeitig ausfallen. Das tückische daran: Der Root Cause liegt häufig nicht im OSPF-Protokoll selbst, sondern in der Umgebung – etwa in einem Layer-1/Layer-2-Problem, einem MTU-Mismatch, falschen Timern, einer neuen ACL, einer asymmetrischen Multicast-Erreichbarkeit oder in instabilen Links, die „nur kurz“ flappen. Dieser Artikel liefert eine praxisorientierte Checkliste, mit der Sie OSPF Neighbor Down systematisch eingrenzen: von den häufigsten Ursachen über schnelle Verifikationsschritte bis zu sicheren Recovery-Maßnahmen, die die Lage stabilisieren, ohne zusätzliche Instabilität zu erzeugen. Der Fokus liegt auf einem Vorgehen, das in NOC- und Produktionsumgebungen funktioniert: erst die Nachbarschaftszustände und die wichtigsten Parameter verifizieren, dann gezielt die Ursache isolieren, anschließend kontrolliert recovern und zum Schluss die Prävention ableiten.

OSPF Nachbarschaft verstehen: Was „Down“ wirklich bedeutet

OSPF bildet Nachbarschaften zwischen Routern, um Link-State-Informationen auszutauschen. Diese Nachbarschaften durchlaufen definierte Zustände (z. B. Down, Init, 2-Way, ExStart, Exchange, Loading, Full). „Neighbor Down“ bedeutet in der Praxis: Eine zuvor etablierte Nachbarschaft ist abgerissen oder kommt nicht mehr in den erwarteten Zustand (meist „Full“ auf Broadcast-/NBMA-Netzen mit DR/BDR oder „Full“ bzw. „2-Way“ je nach Netzwerktyp und Implementierung). Häufig sehen Sie das Ereignis als Log-Meldung, und kurz danach ändern sich Routen, Pfade oder ECMP-Verteilungen.

• Down: Es werden keine gültigen Hello-Pakete vom Neighbor empfangen oder der Neighbor ist aus der Neighbor-Tabelle entfernt.
• Stuck States: Nachbarschaft bleibt in ExStart/Exchange/Loading hängen und erreicht Full nicht.
• Konvergenzfolgen: SPF-Neuberechnung, Routen-Updates, ggf. BFD-Trigger (falls im Einsatz).

Für die Protokollgrundlagen ist die maßgebliche Referenz RFC 2328 (OSPFv2). Wenn Sie OSPFv3 betreiben, ist RFC 5340 (OSPF for IPv6) relevant.

Typische Ursachen für OSPF Neighbor Down

Im Betrieb lohnt es sich, Ursachen in drei Klassen zu sortieren: Transport/Underlay (Layer 1–3), OSPF-Parameter und Plattform-/Control-Plane-Themen. Diese Struktur verhindert, dass Sie sich in OSPF-Details verlieren, obwohl die Verbindung physisch instabil ist.

Underlay- und Transportprobleme

• Link-Flap / Layer-1-Degradation: Kurzzeitige Aussetzer reichen, um Hello/Dead-Interval zu reißen.
• Layer-2-Probleme: VLAN-Drift, STP-Events, LACP-Instabilität, MAC-Flapping oder Broadcast-Storms beeinflussen OSPF indirekt.
• IP-Connectivity: Falsche IP/Mask, falsches VLAN, ARP-Probleme, asymmetrischer Pfad.
• MTU-Mismatch: Häufige Ursache für „stuck in ExStart/Exchange“ und später „Neighbor Down“ nach Retries.
• Multicast-Block: OSPF nutzt Multicast (224.0.0.5/224.0.0.6 bei OSPFv2); ACLs/CoPP können das stören.

OSPF-Parameter-Mismatches

• Hello/Dead-Interval Mismatch: Einer der Klassiker; die Nachbarschaft kommt nicht stabil hoch oder fällt wieder.
• Area-Mismatch: Unterschiedliche Area-IDs am Interface verhindern Adjacency.
• Authentication Mismatch: Key falsch, Verfahren unterschiedlich (z. B. Null vs. Keyed), führt zu Ignorieren von Hellos.
• Network Type Mismatch: Broadcast vs. Point-to-Point vs. NBMA; kann DR/BDR-Logik und Nachbarschaftsaufbau beeinflussen.
• Stub-/NSSA-Inkonsistenz: Area-Flags unterscheiden sich; Adjacency wird abgelehnt.

Plattform und Control Plane

• CPU-Spikes / Prozess-Instabilität: Hellos werden verzögert gesendet/empfangen; Dead-Interval reißt.
• CoPP/Policing: OSPF-Pakete werden gedroppt oder rate-limited.
• Bug/Memory Pressure: OSPF-Daemon oder Kernel-Probleme, besonders nach Upgrades oder Feature-Änderungen.
• Interface-Queue Drops: Bei Überlast können Control-Pakete verloren gehen (selten, aber kritisch in Engpässen).

Schnelle Triage: Was Sie in den ersten 5 Minuten klären sollten

Bevor Sie tief in Logs und LSDB gehen, hilft eine kurze, konsequente Triage. Ziel ist, die wahrscheinlichste Ursacheklasse zu bestimmen und den Blast Radius zu begrenzen.

• Scope: Ist nur ein Neighbor down oder mehrere? Mehrere gleichzeitig sprechen eher für Underlay oder Control Plane.
• Topologie: Ist es ein Backbone-Link, ein Access-Edge oder ein internes Transit-Segment?
• Flapping: Ist es ein einmaliger Down oder wiederholt es sich im Minutenrhythmus?
• Change-Korrelation: Gab es kurz vorher ein Change (ACL, MTU, VLAN, LACP, Upgrade)?
• Impact: Welche Routen sind verschwunden? Gibt es Traffic-Shift und Überlast auf Alternativpfaden?

Checkliste: OSPF Neighbor Down systematisch prüfen

Diese Checkliste ist bewusst herstellerneutral formuliert. In der Praxis setzen Sie sie mit den jeweiligen Befehlen um (z. B. „show ospf neighbor“, Interface-Counter, ACL/Firewall-Regeln, Logs). Wichtig ist die Reihenfolge: erst Underlay, dann OSPF-Parameter, dann Spezialfälle.

Physik und Interface-Health

• Interface Status: up/up? Gab es Link-Flaps?
• Error Counter: CRC/Input Errors, Drops, Discards; ein „halb kaputter“ Link ist eine häufige Root Cause.
• Speed/Duplex/Autoneg: Mismatch kann zu Paketverlusten führen, die OSPF als Dead-Interval-Timeout sieht.
• Optik/DOM-DDM: Bei Glasfaser: Rx/Tx-Power prüfen, Alarmzustände beachten.

IP-Connectivity und Erreichbarkeit

• IP und Maske: Stimmen Addressing und Subnet überein?
• ARP/ND: Wird die Neighbor-MAC sauber gelernt? Gibt es ARP-Instabilität?
• Ping/Traceroute: Erreichbarkeit des Neighbor-IPs (bei PtP) oder der Interface-IP (je nach Design) verifizieren.
• Multicast-Pfad: Blockt etwas Multicast im Segment? OSPFv2 Hellos laufen über Multicast.

OSPF-Interface-Parameter vergleichen

• Area-ID: Muss identisch sein.
• Hello/Dead-Interval: Muss identisch sein (oder kompatibel im Design, aber praktisch: identisch pro Link).
• Network Type: Broadcast/PtP/NBMA konsistent setzen.
• Authentication: Gleiche Methode und gleicher Key.
• MTU: OSPF kann bei MTU-Problemen in ExStart/Exchange hängen bleiben.

OSPF-State gezielt interpretieren

• Down: Keine Hellos oder Hellos werden verworfen (Auth/Area/Timer/ACL).
• Init: Hellos kommen an, aber der Neighbor sieht Sie nicht (asymmetrische Sicht, oft ACL/Multicast oder falsche Source).
• 2-Way: Auf Broadcast-Netzen normal für nicht-DR-Adjacencies, aber auf PtP meist ein Hinweis auf Network-Type/DR-Logik.
• ExStart/Exchange stuck: Oft MTU, DBD-Problem oder Implementierungs-/Interoperabilitätsissue.
• Loading stuck: LSAs werden nicht vollständig ausgetauscht, kann auf Paketverlust, MTU oder Filter/Policy hinweisen.

Timer verstehen: Wann „Down“ durch Dead-Interval getriggert wird

Viele Neighbor-Down-Events entstehen schlicht dadurch, dass innerhalb des Dead-Intervals keine gültigen Hello-Pakete empfangen werden. Wenn der Link instabil ist oder die Control Plane überlastet, reichen wenige Sekunden Verzögerung. Als praktische Faustregel gilt: Je aggressiver die Timer, desto schneller Konvergenz, aber desto höher die Empfindlichkeit gegen Jitter und Paketverlust.

$\mathrm{DeadInterval}=\mathrm{HelloInterval}\times \mathrm{DeadMultiplier}$

In vielen Designs ist der DeadMultiplier implizit (klassisch 4). Wenn Sie Timer anpassen, sollten Sie sicherstellen, dass Underlay, QoS/CoPP und Plattformleistung das zuverlässig tragen. Andernfalls erzeugen Sie „OSPF Neighbor Down“ als Symptom einer zu aggressiven Konfiguration.

Recovery-Schritte: Stabilisieren, ohne Nebenwirkungen zu erzeugen

Recovery heißt in erster Linie: Die Nachbarschaft wieder stabil in den erwarteten Zustand bringen und die Topologie konsistent machen. Dabei ist Vorsicht geboten: Unkoordiniertes „clear ospf process“ oder hektisches Interface-Flapping kann kurzfristig helfen, aber die gesamte Area destabilisieren, SPF-Stürme auslösen und zusätzliche Incidents erzeugen. Nutzen Sie Recovery daher abgestuft.

Stufe: Sicherer Sofort-Check

• Underlay stabilisieren: Wenn Errors/Flaps sichtbar sind, zuerst physisch und Layer 2 beheben.
• ACL/CoPP prüfen: OSPF- und Multicast-Traffic darf nicht ungewollt gedroppt werden.
• Konfig-Drift entfernen: Timer/Area/Auth/MTU auf beiden Seiten identisch setzen.

Stufe: Kontrollierte Adjacency-Neuinitialisierung

• Interface reset statt Prozessreset: Wenn möglich, nur das betroffene Interface kurz neu initialisieren, nicht den gesamten OSPF-Prozess.
• Minimal-invasiv arbeiten: Erst wenn die Ursache behoben ist, Adjacency neu aufbauen lassen.
• Wirkung messen: Neighbor-State, LSDB-Sync, Route-Table und Traffic-Pfade verifizieren.

Stufe: Prozessmaßnahmen nur mit Bedacht

• OSPF-Prozess neu starten: Nur wenn klar ist, dass es ein Prozess-/Daemon-Thema ist oder eine LSDB-Inkonsistenz nicht anders lösbar ist.
• Wartungsfenster bevorzugen: In kritischen Backbones kann ein Prozessreset einen erheblichen Impact haben.
• Rollback-Plan: Vorher definieren, wie Sie bei unerwarteten Effekten zurückgehen.

Häufige Spezialfälle: Wenn die Standardchecks nicht reichen

Es gibt Fälle, in denen das Underlay stabil scheint und Parameter konsistent sind, der Neighbor aber trotzdem flappt oder nicht Full wird. Hier sind typische „zweite Ebene“-Themen, die in Produktion häufig vorkommen.

MTU-Mismatch als „Stuck in ExStart“ Klassiker

Wenn die MTU auf den Interfaces unterschiedlich ist, scheitert oft der Database Description (DBD) Austausch. Die Nachbarschaft bleibt hängen und kann schließlich als Down erscheinen, weil Retries scheitern oder die Session neu startet. Prüfen Sie MTU nicht nur am Interface, sondern auch in eventuellen Tunneln/Encapsulations (VLAN-Tagging, QinQ, GRE/IPsec, VXLAN-Underlay).

Asymmetrische Filter: Hellos kommen an, aber Antworten nicht

Wenn eine ACL nur in eine Richtung OSPF oder Multicast blockt, sieht eine Seite den anderen (Init), aber die Gegenseite sieht keine vollständige Kommunikation. Achten Sie auf Richtungsabhängigkeit: Input/Output-ACLs, Firewall-Zonen, VRF-Boundaries oder Policy-basierte Filter.

DR/BDR und Network Type auf Broadcast-Segmenten

Auf Ethernet-Broadcast-Netzen werden DR/BDR gewählt. Wenn Network Type oder Prioritäten inkonsistent sind, kann das zu unerwarteten Neighbor-States führen. In instabilen Situationen sehen Sie dann häufige DR-Wechsel, was die LSDB-Synchronisation zusätzlich belastet.

Control Plane Policing (CoPP) und QoS

CoPP schützt Router, kann aber OSPF unabsichtlich drosseln. Besonders bei Störungen (viele Hellos, viele LSAs, Rekonvergenz) werden Control-Pakete mehr. Wenn CoPP zu eng ist, bricht OSPF genau dann weg, wenn es am dringendsten gebraucht wird.

Prävention: Wie Sie Neighbor-Down-Events deutlich seltener machen

Viele OSPF Neighbor Down Incidents sind Wiederholer, weil die Umgebung nicht „routing-freundlich“ gehärtet ist. Prävention bedeutet, das Underlay stabil zu halten, Drift zu vermeiden und OSPF so zu konfigurieren, dass es robust gegen erwartbare Betriebsereignisse ist.

• Underlay-Baselines: Interface-Errors, Optikwerte, Flap-Raten und L2-Events als Frühindikatoren überwachen.
• Konfig-Templates: Einheitliche OSPF-Profile pro Linktyp (PtP, Broadcast, Backbone, Edge), inklusive Auth/Timer/MTU.
• Timer konservativ wählen: Nicht aggressiver als nötig; Stabilität priorisieren, wenn die Plattform/Links nicht „carrier-grade“ sind.
• BFD bewusst einsetzen: Wenn Sie sehr schnelle Failure Detection benötigen, BFD als separates Tool nutzen und die Implikationen testen.
• CoPP/QoS validieren: OSPF-Control-Traffic muss auch im Incident-Fall durchkommen.
• Change-Disziplin: ACLs, MTU, VLAN-Änderungen und Port-Profile immer end-to-end prüfen, nicht nur lokal.

Ticket- und RCA-Checkliste: Was Sie dokumentieren sollten

OSPF-Probleme eskalieren schnell an Engineering oder Vendor. Ein gutes Ticket enthält daher nicht nur „Neighbor Down“, sondern eine nachvollziehbare Beweiskette. Das verkürzt MTTR und verhindert, dass Teams dieselben Checks doppelt durchführen.

• Nachbar-Identität: Router-ID, Interface, Area, Network Type.
• Zeitlinie: Startzeit, Flap-Pattern, Korrelation zu Changes oder Underlay-Events.
• OSPF-States: Letzter State vor Down, ggf. „stuck in ExStart/Exchange“.
• Underlay-Indikatoren: Link-Flaps, Errors, LACP/STP-Events, optische Werte.
• Parametervergleich: Hello/Dead, Auth, MTU, Area, Stub/NSSA-Flags.
• Mitigation und Wirkung: Was wurde geändert/isoliert und wie hat sich Neighbor/Traffic verhalten?

Outbound-Links: Relevante Standards und vertiefende Referenzen

• RFC 2328 – OSPF Version 2 (Grundlagen, Neighbor States, Hello/Dead)
• RFC 5340 – OSPF for IPv6 (OSPFv3)
• RFC 826 – ARP (hilfreich bei L2/L3-Connectivity-Problemen rund um OSPF)

Checkliste zum Kopieren: OSPF Neighbor Down in der richtigen Reihenfolge lösen

• Scope bestimmen: Ein Neighbor oder mehrere? Flapping oder einmalig?
• Underlay prüfen: Interface up/up, Errors, Flaps, Optik/Kabel, VLAN/L2-Stabilität.
• IP-Connectivity prüfen: ARP/ND, Ping, Multicast-Erreichbarkeit (OSPFv2), asymmetrische Filter ausschließen.
• OSPF-Parameter vergleichen: Area, Hello/Dead, Auth, MTU, Network Type, Stub/NSSA-Flags.
• State interpretieren: Down/Init/2-Way/ExStart/Exchange/Loading gezielt als Hinweis nutzen.
• Kontrollierte Recovery: Ursache beheben, dann Adjacency minimal-invasiv neu initialisieren.
• Wirkung verifizieren: Neighbor Full, LSDB konsistent, Routen stabil, Traffic-Pfad plausibel.
• Prävention ableiten: Templates, Baselines, CoPP/QoS, Timer-Strategie, Change-Prozess verbessern.

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.