Aktuelle LAN-Switches müssen die Anforderungen von IP-Telefonie, Video-Übertragung und klassischer Datenübertragung erfüllen. Dafür, dass sie diesem modernen Dreikampf gewachsen sind, sorgen die Hersteller mit Gigabit-Ethernet- und 10-Gigabit-Ethernet-Technologie, Datenpriorisierungsmechanismen und Bandbereitenmanagement-Funktionalität. – Zumindest auf dem Papier. Ob aktuelle LAN-Switches diesen Dreikampf auch in der Realität bestehen, musste eine Auswahl aktueller Geräte in unseren Real-World Labs an der FH Stralsund beweisen. Unsere Testspezifikation haben wir bereits im vergangenen Herbst an die einschlägigen Hersteller geschickt und diese eingeladen, an unserem Vergleichstest in unseren

Real-World Labs an der FH Stralsund teilzunehmen. Auf den Messen Systems und Exponet haben wir dann den einschlägigen Herstellern unser Testprojekt erläutert. Neben 3Com, Alcatel, Allied Telesyn und D-Link waren unter anderem auch Cisco, Extreme Networks, Hewlett-Packard und Nortel an einer Teilnahme interessiert. Als dann nach fast dreimonatiger Vorlaufphase unsere Testtermine anstanden, gelang es mit Ausnahme der vier erstgenannten den Herstellern nicht, innerhalb der gesetzten Frist ein funktionierendes System in unseren Labs vorzuführen. Die Gründe hierfür reichen von »mangelnden Ressourcen« bis hin zu noch nicht fertig gestellten neuen Modellen. Das erste Testfeld der diesjährigen Switch-Testserie bildeten letztendlich 3Coms »SuperStack 4 Switch 5500G-EI 24-Port«, Alcatels »OmniSwitch 9700«, Allied Telesyns »9924TS« und D-Links »DXS-3350SR«. Eine zweite Teststaffel ist schon in Vorbereitung. In der Warteschleife befinden sich unter anderem Cisco, Hewlett-Packard, Huawei und SMC. Es bleibt also spannend.

Die Network Computing Musterfirma

Im Mittelpunkt unserer Testspezifikation steht die Network Computing Musterfirma. Diese ist ein innovatives Unternehmen, das im Bereich der Automobilzubehörindustrie tätig ist. Die Musterfirma verteilt sich auf mehrere Standorte:

• Firmenhauptsitz in Stralsund mit den Abteilungen
• Forschung & Entwicklung (250 PC-Arbeitsplätze),
• Marketing (150 PC-Arbeitsplätze),
• Sales (200 PC-Arbeitsplätze),
• Verwaltung (80 PC-Arbeitsplätze),
• Rechenzentrum (Serverfarm, SAN, Administration, 5 PC-Arbeitsplätze) sowie
• Geschäftsführung (20 PC-Arbeitsplätze).

Produktionsstandort in Rostock mit

• Produktion in vier Betrieben mit insgesamt 300 PC-Arbeitsplätzen und
• Backup-Rechenzentrum (Serverfarm, SAN, Administration, fünf PC-Arbeitsplätze).

Hinzu kommen vier Niederlassungen in Frankfurt, Berlin, München und Passau mit jeweils 30 PC-Arbeitsplätzen und zwei Auslandsniederlassungen in New York und Hongkong mit jeweils 40 PC-Arbeitsplätzen.

Die IT-Verantwortlichen der Network Computing-Musterfirma möchten alle Standorte sowie Partnerfirmen in einem Intranet auf IP-Basis integrieren. Neben den klassischen Datenanwendungen sollen über dieses Intranet auch Telefonie und Videoübertragung realisiert werden. Dabei soll das Unternehmensnetz in Segmente unterteilt werden, die den verschiedenen Abteilungen an den Hauptstandorten beziehungsweise den einzelnen Niederlassungen zugeordnet werden sollen. Die Segmente sollen hochperformant miteinander verbunden aber zugleich auch durch die entsprechenden Sicherheitstechnologien gegeneinander abgesichert werden.

