Lastspitzen sorgen in vielen Ethernet-basierten Unternehmensnetzen immer wieder dafür, dass es im Netz eng wird, und dann kommt es je nach Aus- und Überlastung zu teils erheblichen Datenverlusten. Aber auch andere übertragungstechnische Parameter, wie Latency oder Jitter, können – wenn sie gewisse Toleranzwerte überschreiten, weil beispielsweise das Netzwerk und seine Komponenten überfordert sind, zu Störungen einzelner Services oder auch der gesamten Kommunikation führen. Im Zeitalter konvergenter Netze, die Echtzeitapplikationen wie Voice- und Video-over-IP aber auch Produktionsteuerungsdaten in das klassische Datennetz integrieren, führen Datenverluste und andere Störungen in der Praxis zu empfindlichen Kommunikationsstörungen und Produktionsausfällen. So haben in realen Projekten schon mangelhaft priorisierende Switches ganze Call-Center außer Betrieb gesetzt.

Info

Das Testfeld

• D-Link DGS-3324SR inklusive vier Combo-Ports sowie

• HP Procurve Switch 5308XL mit HP Procurve Switch XL Mini-GBIC Modul sowie HP ProCurve Gigabit-SX-LC Mini-GBIC

Auswirkungen von Datenverlusten

Bei klassischen Dateitransfers arbeitet das System mit möglichst großen Datenrahmen. Bei Echtzeit-Applikationen teilt sich das Feld. Video-Übertragungen nutzen ähnlich den Dateitransfers relativ große Datenrahmen. Voice-over-IP bewegt sich dagegen im Mittelfeld. Messungen mit Ethernet-LAN-Phones der ersten Generation in unseren Real-World Labs haben beispielsweise ergeben, dass diese Voice-over-IP-Lösung die Sprache mit konstant großen Rahmen von 534 Byte überträgt. Aktuelle Lösungen überlassen es dem IT-Verantwortlichen selbst festzulegen, mit welchen Frame-Größen die Systeme arbeiten sollen. Dabei sollte der IT-Verantwortliche berücksichtigen, dass der Paketierungs-Delay mit kleiner werdenden Datenrahmen kleiner wird. Dagegen wächst der Overhead, der zu Lasten der Nutzdatenperformance geht, je kleiner die verwendeten Pakete sind. Generell kann man bei der IP-Sprachübertragung davon ausgehen, dass mittelgroße Frames verwendet werden. Und auch die meisten Web-Anwendungen nutzen mittelgroße Datenrahmen. Kurze Frames von 64 Byte sind dagegen beispielsweise bei den TCP-Bestätigungspaketen oder interaktiven Anwendungen wie Terminalsitzungen zu messen.

Für eine realitätsnahe und aussagefähige Auswertung der Messergebnisse ist es darüber hinaus entscheidend zu wissen, welche Framegrößen in welchen Verteilungen in realen Netzwerken vorkommen. Die Analyse der Verteilung der Framegrößen, die für das MCI-Backbone dokumentiert sind, sowie die Ergebnisse der Analyse typischer Business-DSL-Links haben ergeben, dass rund 50 Prozent aller Datenrahmen in realen Netzwerken 64 Byte groß sind. Die übrigen rund 50 Prozent der zu transportierenden Datenrahmen streuen über alle Rahmengrößen von 128 bis 1518 Byte.

Für die Übertragung von Real-Time-Applikationen ist zunächst das Datenverlustverhalten von entscheidender Bedeutung. Für Voice-over-IP gilt beispielsweise: Ab 5 Prozent Verlust ist je nach Codec mit deutlicher Verschlechterung der Übertragungsqualität zu rechnen, 10 Prozent führen zu einer massiven Beeinträchtigung, ab 20 Prozent Datenverlust ist beispielsweise die Telefonie definitiv nicht mehr möglich. So verringert sich der R-Wert für die Sprachqualität gemäß E-Modell nach ITU G.107 schon bei 10 Prozent Datenverlust um je nach Codec 25 bis weit über 40 Punkte, also Werte, die massive Probleme im Telefoniebereich sehr wahrscheinlich machen. Auf Grund ihrer Bedeutung für die Übertragungsqualität haben wir daher das Datenrahmenverlustverhalten als primäres K.O.-Kriterium für unsere Tests definiert. Die Parameter Latency und Jitter sind dann 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. Dafür, dass es zu solchen massiven Datenverlusten im Ethernet-LAN erst gar nicht kommt, sollen entsprechend gut funktionierende Priorisierungsmechanismen sorgen. Bei entsprechender Überlast im Netz sind Datenverluste ganz normal, jedoch sollen sie durch die Priorisierungsmechanismen in der Regel auf nicht echtzeitfähige Applikationen verlagert werden. Arbeitet diese Priorisierung nicht ausreichend, kommt es auch im Bereich der höher priorisierten Daten zu unerwünschten Verlusten.

