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, fünf 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 untersuchen.

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 der ersten Testreihe 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 haben wir in Network Computing 4/2007 veröffentlicht. Wie sich die Switches im Multicast-Betrieb bewährt haben erläutern wir nun im vorliegenden Artikel.

Innerhalb der Testreihe Multicast-Betrieb haben wir die Systeme in zwei 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. Hierbei sendeten vier Gigabit-Ethernet-Ports und adressierten jeweils 16 weitere Gigabit-Ethernet-Ports. Im zweiten Test-Setup haben wir dann ein Downlink-Szenario aufgebaut. Hierbei sendete ein 10-Gigabit-Ethernet-Port auf 20 Gigabit-Ethernet-Ports.

Unsere 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 gleichmäßig 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 so 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 idealtypische Verhalten zeigen: Bei 100 Prozent Last an den Ausgangsports sollten alle Datenströme ungehindert weitergeleitet 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 der 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 Multicast intern
Im ersten Multicast-Test 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 niedrigste 8 entspricht. Die Datenströme dieser einzelnen Prioritäten wurden dann in die jeweiligen Hardware-Queues geleitet.

Die 16 übrigen Gigabit-Etherent-Ports abonnierten im Multicast-Modus alle vier Datenströme, so dass bei Volllast an den Eingangsports eine vierfache Überlast an den 16 Ausgangsports anlag, was einer Gesamtlast des Switches von 64 GBit/s entspricht. In nacheinander folgenden Messungen hat der Spirent-Lastgenerator wieder 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.

D-Links DXS-3350SR arbeitete im internen Multicast-Strict-Priority-Betrieb mit einem Burst-Format von einem Frame standardkonform und leistete sich keine außerplanmäßigen Datenverluste. Wechselten wir auf ein Burst-Format von 100 Frames, dann waren die Grenzen des D-Link-Switches dagegen schnell erreicht. Schon bei einer Last von 100 Prozent an den Ausgangsports mussten wir außerplanmäßige Datenverluste verzeichnen. Dabei waren die Datenverluste um so höher, um so größer das gewählte Frame-Format war. Im Betrieb mit den 64 und 256 Byte kleinen Frames arbeitete der D-Link-Switch noch einwandfrei. Verwendeten wir 512 Byte große Frames, waren über alle Prioritäten hinweg schon rund 17 Prozent Frame-Loss zu verzeichnen. Mit ansteigendem Frame-Format stiegen dann auch die Datenverluste weiter.

Maximal betrugen sie bei 100 Prozent Last gut 50 Prozent aller Daten über alle Prioritäten hinweg. Dabei teilen sich die Datenverluste gleichmäßig auf die Prioritäten 1, 3 und 5 auf. Lediglich die höchste Priorität blieb von ungebührlichen Datenverlusten verschont. Bei höheren Eingangslasten verhielt sich der DXS-3350SR analog. Dabei stiegen die Datenverluste noch entsprechend weiter an. Da die höchste Priorität aber durchgehend von Datenverlusten verschont blieb, war dann bei Maximallast die Welt anscheinend wieder in Ordnung. Hier verlor der D-Link-Switch entsprechend der Strict-Priority-Policy alle Daten bis auf die der höchsten Priorität.

Im Betrieb mit Bandbreitenmanagement verhielt sich der DXS-3350SR durchgehend unauffällig. Er setzte die vorgegebenen Mindestbandbreiten ohne größere Abweichungen um. Dabei arbeitete der D-Link-Switch im Betrieb mit einer Burst-Size von einem Frame noch etwas präziser als mit einem Burst-Format von 100 Frames. Aber auch hier schwankte die maximale Abweichung von den Sollwerten höchstens um die zwei Prozent.

Auch Extreme Networks Summit-X450a-24t arbeitete im internen Multicast-Strict- Priority-Betrieb mit einem Burst-Format von einem Frame weitgehend unauffällig. Dabei leistete er sich einen Ausrutscher bei der Messung mit 133 Prozent an den Ausgangsports bei der Messung mit dem größten Frame-Format. Hier gingen gut 15 Prozent der Daten in der Priorität 3 verloren, was theoretisch nicht erforderlich gewesen wäre. Statt dessen verwarf der Extreme-Switch zu wenige Daten der niedrigsten Priorität. Wechselten wir in den Betrieb mit einem Burst-Format mit 100 Frames, zeigte der Summit-X450a-24t ähnliche, noch etwas größere Probleme als der D-Link-Switch. So gingen schon bei 100 Prozent Last am Ausgangsport im Betrieb mit den größten Frames fast 70 Prozent aller Daten verloren. Dabei wurden auch die am höchsten priorisierten Daten mit rund 14 Prozent Frame-Loss in Mitleidenschaft gezogen. Die übrigen Datenverluste verteilten sich ziemlich gleichmäßig auf die anderen Prioritäten. Unter höheren Eingangslasten blieb das Leistungsbild ziemlich gleich. Unter maximaler Last gelang es dem Extreme-Switch dann, ein weitgehend standardkonformes Bild abzugeben. Selbst bei der Messung mit den größten Frames gingen hier die Verlustraten in der höchsten Priorität auf deutlich unter ein Prozent zurück.