Die Ausgangssituation

Die Network Computing-Musterfirma möchte neben den klassischen Datenapplikationen und Voice-over-IP weitere Real-Time-Applikationen in ihr Unternehmensnetz zunächst am Firmenhauptsitz integrieren. Ein geeigneter Vergleichstest soll evaluieren, welche Switches für diese Aufgaben auch unter entsprechender Last geeignet sind.

Eine intelligente Ausnutzung der in einem konvergenten Netzwerk vorhandenen Bandbreiten und die Garantie für angemessene Service-Qualitäten der einzelnen Anwendungen setzt eine durchgängige Switching-Policy voraus, die nicht nur blind bestimmten Daten die Vorfahrt anderen gegenüber einräumt, sondern ein sinnvolles Bandbreitenmanagement für das gesamte Netzwerk realisiert. So ist es möglich, bei auftretenden Überlasten die Störungen im Betrieb gering und lokal begrenzt zu halten. Aus diesem Grund haben wir für unseren Vergleichstest Switches gefordert, die CoS-Queuing-Mechanismen sowie Bandbreitenmanagement unterstützen und damit erlauben, nicht nur bestimmten Applikationen Vorfahrt anderen gegenüber einzuräumen, sondern auch durch die Einräumung von Mindestbandbreiten die Service-Qualität niedriger Prioritäten und somit das Funktionieren der entsprechenden Applikationen zu garantieren und dafür zu sorgen, dass Dienste nicht mehr senden als vorgesehen.

Die Tests sollten die verschiedenen CoS-Queuing-Mechanismen wie Strict-Priority-Queuing, Weighted-Fair-Queuing oder Weighted-Round-Robin auf ihre Eignung für das geplante Szenario untersucht werden.

Folgende Dienste sollen im LAN integriert werden:

• Videokonferenzen (Video-over-IP, bidirektional, unicast),
• Videodistribution (Multicast-Betrieb),
• Voice-over-IP (Call-Center),
• SAP-Anwendungsdaten,
• CAD- und CAM-Anwendungsdaten sowie
• übrige Datenanwendungen und Updates.

Die Marketing-Abteilung produziert auch Filme zu Werbungs- und Schulungszwecken und hat ein großes Videoarchiv. Weiterhin unterhält die Marketing-Abteilung ein Callcenter für das Direktmarketing. Die Abteilungen Forschung & Entwicklung wie auch die Produktion arbeiten mit CAD- und CAM-Applikationen. Der Fertigungsbereich soll auf Industrial-Ethernet umgerüstet und in das Intranet integriert werden.

Um die möglichst absolute Störungsfreiheit der Kommunikations- und Arbeitsprozesse im Unternehmen zu garantieren, ist eine mindestens vierstufige Daten-Priorisierung sowie eine intelligente Queuing-Policy erforderlich. Gefordert ist für die Edge-Switches neben der Datenpriorisierung ein intelligentes Bandbreitenmanagement, das es ermöglicht, von vorneherein eine Überlastung des Backbones zu vermeiden.

Daraus ergeben sich folgende Anforderungen an die Teststellungen:

• Layer-3-Gigabit-Ethernet-Switch,
• mindestens 24 Gigabit-Ethernet-Kupfer-Ports (Steckertyp RJ45),
• mindestens zwei 10-Gigabit-Ethernet-Uplink-Ports (Multimode-Fibre, Steckertyp LC),
• Datenpriorisierung nach IEEE 802.1p/Q auf Layer-2,
• Diffserv-Datenpriorisierung nach RFC 2474 oder
• Type-of-Service-Datenpriorisierung nach RFC 791 und/oder 1349 auf Layer-3,
• mindestens zwei CoS-Queuing-Mechanismen, wie Strict-Prioriry-Queuing, Weighted-Fair-Queuing oder Weighted-Round-Robin, die softwareseitig konfiguriert werden können,
• Multicast (IGMP-Snooping).

Testparameter und Verfahren