Qualitätssicherungsmechanismen

Um solchen Problemen vorzubeugen rüsten die Ethernet-Hersteller ihre Switches mit einer zusätzlichen Funktionalität aus, die es ermöglichen soll, bestimmten Applikationen die Vorfahrt im Netzwerk einzuräumen, wenn es einmal eng wird. Diese Priorisierungs-Mechanismen werden allgemein als Class-of-Service oder – verfälschend in Anlehnung an ATM – als Quality-of-Service bezeichnet. Standardisiert ist eine achtstufige Priorisierung auf Layer-2 nach IEEE 802.1p/Q und auf Layer-3 nach RFC 1349/2474/2475. Die jeweils zugeordnete Priorisierung lesen die Systeme aus den Headern der Datenpakete aus.

Wie Switches die Datenpakete dann gemäß ihrer Priorität behandeln, hängt von den jeweils implementierten Queuing-Mechanismen ab. So besteht beispielsweise die Möglichkeit, bestimmten Daten absolute Vorfahrt einzuräumen oder auch für niedrigere Prioritäten Mindestdurchsatzraten zu garantieren. Eine gute Queuing- oder Scheduling-Strategie sollte folgende Voraussetzungen erfüllen:

• Sie muss die faire Verteilung der Bandbreite auf die verschiedenen Serviceklassen unterstützen. Dabei sollte auch die Bandbreite für besondere Dienste berücksichtigt werden, so dass es zu bestimmten Gewichtungen bei der Fairness kommen kann.

• Sie bietet Schutz zwischen den verschiedenen Serviceklassen am Ausgangsport, so dass eine Serviceklasse mit geringer Priorität nicht die anderen Serviceklassen anderer Queues beeinflussen kann.

• Wenn ein Dienst nicht die gesamte Bandbreite verwendet, die für ihn reserviert ist, dann sollte diese Überkapazität auch anderen Diensten zur Verfügung stehen, bis der eigentliche Dienst diese Kapazitäten wieder benötigt. Alternativ soll die Bandbreite für diesen Dienst absolut begrenzt werden.

• Ein schneller Algorithmus, der hardwaremäßig implementiert werden kann, muss für diese Strategie existieren. Nur dann kann diese Strategie auch auf Switches eingesetzt werden, die mit hoher Geschwindigkeit arbeiten. Algorithmen, die nur softwareseitig implementiert werden können, sind in der Regel ungeeignet, da man die Priorisierung bei hoher Last braucht, und gerade dann reicht die Performance der Softwarelösung in der Regel nicht aus.

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 Hersteller von Switches verwenden oft eigene Namen für die CoS-Queuing-Strategien oder ändern die eigentliche Strategie nach ihren Vorstellungen ab. Oft werden auch verschiedene Strategien miteinander kombiniert, um die Ergebnisse zu verbessern. Die ursprünglichen Queuing-Strategien sind:

• First-In First-Out (FIFO),

• Strict- und Rate-Controlled-Priority-Queuing (PQ),

• Fair-Queuing (FQ),

• Weighted-Fair-Queuing (WFQ),

• Weighted-Round-Robin-Queuing (WRR), auch als Class-Based-Queuing (CBQ) bezeichnet und

• Deficit-Weighted-Round-Robin-Queuing (DWRR).

Wie diese Verfahren im einzelnen arbeiten, haben wir in einem separaten Grundlagenartikel in Network Computing 4/04 ab Seite 48 dargestellt.

Das Real-World-Labs-Testszenario

Wir wollten wissen, wie gut Queuing-Mechanismen heute in aktuellen LAN-Switches arbeiten und ob es mit ihnen möglich ist, die gewünschte Policy zu realisieren. Aus diesem Grund haben wir zwei Class-of-Service-fähige LAN-Switches einer umfangreichen Testprozedur unterzogen. Um unseren Test wie gewohnt im Vorfeld sauber zu strukturieren, haben wir zur Definition unserer Test-Spezifikation, die wir an alle einschlägigen Hersteller gesandt haben, wieder auf unser Modellunternehmen HighFair zurückgegriffen.