Im Bandbreitenmanagementbetrieb und mit einer Burst-Size von einem Frame arbeitete der Summit-X450a-24t recht präzise. Maximal wich er um die zwei Prozent von den vorgegebenen Werten ab. Wechselten wir zum Betrieb mit der Burst-Size von 100 Frames, dann arbeitete der Extreme-Switch sogar noch etwas präziser.

Auch Hewlett-Packards Procurve-5406zl-48G kam mit den Vorgaben im internen Multicast-Strict-Priority-Modus mit einem Burst-Format von einem Frame recht gut zurecht. Allerdings leistete er sich zwei Aussetzer. Bei unserer Messung mit 200 Prozent Last am Ausgangsport und 64-Byte-Paketen entfielen unnötigerweise über fünf Prozent der Datenverluste auf die zweithöchste Priorität. Und bei der Messung mit der höchsten Last und den kleinsten Frames gingen über 50 Prozent der Daten in der höchsten Priorität verloren. Mit Strict-Priority und einem Burst-Format von 100 Frames hatte der HP-Switch dann größere Probleme. Schon bei einer Last am Ausgangsport von 100 Prozent gingen bis zu rund 44 Prozent aller Daten verloren. Dabei verwarf der HP-Switch bei allen Laststufen jeweils Daten in der höchsten Priorität, wenn wir 64-Byte- oder 512-Byte-Pakete verwendeten. Auch gingen bei allen Laststufen immer wieder mehr Daten verloren, als theoretisch erforderlich gewesen wäre.

Die Disziplin Bandbreitenmanagement beherrschte der HP-Switch dagegen recht souverän. So lag er in den durchschnittlichen Abweichungen von den Sollwerten zwischen D-Link und Extreme. Mehr als ein Prozent wich er in der Regel nicht von seinen Vorgaben ab. Einen Ausrutscher leistete sich der Procurve-Switch allerdings bei unserer Messung mit den kleinsten Frames und einem Burst-Format von einem Frame. Hier kam der HP-Switch auf eine durchschnittliche Abweichung vom Mittelwert von über zwölf Prozent. Im Detail bedeutet das zu hohe Datenverluste zwischen gut fünf Prozent in der höchsten und über 18 Prozent in der niedrigsten Priorität.

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 verarbeitet 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.

Auch bei unseren Messungen mit einer Burst-Size von 100 Frames war dieser Priorisierungsmechanismus erkennbar. Allerdings leistete sich auch der Nortel-Switch hier ein paar Ausreißer. So verlor er bei unseren Messungen mit 100 Prozent Last und einem Frame-Format von 512 Byte, als noch gar keine Verluste erforderlich gewesen wären, fast zehn Prozent der Daten in der niedrigsten Priorität. Verwendeten wir bei der gleichen Messung 1024-Byte-Pakete, gingen über 30 Prozent der Daten in der zweitniedrigsten Priorität verloren. Bei der Messung mit 133 Prozent Last an den Ausgangsports verwechselte der Nortel-Switch bei der Messung mit 1024-Byte-Paketen dann plötzlich die Prioritäten 3 und 5. Hier verwarf er an Stelle von rund 23 Prozent in der Priorität 3 fast 36 Prozent in der Priorität 5. Auch unter maximaler Last verlor der Nortel-Switch hier keine Daten der höchsten Priorität. Allerdings teilte er bei der Messung mit dem größten Frame-Format die Datenverluste zwischen den Prioritäten 3 und 5 deutlich gleichmäßiger auf, als er sollte. Hier konnten wir Verluste in der Priorität 3 von gut 60 und in der Priorität 5 von über 50 Prozent messen.