Als Testverfahren haben wir RFC 2544 (One-to-Many, Many-to-One, Many-to-Many) festgelegt. Gemessen werden hierbei Performance, Packet-Loss, Latency und Jitter. Analysiert wird dann das unterschiedliche Verhalten in den verschiedenen CoS-Queuing-Modi.

Bei der Priorisierung mit Bandbreitenmanagement sind zwei grundsätzlich unterschiedliche Verhaltensweisen der Switches zu unterscheiden: Rate-Limited-Switching und Weighted-Switching. Beim Rate-Limited-Switching garantiert der Switch den entsprechend konfigurierbaren Bandbreitenanteilen der einzelnen Prioritäten nicht nur eine Mindestbandbreite, er »deckelt« quasi auch die Durchsätze, indem er übrige Bandbreiten, die ein Dienst, dem sie zur Verfügung stehen, derzeit nicht benötigt, auch nicht für andere Dienste verfügbar macht. Eine solche Funktionalität ist insbesondere für den Edge-Bereich je nach Policy unverzichtbar, weil es so möglich ist, der Entstehung von Überlasten bereits in der Netzwerkperipherie vorzubeugen. Switches im Core-Bereich sollten dagegen die Mindestbandbreiten für die ihnen zugeordneten Dienste reservieren. Wenn diese Dienste die ihnen zustehenden Bandbreiten aber nicht benötigen, dann sollten andere Dienste freie Bandbreiten über die ihnen selbst zustehenden hinaus ruhig nutzen können. Ansonsten wird die insgesamt im Core-Bereich zur Verfügung stehende Bandbreite unnötig verringert. Ein solches Verhalten kann aber auch im Rahmen der Policy erwünscht sein. Um den verschiedenen Mechanismen gerecht zu werden, haben wir lediglich das Verhalten der Systeme bei Volllast gewertet, da dann unabhängig vom verwandten Mechanismus die gleichen Maximalbandbreiten für die jeweilige Priorität eingehalten werden müssten.

Messtechnisch sind die einzelnen CoS-Queuing-Verfahren zum Teil schlecht auseinander zu halten, da sie unter entsprechenden Lasten zu einem ähnlichen Verhalten der Systeme führen. Dieser Fakt ist aber auch nicht weiter problematisch, da für einen möglichst störungsfreien Netzwerkbetrieb das konkrete Switching-Verhalten der Systeme und nicht die dahinter stehenden Mechanismen und Theorien entscheidend sind. Konkret haben wir zwei Policies isoliert und messtechnisch untersucht. Zunächst sollten die Switches eine Strict-Priority-Policy umsetzen. Hier kam es vor allem darauf an, dass die Daten der höchsten Priorität unter allen Umständen weitergeleitet werden sollten. Danach haben wir mit Bandbreitenmanagement gearbeitet. Hier sollten die Systeme den Datenströmen aller vier Prioritäten Maximalbandbreiten garantieren, um einem Zusammenbruch der Anwendungen niedrigerer Prioritäten bei Überlast vorzubeugen.

Aus den Ergebnissen von Performance-Messungen wie den von uns durchgeführten ist gut zu erkennen, ob, und wenn ja, in welchem Bereich, das jeweilige System Schwierigkeiten hat. Arbeitet der so belastete Switch korrekt, muss er in allen Fällen gemäß den »Class-of-Service-Regeln« die niedrig priorisierten Daten zu Gunsten der höher priorisierten verwerfen. Ein Datenverlust in der höchsten Priorität dürfte bei allen unseren Strict-Priority-Tests theoretisch nicht vorkommen, nur so würde der jeweilige Switch die fehlerfreie Übertragung der am höchsten priorisierten Echtzeitapplikation, beispielsweise einer Video-Konferenz, garantieren.

Für die Switches sind pro Zeiteinheit um so mehr Header-Informationen auszuwerten, um so kleiner die einzelnen Datenrahmen sind. Ein Switch wird also zuerst Probleme mit 64-Byte-Datenströmen bekommen, wenn er bei der internen Verarbeitungsgeschwindigkeit an seine Grenzen stößt. Bei großen Datenrahmen können je nach Design dagegen schneller Probleme mit dem Speichermanagement beziehungsweise mit der Größe des überhaupt verfügbaren Pufferspeichers entstehen.