Unser Modellunternehmen HighFair möchte neben den klassischen Datenapplikationen und Voice-over-IP weitere Real-Time-Applikationen in ihr Unternehmensnetz integrieren. Ein geeigneter Vergleichstest sollte evaluieren, welche Switches für diese Aufgaben auch unter entsprechender Last geeignet sind. Dabei galt es, verschiedene CoS-Queuing-Mechanismen, wie Strict-Priority-Queuing, Weighted-Fair-Queuing oder Weighted-Round-Robin, auf ihre Eignung für das geplante Szenario zu untersuchen.

Folgende Dienste sollten im LAN der HighFair integriert werden:

• Videokonferenzen (Video-over-IP, bidirektional, unicast),

• Voice-over-IP (Call-Center),

• SAP-Anwendungsdaten sowie

• übrige Datenanwendungen und Updates.

Um die möglichst absolute Störungsfreiheit der Kommunikations- und Arbeitsprozesse in unserem Modellunternehmen zu garantieren, ist eine vierstufige Daten-Priorisierung sowie eine intelligente Queuing-Policy erforderlich. Gefordert haben wir neben der Datenpriorisierung ein intelligentes Bandbreitenmanagement, das es ermöglicht, von vorneherein eine Überlastung des Backbones zu vermeiden. Aus diesem Szenario ergaben sich im Detail die folgenden Anforderungen an die Teststellungen.

Teststellung Gigabit-Ethernet-Switch:

• Mindestens 20 Gigabit-Ethernet-Ports (Multimode-LWL mit SC-Stecker),

• 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 sowie

• mindestens 2 CoS-Queuing-Mechanismen, wie Strict-Prioriry-Queuing, Weighted-Fair-Queuing oder Weighted-Round-Robin, die softwareseitig konfiguriert werden können.

Als Testverfahren haben wir Messungen nach RFC 2544 (Many-to-One) festgelegt, die die Parameter Performance, Packet-Loss, Latency und Jitter ermitteln. Analysiert wird dann das unterschiedliche Verhalten der Systeme in den verschiedenen CoS-Queuing-Modi.

Unsere Testspezifikation haben wir an die einschlägigen Hersteller geschickt und diese eingeladen, an unserem Real-World-Labs-Test in den Labs des Messgeräteherstellers Spirent in Kalifornien teilzunehmen. Letztendlich waren lediglich D-Link und Hewlett-Packard im Stande, eine funktionierende Teststellung zur Verfügung zu stellen. Das Feld der Gigabit-Ethernet-Switches bildeten daher D-Links »DGS-3324SR« inklusive vier Combo-Ports sowie Hewlett-Packards »HP Procurve Switch 5308XL« mit »HP Procurve Switch XL Mini-GBIC Modul« sowie »HP ProCurve Gigabit-SX-LC Mini-GBIC«.

Die Gigabit-Ethernet-Switches im Test

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. Als zweites Testszenario haben wir dann 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.

Strict-Piority-Switching

In unserem Gigabit-Ethernet-Switch-Test haben wir ausschließlich die Gigabit-Ethernet-Ports der Systeme im Test eingesetzt. Um die notwendigen Lasten erzeugen zu können haben wir mit unseren Smartbits auf 16 Gigabit-Ethernet-Eingangs-Ports gesendet und vier Gigabit-Ethernet-Ausgangs-Ports adressiert. In diesem Test-Setup beträgt die maximale Überlast am Switch-Ausgang 400 Prozent.

Da wir die Switches systematisch überlastet haben, kam es bei einer maximalen Last von 100 Prozent auf den Eingangsports zu einer vierfachen Überlastung der Ausgangsports. Dadurch ist es natürlich normal, dass die Switches im Test viele Frames nicht übertragen konnten und somit viele Frames verloren. Anhand der Verteilung der einzelnen Prioritäten oder der einzelnen resultierenden Bandbreiten konnten wir dann erkennen, ob und wenn ja wo der jeweilige Testkandidat Probleme hatte.

