Lastspitzen sorgen in vielen auf Ethernet basierenden Unternehmensnetzen immer wieder dafür, dass es im Netz eng wird. 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.

Report-Card: Policy-based Switching Layer-2

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.

Info

Das Testfeld

Core-Switches

• Extreme Networks Alpine 3804

• Hewlett-Packard HP ProCurve Switch 5308XL

• MRV OptiSwitch Master

Edge-Switches

• Cisco Catalyst 2950G-24

• D-Link DES-3326S

• Extreme Networks Summit 48si

• Hewlett-Packard HP ProCurve Switch 5308XL

• MRV OptiSwitch Master

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 NCI-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 Datenrahmen-Verlustverhalten als primäres K.o.-Kriterium für unseren Test 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.

Messeregbnisse mit Bandbreitenmanagement in Prozent

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, eignen sich lediglich für langsame Switches.

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),

• Stirct- 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.

Info

Real-Time-Switches in Network Computing

• Real-Time-Core- und -Edge-Switches, Klassengesellschaft im Netz, Teil 1 Core-Switches, in NWC 4/04, S. 14 ff.,

• Klassengesellschaft im Netz die Theorie, in NWC 4/04, S. 48 ff.,

• Pilottest Class-of-Service-Queuing: Vorfahrt im Netz, in Special Konvergenz, S.II in NWC 20/03.

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 ein Feld von Class-of-Service-fähigen LAN-Switches in unseren Real-World Labs an der FH Stralsund einer umfangreichen Testprozedur unterzogen. Um unseren Test wie gewohnt von vornherein 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 sein 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, sind eine vierstufige Daten-Priorisierung sowie eine intelligente Queuing-Policy erforderlich. Gefordert haben wir für die Edge-Switches neben der Datenpriorisierung ein intelligentes Bandbreitenmanagement, das es ermöglicht, von vornherein eine Überlastung des Backbones zu vermeiden. Aber auch die Core-Switches sollten mindestens zwei CoS-Queuing-Mechanismen beherrschen, so dass die Implementierung der gewünschten und notwendigen Switching-Policy im gesamten Netzwerk möglich ist. Aus diesem Szenario ergaben sich im Detail die folgenden Anforderungen an die Teststellungen.

Teststellung Core-Switch

• Layer-3-Ethernet-Switch,

• mindestens 5 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.

Teststellung Edge-Switch

• Layer-3-Ethernet-Switch,

• mindestens 24 Fast-Ethernet-Ports und 2 Gigabit-Ethernet-Ports (Multimode-LWL mit SC-Stecker oder Kupfer),

• 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 2 CoS-Queuing-Mechanismen wie Strict-Priority-Queuing, Weighted-Fair-Queuing oder Weighted-Round-Robin, die softwareseitig konfiguriert werden können, sowie

• Bandbreitenmanagement mit einstellbaren Maximalbandbreiten je Priorität.

Als Testverfahren haben wir Messungen nach RFC 2544 (One-to-Many, Many-to-One, Many-to-Many) 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 alle einschlägigen Hersteller geschickt und diese eingeladen, an unserem Real-World-Labs-Test in unseren Labs an der FH Stralsund teilzunehmen. Letztendlich folgten die Firmen Cisco, Compu-Shack, D-Link, Extreme Networks, Hewlett-Packard und MRV unserer Einladung. Compu-Shacks »GIGAline Xologic 2600M« unterstützte entgegen unserer Test-Spezifikation nur zwei Prioritäten, weshalb wir den Switch aus dem Testfeld herausnehmen mussten. Das Feld der Core-Switches bildeten Extreme Networks »Alpine 3804«, Hewlett-Packards »HP ProCurve Switch 5308 XL« und MRVs »OptiSwitch Master«. Cisco hat ihren ursprünglich zugesagten Core-Switch – vermutlich auf Grund von Vortests in ihrem Hause – unmittelbar vor ihrem Testtermin in unseren Real-World Labs aus dem Rennen genommen. Als Edge-Switches standen dann Ciscos »Catalyst 2950G-24«, D-Links »DES-3326S«, Extreme Networks »Summit 48si«, Hewlett-Packards »HP ProCurve Switch 5308XL« und MRVs »OptiSwitch Master« zur Verfügung. Wie die Core-Switches sich in unserem Test bewährt haben, steht im ersten Teil dieses Vergleichstests, den wir in Network Computing 4/04 ab Seite 14 veröffentlicht haben.