Die Tests im Detail

Durchgeführt haben wir insgesamt vier Class-of-Service-Testreihen jeweils mit Layer-3-Priorisierung und abwechselnd unter Verwendung der Priorisierungsmechanismen Strict-Priority und Bandbreitenmanagement. In den ersten beiden Test-Setups haben wir die Datenverlustraten sowie Latency und Jitter bei der Datenkommunikation zwischen den Gigabit-Ethernet-Ports untereinander auf einem Switch untersucht. Dabei haben wir in der ersten Testreihe die Switches im Multicast-Modus und in der zweiten Testreihe im Unicast-Modus betrieben. Bei der dritten Testreihe haben wir dann ein Uplink-Szenario aufgebaut. Hierbei sendeten die Gigabit-Ethernet-Ports auf die 10-Gigabit-Ethernet-Ports. In der vierten Testreihe hatte das entsprechende Downlink-Szenario von den 10-Gigabit-Ethernet-Ports auf die Gigabit-Ethernet-Ports zum Thema. Die Ergebnisse der ersten beiden Testreihen stellen wir im vorliegenden Artikel vor. Die übrigen Resultate folgen in einer der kommenden Ausgaben von Network Computing.

Testreihe Gigabit-Ethernet Multicast

In der ersten Testreihe unserer Class-of-Service-Testsuite haben wir mit unserem Lastgenerator auf vier Gigabit-Ethernet-Ports parallel Datenströme gesendet. Jeder dieser Ports hatte nur einen Datenstrom zu verarbeiten, so dass insgesamt vier Ströme unterschiedlicher Priorität anlagen. Für die Festlegung der Prioritäten haben wir die DSCP-Werte 8, 24, 40 und 56 verwendet, wobei die höchste Priorität 56 und die niedrigste 8 entspricht. Die Datenströme dieser einzelnen Prioritäten wurden dann in die jeweiligen Hardware-Queues geleitet.

Die 20 übrigen Gigabit-Etherent-Ports abonnierten im Multicast-Modus alle vier Datenströme, so dass bei Volllast an den Eingangsports eine vierfache Überlast an 20 Ausgangsports anlag, was einer Gesamtlast des Switches von 80 GBit/s entspricht. In nacheinander folgenden Messungen hat der Spirent-Lastgenerator Datenströme bestehend aus Datenrahmen von je 64, 128, 256, 512, 1024, 1280 und 1518 Byte erzeugt. Alle Messungen haben wir zunächst mit Burst-Size 1 und dann mit Burst-Size 100 durchgeführt.

Beträgt die Burst-Size einen Frame, bedeutet dies, dass der Lastgenerator die erzeugte Last kontinuierlich auf der Zeitachse verteilt sendet. Der belastete Switch kann so die erzeugte Last kontinuierlich abarbeiten. Im Betrieb mit einer Burst-Size von 100 Frames sendet der Lastgenerator dagegen mit Leitungsgeschwindigkeit 100 Frames nacheinander. Dann folgt eine Pause, so dass der Generator im Mittel die jeweils konfigurierte Durchsatzleistung erzeugt. Während der Sendephase muss der belastete Switch die Datenströme im Pufferspeicher zwischenspeichern und in der folgenden Pause abarbeiten.

Die Last an den Eingangsports startete jeweils bei 25 Prozent und wurde dann in entsprechenden Schritten auf 100 Prozent erhöht. Das bedeutete an den Ausgangsports eine Last zwischen 100 und 400 Prozent – dabei waren die Lastanteile für die vier Prioritäten immer gleich groß, so dass die Daten der verschiedenen Prioritäten immer in einem gleichen Verhältnis zueinander standen. Die einzelnen Messreihen haben wir jeweils für die unterschiedlichen Priorisierungstechniken auf Layer-3 mit einer Burst-Size von 1 und von 100 Frames durchgeführt.