Test Multicast Uplink
Im zweiten Multicast-Test unserer Class-of-Service-Testsuite haben wir mit unserem Lastgenerator auf einen 10-Gigabit-Ethernet-Port vier Datenströme gesendet. Dieser Port 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 wieder 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 adressierten 20 Gigabit-Ethernet-Ports abonnierten im Multicast-Modus alle vier Datenströme, so dass bei maximaler Last von 1 GBit/s je Datenstrom eine vierfache Überlast an den 20 Ausgangsports anlag, was einer Gesamtausgangslast des Switches von 80 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. Diese Messungen haben wir mit Burst-Size 1 durchgeführt.

D-Links DXS-3350SR arbeitete bei unseren Messungen im Multicast-Uplink- Strict-Priority-Modus mit einem Burst-Format von einem Frame korrekt. Alle ungebührlichen Datenverluste, die messbar waren, bewegten sich deutlich unter der Ein-Prozent-Marke. Und auch im Betrieb mit Bandbreitenmanagement verhielt sich der D-Link-Switch hier als Musterschüler.

Extreme Networks Summit-X450a-24t leistete sich im Strict-Priority-Modus zwei kleinere Ausrutscher. Bei unserer Messung mit 100 Prozent Last und mit den größten Frames verlor er zwischen rund 2,6 Prozent Daten in der höchsten und rund einem Prozent Daten in der niedrigsten Priorität. Dabei wäre hier theoretisch mit keinen Verlusten zu rechnen. Bei einer Ausgangslast von 133 Prozent verlor der Extreme-Switch dann zu Gunsten der niedrigsten Priorität rund 2,3 Prozent der Daten in der Priorität 3.

In der Disziplin Bandbreitenmanagement arbeitete der Summit-X450a-24t zwar nicht so präzise wie das D-Link-Gerät. Mit mittleren Abweichungen von den Sollwerten von gut einem Prozent war die Leistung des Extreme-Switches aber durchaus in Ordnung.

Hewlett-Packards Procurve-5406zl-48G zeigte bei unseren Messungen im Strict-Priority-Betrieb eine erkennbare Schwäche bei der Verarbeitung der kleinsten Frames. War bei 100 Prozent Last an den Ausgangsports noch die Welt in Ordnung, so verlor der HP-Switch bei 133 Prozent Last in den Prioritäten 3, 5 und 7 jeweils über vier Prozent. Bei steigender Last behandelte der Procurve-5406zl-48G die genannten Prioritäten gleich und verteilte die Verlustraten unabhängig von der Policy paritätisch. Das bedeutet über 33 beziehungsweise 65 Prozent Datenverluste in der höchsten Priorität. Verwendeten wir größere Datenpakete, arbeitete der HP-Switch dagegen wieder wie gefordert.

Auch bei unseren Messungen im Uplink-Betrieb mit Bandbreitenmanagement leistete sich der HP-Switch wieder einen Ausreißer. Verwendeten wir hier 256-Byte-Pakete, dann erreichte der Procurve-Switch eine durchschnittliche Abweichung von den Sollwerten von gut zwölf Prozent.

Deutliche Probleme mit kleinen Frames zeigte Nortels Ethernet-Routing- Switch-ERS-5530 bei unseren Messungen. Schon bei unserem Test mit 100 Prozent Last an den Ausgangsports gingen bei der Messung mit den kleinsten Frames rund 83 Prozent aller Daten verloren. Betrug das Frame-Format 256 Byte, verlor der Switch immer noch fast 45 Prozent. Dabei streuten die Verlustraten gleichmäßig über alle Prioritäten. Erhöhten wir die Last, dann stiegen auch die Datenverluste entsprechend weiter an. In der höchsten Priorität verlor der Nortel-Switch dann bei 400 Prozent Last in der höchsten Priorität zwischen 23 und 95 Prozent aller Daten. Dabei erreichte er die höchsten Verlustraten im Betrieb mit den kleinsten Frames. Auch blieb bei den Messungen mit kleineren Frames generell der Gesamtdurchsatz des Systems hinter den Erwartungen zurück.

Fazit
Nach dem Motto »It`s not a bug, it`s a feature« kann die Leistung des Nortel-Switches in unserem Vergleichstest auch zusammenfassend 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 wie schon im ersten Teil dieses Vergleichstests 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 der Verwendung von bestimmten Frame-Formaten deutlich mehr Daten zu verlieren, als theoretisch erforderlich gewesen wäre. Hierfür sind wohl zu klein ausgelegte Pufferspeicher oder eine mangelnde Performance verantwortlich zu machen – ein Problem, das alle getesteten Switches in mehr oder weniger starker Ausprägung 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 zumeist 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