In einer ersten Messreihe haben wir zunächst Strict-Piority-Switching gefordert und untersucht. In unseren Tests haben wir jeweils mit unseren Smartbits-Lastgeneratoren Datenströme auf die Eingangs-Ports gesendet und diese Datenströme auf die Ausgangsports adressiert. Hierbei haben wir Datenströme in den vier Layer-2-Prioritäten – VLAN 7, 5, 3 und 1 nach IEEE 802.1p/Q – erzeugt. Die Eingangslast wird hierbei schrittweise erhöht, so dass die Last an den Eingangsports 25, 33,33, 50 und 100 Prozent betrug, was bei einer vierfachen Überlast einer Last am Ausgangsport von 100, 133, 200 und 400 Prozent entspricht. Die Datenströme bestanden aus konstant großen Frames von jeweils 64, 128, 512, 1024 und 1518 Byte. Als Burst-Size haben wir 1 Frame verwendet. Für die Ergebnisse haben wir die für CoS wichtigen Parameter Frame-Loss, Latency und Jitter ausgewertet. Im Mittelpunkt unserer Analysen steht dabei wegen seiner Bedeutung für die Übertragungsqualität das Datenverlustverhalten.

Verhält sich ein Switch anforderungsgerecht, dann verliert er bei 100 Prozent Last am Ausgangsport noch keine Daten. Bei 133 Prozent Last sollte er dann Totalverlust der niedrigsten Priorität erzeugen, die anderen Streams sollten ohne Verluste ankommen. Bei 200 Prozent Last sollte der Switch dann die Daten der beiden niedrigen Prioritäten komplett verlieren und die beiden hohen Prioritäten ungehindert passieren lassen. Bei Volllast ist dann bei einer Last am Ausgangsport von 400 Prozent ein Totalverlust aller Prioritäten mit Ausnahme der höchsten erforderlich, damit die höchste Priorität noch verlustfrei verarbeitet werden kann. Die Daten der höchsten Priorität sollten in allen Fällen unbeschadet die Systeme passieren.

Betrug die Last 100 Prozent, so arbeitete D-Links DGS-3324SR in der Disziplin Strict-Piority-Switching noch völlig unauffällig – alle Daten aller Frame-Formate erreichten problemlos ihr Ziel. Bei Überlast zeigte das D-Link-System dann Probleme. Betrug die Last 200 Prozent, dann sollte der Switch bei einer normkonformen Arbeitsweise die Daten der beiden niedrigen Prioritäten vollständig verwerfen und die Datenströme der beiden hohen Prioritäten unbeschadet passieren lassen. Diese Vorgabe setzte der DGS-3324SR aber nur unsauber um, so verlor er bei der Messung mit 64-Byte-Paketen 16,5 Prozent in der höchsten und 17,11 Prozent in der zweithöchsten Priorität. Dafür betrug die Verlustrate in der zweitniedrigsten Priorität nur 66,38 Prozent. Hier wäre Totalverlust zu erwarten gewesen. Wurden die Frames größer, so stiegen auch die Verlustraten in den hohen Prioritäten weiter an. Bei der Messung mit 1518 Byte großen Datenrahmen verwarf der D-Link-Switch dann 39,5 Prozent der Daten in der höchsten und 41,47 Prozent der Daten in der zweithöchsten Priorität. Am besten kam der D-Link-Switch mit 128 Byte großen Frames zurecht, hier betrug die Verlustrate in der höchsten Priorität 11,28 Prozent. Bei 400 Prozent Last verstärkte sich der Effekt dann noch. Hier sollte der DGS-3324SR die Daten der höchsten Priorität zu 100 Prozent passieren lassen und die Daten aller niedrigeren Prioritäten vollständig verwerfen. Statt dessen verlor der Switch aber je nach Frame-Format zwischen gut 52 und fast 65 Prozent der Daten der höchsten Priorität – auch wieder zu Gunsten der anderen Queues. Dabei zeigen die Gesamtdurchsatzraten des DGS-3324SR, dass der Switch insgesamt die Durchsatzraten durchaus schaffte, die zu erwarten waren. Allerdings arbeitet die Priorisierung unsauber. Lediglich die Daten der niedrigsten Priorität wurden wie gefordert bei Überlast vollständig verworfen.

HPs Procurve-Switch-5308XL arbeitete dagegen in der Disziplin Strict-Piority-Switching völlig normkonform und fehlerfrei. Auch bei Maximalllast priorisierte das HP-System völlig tadellos, die Messergebnisse entsprechen exakt den theoretischen Sollwerten. Dort, wo keine Datenverluste zu erwarten waren, leistete sich der HP-Switch auch nicht einen Ausrutscher.