Bei den Messungen mit Strict-Priority sollten die Switches folgendes idealtypisches Verhalten zeigen: Bei 100 Prozent Last sollten alle Datenströme ungehindert weiter geleitet werden. Bei zunehmender Last sollten die Switches dann jeweils möglichst viele Daten der niedrigsten Prioritäten verlieren und möglichst viele Daten der hohen Prioritäten unbeschadet passieren lassen. Bei vierfacher Überlast sollte der jeweilige Switch folglich alle Daten mit Ausnahme denen der höchsten Priorität verwerfen.

Für die Tests mit Bandbreitenmanagement haben wir eine einfache Policy definiert, die bestimmten Applikationen Bandbreiten reservieren sollte. Als Maximalbandbreiten haben wir für die höchste Priorität DSCP-Wert 56 10 Prozent, für DSCP-Wert 40 20 Prozent, für DSCP-Wert 24 30 Prozent und für DSCP-Wert 8 40 Prozent gefordert. Ansonsten entsprachen der Testaufbau und -durchführung dem mit Strict-Priority wie oben.

Aus den Ergebnissen dieser Messungen ist dann gut zu erkennen, ob, und wenn ja, in welchem Bereich, das jeweilige System Schwierigkeiten hat. Arbeitet der so belastete Switch korrekt, muss er in allen Fällen gemäß den »Class-of-Service-Regeln« die niedrig priorisierten Daten zugunsten der hoch priorisierten verwerfen. Ein Datenverlust in der höchsten Priorität dürfte bei allen Tests theoretisch nicht vorkommen, nur so würde der jeweilige Switch die fehlerfreie Übertragung der am höchsten priorisierten Echtzeitapplikation, beispielsweise einer Video-Konferenz, garantieren.

Für die Switches sind pro Zeiteinheit um so mehr Header-Informationen auszuwerten, um so kleiner die einzelnen Datenrahmen sind. Ein Switch wird also zuerst Probleme mit 64-Byte-Datenströmen bekommen, wenn er bei der internen Verarbeitungsgeschwindigkeit an seine Grenzen stößt. Bei großen Datenrahmen können je nach Design dagegen schneller Probleme mit dem Speichermanagement entstehen.

Hat ein Switch Probleme bei unseren Messungen mit Strict-Priority und einer Burst-Size von 100 Frames, sind entweder die Pufferspeicher zu knapp bemessen oder es besteht ein Problem mit dem Speichermanagement. Treten Probleme bei den Messungen mit einer Burst-Size von einem Frame auf, ist von grundlegenden funktionalen Mängeln auszugehen. Gleiches gilt bei Problemen mit unsauber arbeitendem Bandbreitenamanagement.

Auf Grund ihrer Bedeutung für die Übertragungsqualität haben wir das Datenrahmenverlustverhalten als primäres K.O.-Kriterium definiert. Die Parameter Latency und Jitter sind gegebenenfalls für die genauere Diagnose und weitere Analyse im Einzelfall wichtig. Sind jedoch die Datenverlustraten von Hause aus schon zu hoch, können gute Werte für Latency und Jitter die Sprachqualität auch nicht mehr retten. Diese Parameter ziehen wir folglich erst dann hinzu, wenn die Ergebnisse der Paketverlustmessung unkritisch sind.

