"Pakete lügen nicht"

Herr Bongertz, Kunden kommen zu Ihnen, wenn sie Probleme mit ihrem Netzwerk haben. Um welche Art von Problemen handelt es sich dabei?

Unsere Kunden melden oft, dass ihr Netzwerk langsam ist, dass es Unterbrechungen gibt, die nicht gewollt sind oder dass Verbindungen nicht zustande kommen.

Wie gehen Sie vor, wenn ein Kunde mit einem Netzwerkproblem an Sie herantritt?

Zuerst finden wir in einem detaillierten Gespräch heraus, wie sich das Problem bemerkbar macht, und welche und wie viele Anwender und Geräte betroffen sind. Weiter ist es sehr wichtig zu wissen, ob sich das Problem reproduzieren lässt oder nicht. Reproduzierbare Fehler sind meist recht einfach zu analysieren, denn dann führen wir genau bei den entsprechenden Geräten die nötigen Messungen durch.

Welche Art von Messungen sind das?

Je nach Umfang des Problems und der betroffenen Geräte werden ein oder mehrere Messgeräte an genau ausgewählten Mess­punkten aufgebaut. Dabei ist unter anderem die Leitungsgeschwindigkeit wichtig, denn ab einigen hundert Megabit und Vollduplex kann man exakte Messungen oft nur noch mit Spezialmess­geräten durchführen. In einfachen Fällen kommt durchaus auch schon einmal Wireshark auf einem Laptop zum Einsatz.

Wireshark kann ja eigentlich jeder benutzen.

Das ist richtig, es ist ein frei verfügbares und sehr mächtiges Werkzeug. Allerdings muss man damit auch umgehen können, denn wenn man in ein paar Millionen Netzwerkpaketen genau die 10 finden muss, die das Problem verursachen, hilft blosses Durchsehen der Pakete nicht und dauert viel zu lange. Und gerade in der Netzwerkanalyse ist Erfahrung ungeheuer wichtig, um uninteressante Problemmeldungen vom echten Problem unterscheiden zu können.

Wie messen Sie, wenn Sie das Auftreten der Störung nicht an einem bestimmten Zeitpunkt festmachen können?

In so einem Fall wird es aufwendig, weil wir die Messungen teilweise tagelang laufen lassen müssen, und das in den meisten komplexeren Fällen mit mehreren Messgeräten gleichzeitig.

Wie gehen Sie in einem solchen Fall vor?

Wenn der Kunde eigene Geräte hat, macht er die Messungen oft selbst. Das hängt auch von den Netzwerktechnikern beim Kunden ab. Manchmal wissen sie, wie sie messen müssen, können aber die Ergebnisse nicht auswerten. Falls sie keine eigenen Geräte haben oder die Messung nicht selbst planen können, fahren wir hin, installieren die Messgeräte und lassen sie dort laufen. Nach ein paar Tagen kommen wir wieder, um die Auswertung zu machen.

Wie lange dauert es im Durchschnitt, um ein Problem zu lösen?

Wenn das Problem reproduzierbar ist, dauert es meistens ein bis zwei Tage, da man meistens schnell Zusammenhänge erkennt. Die nicht reproduzierbaren Probleme nehmen viel mehr Zeit in Anspruch, eine Woche ist da schon fast das Minimum. Das längste, das wir je hatten, waren 60 Personentage, bei einer Schweizer Bank. Wir waren zu dritt und mussten eine Multi-Tier Applikation in einem sehr komplexen Netzwerk mit virtuellen Servern, SSL-Verschlüsselung, Loadbalancern und NAT-Gateways analysieren. Das war schon sehr aufwendig. Es kamen sehr viele Messpunkte zusammen und wir mussten uns durch ungefähr ein Terabyte an Messdaten arbeiten, was mehrere Millionen bis Milliarden Pakete ausmacht. Der Fehler lag dann schliesslich bei der Software. Wir haben daraufhin Vorschläge gemacht, wie man diese verbessern und wie man unperformante Netzwerkkommunikation vermeiden kann.

Können Sie allen Ihren Kunden helfen?

