Kommentar: Fehleranalyse
Wie man mit Testen ein Netz lahmlegt
Applikationsentwickler sind eine ganz besondere Spezies an Menschen. Sie sind wichtig, können Alles und machen keine Fehler. Das Netzwerk ist für diese Berufsgruppe nur Mittel zum Zweck. Es ist transparent und daher in seiner Wertigkeit untergeordnet. Was zählt ist die GUI und die damit verknüpften Daten.
Vor einigen Wochen erhielten wir einen Anruf von einem Kunden. Er beklagte sich, dass sein Netzwerk von Zeit zu Zeit aus unerfindlichen Gründen entweder zu langsam arbeitete oder die Daten vollständig verlor. Die Fehlersuche hatte höchste Priorität und wir mussten alles stehen und liegen lassen.
Der erste Blick auf die im Netz integrierten Switches ergab eine anormale CPU-Auslastung. Normalerweise haben die Catalyst-6509-Switches kaum etwas zu tun und laufen die meiste Zeit mehr oder weniger fast im Leerlauf. Die weitere Analyse ergab auf den Schnittstellen eine deutlich höhere Last als gewöhnlich. Dies sollte jedoch allein nicht die Ursache des Problems sein.
Eine genauere Verkehrsanalyse mit dem Analysewerkzeug "WireShark" brachte weitere Details ans Licht. Auf dem Netz tummelte sich eine Menge an Multicast-Datenverkehr. Diese Datenströme waren bei der letzten routinemäßigen Kontrolle noch nicht da. Seltsam, niemand hatte erwähnt, dass in der Zwischenzeit neue Anwendungen im Unternehmen installiert wurden. Trotzdem war die Netzinfrastruktur so ausgelegt, dass das Netzwerk mit Multicast-Verkehr problemlos fertig werden sollte.
Der gesamte Multicast-Verkehr wurde an die Adresse 224.0.0.5 geschickt. Bei dieser Zieladresse handelt es sich um die "All OSPF Routers"-Adresse. Da der Catalyst auch als Layer-3-Komponente für das OSPF-Routing konfiguriert war, bedeutete dies, dass die Layer-3-Komponenten im Switch jedes dieser Multicast-Pakete verarbeiten musste. Damit war eine logische Erklärung für die extrem hohe CPU-Last gefunden.
Das Netz arbeitete, abgesehen vom Multicast-Problem, stabil wie immer und eigentlich hätte sehr wenig OSPF-Verkehr auftreten müssen. Was war also die Ursache?
Der gesamte "komische" Datenverkehr wurde von einer einzigen Quell-Adresse übermittelt. Daher war es nicht schwer herauszufinden, an welchem Etagen-Switch dieses Gerät angeschlossen war. Die Deaktivierung des betreffenden Switch-Ports reduzierte die Verkehrs- und CPU-Last auf dem Catalyst-Switch schlagartig und das Lastaufkommen normalisierte sich.
Ich ging spazieren und als ich in die Gegend kam, in der der besagte Switch installiert war, fand ich eine Gruppe von Anwendungsentwicklern. Und einer von ihnen sah nicht besonders glücklich aus. Er starrte auf einen Bildschirm, auf dem sich offenbar nicht viel tat. Bingo! Erwischt!
- Wie man mit Testen ein Netz lahmlegt
- Kleine Ursache - große Wirkung
Lesen Sie mehr zum Thema
