Categories: Workspace

IT-Gruppe identifiziert P2P-Bandbreitenproblem

Der Test
Der Plan war simpel: Während Rose das Netzwerk überwachte, sollten die Mitarbeiter des IT-Teams verschiedene Instanzen von KaZaA ausführen, um die Anzahl der Netzwerkverbindungen zu erreichen, bei der die Zugriffsprobleme begannen.

KaZaA wurde auf einigen Rechnern der IT-Abteilung installiert und gestartet. Die IT-Mitarbeiter legten Ordner für den gemeinsamen Zugriff an und erstellten in diesen Dummy-Downloads mit ansprechenden Dateinamen. Denn es genügte nicht, KaZaA nur auszuführen, die Benutzer mussten auch etwas zum Herunterladen haben, oder das IT-Team hätte selber Downloads durchführen müssen.

In diesem Fall wurden als Köder Dummy-Dateien mit Namen wie „MIBII“, „EpisodeII“ und anderen einladenden Titeln benutzt, die das Interesse der Benutzer am Download wecken sollten. Die Dateien enthielten allerdings nur unbrauchbare Daten.

Der Plan schien zu funktionieren. Die Benutzer bauten Verbindungen auf und begannen mit dem Download der Dateien, wodurch die Anzahl der aktiven Verbindungen und die Nutzung der Bandbreite entsprechend anstieg. Rose überwachte die Aktivität und wartete auf Rückmeldungen zu Netzwerkproblemen. Ein in Bloomington befindliches Dienstprogramm lieferte Statistiken zur Netzwerknutzung, die alle fünf Minuten aktualisiert wurden. Diese stellten die wichtigste Informationsquelle hinsichtlich der Bandbreitennutzung dar.

Es dauerte ungefähr eine Stunde, bis der Punkt erreicht war, an dem Schwierigkeiten beim Zugriff auf das Netzwerk auftraten. Wie schon zuvor begannen die Probleme mit Erreichen einer Bandbreitennutzung von 6 MBit/s. Einer der Rechner, auf dem KaZaA ausgeführt wurde, wies dabei mehr als 2500 Verbindungen auf.

Als das Netzwerk ins Stocken geriet, begann Rose mit einem Ping-Befehl zu untersuchen, wo sich der Engpass befand. Während er an der Diagnose des Problems arbeitete, stand er mit einem Techniker des Campus in Bloomington in Kontakt, der von der anderen Seite der Verbindung her ein Ping an das Netzwerk der IUS schickte.

Obwohl die von Rose initiierten Pings nach Bloomington auf Probleme hinwiesen, waren in den Pings von Bloomington an die IUS keinerlei Unregelmäßigkeiten festzustellen.

Rose griff über Telnet auf einen HP-Switch zwischen dem IUS-LAN und dem Cisco-Router zu, der die IUS mit den Servern in Bloomington verband, und startete ein Ping des Routers. Die Pings führten entweder zu Zeitüberschreitungen oder dauerten ungewöhnlich lange. Dagegen traten beim Ping von der anderen Seite her, vom Cisco-Router zum HP-Switch, keine Probleme auf. Nur die ausgehenden Pings wurden blockiert.

Trotz der relativ geringen im Netzwerk genutzten Bandbreite schien der Engpass am HP-Switch die Ursache für die Schwierigkeiten beim Zugriff zu sein.

Ergebnisse
Der KaZaA-Test scheint erfolgreich gewesen zu sein. Durch die Überwachung des Netzwerks während der Ausführung von KaZaA durch andere Rechner war Rose in der Lage, das Problem auf einen bestimmten Bereich einzugrenzen. Leider konnte der Test nicht aufzeigen, welcher Vorgang im Switch die Probleme mit der Bandbreite und dem Zugriff auslöst. Die IT-Abteilung wird zwar noch weitere Analysen durchführen müssen, um herauszufinden, was genau mit dem Switch geschieht, dennoch ließen sich in diesem Fall bereits zwei Tatsachen feststellen:

  • Die Verwendung von KaZaA im Netzwerk verursacht unakzeptable Probleme mit der Bandbreite.
  • Der HP-Switch stellt gegenwärtig einen System-Engpass dar.

Der nächste Schritt des Analyseprozesses wird das Ausklammern des Switchs aus der Gleichung sein, um zu sehen, ob dies die Performance des Netzwerks verbessert. Die Verwendung von KaZaA könnte zwar auch einen zu klärenden Punkt darstellen, wichtiger ist jedoch die Frage, wie die Nutzung von 6 MBit/s Bandbreite einer 45 MBit/s-Verbindung dafür sorgen kann, dass der ausgehende Traffic nicht über den Router hinausgelangt, so dass die Benutzer auf dem IUS-Campus nicht auf die Domänen-Controller in Bloomington zugreifen können.

Die Untersuchungen sind zwar noch nicht abgeschlossen, doch ist es den Mitarbeitern der IUS gelungen, durch eine recht ungewöhnliche Methode Belastungstests auf ihrem Netzwerk auszuführen, die schließlich eine Lokalisierung der Stelle ermöglichten, von der die Probleme mit der Bandbreite ausgehen.

Wenn Sie ebenfalls mit Bandbreitenproblemen konfrontiert sind und ein Load Testing durchführen wollen, sollten Sie auch Alternativen zu den von Ihnen verwendeten Standard-Tools in Betracht ziehen. Sie könnten überrascht sein, welche Erkenntnisse sich durch die simple Simulation verschiedener Arten von Netzwerk-Traffic und die Überwachung von deren Auswirkungen auf Ihre Infrastruktur gewinnen lassen.

Page: 1 2

ZDNet.de Redaktion

Recent Posts

Bedrohungen in Europa: Schwachstellen in der Lieferkette dominieren

Hinter 84 Prozent der Zwischenfälle bei Herstellern stecken Schwachstellen in der Lieferkette. Auf dem Vormarsch…

5 Tagen ago

Bericht: Apple arbeitet an faltbarem iPad

Es kommt angeblich 2028 auf den Markt. Das aufgeklappte Gerät soll die Displayfläche von zwei…

6 Tagen ago

HPE baut Supercomputer am Leibniz-Rechenzentrum

Das System basiert auf Hardware von HPE-Cray und Nvidia. Die Inbetriebnahme erfolgt 2027.

6 Tagen ago

Bund meldet Fortschritte in der Netzversorgung

Die Bundesnetzagentur hat ihr Gigabit-Grundbuch aktualisiert. Drei von vier Haushalten sollen jetzt Zugang zu Breitbandanschlüssen…

6 Tagen ago

Vorinstallierte Schadsoftware auf IoT-Geräten

Mit dem Internet verbundene Digitale Bilderrahmen oder Mediaplayer können mit Schadsoftware infiziert werden und sind…

1 Woche ago

iOS und iPadOS 18.2 beseitigen 21 Sicherheitslücken

Schädliche Apps können unter Umständen einen Systemabsturz auslösen. Mindestens eine Anfälligkeit erlaubt eine Remotecodeausführung.

1 Woche ago