Die Edge-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 zweite Testszenerie 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 zugunsten 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 desto mehr Header-Informationen auszuwerten, je 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-Priority-Switching

Im Edge-Switch-Test haben wir mit drei Test-Setups gearbeitet. Zunächst haben wir ausschließlich die Fast-Ethernet-Ports der Systeme im Test eingesetzt. Um die notwendigen Lasten erzeugen zu können haben wir mit unseren Smartbits auf 16 Fast-Ethernet-Eingangs-Ports gesendet und vier Fast-Ethernet-Ausgangs-Ports adressiert. Im zweiten Test-Setup haben dann zwei Gigabit-Ethernet-Eingangs-Ports fünf Fast-Ethernet-Ausgangs-Ports adressiert. In diesen beiden Test-Setups beträgt die maximale Überlast am Switch-Ausgang 400 Prozent. Im dritten Test-Setup haben die Smartbits-Lastgeneratoren auf 24 Fast-Ethernet-Eingangs-Ports ihre Datenströme gesendet und dann auf einen Gigabit-Ethernet-Ausgangsport adressiert. Alle drei Test-Setups bilden so gemeinsam die Datenströme ab, die ein Edge-Switch in typischen Unternehmensnetzen zu bewältigen hat, nämlich Uplink, Downlink und (gruppen-)interne Kommunikation.

Da wir die Switches systematisch überlastet haben, kam es bei einer maximalen Last von 100 Prozent auf den Eingangsports zu einer vierfachen beziehungsweise 2,4-fachen Überlastung des oder 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 den oder die Eingangs-Ports gesendet und diese Datenströme auf den oder 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, die in den Szenarien Fast-Ethernet vs. Fast-Ethernet und Gigabit-Ethernet vs. Fast-Ethernet entsteht, einer Last am Ausgangsport von 100, 133, 200 und 400 Prozent entspricht. Bei unseren Tests mit dem Setup Fast-Ethernet vs. Gigabit-Ethernet haben wir Eingangslasten von 41,67, 55,55, 83,33 und 100 Prozent verwendet, die wegen der maximal möglichen 2,4-fachen Überlast in diesem Szenario Lasten von 100, 133, 200 und 240 Prozent am Ausgangsport entsprachen.

Die Datenströme bestanden aus konstant großen Frames von jeweils 64, 128, 512, 1024 und 1518 Byte. Als Burst-Size haben wir einmal 1 Frame und danach 100 Frames verwendet. Die gleiche Messreihe haben wir dann mit Layer-3-Priorisierung nach Diffserv wiederholt und Datenströme der Prioritäten DSCP 48, 32, 16 und 0 generiert. 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 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. Beträgt die Maximallast am Ausgangsport 240 Prozent, sind Verluste von 100 Prozent für die beiden niedrigen Prioritäten und von 33,33 Prozent in der zweitniedrigsten Priorität zu erwarten. Die Daten der höchsten Priorität sollten in allen Fällen unbeschadet die Systeme passieren.

Generell beherrschten alle fünf Edge- wie zuvor auch die drei Core-Switches die vierstufige Priorisierung. Gegenüber unseren Testsergebnissen im vergangen Jahr fällt auf, dass in der Disziplin Strict-Piority-Switching, die auch schon im CoS-LAN-Switch-Vergleichstest 2003 Gegenstand unserer Untersuchungen war, alle Switches – mit einer einzigen Ausnahme – die höchste Priorität auch wirklich strikt behandelt hat. Weiterhin sind die Probleme mit kleinen Datenrahmen, die im vergangenen Jahr noch weiter verbreitet und auf eine nicht ausreichende Rechenpower zurückzuführen waren, kein großes Thema mehr.

Allerdings hatten alle Systeme im Testfeld unter bestimmten Bedingungen Schwierigkeiten, ihre Vorgaben zu erfüllen. Dabei teilt sich das Feld in Systeme, die Strict-Piority-Switching besonders gut beherrschen, und in solche, die eher auf Bandbereitenmanagement fokussiert sind.