Switching mit Bandbreitenmanagement

Auch in unseren Tests mit Bandbreitenmanagement haben wir jeweils mit unseren Smartbits-Lastgeneratoren Datenströme auf die Eingangs-Ports gesendet und diese Datenströme auf die Ausgangsports adressiert. Hierbei haben wir Datenströme in den vier Layer-2-Prioritäten – VLAN 7, 5, 3 und 1 nach IEEE 802.1p/Q – erzeugt. Die Eingangslast wird hierbei schrittweise erhöht, so dass die Last an den Eingangsports 25, 33,33, 50 und 100 Prozent betrug, was bei einer vierfachen Überlast einer Last am Ausgangsport von 100, 133, 200 und 400 Prozent entspricht.

Die Datenströme bestanden aus konstant großen Frames von jeweils 64, 128, 512, 1024 und 1518 Byte. Die Burst-Size betrug hierbei 1 Frame. Als Maximalbandbreiten haben wir für die höchste Priorität VLAN 7 10 Prozent, für VLAN 5 20 Prozent, für VLAN 3 30 Prozent und für VLAN 1 40 Prozent gefordert. Für die Ergebnisse haben wir dann die für CoS wichtigen Parameter Frame-Loss, Latency und Jitter ausgewertet. Im Mittelpunkt auch dieser Analysen steht wegen seiner Bedeutung für die Übertragungsqualität das Datenverlustverhalten. 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 hier ausschließlich 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.

D-Links DGS-3324SR unterstützte ausschließlich Strict-Piority-Switching, weshalb D-Links Teststellung in der Disziplin Bandbreitenmanagement passen musste.

HPs Procurve-Switch-5308XL blieb insgesamt in seinen gemessenen Datenverlusten recht dicht an den geforderten Sollwerten. Dabei hat er um so präziser gearbeitet, um so größer die zu transportierenden Frames waren. So betrug der Mittelwert der Abweichungen bei der Messung mit 64-Byte-Frames noch 2,32 Prozent. In den hohen Prioritäten verlor der HP-Switch etwas zu wenig Daten. Dies ging zu Lasten der niedrigsten Priorität, wo die Verlustrate dann immerhin fast 5 Prozent zu hoch war. Verwendeten wir 128 Byte große Frames, so ging der Mittelwert der Abweichung von den Sollwerten auf 1,57 Prozent zurück. Bei den Messungen mit noch größeren Frames arbeitete der Procurve-Switch-5308XL dann noch souveräner. So weicht der Mittelwert der Abweichungen bei der Messung mit 1518-Byte-Frames nur noch 0,32 Prozent.

Multicast-Betrieb

Hat es sich bei den obigen Messungen generell um Punkt-zu-Punkt-Verbindungen gehandelt, bei denen der Switch Datenströme zwischen den verschiedenen Ports vermitteln muss, so sendet der Switch im Multicast-Betrieb den Datenstrom, der an einem Port ankommt, an eine festgelegte Zahl von Ports weiter. Im Fall unseres Testaufbaus bedeutete das, dass der Smartbits-Lastgenerator auf einen Port des zu testenden Switches mit Volllast gesendet hat. Der Switch im Test musste dann den Datenstrom vervielfältigen und an 18 Ausgangsports senden, die wiederum mit dem Smartbits-Analysator verbunden waren. Den 20. Gigabit-Ethernet-Port haben wir zur Kontrollmessung ebenfalls mit dem Smartbits-System verbunden, um zu sicher zu stellen, dass das System nicht in den Broadcast-Betrieb wechselt und die Datenströme einfach an alle Ports sendet. Diese Messung haben wir dann wieder nacheinander mit 64, 128, 512, 1024 und 1518 Byte großen Frames durchgeführt. Für den Multicast-Betrieb haben wir das auf IP basierende Internet-Group-Management-Protocol, kurz IGMP, genutzt, um im Trainingsverkehr den Switch lernen zu lassen, an welche Ports er den Multicast-Traffic senden soll. Stößt der Switch im Test in diesem Szenario an seine Grenzen, dann kommt es zu Datenverlusten und die maximale Durchsatzrate sinkt.

D-Links DGS-3324SR verhielt sich in diesem Szenario vorbildlich und patzte bei keiner Frame-Größe. Zu messen waren konstant 100 Prozent Last an allen Ausgangsports.

