Schneller schalten

Die Network-Computing-Musterfirma stand im Mittelpunkt unserer Testspezifikation. 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),
• Diffserv-Datenpriorisierung nach RFC 2474 oder
• Type-of-Service-Datenpriorisierung nach RFC 791 und/oder 1349 auf Layer-3,
• mindestens zwei CoS-Queuing-Mechanismen, darunter Strict-Prioriry-Queuing und Weighted-Fair-Queuing oder Weighted-Round-Robin, die softwareseitig konfiguriert werden können,
• Multicast (IGMP-Snooping).

Testparameter und Verfahren
In unserem standardisierten Testverfahren mussten die Switches nun unter Beweis stellen, wie performant sie wirklich in Triple-Play-Netzen arbeiten. 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.

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.

Die Tests im Detail
Durchgeführt haben wir zwei Class-of-Service-Testreihen jeweils mit Layer-3-Priorisierung und abwechselnd unter Verwendung der Priorisierungsmechanismen Strict-Priority und Bandbreitenmanagement. In den ersten beiden Testreihen haben wir die Switches im Unicast-Betrieb untersucht. Im Mittelpunkt der zweiten Testreihe stand das Verhalten der Systeme im Multicast-Betrieb. Die Ergebnisse der ersten Testreihe stehen im vorliegenden Artikel. Wie sich die Switches im Multicast-Betrieb bewährt haben erläutern wir dann in einer der folgenden Ausgaben von Network Computing.

Innerhalb der Testreihe Unicast-Betrieb haben wir die Systeme in drei Test-Setups untersucht. Zunächst haben wir die Datenverlustraten sowie Latency und Jitter bei der Datenkommunikation zwischen den Gigabit-Ethernet-Ports intern auf einem Switch untersucht. Im zweiten Test-Setup haben wir dann ein Downlink-Szenario aufgebaut. Hierbei sendeten zwei 10-Gigabit-Ethernet-Ports auf fünf Gigabit-Ethernet-Ports. Im dritten Test-Setup hatte das entsprechende Uplink-Szenario von 20 Gigabit-Ethernet-Ports auf einen 10-Gigabit-Ethernet-Port zum Thema.

Alle Messungen haben wir jeweils mit einer Burst-Size von einem und von 100 Frames 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 200 beziehungsweise 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 idealtypische Verhalten zeigen: Bei 100 Prozent Last an den Ausgangsports 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 Minimalbandbreiten haben wir für die höchste Priorität mit DSCP-Wert 56 40 Prozent, für DSCP-Wert 40 30 Prozent, für DSCP-Wert 24 20 Prozent und DSCP-Wert 8 10 Prozent festgelegt.

Aus den Ergebnissen dieser Messungen 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 hoch priorisierten verwerfen. Ein Datenverlust in der höchsten Priorität dürfte bei allen 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 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 einem unsauber arbeitenden Bandbreitenmanagement. Arbeitet der Switch im Test mit Bandbreitenmanagement, dann sollte er sich grundsätzlich durch eine höhere Burst-Size nicht beeinträchtigen lassen. Das liegt daran, dass der Switch bei korrekt arbeitendem Bandbreitenmanagement eventuelle Überlasten entsprechend der implementierten Policy verwirft.

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.

Test Unicast-intern
Im ersten Test-Setup unserer Class-of-Service-Unicast-Testreihe haben wir mit unserem Lastgenerator auf 16 Gigabit-Ethernet-Ports parallel Datenrahmen gesendet und diese an vier Gigabit-Ethernet-Ports adressiert. Dabei sendete jeder Switch-Input-Port vier Datenströme der vier Prioritätsklassen an jeden Switch-Output-Port. Da 16 Ports gleichzeitig sendeten betrug die Gesamtlast des Systems in diesem Unicast-Betrieb maximal 16 GBit/s, so dass bei Volllast an den Ausgangsports eine vierfache Überlast anlag. In nacheinander folgenden Messungen hat der Spirent-Lastgenerator Datenströme bestehend aus Datenrahmen von je 64, 256, 512, 1024 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. Wir haben dabei abwechselnd die Priorisierungsmechanismen Stirct-Priority und Bandbreitenmanagement eingesetzt. 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.