Normalerweise schon. Es gibt aber Fälle, in denen wir einen Auftrag ablehnen. Nämlich dann, wenn Kunden eigentlich nur eine Art Kabeltest machen wollen, um herauszufinden, ob ihr Netzwerk vom Elektrotechniker gut aufgebaut wurde. So etwas machen wir nicht.

Gibt es Fälle, die für Sie "unlösbar" sind?

Ja, wenn das Protokoll proprietär oder verschlüsselt ist, kann man es oft nicht tief genug entziffern. Die Remote-Desktop-Protokolle von Citrix und von Microsoft zum Beispiel sind nicht öffentlich dokumentiert, so dass sich die Auswertung dann auf die Netzwerk-Layer einschliesslich des Transmission Control Protocols erstreckt. Das reicht allerdings glücklicherweise in vielen Fällen schon, um eine Aussage machen zu können. Protokolle wie etwa das Server-Message-Block-Protokoll, kurz SMB, hingegen sind inzwischen gut und öffentlich dokumentiert, da geht es einfacher. Ansonsten kann es manchmal auch passieren, dass man nur die Aussage machen kann, dass das Netzwerk mit Sicherheit nicht das Problem ist. Damit weiss der Kunde immerhin, dass er sich auf andere Bereiche konzentrieren kann.

Worauf sollte man beim Aufbau von Netzwerken achten, um Probleme zu vermeiden?

Es gibt weit verbreitete Fehler, die man manchmal schon fast erahnt, wenn der Kunde das Problem beschreibt. Beispielsweise wenn ein Kunde erwähnt, dass sein Netzwerk immer langsamer wird, bis es ganz stehenbleibt und dann auf einmal wieder läuft. In so einem Fall wissen wir, dass der Spanning-Tree-Algorithmus eine häufige Ursache ist. Es gibt mittlerweile aber nur noch wenige unserer Kunden, die noch dieses in die Jahre gekommene Protokoll benutzen. Stattdessen werden Link Aggregation und andere Techniken als Alternative eingesetzt. Wenn die Verkabelung als Ursache des Problems erkannt wird, muss die Strukturierung des Netzwerkes verbessert werden, um die Geschwindigkeits- und Verbindungsprobleme zu lösen. Solche Probleme kommen allerdings meist eher bei kleineren Firmen mit nicht so erfahrenen Netzwerkern vor.

Haben Sie noch ein anderes Beispiel für ein typisches Netzwerkproblem?

Ja. Wenn der Kunde sagt, das Netzwerk sei langsam, aber man sieht, dass eines von zwei Systemen, das mit dem anderen kommuniziert, überlastet ist. Dies kann ein Problem auf einem überlasteten Server sein, aber auch auf einem Client. Ein typisches Beispiel sind Thin Clients, die heutzutage häufig eingesetzt werden. Diese sind von ihrer Performance her sehr viel schwächer als Fat Clients. Wenn sich Anwender damit zum Beispiel ein aufwendiges Flash-Video ansehen wollen, führt das leicht zu Problemen. Man sieht dann an den Messdaten, dass der Client dem Server signalisiert, langsamer zu senden, damit er Zeit für die Verarbeitung hat. Im schlimmsten Fall signalisiert einer der beiden Systeme sogar einen totalen Stop. Der extremste Fall, den ich dabei bisher hatte, war ein Thin Client,­ der dem Server für eine ganze Minute gemeldet hat, dass er nicht mehr empfangen kann. Das merkt der Anwender natürlich, weil sein System für die Zeit vollständig einfriert. Und üblicherweise soll dann das Netzwerk schuld sein, was gar nicht stimmt.

Wenn man alle Probleme der IT-Infrastruktur eines Unternehmens betrachtet, wie viel Prozent davon sind auf Probleme im Netzwerk zurückzuführen?

In den fast zehn Jahren, in denen ich das bereits mache, habe ich festgestellt, dass nur in 20 Prozent der Fälle wirklich eine Komponente des Netzwerks schuld ist. Ansonsten sind es Performance-Probleme auf Client oder Server, und in ganz vielen Fällen Probleme mit der Applikation selbst.

