In der vergangenen Woche erhielt ich einen Anruf eines Kunden. Kurz vor dem Feierabend, aber mit hoher Dringlichkeit. Gemeldet wurden unerklärliche Netzwerkprobleme die zum teilweisen Ausfall verschiedener Segmente führten. Da meine Versuche, via Remote-Desktop-Sitzung über den bestehenden VPN-Standort-Tunnel mögliche Ursachen in Erfahrung zu bringen, scheiterten, blieb nur noch der Vor-Ort-Einsatz übrig.

Die Geschichte

Kurze Zeit später befand ich mich mit einem Kollegen am Ort des Geschehens. Der erste Blick galt der Firewall – einem Microsoft TMG 2010 – da hier die besten Analyse-Möglichkeiten gegeben waren.

Die Firewall dient als zentrales Gateway für insgesamt 5 verschiedene Netze – nach wenigen Minuten stand fest: Aus einem bestimmten Problem-Netzwerk wurden massiv Broadcast-Messages versendet. Diese führten dazu, dass die interne Protokollierung (integrierte SQL Datenbank) des TMG ordentlich gestresst wurde – im Process Explorer konnte man die Auslastung gut beobachten. Leider führte dieser Umstand – trotz aktueller Hardware von Hewlett Packard (DL360 G7) – zu einem instabilen Funktionsverhalten des Servers und somit zu Abbrüchen bei VPN- und anderen Datenverbindungen.

Die Untersuchung mit Hilfe der Protokollierung des TMG (aktuelle Protokollzeit, problematisches Netz als Quellnetzwerk) brachte nach etwa 20 Ergebnissen – sinngemäß, den genauen Wortlaut habe ich leider nicht notiert – diesen Fehler:

Die Abfrage wurde abgebrochen, da zu viele Ergebnisse in kurzer Zeit geliefert wurden.

Die 20 Ergebnisse zeigten zumindest verweigerte Verbindungen, alles Broadcast-Messages, die auch der Adapter der Firewall im Problem-Netzwerk empfing. Aus Sicherheitsgründen deaktivierten wir den betroffenen Adapter und setzten unsere Fehlersuche zwei Stockwerke tiefer – im Segement des Problem-Netzwerkes – fort.

Mit Notebook und jeder Menge aktueller Anti-Viren-Software im Gepäck untersuchten wir zunächst den Etagen-Switch des betroffenen Segements. Selbiger – ein Modell der HP ProCurve-Serie – meldete im Status-Bereich folgende Warnungen:

Die Verfolgung des Ports führte uns zu einem Server, dem Domänencontroller eines Teil-Netzes, da das Problem-Netzwerk per VLAN in zwei weitere Netze getrennt war. Nach der Anmeldung an dem Domänencontroller, entkräfteten mehrere aktuelle und unterschiedliche Virenscanner den Verdacht einer Infektion durch Schadsoftware. Erst der Aufruf des Process Explorers brachte Gewissheit. Obwohl das System so gut wie keine Last hatte, brachte die Einblendung der Spalten Receive Bytes und Send Bytes des Reiters Process Network ein verblüffendes Resultat.

Der Prozess tcpsvcs.exe (C:\WINDOWS\system32\tcpsvcs.exe) sendete pro Sekunde etwa 10 MByte(!) in das Netzwerk. Über die Eigenschaften des Prozesses erfuhren wir, wer sich dahinter verbarg – der Dienst des DHCP Servers:

Nach dieser Erkenntnis ließ sich das Verhalten sehr gut nachstellen – wurde der DHCP Server beendet, funktionierte das gesamte Unternehmensnetzwerk wieder zuverlässig ohne Probleme – ein Neustart des DHCP-Servers sorgte sofort zu einem Fluten des Netzes mit Broadcast-Messages und so zu den schon geschilderten Phänomenen. Pings in diesem Netzwerk gingen zu 70 Prozent verloren, die restlichen Pakte hatten Laufzeiten von mehr als 600 Millisekunden.

Trotz Kaskadierung des betroffenen Teil-Netzes war der Übeltäter relativ schnell identifiziert – auf einem weiteren Switch zeigten zwei Ports eine extrem hohe Auslastung und nach der Zuordnung am Patch-Feld standen wir wenig später vor einem Bodentank mit den beiden Ports.

Beide Port waren belegt, die Kabel verschwanden aber im Unterboden. Nach ein wenig Zug an einem Kabel traute ich meinen Augen kaum: beide Ports waren durch dasselbe Kabel verbunden – ein perfekter Loop!

Fazit

Wer für diese Netzwerk-Schleife verantwortlich war, blieb leider ungeklärt – vermutlich hatte ein Mitarbeiter das “lose” Kabelende in den freien Port im Bodentank gesteckt. Die Geschichte ist zwar relativ schnell erzählt, allein das Ausmaß der Folgen zeigt, mit welch einfachen Dingen sich ein Netzwerk lahmlegen lässt – physischen Zugang vorausgesetzt. Für die Identifizierung des Problems brauchten wir trotzdem etwa 2 volle Stunden, zu unserem Glück waren die Mitarbeiter schon aus dem Haus.