D-Links DXS-3350SR arbeitete im Strict-Priority-Betrieb mit einer Burst-Size von einem Frame mustergültig und verwarf praktisch genau so viele Frames, wie nach der jeweiligen Last und entsprechend der geforderten Policy zu erwarten war. Führten wir die gleiche Messung mit einer Burst-Size von 100 Frames durch, hatte das System allerdings deutliche Probleme. Zu gute halten kann man dem DXS-3350SR, dass er es immer schaffte, die höchste Priorität bei allen Messungen von ungebührlichen Datenverlusten frei zu halten. Dafür verlor das System aber schon bei der Messung mit 100 Prozent Last an den Ausgangsports, als theoretisch noch gar keine Datenverluste notwendig gewesen wären, bei der Messung mit dem größten Frame-Format insgesamt fast 50 und bei der Messung mit dem zweitgrößten Frame-Format noch 40 Prozent aller Daten. Mit den 64 und 256 Byte kleinen Frame-Formaten kam das D-Link-Gerät dagegen praktisch fehlerfrei zurecht. Bei steigernder Last zeigten sich die genannten Probleme noch etwas deutlicher. Erst bei Volllast war dann die Welt anscheinend wieder in Ordnung, weil die oberste Priorität immer »sauber« blieb.

Die Disziplin Bandbreitenmanagement beherrschte der D-Link-Switch dagegen ohne Fehl und Tadel. Unabhängig vom Frame-Format und der Burst-Size wich das System bei allen Messungen mit Werten von deutlich weniger als einem Prozent von den Sollwerten ab.

Auch Extreme Networks Summit-X450a-24t leistete sich bei unseren Strict-Priority-Messungen mit einer Burst-Size von einem Frame keine nennenswerten Verlustraten. Bei unseren Messungen mit einer Burst-Size von 100 Frames und großen Frame-Formaten bekam dann auch der Extreme-Switch Probleme. So verlor das Gerät schon bei 100 Prozent Last an den Ausgangsports und 1518-Byte-Frames zwischen 57 Prozent in der niedrigsten und 34 Prozent in der höchsten Priorität. Verwendeten wir 1024-Byte-Frames, gingen die Verluste hier auf Werte zwischen rund 35 und 20 Prozent zurück. Mit kleineren Frame-Formaten kam der Extreme-Switch dann wieder gut zurecht. Das gleiche gilt auch für die Messungen ab 200 Prozent Last an den Ausgangsports. Bei Volllast arbeitete der Summit-X450a-24t dann wieder völlig unauffällig. Hier konnten wir dann auch lediglich geringe Verluste von maximal 0,1 Prozent in der höchsten Priorität ermitteln.

Bei den Messungen mit Bandbreitenmanagement arbeitete der Extreme-Switch zwar nicht ganz so exakt wie der D-Link. Insgesamt sind aber maximale Abweichungen von den Sollwerten von unter 2 Prozent unkritisch. Dabei glichen sich die Ergebnisse der Messungen mit den beiden Burst-Formaten wie ein Ei dem anderen.

Auch Hewlett-Packards Procurve-Switch-5406zl-48G beherrschte die Disziplin Strict-Priority mit einer Burst-Size von einem Frame nahezu perfekt. Nennenswerte Datenverluste konnten wir ihm hier keine nachweisen. Anders sah es auch bei dem HP-Switch aus, wenn die Burst-Size 100 Frames betrug. Auch der Procurve-Switch mochte hier keine großen Frame-Formate. So verlor er schon bei der Messung mit 100 Prozent Last an den Ausgangsports und 1518-Byte-Paketen insgesamt 42 Prozent aller Daten. Mit 1024-Byte-Paketen betrug der Gesamtverlust noch gut 26 Prozent. Allerdings verteilten sich bei dem HP-Switch die ungebührlichen Datenverluste auf die Prioritäten 1, 3 und 5. Die höchste Priorität blieb wie beim D-Link-Switch generell von Datenverlusten verschont. Die Schwäche bei der Priorisierung großer Frames behielt der HP-Switch dann auch bei höheren Lasten bei. Bei Volllast war sie dann nicht mehr sichtbar, da hier mit Ausnahme der höchsten Priorität ohnehin alle Daten verworfen werden mussten.

In der Disziplin Bandbreitenmanagement schlug sich der HP-Switch wie schon in den vorhergehenden Tests recht gut. Dabei zeigte er eine leichte Schwäche für 64-Byte-Frames. Die verwendete Burst-Size hatte auf das Verhalten des Switches dabei keinen Einfluss.