Wo liegen denn die Hauptproblemstellen?

Im Netzwerk sind dies unter anderem Paket Shaper, das heisst Priorisierungsgeräte, manchmal auch Firewalls, die nicht richtig konfiguriert sind. Es können auch zu hohe Datenmengen von Switches und Router sein, die auf zwei Seiten mit unterschiedlichen Leitungsgeschwindigkeiten arbeiten. Dann gibt es Stress, weil der Switch die Menge an Daten, die auf der schnellen Seite reinkommt, nicht mehr schnell genug weiterleiten kann und Pakete erst buffert und schliesslich verwirft. Wenn es nicht das Netzwerk ist, sind es meist die Endgeräte, also die Hardware. Oder es sind die Applikationen selbst, weil die nicht performant genug programmiert sind. Viele Entwickler kennen sich mit Netzwerken nicht aus und programmieren umständliche Routinen. Da werden zum Beispiel oft viel zu viele Daten angefragt, die gar nicht gebraucht werden, oder sie werden immer wieder geholt statt sie zu cachen.

Sie arbeiten in der Schweiz ja mit Silvia ­Hagen, der Gründerin des Netzwerk-Beratungsunternehmens Sunny Connection zusammen. Wie funktioniert diese Zusammenarbeit im Detail?

Ja, Sunny Connection bietet unsere Dienste in der Schweiz an. Es ist meistens so, dass Silvia Hagen mit Kunden spricht und uns dazuholt, wenn sie merkt, dass es um eine Netzwerkanalyse geht. Wir besprechen dann das Problem gemeinsam und machen die Messung und die Auswertung zusammen. Sie agiert in so einem Fall als Verbindungsglied zwischen uns und den Kunden. Das ist gut, weil sie in der Schweiz ihre Basis hat. Damit entlastet sie uns vom Projektmanagement und wir können uns auf unser Kerngebiet konzentrieren.

Warum interessieren Sie sich für Netzwerke?

Netzwerke sind meist komplexe Systeme mit viel Interaktion und spannenden Abläufen. Netzwerkanalyse ist dabei ein nützliches Werkzeug, um diese Abläufe sichtbar zu machen und zu verstehen. Sie ist dabei aber nicht nur für die Verbesserung der Performance geeignet, sondern auch um Angriffszenarien zu erkennen, zu analysieren, und abzuwenden. Und Angriffe nehmen in der heutigen Zeit ja immer mehr zu, wobei es sehr schwierig sein kann, Angriffe von normalem Datenverkehr zu unterscheiden

Was fasziniert Sie an Ihrer Arbeit?

Grundsätzlich fasziniert es mich, bis ins Detail sehen zu können, was hinter den Kulissen passiert, und zu sehen, was die Geräte genau machen. Ich sehe so zum Beispiel, was mein Webbrowser macht, um eine Webseite öffnen zu können. Denn: Pakete lügen nicht. Wenn ich richtig an der richtigen Stelle zur richtigen Zeit messe, sehe ich genau, was passiert.

Was frustriert Sie an Ihrer Arbeit?

Frustrierend ist, wenn man ein Problem in einem Gerät oder einer Software entdeckt und die Hersteller das dann abstreiten, was übrigens fast der Normalfall ist. Bei einem anderen Hersteller haben wir einmal ein Problem in seiner Software entdeckt, was er auch zugegeben hat. Allerdings konnte er es nicht lösen, weil er keine Entwickler mit dem nötigen Know-how mehr hatte. Da kann man nichts mehr machen.

Sie arbeiten jetzt seit zehn Jahren in der Netzwerkanalyse. Was haben Sie vorher ­gemacht?

Ich habe eine Ausbildung als Fachinformatiker und habe vorher für eine Datenbankfirma gearbeitet sowie Computerspiele ins Deutsche übersetzt.

Was möchten Sie in Zukunft noch tun?

Ich möchte weiterhin in der Netzwerkanalyse arbeiten. Mich interessiert dabei besonders der Security-Bereich.