HPs Procurve-Switch-5308XL zeigte dagegen bei der Messung mit den kleinsten Datenrahmen und lag hier gut 10 Prozent unter der maximalen Durchsatzleistung. Bei den Messungen mit größeren Frames lag der Procurve-Switch-5308XL dann wie das D-Link-System konstant bei 100 Prozent Leistung.

Info

So testete Network Computing

Als Lastgenerator und Analysator haben wir in unseren Real-World Labs einen »Smartbits 6000B Traffic Generator/Analysor« von Spirent Comminications eingesetzt. Das in dieser Konfiguration rund 320000 Euro teuere System ist mit der Software »SmartFlow« ausgestattet und mit 24 Gigabit-Ethernet-Kupfer-Ports bestückt. Alle Ports können softwareseitig als Lastgeneratorausgang und/oder als Analysatoreingang eingesetzt werden. Die Class-of-Service-Eigenschaften der Switches im Testfeld haben wir in verschiedenen Testreihen gemäß RFC 2544 (vgl.: www.ietf.org/rfc/rfc2544.txt) gemessen. In diesen Tests haben wir die Priorisierung auf Layer-2 nach IEEE 802.1p/Q untersucht. In unseren Testszenarios »Gigabit-Ethernet-Switches« haben wir verschieden priorisierte Datenströme von einem oder mehreren Eingangsports auf einen oder mehrere Ausgangsports gesendet. Die die Priorisierung festlegenden Bits haben wir im Header der Datenrahmen mit drei Bits nach IEEE 802.1p und auf Layer-2 und nach ToS beziehungsweise Diffserv auf Layer-3 festgelegt. Durch eine gezielte Überlastung der Switches in diesen Tests ist es möglich, das genaue Datenverlustverhalten sowie weitere Testparameter wie Latency oder Jitter zu ermitteln, das Leistungspotential der untersuchten Switches zu analysieren und deren Eignung für bestimmte Einsatzszenarien zu prüfen. Ein Durchsatztest im Multicast-Modus unter Einsatz des Internet-Group-Management-Protocol (IGMP) in der Trainingsphase hat unser Testszenario ergänzt.

Fazit

D-Links DGS-3324SR zeigte – entsprechende Überlasten im Netzwerk vorausgesetzt – deutliche Probleme bei der vierstufigen Priorisierung. Was stimmte waren der Gesamtdurchsatz des Systems. Auch das Verwerfen der Daten der niedrigsten Priorität funktionierte fehlerfrei. Dass der D-Link-Switch andere Priorisierungsmechanismen als Strict-Priority-Queuing erst gar nicht unterstützt, schränkt die Einsatzmöglichkeiten des D-Link-Produktes weiter ein. Kommt der IT-Verantwortliche mit zwei Prioritäten aus und benötigt er kein intelligenteres Bandbreitenmanagement, dann kann der DGS-3324SR durchaus ein interessantes Angebot sein, für unser Szenario ist der kleine Gigabit-Ethernet-Switch von D-Link nicht geeignet.

Recht zuverlässig arbeitete dagegen der HP-Procurve-Switch-5308XL in unserem geforderten Szenario. Wie schon unser Real-Time-Core- und Edge-Switch-Vergleichstest im Frühjahr 2004 gezeigt hat beherrscht die neue Generation der Procurve-Switches neben dem Bandbreitenmanagement auch das Strict-Priority-Queuing recht gut. – Und das auch, wenn immerhin 20 Gigabit-Ethernet-Ports in einem Chassis gleichzeitig arbeiten müssen.

Im Multicast-Test hatte dann der D-Link-Switch die Nase vorn, hier arbeitete der DGS-3324SR durchgängig mit Wirespeed. Dem Procurve-Switch-5308XL war dagegen eine – nicht allzu dramatische – Schwäche bei der Messung mit 64-Byte-Paketen zu attestieren. Diese Schwäche ist allerdings unkritisch, da im Multicast-Betrieb in der Regel große UDP-Pakete – beispielsweise bei der Video-Distribution – zu erwarten sind.

Insgesamt hat der vorliegende Test gezeigt, dass Gigabit-Durchsätze inzwischen machbar sind. Allerdings ist den IT-Verantwortlichen nach wie vor anzuraten, auf unabhängige Tests zu setzen, denn es ist immer noch nicht überall Gigabit und Quality-of-Service drin, wo es drauf steht.

Prof. Dr. Bernhard G. Stütz, [ dg ]