3Coms Superstack-4- Switch-5500G- EI-24-Port arbeitete in der Disziplin Strict-Priority unerschütterlich – so lange die Burst-Size 1 Frame betrug. Bei einer Burst-Size von 100 Frames verlor der Switch dagegen deutlich mehr Daten, als theoretisch erforderlich gewesen wäre. Dabei waren die ungebührlichen Datenverluste um so höher, je größer die verwendeten Datenrahmen waren. Bei der Messung mit 100 Prozent Last, als noch gar keine Datenverluste erforderlich gewesen wären, verlor der Superstack bei der Messung mit 128-Byte-Frames schon im Durchschnitt über alle Prioritäten 21,8 Prozent. Verwendeten wir 1518-Byte-Frames, verwarf das System im Durchschnitt über 66 Prozent aller Daten. Für die Prioritäten 1 bis 5 bedeutet das Datenverluste von gut 88 Prozent. Allerdings gelang es dem 3Com-Switch, die höchste Priorität immer frei von Datenverlusten zu halten. Und das auch bei Volllast. Die Disziplin Bandbreitenmanagement beherrschte der Superstack dagegen nahezu perfekt. Sowohl bei den Messungen mit einer Burst-Size von 1 wie auch von 100 Frames blieben die Abweichungen von den geforderten Bandbreiten deutlich unter der 1-Prozent-Marke.

Auch Alcatels Omniswitch-9700 beherrschte die Disziplin Strict-Priority mit einer Burst-Size von einem Frame perfekt. Überfordert zeigte sich auch dieser Switch dann beim Test mit einer Burst-Size von 100 Frames. Mit durchschnittlichen Verlusten bei 100 Prozent zwischen 18 Prozent bei der Messung mit 512-Byte-Frames und über 56 Prozent bei den größten Frames verhielt er sich ähnlich wie der 3Com-Switch zuvor. Und wie dieser schaffte es auch der Alcatel-Switch, die höchste Priorität immer verlustfrei zu halten. Dies ging allerdings zu Lasten der zweithöchsten, bei der maximale Verlustraten von 75 Prozent zu verzeichnen waren, obwohl das System diese Daten unbeschadet hätte passieren lassen sollen. In der Disziplin Bandbreitenmanagement verhielt sich der Omniswitch unabhängig von der Burst-Size dagegen mustergültig. Auch hier blieben die Abweichungen vom Sollwert deutlich unter der 1-Prozent-Marke.

Nahezu fehlerfrei arbeitete auch Allied Telesyns 9924TS bei unserem Test mit Strict-Priority. Lediglich bei Volllast und kleinen Frame-Formaten kam es zu außerplanmäßigen Datenverlusten. Verwendeten wir 64-Byte-Pakete, verwarf der Switch fast 43 Prozent der Daten in der höchsten Priorität. Dafür gingen nur gut 57 Prozent in der zweithöchsten Priorität verloren, obwohl hier ein Totalverlust zu erwarten gewesen wäre. Betrug die Frame-Größe 128 Byte, kam der Switch noch auf eine außerplanmäßige Verlustrate in der höchsten Priorität bei Volllast von gut 4 Prozent. Betrug die Burst-Size 100 Frames, kam auch der 9924TS an seine Grenzen. Schon bei 100 und 200 Prozent Last hatte er Probleme mit dem kleinsten Frame-Format. In der höchsten Priorität bedeutet das Datenverluste zwischen gut 24 Prozent bei 200 Prozent Last und rund 38 Prozent bei Volllast. Darüber hinaus leistete sich der 9924TS unter Volllast aber auch noch ungebührliche Datenverluste bei den Messungen mit großen Datenpaketen. So kam er bei der Messung mit 1518-Byte-Paketen auf gut 18 Prozent Frame-Loss in der höchsten Priorität.

Auch bei den Messungen mit Bandbreitenmanagement arbeitete der Switch von Allied Telesyn nicht so präzise wie der Mitbewerb zuvor. So betrug die durchschnittliche Abweichung vom Sollwert bei der Messung mit 64-Byte-Paketen über 9 Prozent. Mit größeren Frames kam der Switch tendenziell besser zurecht. Hier schwankten dann die durchschnittlichen Abweichungen zwischen gut 2 und 4,5 Prozent. Allerdings waren von diesen Schwankungen in erster Linie die niedrigen Prioritäten betroffen. Im Bereich der höchsten Priorität arbeitete der 9924TS relativ präzise. Dies gilt sowohl für die Messungen mit einer Burst-Size von 1 als auch für die Messungen mit einer Burst-Size von 100 Frames.