In einzelnen Szenerien kam es bei den Tests der Edge-Switches teils zu massiven zu Datenverlusten in den niedrigeren Prioritäten, insbesondere bei einer Burst-Size von 100 Frames, obwohl diese gar nicht erforderlich gewesen wären.

Cisco hatte ihre Hausaufgaben gemacht, der sorgsam ausgewählte Catalyst-2950G-24 erlaubte sich keine größeren Schwächen. Eine Ausnahme bildet hierbei das Uplink-Test-Setup. Als der Cisco-Switch mit allen 24 Fast-Ethernet-Ports auf einen Gigabit-Ethernet-Port senden musste, verlor er bei den Messungen mit einer Burst-Size von 100 Frames bereits bei 100 Prozent Last am Ausgangsport massiv Daten in den niedrigen Prioritäten, so dass die Gesamtverluste bei allen drei gewerteten Frame-Größen um die 30 Prozent schwankte. Für die Datenströme der einzelnen niedrigen Prioritäten bedeutet dieses Verhalten Verlustraten von mehr als 60 Prozent, obwohl der Switch gerade voll ausgelastet war und Datenverluste noch gar nicht erforderlich gewesen wären. Bei höheren Lasten am Ausgangsport versteckte sich diese Schwäche quasi hinter den ohnehin von der Technologie und dem Testaufbau her erforderlichen Verlustraten. Die beiden hohen Prioritäten blieben aber von diesem Effekt weitgehend unbehelligt. In der höchsten Priorität konnten wir hier keine Datenverluste ermitteln, in der zweithöchsten Priorität blieben die maximalen Datenverluste unter drei Prozent.

Auch die Entwickler im Hause D-Link sind in den vergangenen Monaten nicht untätig gewesen. Im internen Datenverkehr zwischen den Fast-Ethernet-Ports leistete sich D-Links DES-3326S keinerlei Schwächen. Im Downlink-Modus Gigabit-Ethernet vs. Fast-Ethernet gelangte das System dann bei Höchstlast, 1518 Byte großen Frames und Burst-Size 100 an seine Grenzen. Hier teilten sich plötzlich die beiden hohen Prioritäten die Datenverlustraten brüderlich, obwohl die höchste Priorität vor der zweithöchsten absoluten Vorrang haben sollte. Die zweite Schwäche, die der D-Link-Switch noch zeigte, gleicht ziemlich exakt der oben beschriebenen Schwäche des Cisco-Systems. Auch der D-Link-Swich produzierte im Uplink-Betrieb schon bei 100 Prozent Last am Ausgangsport Verlustspitzen in den niedrigen Prioritäten von bis zu rund 62 Prozent, obwohl hier noch alle Daten ungehindert hätten passieren sollen. Aber auch diese Schwäche des D-Link-Switches beschränkt sich wie bei Cisco auf die beiden niedrigen Prioritäten, die beiden hohen Prioritäten blieben weitgehend unberührt.

Extreme Networks Summit-48si litt unter der gleichen Schwäche wie die Switches von Cisco und D-Link. Allerdings waren hier nicht nur der Uplink-Modus, sondern auch die Switch-interne Fast-Ethernet-Fast-Ethernet-Kommunikation betroffen. Hier gingen bis zu 30 beziehungsweise 35 Prozent der Daten in den niedrigen Prioritäten verloren, obwohl noch gar keine Datenverluste erforderlich gewesen wären. Im Betrieb Gigabit-Ethernet vs. Fast-Ethernet arbeitete der Extreme-Edge-Switch dagegen mustergültig.

Auch Hewlett-Packards Procurve-Switch-5308XL verlor unnötig viele Daten bei den Messungen mit 100 Prozent Last am Ausgangsport und einer Burst-Size von 100. Im Betrieb Fast-Ethernet vs. Fast-Ethernet betrugen die maximalen Verlustraten rund 50 Prozent. Im Betrieb Gigabit-Ethernet vs. Fast-Ethernet arbeitete das HP-System dagegen ohne Fehl und Tadel. Bei den Messungen Fast-Ethernet vs. Gigabit-Ethernet, 100 Prozent Last am Ausgangsport und einer Burst-Size von 100 Frames wiederholte sich dann das Bild. Hier kam der Switch auf Verluste von rund 30 Prozent. Und auch bei einer Last von 200 Prozent lagen hier noch die unerwünschten Verluste in der zweithöchsten Priorität bei maximal rund 30 Prozent. Die Daten der höchsten Priorität blieben aber auch bei dem HP-Switch bei allen Messungen unberührt.