Nortel Networks Ethernet-Routing- Switch-ERS-5530 beherrschte keine »echte« Strict-Priority. Der Hersteller geht hier einen eigenen Weg, der zu entsprechend anderem Datenverlustverhalten führt. Der Hersteller selbst gibt an, dass alleine die höchste Priorität mit Strict-Priority behandelt wird. Die übrigen Queues behandelt Nortel nach einem Weighted-Fair-Queuing-Verfahren. Wie dieses funktioniert, ist an den Testergebnissen mit einer Burst-Size von einem Frame gut zu erkennen. Bei 100 Prozent Last an den Ausgangsports verwirft der Switch noch keinerlei Daten, was bei entsprechender Performance auch zu fordern ist. Verlangt die Überlast, dass der Switch im Strict-Priority-Modus die niedrigste Priorität vollständig verwirft, dann teilt der Nortel-Switch die Verlustraten zwischen der niedrigsten und der zweitniedrigsten Priorität auf. Rund 74 Prozent gingen von der niedrigsten Priorität verloren. Von der zweitniedrigsten Priorität waren um die 23 Prozent betroffen. In der nächsten Stufe, bei 200 Prozent Last an den Ausgangsports, verwirft ein Switch mit Strict-Priority die beiden niedrigen Prioritäten vollständig. Der Nortel-Switch hat dagegen die Verlustraten unter den Prioritäten 1, 3 und 5 im Verhältnis von 91, 73 und 35 Prozent verworfen. Unter Volllast hat sich der Nortel-Switch dann wieder verhalten wie ein »echter« Strict-Priority-Switch: Totalverlust in den unteren Prioritäten, keine Verluste in der höchsten Priorität.

Verwendeten wir eine Burst-Size von 100 Frames, änderte sich das Verhalten des Nortel-Switches genauso wie das der Mitbewerber. Und die hier zu beobachtenden Verhaltensweisen sind nicht mit einem abweichenden Priorisierungs-Mechanismus zu begründen. Große Frame-Formate führten auch hier zu überproportionalen Datenverlusten. Verwendeten wir 1518-Byte-Frames, verlor der Switch schon bei 100 Prozent Last an den Ausgangsports insgesamt fast 44 Prozent aller Daten. Bei einem Frame-Format von 1024 Byte kam er noch auf einen Gesamtverlust von rund 34, bei 512-Byte auf 7 Prozent. Mit noch kleineren Frames kam er dann wieder problemlos zurecht. Wirklich »strict« verarbeitete aber auch der Nortel-Switch die höchste Priorität. Hier waren auch bei der großen Burst-Size keinerlei Datenverluste zu beklagen.

Ein funktionierendes Bandbreitenmanagement konnte Nortel auch demonstrieren. Dabei hielt der Nortel-Switch die Vorgaben bei unseren Messungen mit großen Frames recht exakt ein. Mit abnehmendem Frame-Format entfernten sich die Messwerte dann immer mehr von unseren Vorgaben. So betrug die durchschnittliche Abweichung von unseren Vorgaben bei der Messung mit den kleinsten Frames gut 6 Prozent. Benachteiligt wurde dabei die niedrigste Priorität. Grund für dieses Verhalten ist ein vom Verfahren anderer Hersteller abweichender Algorithmus, der auf der Payload-Länge und nicht auf der Frame-Länge basiert.

Auf Grund seines spezifischen Verhalten fällt der Nortel-Switch somit aus der weiteren Bewertung des Testfeldes heraus.

Test Unicast-Downlink
Im nächsten Test-Setup unserer Class-of-Service-Testsuite haben wir mit unserem Lastgenerator auf zwei 10-Gigabit-Ethernet-Ports parallel Datenströme gesendet. Jeder dieser Ports hatte vier Datenströme 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 beiden 10-Gigabit-Ethernet-Ports haben dann ihre Datenströme an fünf Gigabit-Ethernet-Ports gesendet, so dass bei Volllast an den Switch-Ausgangsports eine vierfache Überlast anlag, was einer Gesamtlast des Switches von 20 GBit/s entspricht. In nacheinander folgenden Messungen hat der Spirent-Lastgenerator Datenströme bestehend aus Datenrahmen von je 64, 256, 512, 1024 und 1518 Byte erzeugt. Alle Messungen haben wir zunächst mit Burst-Size 1 und dann mit Burst-Size 100 durchgeführt. Auch hier haben wir die Priorisierungsmechanismen Strict-Priority und Bandbreitenmanagement eingesetzt. Alle weiteren Details entsprechen den Testreihen oben.