Völlig unauffällig verhielt sich D-Links DXS-3350SR bei den Messungen mit Strict-Priority und einer Burst-Size von einem Frame. Betrug die Burst-Size dagegen 100 Frames, ähnelte sein Verhalten dem des 3Com- und des Alcatel-Switches. Dabei leistete sich auch der D-Link-Switch keinerlei Ausreißer in der höchsten Priorität. In der zweithöchsten kam er dann aber schon bei 100 wie auch bei 200 Prozent Last auf Werte zwischen 22,4 Prozent bei einem Frame-Format von 512 Byte und 67 Prozent bei einem Frame-Format von 1518 Byte. Völlig unauffällig verhielt sich der DXS-3350SR dagegen bei unseren Messungen mit Bandbreitenmanagement. Hier konnten wir ihm Abweichungen vom Sollwert nur deutlich unterhalb der 1-Prozent-Marke nachweisen.

Testreihe Gigabit-Ethernet Unicast

In der zweiten Testreihe unserer Class-of-Service-Testsuite haben wir mit unserem Lastgenerator auf 16 Gigabit-Ethernet-Ports parallel Datenrahmen gesendet und diese an vier Gigabit-Ethernet-Ports adressiert. Dabei sendete jeder Input-Port vier Datenströme der vier Prioritätsklassen an jeden Output-Port. Da 16 Ports gleichzeitig sendeten betrug die Gesamtlast des Systems in diesem Unicast-Betrieb 16 GBit/s. In nacheinander folgenden Messungen hat der Spirent-Lastgenerator Datenströme bestehend aus Datenrahmen von je 64, 128, 256, 512, 1024, 1280 und 1518 Byte erzeugt. Alle Messungen haben wir zunächst mit Burst-Size 1 und dann mit Burst-Size 100 durchgeführt, um auch aussagefähige Ergebnisse in Bezug auf die Kapazität der Pufferspeicher zu erhalten. Auch hier haben wir die Priorisierungsmechanismen Stirct-Priority und Bandbreitenmanagement eingesetzt. Alle weiteren Details entsprechen der ersten Testreihe oben.

3Coms Superstack arbeitete im Strict-Priority-Modus mit einer Burst-Size von einem Frame recht unauffällig und regelkonform. Lediglich unter Volllast und bei einem Frame-Format von 1024 Byte konnten wir ihm einen ungebührlichen Datenverlust von 8,6 Prozent in der höchsten Priorität nachweisen. Deutlich mehr Probleme hatte das System dann bei unseren Messungen mit einer Burst-Size von 100 Frames. So kam der Superstack schon bei 100 Prozent Last, als noch gar keine Datenverluste erforderlich gewesen wären, auf eine durchschnittliche Verlustrate über alle Prioritäten von fast 55 Prozent. Die höchsten Verlustraten in der höchsten Priorität konnten wir dann bei 200 Prozent Last und einem Frame-Format von 1518 Byte messen. Bei der Messung mit Volllast leistete sich der Switch dann noch einen Ausreißer. Betrug das Frame-Format 1024 Byte, verlor der Switch hier gut 7 Prozent der höchstpriorisierten Daten. Die Disziplin Bandbreitenmanagement beherrschte der Superstack dann nahezu perfekt. Wie schon zuvor im Multicast-Betrieb konnten wir dem 3Com-Switch lediglich Abweichungen von den Sollwerten von deutlich unter einem Prozent nachweisen.

Auch Alcatels Omniswitch-9700 hatte keine Probleme mit dem Strict-Priority-Betrieb – so lange die Burst-Size ein Frame betrug. Arbeiteten wir mit einer Burst-Size von 100 Frames, kam auch der Omniswitch-9700 schnell an seine Grenzen. Dabei muss hervorgehoben werden, dass der Alcatel sich unter keinen Umständen Schwächen in der höchsten Priorität leistete. Hier waren durchweg keine Datenverluste zu verzeichnen. Schon bei 100 Prozent Last waren aber in den Prioritäten 1, 3 und 5 Datenverluste zwischen rund 22 Prozent bei 512 Byte-Paketen und um die 73 Prozent bei den größten Frames im Test zu verzeichnen. Im Umgang mit großen Frames zeigte der Alcatel-Switch auch bei unseren Messungen in der Disziplin Bandbreitenmanagement. So konnten wir eine durchschnittliche Abweichung von gut 6 Prozent vom Sollwert bei beiden Messungen mit 1518-Byte-Frames feststellen. Allerdings gingen diese Schwankungen zu Lasten der niedrigeren Prioritäten. Die höchste Priorität wurde auch hier besonders exakt behandelt.