MRVs Optiswitch-Master verlor bei den Messungen Fast-Ethernet vs. Fast-Ethernet und einer Burst-Size von 100 Frames massiv an Daten. So verwarf das System beispielsweise bei der Messung mit 1518-Byte-Paketen in der zweithöchsten Priorität ein Maximum von gut 87 Prozent der Daten. Bei 200 Prozent Last wiederholte sich das Bild. Erst bei Maximalllast arbeitete das MRV-System wie erwartet, da es ohnehin die Daten mit Ausnahme der höchsten Priorität verwerfen sollte, und in der höchsten Priorität leistete sich auch der Optiswitch-Master keinerlei Schwächen. In der Disziplin Gigabit-Ethernet vs. Fast-Ethernet arbeitete auch der MRV-Switch verlässlicher. Bei einer Burst-Size von 100 Frames und eine Last am Ausgangsport von 100 beziehungsweise 200 Prozent waren aber wieder unerwünschte Datenverluste festzustellen. Dabei gingen hier in der zweithöchsten Priorität rund 20 beziehungsweise 25 Prozent aller Daten verloren. Probleme hatte der Optiswitch-Master dann auch bei den Messungen Fast-Ethernet vs. Gigabit-Ethernet. Hier waren schon bei einer Burst-Size 1, einer Last am Ausgangsport von 1 Frame und 1518-Byte-Pakten Verluste von mehr als 12 Prozent in allen Prioritäten mit Ausnahme der höchsten zu verzeichnen. In den niedrigen Prioritäten gingen dann bei einer Burst-Size von 100 Frames bis zu mehr als 95 Prozent der Daten verloren.

Sollwerte in Prozent

Switching mit Bandbreitenmanagement

Auch in unseren Tests mit Bandbreitenmanagement haben wir jeweils mit unseren Smartbits-Lastgeneratoren Datenströme auf den oder die Eingangs-Ports gesendet und diese Datenströme auf den oder 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, die in den Szenarien Fast-Ethernet vs. Fast-Ethernet und Gigabit-Ethernet entsteht, einer Last am Ausgangsport von 100, 133, 200 und 400 Prozent entspricht. Bei unseren Tests mit dem Setup Fast-Ethernet vs. Gigabit-Ethernet haben wir Eingangslasten von 41,67, 55,55, 83,33 und 100 Prozent verwendet, die wegen der maximal möglichen 2,4-fachen Überlast in diesem Szenario Lasten von 100, 133, 200 und 240 Prozent am Ausgangsport entsprachen.

Die Datenströme bestanden aus konstant großen Frames, zunächst haben wir für die VLAN-Prioritäten 7 und 1 1518- und für die VLN-Prioritäten 5 und 3 64-Byte-Pakete verwendet. Dann haben wir die Messungen mit 1518-Byte-Paketen in allen Prioritäten wiederholt. 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 Bandbreiten management 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. Ein später im Jahr folgender Test wird diese Mechanismen noch detaillierter analysieren.

Insgesamt haben die Edge-Switches im Testfeld auch in der Bandbreitenmanagement-Disziplin recht ordentlich gearbeitet. Allerdings musste D-Link hier passen, ihr DES-3326S beherrschte ausschließlich die Strict-Priority, Bandbreitenmanagement war hier nicht implementiert. Auch hier unterschieden sich die übrigen Switches im Testfeld teils deutlich. Arbeiteten alle Edge-Switches mit homogenen Frame-Größen hier noch recht gut, so trennte sich das Feld dann bei den Messungen mit heterogenen Frame-Formaten.

