Gegenstand der Tester-Neugierde war diesmal ein komplettes Szenario, wie es in der Netzwerkpraxis häufig vorkommt (Bild 1): Die Datenströme werden im Testgerät (Netcom Smartbits) erzeugt und auf einen Workgroup-Switch gegeben. Von dort laufen sie über einen Gigabit-Uplink auf den Gigabit-Switch, der in diesem System den Backbone verkörpert. Dieser reicht die Daten seinerseits an einen zweiten Workgroup-Switch weiter. Das geschieht ebenfalls über einen Uplink, der in die-sem Fall natürlich besser "Downlink" heißen würde. Von dort gelangen sie zurück zum Meßgerät. Selbstverständlich bildet die Datenverbindung in diesem Mininetz keine Einbahnstraße, die Bits fließen in Gegenrichtung genauso. Weil in der Praxis solche Unternehmensnetze auch häufig aus einer Hand stammen, stellten auch wir unsere Konfiguration aus Geräten eines einzelnen Herstellers zusammen.
Für den Backbone wählten wir einen muskelbepackten Gigabit-Switch der Enterprise-Klasse, den "Smartswitch Router 8000" des US-Herstellers Cabletron. Die Typenbezeichnung deutet an, daß die Maschine nicht nur als Switch für die physikalische Ebene fungiert, sondern auch Routing und Layer-4-Switching beherrscht. Dem konnten wir in diesem Rahmen allerdings nicht auf den Grund gehen; unsere Tests beschränkten sich auf die beiden unteren OSI-Ebenen. Allerdings haben wir uns vorgenommen, zu einem späteren Zeitpunkt auch die höheren Schichten einer genaueren Betrachtung zu unterziehen.
Bei den beiden Workgroup-Switches, die dem Backbone-Switch zu-arbeiten, handelt es sich um identische Geräte des Typs "Smartswitch Router 2000", ebenfalls aus dem Hause Cabletron. Dieses Modell ist seit August vergangenen Jahres am Markt, der 8000er seit knapp einem Jahr. Die Anordnung, bestehend aus den beiden 2000ern und dem 8000er Switch, wurde während der gesamten Untersuchungen soweit sinnvoll als einheitliches Ganzes getestet. Die wichtigsten Erhebungen dienten der Erfassung des Durchsatzes, der Latenzzeit und der Korrektheit der Übertragung. Weitere Messungen beleuchteten die Fähigkeit der Geräte, Daten zwischenzupuffern ("Back-to-Back"- Test) und die relevanten Standards einzuhalten.
Kaum ein Haar in der Suppe
Um das Ergebnis gleich vorwegzunehmen: Den Cabletron-Konstrukteuren ist mit den getesteten Geräten ein großer Wurf gelungen. In fast allen Disziplinen schneiden die Switch-Router optimal ab, und es bedarf schon einer ausgeprägten Akribie, vielleicht gar einer gewissen Portion Haarspalterei, um den Testkandidaten überhaupt irgendwelche Schwächen nachzuweisen.
So beim ersten und wichtigsten Test, dem Durchsatz. Dabei wird jeweils ein Datenstrom von einem Port A zu einem Port B gesendet. Bei der Messung werden immer fünf Portpaare gleichzeitig mit den Datenströmen belastet, jeweils in den Betriebsarten Halbduplex (Ports senden und empfangen wechselweise) und Vollduplex (Ports senden und empfangen gleichzeitig). Die Meßergebnisse sind für alle Portpaare und Betriebsarten identisch, der theoretisch maximal mögliche Durchsatz wird in allen Fällen erreicht. Dieser Durchsatz wird in Frames pro Sekunde angegeben; wie hoch die maximale Leistung ist, hängt von der Paketlänge ab. Beträgt diese beispielsweise 64 Byte, so kann ein Switch schon rein theoretisch maximal 148 810 Pakete pro Sekunde und Port durchschalten. Sendet die Applikation Datenpakete mit dem in der Ethernet-Welt größten zulässigen Volumen von 1518 Byte, so beläuft sich das theoretische Maximum auf 8130 Pakete in jeder Sekunde. Die getestete Konfiguration zeigt hier ein absolut untadeliges Verhalten: Beim Transport von 1518-Byte-Paketen reicht sie 8127 Pakete pro Sekunde durch das Kabel, nur ganz minimal weniger als die Mathematik es erlaubt. Und bei kleineren Paketen erreicht sie gar dieses theoretische Maximum.
Ein Switch, der alle ihm anvertrauten Daten unbeschadet abliefert, läßt vermuten, daß er keine Pakete verliert. Um das zu überprüfen, sehen die Normen RFC 1242 und RFC 1944, eine spezielle Prozedur vor. Bei diesem "Packet Loss Rate Test" wird ein konstanter Datenstrom auf den Prüfling gegeben und gezählt, wie viele abgeschickte Pakete verlorengegangen sind. Wie aufgrund der Durchsatzmessungen zu erwarten, kamen alle Pakete an: Null Fehler.
Diese Messung läßt sich variieren: Senden beispielsweise mehrere Eingangsports auf einen Ausgangsport, so tritt dort eine entsprechend höhere Last auf. Wir ließen zehn Ports mit jeweils zehn Prozent der Vollast auf einen Ausgangsport senden, so daß letzterer an seine Grenze geriet. Auch hier war das Ergebnis nahezu optimal, lediglich bei den Framegrößen 64 Byte und 256 Byte kam es zu Paketverlusten. Die hielten sich jedoch in Grenzen: Im schlimmsten Fall betrugen sie 0,058 Prozent. Eine verschärfte Variante ist der "X-Stream-Test". Hierbei sendet jeder Port mit zehn Prozent seiner Kapazität Daten an zehn andere Ports gleichzeitig. Logischerweise summiert sich dabei die Auslastung auf der Empfangsseite an jedem Port auf 100 Prozent - zusätzlich zu der zehnprozentigen Last durch die Aussendung der Daten. Entsprechend stark wird die Switchmatrix der Geräte belastet. Bei dieser Messung traten überhaupt nur dann Probleme auf, wenn die Daten in die kleinste mögliche Paketgröße (64 Byte) portioniert wurden. Die Verlustrate betrug dann vernachlässigbare 0,21 Prozent. Wenn wir die Anzahl der beteiligten Ports auf neun reduzierten, kamen gar alle Frames heil auf der anderen Seite an.
Weiche Knie bei voller Last
Ein drittes wichtiges Leistungskriterium bei Netzwerkequipment ist die Latenzzeit. Das ist die Zeit, die zwischen dem Eintreffen des ersten Bits eines Datenpakets an einem Eingangsport und dem Eintreffen des letzten Bits desselben Pakets am Ausgangsport vergeht. Neben dem absoluten Wert der Latenzzeit ist auch seine Streuung interessant. Wichtig sind diese beiden Größen für die Übermittlung von Multimediadaten. Dazu zählen auch Telefongespräche über IP-Netze. Auch in dieser Disziplin zeigten unsere Messungen gute Resultate. Besonders positiv fiel uns auf, daß alle pro Durchgang gemessenen Werte dicht beieinander lagen, also nicht über einen mehr oder weniger breiten Bereich streuten. Dies läßt auf eine solide hardwaretchnische Implementierung der Switch Fabric schließen.
Auch bei steigender Last bleiben die Latenzzeiten weitgehend konstant. Dies gilt allerdings nur bis in den Bereich von etwa 90 Prozent der Vollast. Und damit sind wir bei der einzigen Schwäche, die sich die Cabletron-Switches in unserem Test leisteten: Nähert sich die Last dem Grenzbereich, so steigen die Latenzzeiten recht deutlich an. Allerdings: Man mußte den Lastgenerator schon ziemlich nahe an die 100 Prozent heranregeln, damit unsere Testkandidaten weiche Knie bekamen (Bild 4).
Manche Switches tendieren bei Vollast auf einem Port dazu, auch auf anderen, nicht ausgelasteten Ports Daten zu "vergessen"; Fachleute sprechen hier von "Head-of-Line-Blocking" (HOLB). Der hierfür zuständige Test ist in der Norm RFC 2285 beschrieben. Ergebnis: Die Kandidaten hatten mit dieser Art von Überlast keinerlei Probleme. Auch durch das Bombardement mit fehlerhaften Datenframes war das Trio nicht aus der Ruhe zu bringen; es verwarf zuverlässig und vollständig alle "illegalen" Datenpakete. Last, but not least quälten wir die Anordnung, indem wir die Zeit zwischen zwei aufeinanderfolgenden Datenpaketen bis auf das zulässige Minimum und dann noch weiter verkürzten. Dieses Minimum heißt Interframe-Gap; es beträgt bei Standard-Ethernet 9,6 µs, bei Fast-Ethernet 960 ns und bei Gigabit-Ethernet 96 ns. Die Switches erwiesen sich auch hier als sattelfest - bis zum Standard-Minimum waren sie nicht zu erschüttern. Große Reserven für noch kürzere Interframe-Gaps wiesen sie allerdings nicht auf. Ein Problem muß man darin nicht unbedingt erblicken, denn keine normale Ethernet-Karte sendet in kleineren als von der Norm vorgesehenen Zeitabständen. Aus diesem Grund kommen kürzere Frame-Abstände in der Praxis so gut wie nicht vor.
Kurzes Fazit: Das Cabletron-Trio erwies sich als ausgesprochen standfest. Die geringfügigen Schwächen im Bereich der Latenzzeiten können den positiven Eindruck nicht schmälern. Allerdings sollte sich der Leser vor Augen halten, daß alle diese Aussagen sich nur auf den OSI-Layer 2 beziehen. Das Bild könnte sich ändern, wenn auch die höheren Protokollebenen einbezogen werden. gateway wird am Ball bleiben und diese Aspekte zu einem späteren Zeitpunkt unter die Lupe zu nehmen.