Bei unseren Messungen mit Strict-Priority vermochte Allied Telesyns 9924TS zu punkten. sowohl bei unseren Messungen mit einer Burst-Size von 1 wie auch von 100 Frames leistete sich der Switch maximal ganz geringe Verluste, die deutlich unter der 1-Prozent-Grenze blieben. In der Disziplin Bandbreitenmanagement hatte der 9924TS dann wie zuvor schon bei den Multicast-Messungen Probleme mit kleinen Frames. Verwendeten wir 64-Byte-Pakete und eine Burst-Size von 1 beziehungsweise 100 Frames, betrug die durchschnittliche Abweichung gut 9 Prozent. Bei größeren Frame-Formaten arbeitete das System deutlich besser. Dabei gingen hier die unerwünschten Abweichungen in erster Linie zu Lasten der niedrigeren Prioritäten.

Perfekt arbeitete D-Links DXS-3350SR im Modus Strict-Priority mit einer Burst-Size von einem Frame. Verwendeten wir dagegen eine Burst-Size von 100 Frames, kam es auch hier zu ungebührlichen Datenverlusten. So verlor der DXS-3350SR schon bei einer Last von 100 Prozent und den größten Frames insgesamt fast 50 Prozent aller Daten, obwohl hier theoretisch noch gar keine Datenverluste erforderlich gewesen wären. Die Daten der höchsten Priorität blieben von Verlusten allerdings in allen Fälle unberührt. In der zweithöchsten Priorität waren dagegen bei der gleichen Messung fast 64 Prozent Frame-Loss festzustellen. Bei kleineren Frame-Formaten fielen die Verluste moderater aus. So kam der D-Link-Switch bei der Messung mit 100 Prozent Last und 512-Byte-Paketen noch auf eine durchschnittlichen Gesamtverlust von gut 16 Prozent. Diese verteilten sich relativ gleichmäßig auf die Prioritäten 1 bis 5. In der Disziplin Bandbreitenmanagement verhielt sich der DXS-3350SR dagegen völlig korrekt. Sowohl bei den Messungen mit einer Burst-Size von einem als auch von 100 Frames blieben die Abweichungen vom Sollwert deutlich unter einem Prozent.

Fazit

Bandbreite ist nicht alles. – Um den Faktor 10 beschleunigt haben sich die Durchsätze, die LAN-Switches der aktuellen Generation bieten. Nach wie vor nicht perfekt arbeiten sie aber, wenn es gilt, Priorisierungsmechanismen umzusetzen. Neben zum Teil nicht exakt umgesetzten CoS-Regeln sind insbesondere mangelnde Ressourcen im Puffer-Speicherbereich festzustellen. Diese werden bei unseren Messungen mit einer Burst-Size von 100 Frames deutlich. Und 100 Frames sind für Gigabit-Ethernet-Switches mit 10-Gigabit-Ethernet-Uplinks nicht mehr allzu viel. Da sind die Hersteller wohl wieder einmal davon ausgegangen, dass sie drohenden Engpässen mit »Bandbreite satt« begegnen können. Dabei füllen die neuen Switches auch ihre Pufferspeicher mit der zehnfachen Geschwindigkeit. Von daher wird es sicher für anspruchsvolle Umgebungen wie bei unserer Musterfirma sinnvoll sein, in größere Pufferspeicher zu investieren.

Prof. Dr. Bernhard G. Stütz,
dg@networkcomputing.de