Mit Abweichungen vom Sollwert von unter einem Prozent arbeitete Ciscos Catalyst-2950G-24 im Test mit homogenen Frame-Formaten recht zuverlässig. Bei den Messungen mit heterogenen Frame-Größen im Modus Fast-Ethernet vs. Fast-Ethernet hatte der Cisco-Switch dagegen deutliche Probleme, die konfigurierten Werte zu halten. In der höchsten und der niedrigsten Priorität waren die Verlustraten deutlich niedriger als konfiguriert. Dafür verwarf der Cisco-Switch in den beiden mittleren Prioritäten erheblich mehr Daten als gewünscht. Die durchschnittliche Abweichung aller Kategorien vom eingestellten Sollwert betrug hier über 19 Prozent. Bei den Uplink- und Downlink-Messungen verhielt sich der Cisco-Switch fast genauso, hier betrugen die Mittelwerte der Abweichungen vom Sollwert bei der Verwendung heterogener Frame-Größen gut 18 beziehungsweise 21 Prozent.

Extreme Networks Summit-48si verhielt sich ähnlich wie der Cisco-Switch. Allerdings arbeitete das System schon bei den Messungen mit homogenen Frame-Größen ein wenig unpräziser. So lagen hier für Fast-Ethernet vs. Fast-Ethernet und Gigabit-Ethernet vs. Fast-Ethernet die mittleren Abweichungen bei rund 5 Prozent. Im Uplink-Modus kam der Extreme-Switch sogar auf gut 8,4 Prozent. Dafür lagen die mittleren Abweichungen bei den Messungen mit heterogenen Frame-Größen mit zweimal über 13 und dann gut 18 Prozent jeweils unter denen des Cisco-Switch.

Am präzisesten in der Disziplin Bandbreitenmanagement arbeitete Hewlett-Packards Procurve-Switch-5308XL mit 0,36 und 2,20 Prozent Sollwertabweichung bei den Messungen Fast-Ethernet vs. Fast-Ethernet und Gigabit-Ethernet vs. Fast-Ethernet sowie 0,81 sowie 3,89 Prozent im Modus Fast-Ethernet vs. Gigabit-Ethernet. Hier bewies das HP-System echtes Standvermögen.

Auch MRVs Optiswitch-Master vermochte im Bereich Bandbreitenmanagement zu punkten. Mit 0,22 und 0,82 Prozent-Sollwertabweichung liegt der Switch in der Disziplin Fast-Ethernet vs. Fast-Ethernet noch vor dem HP-System. Bei den übrigen Messungen vermochte der MRV-Switch dann allerdings nicht das Niveau zu halten. So zeigte er bei den Messungen Gigabit-Ethernet vs. Fast-Ethernet durchschnittliche Sollwertabweichungen von 4,5 und 8,69 Prozent. Im Modus Fast-Ethernet vs. Gigabit-Ethernet erreichte er zwar vorbildliche Abweichungen von 0,45 Prozent bei den Messungen mit homogenen Frame-Größen. Bei der Verwendung heterogener Frame-Formate lag die mittlere Sollwertabweichung mit fast 20 Prozent dann aber wieder zwischen den Systemen von Cisco und Extreme, was bei diesen Messungen das obere, negative Ende der Skala bedeutet.

Insgesamt kamen die Switches im Testfeld trotz einiger spezifischer Schwächen relativ gut mit den Vorgaben unserer Testspezifikation zurecht. Solange die Burst-Size 1 betrug war die Switch-Welt weitgehend in Ordnung, deutliche Datenverluste in der höchsten Priorität gehören hier der Vergangenheit an. Auch die im Vorjahr noch häufig festzustellende Schwäche bei der Verarbeitung von keinen Datenrahmen war in dieser Form nicht mehr festzustellen. Trotzdem leisteten sich alle fünf Edge-Switches mehr oder weniger ärgerliche Schwächen, die unsere Messergebnistabellen recht deutlich hervorheben und die Report-Card entsprechend bewertet.

Die erstmals in einem Real-World-Labs-Vergleichstest für Network Computing untersuchten Bandbreitenmanagement-Switching-Eigenschaften haben gezeigt, dass die Systeme im Test zum Teil unter Last recht stark von den konfigurierten Sollwerten abweichen und somit die Durchsetzung einer intelligenten Switching-Policy im Unternehmensnetz schwierig machen. Hier haben auch etablierte, im Strict-Priority-Switching recht gute bis sehr gute Werte erzielende Hersteller noch Entwicklungsbedarf.