D-Links DXS-3350SR arbeitete im Downlink-Betrieb mit Strict-Priority und einer Burst-Size von einem Frame unbeeinträchtigt von den wechselnden Frame-Formaten mustergültig. Und auch die Messergebnisse mit einer Burst-Size von 100 Frames vermochten den D-Link-Switch nicht zu beeinträchtigen. Die Messwerte entsprachen exakt der geforderten Policy.

Die Messungen im Bandbreitenmanagement-Betrieb meisterte der DXS-3350SR ebenfalls mit nur geringfügigen Abweichungen von den Sollwerten, die maximal bei rund einem Prozent lagen. Dabei unterschieden sich die Messergebnisse zwischen den Messungen mit einer Burst-Größe von einem und von 100 Frames nicht.

Extreme Networks Summit-X450a-24t arbeitete mit Strict-Priority weitgehend unauffällig, leistete sich aber ein paar Ausreißer. So verschob er bei unserer Messung mit einer Burst-Size von einem Frame, 200 Prozent Last an den Ausgangsports und den größten Frames jeweils rund zwei Prozent Frame-Loss auf die beiden höchsten Prioritäten, obwohl diese eigentlich verlustfrei hätten bleiben müssen. Bei der gleichen Messung mit einer Burst-Size von 100 Datenrahmen verlor er dann plötzlich bei einer Frame-Größe von 512 Byte rund 23 Prozent der Daten in der zweithöchsten Priorität. Unter Volllast und mit den größten Frames verwarf der Extreme-Switch dann gut 22 Prozent der Daten in der höchsten Priorität. Und zwar sowohl bei einer Burst-Size von einem als auch bei einer Burst-Size von 100 Frames.

Die Disziplin Bandbreitenmanagement beherrschte der Summit-X450a-24t dagegen ohne außerplanmäßige Abweichungen von der geforderten Policy. Bei allen Messungen mit beiden Burst-Formaten blieben die Abweichungen von den Sollwerten maximal im 1-Prozent-Bereich.

Hewlett-Packards Procurve-Switch-5406zl-48G arbeitete bei unseren Messungen mit Strict-Priority und beiden Burst-Formaten absolut konform mit der geforderten Policy. Bis auf eine Ausnahme: Unter Volllast verlor er bei Verwendung der kleinsten Frames unabhängig von der Burst-Size gut 17 Prozent in der höchsten Priorität. Dafür ließ er rund 17 Prozent der zweithöchsten Priorität passieren, die er hätte verwerfen müssen.

Das Bandbreitenmanagement beherrschte der Procurve-Switch-5406zl-48G bei allen Messungen dagegen ebenso souverän wie der Mitbewerb. Absolute Spitzenwerte in der Präzision erreichte er bei der Verarbeitung großer Frame-Formate. So schaffte er bei der durchschnittlichen Abweichung von den Sollwerten im Betrieb mit 1518-Byte-Paketen den Bestwert von 0,07 Prozent. Und das unabhängig vom Burstformat.

Testreihe Unicast-Uplink
Im Unicast-Uplink-Test-Setup unserer Class-of-Service-Testsuite haben wir mit unserem Lastgenerator auf 20 Gigabit-Ethernet-Ports parallel Datenrahmen gesendet und diese an einen 10-Gigabit-Ethernet-Port adressiert. Dabei sendete jeder Input-Port vier Datenströme der vier Prioritätsklassen an jeden Output-Port. Da 20 Ports gleichzeitig sendeten betrug die Gesamtlast des Systems in diesem Unicast-Betrieb 20 GBit/s. Die maximale Belastung des 10-Gigabit-Ausgangsports lag bei einer zweifachen Überlast.

In nacheinander folgenden Messungen hat der Spirent-Lastgenerator Datenströme bestehend aus Datenrahmen von je 64, 256, 512, 1024 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 Strict-Priority und Bandbreitenmanagement eingesetzt. Alle weiteren Details entsprechen den Testreihen oben.

D-Links DXS-3350SR arbeitete im Strict-Priority-Modus absolut fehlerfrei, so lange die Burst-Size 1 Frame betrug. Verwendeten wir Bursts von jeweils 100 Frames, war der Switch dann klar überlastet. So leistete er sich schon bei unserer Messung mit 100 Prozent Last am Ausgangsport Gesamtdatenverluste von zwischen 11 und 46 Prozent, obwohl hier theoretisch gar keine Verluste erforderlich wären. Dabei wuchsen die Probleme mit steigender Frame-Größe proportional an. Allerdings schaffte es der DXS-3350SR, die beiden höchsten Prioritäten von ungebührlichen Datenverlusten frei zu halten. Somit war dann die Welt auch unter Volllast scheinbar wieder in Ordnung.

