OSPF Flap: Root Cause finden (L1, L2 oder Timer?)

Ein „OSPF Flap“ ist im Betrieb eines IP-Netzes oft gefährlicher als ein einmaliger OSPF-Ausfall, weil er das Netz in einen Dauerzustand aus Rekonvergenz, SPF-Neuberechnung und wechselnden Traffic-Pfaden zwingt. Während ein „OSPF Neighbor Down“ meist einen klaren Trigger hat (Link down, Change, Fehler), ist ein Flap häufig ein Symptom für ein intermittierendes Problem: Ein Interface flapped…

BGP Session Down: Schneller Debug (Transport vs. Policy)

Ein „BGP Session Down“ gehört zu den Incident-Typen, bei denen Minuten zählen: Sobald die BGP-Nachbarschaft abreißt, verschwinden Routen, Traffic wird umgeleitet, und je nach Design kann ein kompletter Standort oder ein ganzer Internet-Edge „blind“ werden. In der Praxis ist das Problem jedoch nicht immer BGP selbst. Sehr häufig ist die Ursache im Transport (TCP/179 kommt…

BGP Flap: Kundenauswirkungen und Stabilisierung

Ein BGP Flap ist für Kunden häufig schlimmer als ein einzelner, klarer Ausfall. Während eine einmalige BGP-Session-Unterbrechung oft „nur“ eine kurze Rekonvergenz auslöst, erzeugt ein wiederholtes Up/Down („Flapping“) eine instabile Routing-Lage: Präfixe erscheinen und verschwinden, Pfade wechseln im Minuten- oder Sekundenrhythmus, und Anwendungen verhalten sich unvorhersehbar. Genau deshalb wird ein BGP Flap im NOC häufig…

OTDR fürs NOC: Wann Field Team/Vendor einschalten

OTDR fürs NOC ist ein Thema, das in vielen Organisationen erst dann ernsthaft diskutiert wird, wenn optische Links „komisch“ werden: steigende Fehler, sporadische Link-Flaps, abfallende Rx-Power oder Instabilität nach einem Patch. Ein Optical Time Domain Reflectometer (OTDR) kann in solchen Fällen sehr schnell klären, ob eine Glasfaserstrecke physisch intakt ist, wo sich Dämpfungsstellen befinden und…

Link Down troubleshooten: Port, Kabel, SFP oder Switch?

„Link Down troubleshooten“ gehört zu den häufigsten Aufgaben im Netzwerkbetrieb – und gleichzeitig zu den Fällen, in denen man am schnellsten Zeit verliert, wenn man ohne System vorgeht. Ein Link, der plötzlich „down“ ist, kann viele Ursachen haben: ein deaktivierter Port, ein defektes oder falsch gestecktes Kabel, ein inkompatibles oder sterbendes SFP-Modul, ein Switch-Port mit…

Remote-Hands-SOP: Human Error beim Troubleshooting reduzieren

Eine Remote-Hands-SOP ist im Rechenzentrum und im Netzwerkbetrieb oft der Unterschied zwischen „Problem in 10 Minuten gelöst“ und „zweiter Incident durch Fehlgriff“. Remote Hands sind wertvoll, weil sie schnell vor Ort handeln können, während NOC- oder Engineering-Teams remote diagnostizieren. Gleichzeitig entsteht genau dort ein erhöhtes Risiko für Human Error: unklare Anweisungen, Zeitdruck, schlechte Beschriftung, falsches…

Optik DOM/DDM: Tx/Rx-Power (dBm) fürs NOC richtig lesen

Optik DOM/DDM: Tx/Rx-Power (dBm) fürs NOC richtig lesen ist eine Kernkompetenz im täglichen Netzwerkbetrieb, weil Sie damit viele Glasfaserprobleme erkennen, bevor sie zu einem echten Incident werden. In der Praxis sieht das NOC häufig nur „Interface flapping“, „CRC-Fehler“ oder „BGP Session down“ – die eigentliche Ursache liegt jedoch oft in der optischen Strecke: verschmutzte Stecker,…

Interface Health prüfen: Command-Checkliste für Cisco/Juniper/MikroTik

Interface Health prüfen ist eine der wichtigsten Routineaufgaben im NOC und im Netzwerkbetrieb, weil die meisten Störungen sich zuerst an einem einzelnen Port zeigen: Link-Flaps, steigende CRC-/Input-Errors, Drops durch Queueing, optische Degradation, Speed-/Duplex-Probleme oder ein schleichender Hardwarefehler. Gleichzeitig ist „Interface Health“ mehr als nur „Link up“. Sie brauchen eine systematische Command-Checkliste, die schnell Antworten liefert:…

CRC-/Input-Errors am Interface: Ursachen, Analyse und Lösung

CRC-/Input-Errors am Interface gehören zu den häufigsten Warnsignalen im Netzwerkbetrieb – und gleichzeitig zu den am meisten unterschätzten. Viele Teams reagieren erst, wenn der Link flapping zeigt oder Applikationen Timeouts melden. Dabei sind CRC-Fehler (Cyclic Redundancy Check) und Input Errors oft frühe Indikatoren für physikalische Probleme, fehlerhafte Aushandlung, transceiverbedingte Qualitätsprobleme oder auch für Überlast- und…

Checkliste „Physical Layer First“: Wann L1 zwingend zuerst geprüft wird

Die Checkliste „Physical Layer First“ ist im Netzwerkbetrieb kein Dogma, sondern eine pragmatische Regel zur Zeitersparnis: Wenn bestimmte Symptome auftreten, muss Layer 1 (L1) zwingend zuerst geprüft werden, bevor Sie Stunden in Routing-Tabellen, BGP-Policies oder Firewall-Regeln investieren. Der Grund ist einfach: Physische Probleme erzeugen oft irreführende Folgeeffekte auf höheren Schichten. Ein schlechter Stecker, eine verschmutzte…