Im Bereich des Strict-Priority-Switchings zeigte Ciscos Catalyst-2950G-24 nur bei den Messungen im Uplink-Test deutliche Schwächen, wobei auch hier die Daten der höchsten Priorität unbehelligt das System passieren konnten. Als zweite Hürde erwies sich für den Cisco-Switch das Switching mit Bandbreitenmanagement, wenn heterogene Frame-Größen zum Einsatz kamen. Insgesamt reichen die Leistungen des Cisco-Systems aber immerhin für einen guten zweiten Platz.

Auch D-Links DES-3326S vermochte über weite Strecken des Strict-Priority-Tests zu überzeugen. Deutliche Schwächen zeigte der DES-3326S ähnlich wie das Cisco-System im Uplink-Test. Im Vergleich zu den Testergebnissen in den vergangenen Jahren ist aber hervorzuheben, dass D-Link hier insgesamt aufgeholt hat und die Strict-Priority inzwischen recht gut beherrscht. Schade, dass der Betrieb mit Bandbreitenmanagement derzeit noch nicht möglich ist, hier durch sind die Einsatzmöglichkeiten des D-Link-Systems noch eingeschränkt.

Extreme Networks Summit-48si arbeitete im Strict-Priority-Bereich recht zuverlässig. Schwächen zeigte er insbesondere im Bereich der Messungen mit einer Burst-Size von 100 Frames. Bei den Tests mit Bandbreitenmanagement hatte der Extreme-Switch Probleme, wenn heterogene Frame-Größen zum Einsatz kamen. Hier vermögen andere Systeme besser zu überzeugen.

MRVs Optiswitch-Master war dem Extreme-Switch im Bereich des Messungen mit Bandbreitenmanagement insgesamt überlegen, wobei der Optiswitch-Master große Leistungsunterschiede zwischen den Modi interne Kommunikation, Uplink und Downlink zeigte. Hier schwanken seine Messwerte zwischen dem besten und dem schlechtesten System im Testfeld. Im Bereich Strict-Priority-Switching lag das MRV-System dann hinter Extreme, so dass sich Extreme Networks und MRV einen guten dritten Platz in der Edge-Switch-Wertung teilen.

Hewlett-Packards Procurve-Switch-5308XL vermochte insbesondere im Bandbreitenmanagement-Switch-Test zu überzeugen, aber auch das Strict-Priority-Switching beherrscht der HP-Switch inzwischen recht gut. Positiv hervorzuheben ist an dieser Stelle, dass HP auf Grund der Ergebnisse unserer CoS-Switch-Tests im vergangenen Jahr, bei denen der damals getestete Procurve-5304XL Strict-Priority-Switching überhaupt nicht beherrschte, nachgebessert und die aktuelle Software entsprechend überarbeitet hat. Dass HP im Bereich Bandbreitenmanagement über mehr Erfahrung verfügt, zeigte der Procurve-Switch-5308XL im Bandbreitenmanagement-Test, wo er deutlich präziser als der Mitbewerb arbeitete und sich auch durch die Verwendung heterogener Frame-Größen nicht aus dem Takt bringen ließ, so dass es für HP dieses Mal für einen ersten Platz reicht.

Kritisch ist generell die Verwendung von mehr als zwei Prioritäten, dies hat auch der vorliegende Test deutlich gezeigt. Die Daten höchster Priorität wurden nahezu durchgängig bevorzugt behandelt. Eine weitere Differenzierung – wir hatten vier Stufen gefordert, acht sehen die zu Grunde liegenden Standards vor – kann schnell zur Glücksache werden. Diese Situation zu verbessern, sind die Hersteller gefragt. Probleme wie zu knappe Pufferspeicher sollten sie möglichst bald angehen.