Beim Betrieb mit Bandbreitenmanagement wich der DXS-3350SR bei allen Messungen konstant von den theoretisch zu erwartenden Sollwerten ab. Und zwar verlor er nicht wie vorgesehen bei der 200-prozentigen Höchstlast am Ausgangsport 20 Prozent in der höchsten Priorität. Statt dessen hielt er die höchste Priorität von Verlusten frei und verteilte diese 20 Pozent Frame-Loss auf die drei anderen Prioritäten, die dann konstant rund 5 beziehungsweise 10 Prozent zu viele Daten verlor.

Extreme Networks Summit-X450a-24t arbeitete im Strict-Priority-Modus fehlerfrei – so lange wir ein Burst-Format von einem Frame verwendeten. Stellten wir als Burst-Size 100 Frames ein, verlor der Switch schon bei 100 Prozent Last am Ausgangsport zwischen rund 44 und rund 11 Prozent aller Daten. Dabei stiegen auch hier die Verlustraten kontinuierlich mit der Frame-Größe an. Da sich die außerplanmäßigen Datenverluste nahezu vollständig auf die beiden niedrigen Prioritäten beschränkten, erreichten sie dort maximale Werte von über 86 Prozent. Auch bei den Messungen mit 133 Prozent Last an den Ausgangsports, als die niedrigste Priorität Totalverlust erreichen sollte, verteilte der Summit-X450a-24t die Verlustraten zwischen den beiden niedrigen Prioritäten, Dabei hatte der Switch um so mehr Probleme, um so größer die verwendeten Frames waren. Bei Volllast schaffte es der Extreme-Switch dann wieder, ein den Vorgaben entsprechendes Messergebnis zu erreichen und die beiden hohen Prioritäten von ungebührlichen Datenverlusten zu verschonen.

Nicht ganz so präzise, wie in den anderen Bandbreitenmanagement- Betriebsarten, aber doch relativ dicht an den Sollwerten arbeitete der Extreme-Switch auch im Uplink-Modus. Dabei pendelten sowohl bei einer Burst-Size von einem als auch bei einer Burst-Size von 100 Frames die durchschnittliche Abweichung vom Sollwert um die 2 Prozent. Dabei verlor der Switch in den niedrigen Prioritäten tendenziell zu viele Daten, in den hohen Prioritäten verwarf er etwas weniger Daten als vorgesehen.

Hewlett-Packards Procurve-Switch-5406zl-48G zeigte auch hier schon bei der Burst-Size von einem Frame seine Schwäche im Bereich der kleinsten Frame-Formate. So verwarf er unter Volllast und mit 64-Byte-Frames in den beiden hohen Prioritäten jeweils gut 17 Prozent aller Daten. Dafür reduzierte sich der Frame-Loss in der zweitniedrigsten Priorität von vorgesehenen 100 auf gut 65 Prozent. Bei den Messungen mit einer Burst-Size von 100 Frames hatte der Procurve-Switch-5406zl-48G dann wieder Probleme im Bereich der niedrigen Prioritäten. So verlor er schon bei 100 Prozent Last am Ausgangsport und einer Frame-Größe von 1518 Byte in den beiden niedrigen Prioritäten fast 86 Prozent. Dabei wäre hier noch gar kein Datenverlust zu erwarten gewesen. Die Verlustraten verringern sich hier mit abnehmendem Frame-Format. So arbeitete der HP-Switch mit 64-Byte-Frames und 100 Prozent Last am Ausgangsport wieder fehlerfrei.

Auch in der Disziplin Bandbreitenmanagement arbeitete der Procurve-Switch- 5406zl-48G nicht so präzise wie sonst. Tendenziell bevorzugte er alle höheren Prioritäten. Das führte dazu, dass der Switch zu viele Daten in der niedrigsten Priorität verwarf. Dabei wich der Switch um so mehr von den Sollwerten ab, um so größer das Frame-Format wurde. Betrug der Frame-Loss bei den Messungen mit 64-Byte-Paketen in der niedrigsten Priorität noch knapp 88 anstatt 80 Prozent, so stiegen die Datenverluste mit dem Frame-Format bis auf gut 97 Prozent an Stelle der geforderten 80 Prozent an. Die durchschnittliche Abweichung von den Sollwerten schwankte so zwischen rund 4 und 9 Prozent.

