DNS Troubleshooting im Netzwerk: NXDOMAIN, SERVFAIL und Latency Patterns

DNS Troubleshooting im Netzwerk ist eine der zuverlässigsten Methoden, um „alles fühlt sich kaputt an“-Incidents schnell einzugrenzen – denn DNS ist der Einstiegspunkt für fast jede moderne Anwendung. Wenn DNS nicht stimmt, wirken Web, VPN, SaaS, E-Mail und APIs plötzlich „langsam“ oder „down“, obwohl IP-Connectivity, Routing und Firewalls scheinbar sauber sind. Gleichzeitig ist DNS ein…

Routing Troubleshooting: IGP vs. BGP – wo zuerst schauen?

Routing Troubleshooting ist eine der anspruchsvollsten Aufgaben im Netzbetrieb, weil Fehlerbilder selten „sauber“ auf eine Schicht zeigen. Nutzer melden „Service down“, Monitoring zeigt Paketverlust oder Latenzspitzen, und irgendwo im Hintergrund sind Routen verschwunden, falsch priorisiert oder auf einen unerwarteten Pfad ausgewichen. In diesem Moment hilft eine zentrale Frage: IGP vs. BGP – wo zuerst schauen?…

OSPF Neighbor Troubleshooting: MTU, Auth, Timers, Network Types

OSPF Neighbor Troubleshooting ist einer der häufigsten „Routing mit System“-Fälle im Enterprise- und Providerbetrieb, weil OSPF als IGP zwar robust ist, aber bei kleinen Inkonsistenzen sehr präzise scheitert: Nachbarschaften bleiben in INIT hängen, wechseln ständig zwischen FULL und DOWN, oder kommen gar nicht erst hoch, obwohl der Link physikalisch stabil ist. Genau hier entscheidet Methodik…

IS-IS Troubleshooting: Adjacencies, Levels und LSP Flooding

IS-IS Troubleshooting ist im Betrieb großer, stark segmentierter Netzwerke eine der wertvollsten Fähigkeiten, weil Intermediate System to Intermediate System (IS-IS) als IGP häufig dort eingesetzt wird, wo Stabilität, Skalierung und schnelle Konvergenz entscheidend sind: im Provider-Core, in Data-Center-Fabrics, in Campus-Backbones oder in WAN-Underlays für SD-WAN/Overlay-Designs. Gleichzeitig sind IS-IS-Fehlerbilder für Teams, die primär OSPF gewohnt sind,…

Duplex/Autoneg Issues: Klassiker auf Layer 1/2 sauber beweisen

Duplex/Autoneg Issues sind ein Klassiker auf Layer 1/2 – und genau deshalb so gefährlich: Sie treten selten als kompletter Ausfall auf, sondern als „komische“ Performanceprobleme. Anwendungen wirken langsam, VoIP knackt, Datenübertragungen brechen sporadisch ein, TCP Retransmissions steigen, aber die Link-Auslastung sieht harmlos aus. Oft liegt die Ursache in einer Duplex-Mismatch-Situation (eine Seite Full Duplex, die…

CRC/Interface Errors: Hardware, Kabel, Optics oder Congestion?

CRC/Interface Errors sind im Netzwerkbetrieb ein zweischneidiges Schwert: Einerseits liefern sie einen der klarsten Hinweise auf Probleme auf Layer 1/2, andererseits werden sie in der Praxis häufig falsch gedeutet. In Tickets liest man dann Sätze wie „CRC Errors auf dem Uplink – ist die Leitung voll?“ oder „Interface Errors steigen, wahrscheinlich Congestion“. Genau hier beginnt…

Layer-1 bis Layer-7: Systematisches Troubleshooting in komplexen Netzen

Layer-1 bis Layer-7 Troubleshooting ist in komplexen Netzen der zuverlässigste Weg, Störungen reproduzierbar zu finden und zu beheben – ohne Aktionismus und ohne „Try & Error“. Gerade in hybriden Unternehmensumgebungen mit Campus, Rechenzentrum, Cloud, SD-WAN, VPN, Firewalls, Load Balancern und mehreren Providern entstehen Symptome oft weit entfernt von ihrer Ursache: Ein fehlerhaftes Glasfaser-Patchkabel (Layer 1)…

Optical Troubleshooting: SFP DOM Werte, Dämpfung und Budget-Rechnung

Optical Troubleshooting ist eine Kernkompetenz im Betrieb moderner IT-Netzwerke, weil ein einzelnes Glasfaserproblem oft wie ein „mysteriöser“ Layer-4/7-Fehler wirkt: TCP Retransmissions steigen, VoIP jittert, Services werden sporadisch langsam – und trotzdem steht der Link auf „up“. Genau hier helfen SFP DOM Werte (Digital Optical Monitoring), eine saubere Dämpfungsanalyse und die Budget-Rechnung (Link Budget), um Fehler…

Netzwerkstörung mit System: Runbooks, Evidence und schnelle Entscheidungen

Eine Netzwerkstörung mit System zu bearbeiten ist der Unterschied zwischen „Feuerwehrmodus“ und verlässlichem Betrieb. Wenn kritische Anwendungen ausfallen, zählen Minuten: Anwender erwarten schnelle Wiederherstellung, Management verlangt klare Aussagen, und das Technikteam muss zugleich vermeiden, durch hektische Änderungen weitere Risiken zu erzeugen. Genau hier sind Runbooks, Evidence und schnelle Entscheidungen der Schlüssel. Ein gutes Runbook ist…

ARP-Probleme debuggen: ARP Flux, Cache Issues und Duplicate IPs

ARP-Probleme debuggen gehört zu den unangenehmsten Aufgaben im LAN-Betrieb, weil die Symptome oft „zufällig“ wirken: Ein Server ist mal erreichbar, mal nicht; Verbindungen brechen sporadisch ab; ein Standort meldet „DNS kaputt“, obwohl Routing sauber aussieht; oder ein Gateway scheint „unstabil“, ohne dass Link- oder Queue-Counter auffällig sind. Häufig steckt dann kein klassisches Layer-3-Problem dahinter, sondern…