Insgesamt hat unser Edge- ebenso wie unser Core-Switch-Vergleichstest gezeigt, dass die Hersteller inzwischen gelernt haben, die höchste Priorität bei Überlasten der jeweiligen Policy entsprechend bevorzugt zu behandeln. Somit ist der Aufbau eines konvergenten Netzwerks mit zwei Prioritäten – hoch und niedrig, also mit Echtzeit-Applikation wie Voice-over-IP und traditioneller Datenkommunikation – beim heutigen Stand der Technik weitgehend unkritisch. Soll ein Netzwerk wie in unserem Szenario dagegen mehrstufig priorisieren und so eine effiziente Plattform für mehrere Services bieten, dann stehen die IT-Verantwortlichen wie die Hersteller wieder vor einer komplexen Aufgabe. So hat unser Test gezeigt, dass die Einhaltung der Vorgaben für die zweithöchste Priorität Glücksache ist, keiner der im Testfeld befindlichen Switches hat hier wirklich zur vollen Zufriedenheit gearbeitet.

Dabei mehren sich die Probleme deutlich bei einer Burst-Size von 100 Frames. Gerade diese Disziplin ist aber ein heute in vielen Unternehmensnetzen häufig auftretendes Phänomen, dem sie gewachsen sein sollten. Noch größere Bursts sollten Netzwerkverantwortliche durch ein geeignetes Bandbreitenmanagement im Edge- wie im Core-Bereich allerdings vermeiden. Bei der Burst-Size-100-Problematik ist zu beachten, dass die beobachteten Datenverluste auf Pufferspeicher- oder Speichermanagementprobleme zurückzuführen sind. Muss der Switch im Test mehr Daten verarbeiten, als seine Speicher »verdauen« können, dann kommt es bei Systemen, die mit Store-and-Foreward-Technologie arbeiten, zwangsläufig zu teils erheblichen Verlustraten. Wichtig ist es daher, die Burst-Größen mit Hilfe von intelligentem Bandbreitenmanagement immer so klein zu halten, dass die Pufferspeicher nicht überlastet werden.

So testete Network Computing

Als Lastgenerator und Analysator haben wir in unseren Real-World Labs einen »Smartbits 6000B Traffic Generator/Analyze« von Spirent Comminications eingesetzt. Das in dieser Konfiguration rund 250000 Euro teuere System ist mit der Software »SmartFlow« ausgestattet und mit 24 Fast-Ethernet-Ports, fünf Gigabit-Ethernet-LWL-Ports sowie vier 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 ver- schiedenen Testreihen gemäß RFC 2544 (vgl.: www.ietf.org/rfc/rfc2544.txt) gemessen. In diesen Tests haben wir zunächst die Priorisierung auf Layer-2 nach IEEE 802.1p/Q und dann die Priorierung auf Layer-3 nach Diffserv beziehungsweise ToS untersucht. In unseren Testszenarios »Real-Time-Core- und -Edge-Switches« haben wir verschieden priorisierte Datenströme von einem oder mehreren Eingangsports auf einen oder mehrere Ausgangsports gesendet. Hierbei haben wir Fast-Eternet- sowie Gigabit-Ethernet-Ports verwendet. 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.

Daher sind nicht nur die Hersteller aktiver Komponenten, sondern auch die IT-Verantwortlichen in den Unternehmen und die Systemintegratoren gefragt. Ein mehrstufiges Priorisieren, wie es in modernen konvergenten Netzen, die verschiedene Real-Time-Applikationen integrieren, notwendig ist, erfordert ein wirklich intelligentes Bandbreitenmanagement, das durchgängig im gesamten Netzwerk realisiert wird und dafür sorgt, dass die vorhandenen und entsprechend reservierten Ressourcen nicht überschritten werden. Nur ein intelligentes Bandbreitenmanagement schützt den Core-Bereich des Netzwerks wirklich effizient und vermeidet, dass es zur Überforderung der Pufferspeicher kommt. Allerdings ist die Implementation einer solchen Policy nicht gerade trivial. Sie setzt voraus, dass die Lasten, die ein Netzwerk verarbeiten muss, recht detailliert bekannt sind. Dann muss eine exakte Policy erstellt werden. Um diese zu realisieren, sind alle Switches im Netz entsprechend zu konfigurieren. Wenn dann auch noch die Switches tun, was ihre Hersteller versprechen, dann klappt es auch mit der Priorisierung und der Kommunikation im konvergenten Netz. Prof. Dr. Bernhard G. Stütz, [ dg ]