Fazit
It`s not a bug, it`s a feature – nach diesem Motto kann die Leistung des Nortel-Switches in unserem Vergleichstest auf den Punkt gebracht werden. Einerseits hat Nortel die Vorgaben unserer Ausschreibung schlicht nicht erfüllt. Der Switch konnte die geforderte Strict-Priority-Funktionalität nicht wirklich nachweisen. Statt dessen wartet er mit einem Leistungsverhalten auf, das durchaus auch Vorteile gegenüber den geforderten Verfahren haben mag. So war der Nortel-Switch als einziger im Testfeld in der Lage, eine echte Bandbreitenlimitierung umzusetzen. Diese ist für viele Szenarien wichtig, in denen es darum geht, Netzwerke oder Segmente erst gar nicht in die Überlast zu bringen. Für den vorliegenden Vergleichstest blieb uns jedoch nichts anderes übrig, als Nortel schlicht aus der Wertung zu nehmen, weil er sich nicht direkt mit den anderen Switches vergleichen lässt.

Eindeutig in die Kategorie Bug gehört aber im Fall Nortel ebenso wie beim Mitbewerb im Testfeld das Verhalten, bei einer Burst-Size von 100 Frames und der Verwendung von größeren Frame-Formaten deutlich mehr Daten zu verlieren, als theoretisch erforderlich gewesen wäre. Hierfür sind wohl zu klein ausgelegte Pufferspeicher verantwortlich zu machen – ein Problem, das alle getesteten Switches haben. Und auch sporadisch auftretende Fehler im Betrieb mit Frames der unterschiedlichsten Größenordnungen decken zum Teil noch Design-Schwächen auf. – Wenn ein Switch sich nicht so verhält, wie erwartet, dann kann das schnell zu Problemen im Netzwerk führen. Dabei spielt es keine große Rolle, ob das abweichende Verhalten durch Bugs, Design-Fehler, Kosteneinsparungen bei der Produktion oder proprietäre Algorithmen zu begründen ist. Allerdings muss man allen beteiligten Herstellern zugestehen, dass sie es inzwischen schaffen, die höchste Priorität bis auf geringe Abweichungen von Datenverlusten frei zu halten.

Nicht überzeugend waren im Test aber auch Mängel, die sich in den Messwerten nicht niederschlagen. So arbeiteten die 10-Gigabit-Ethernet-Module des D-Link-Switches recht unzuverlässig. Nach »Power-On« hatten sie regelmäßig rund 90 Prozent Paketverluste zu verzeichnen. Selbst ein Reboot half dann nicht. Ebenso zeigte ein Factory-Default und anschließendes Laden der zuvor funktionierenden Konfiguration keinen Erfolg. Erst eine manuelle Neukonfiguration nach einem Factory-Default brachte den erhofften Erfolg – bis zum nächsten »Power-On«.

IT-Verantwortliche stehen heute bei der Auswahl geeigneter Switch-Systeme einer ganzen Reihe von Fragestellungen und Problemen gegenüber. Auch wenn aktuelle Switches durchaus einsetzbar sind, sie weisen auch im Jahr 2007 noch Verarbeitungs- und Designschwächen auf. Diese sind sicherlich auch durch den Zeit- und Kostendruck bei den Herstellern zu erklären. Hinzu kommen die Sonderwege, die verschiedene Hersteller gehen. Ob der Grund hierfür in der Schaffung intelligenterer Lösungen oder der bequemen Nichtvergleichbarkeit zu suchen sind sei dahin gestellt. Jedenfalls entstehen so wohl auch wieder proprietäre Inseln, die Unternehmen an einzelne Hersteller binden.

Die Auswahl einer geeigneten Highspeed-LAN-Infrastruktur ist jedenfalls nicht trivialer geworden und ohne eine qualifizierte messtechnische Untersuchung der in Frage kommenden Komponenten sind IT-Verantwortliche letztendlich auf die Marketing-Aussagen der Hersteller angewiesen. Und die halten nicht immer einer Überprüfung stand.

Dipl.-Ing. Thomas Rottenau, Prof. Dr. Bernhard G. Stütz,
dg@networkcomputing.de