Dafür, dass es im Netz eng wird, sorgen Lastspitzen in vielen auf Ethernet-basierenden Unternehmensnetzen immer wieder, 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. Zu den Auswirkungen von Datenverlusten und den in den Switches implementierten Qualitätssicherungsmechanismen verweisen wir an dieser Stelle auf die ausführlichen Darstellungen in unseren beiden Artikeln in Network Computing 4/2005 (ab Seite 14 und 52). Im vorliegenden Test haben wir den »Omniswitch 6800-48« von Alcatel und den »Allied Telesyn 9924T« auf ihre Class-of-Service- Fähigkeit hin untersucht. Dabei haben wir die Systeme dem gleichen Testverfahren unterworfen, das auch unseren vorhergehenden LAN-Switch-Vergleichstests zu Grunde lag (siehe NWC 4 2005, S.14 ff.).

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 alle Class-of-Service-fähigen LANSwitches in diesem Jahr einer umfangreichen und standardisierten Testprozedur unterzogen.Unser Modellunternehmen 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 sollten verschiedene CoSQueuing- Mechanismen wie Strict-Priority- Queuing oder Weighted-Fair-Queuing, auf ihre Eignung für das geplante Szenario untersucht werden.

Folgende Dienste sollen ins LAN integriert werden:

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

Um die möglichst absolute Störungsfreiheit der Kommunikations- und Arbeitsprozesse im Unternehmen zu garantieren, ist eine vierstufige Daten-Priorisierung sowie eine intelligente Queuing-Policy erforderlich. Gefordert ist von den Switches neben der Datenpriorisierung ein intelligentes Bandbreitenmanagement,das es ermöglicht, von vorneherein eine Überlastung des Backbones zu vermeiden. Daraus ergaben sich folgende Anforderungen an die Teststellungen:  Layer-3-Gigabit-Ethernet-Switch,

•  mindestens 20 Gigabit-Ethernet-Kupfer-Ports (RJ45-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,
•  mindestens zwei CoS-Queuing-Mechanismen, wie Strict-Priority-Queuing, Weighted-Fair-Queuing oder Weighted-Round-Robin, die softwareseitig konfiguriert werden können, sowie
•  Multicast-Funktionalität (IGMP-Snooping).

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.

Die Kandidaten 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. Im zweiten 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,desto 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

In unserem Gigabit-Ethernet-Switch-Test haben wir ausschließlich die Gigabit-Ethernet-Ports der Systeme 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- und Layer-3-Prioritäten – VLAN 7, 5, 3 und 1 nach IEEE 802.1p/Q und Diffserv/ToS 1, 3, 5 und 7 nach RFC 2474 – 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, 256, 512, 1024, 1280 und 1518 Byte.Alle Messungen haben wir zunächst mit Burst- Size 1 und dann mit Burst-Size 100 durchgeführt, um auch aussagefähige Ergebnisse in Bezug auf die Puffer-Speicherkapazität der zu untersuchenden Switches zu erhalten. 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 also in allen Fällen unbeschadet die Systeme passieren.

Bei den Messungen mit Layer-2-Priorisierung und einer Burst-Size von 1 Frame arbeitete sowohl der Alcatel als auch der Allied Telesyn- Switch regelkonform.Beide Systeme leisteten sich keine außerplanmäßigen Datenverluste und priorisierten tadellos.Unter Volllast und mit kleinen Frames verloren die Systeme zum Teil weniger Daten, als zu erwarten gewesen wäre. Dieses Verhalten ist darauf zurückzuführen, dass der Switch die Daten mit kleineren Interframe-Gaps versendet, als in der Norm definiert ist.

Betrug die Burst-Size 100 Frames, zeigte Alcatels Omniswitch-6800-48 einige Probleme mit großen Frames. So betrug der Frame-Loss bei unserer Messung mit 512-Byte-Paketen und 100 Prozent Last in der niedrigsten Priorität rund 11 Prozent, in der zweithöchsten Priorität noch gut 2 Prozent. Mit noch größeren Frames stiegen dann auch die Verlustraten weiter an, die ihr Maximum bei der Messung mit den 1518-Byte- Frames ereichten.Hier waren Datenverluste von durchschnittlich 46 Prozent zu messen, obwohl hier noch gar keine Verluste erforderlich gewesen wären.Auch bei einer Last von 200 Prozent war dieses Verhalten noch feststellbar.Allerdings blieb die höchste Priorität in allen Fällen von Datenverlusten verschont. Der Allied-Telesyn-9924T war bei der Messung mit einer Burst-Size von 100 Frames im Vorteil. Er leistete sich nur ganz geringe Datenverluste in der Größenordnung von maximal 0,01 Prozent in der höchsten Priorität.

Die Messungen mit Layer-3-Priorisierung ähneln in ihren Ergebnissen denen mit Layer-2- Priorisierung. Sowohl der Omniswitch-6800-48 als auch Allied-Telesyn-9924T leisteten sich keine außerplanmäßigen Datenverluste und zeigten ein unkritisches Verhalten.Auch die Ergebnisse der Messungen mit einer Burst-Size von 100 Frames ähneln denen mit Layer-2-Priorisierung. Hier verlor das Alcatel-System in allen Prioritäten mit Ausnahme der höchsten zum Teil deutlich an Daten. So betrug der Mittelwert der Datenverluste über alle Prioritäten bei einer Last von 100 Prozent maximal rund 44 Prozent, obwohl theoretisch gar keine Datenverluste erforderlich gewesen wären. Der Switch von Allied Telesyn leistete sich dagegen keine ungebührlichen Datenverluste und priorisierte auch bei den Burst- Size-100-Messungen einwandfrei.

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 an die Ausgangsports adressiert.Hierbei haben wir Datenströme in den vier Layer-2- und Layer-3- Prioritäten – VLAN 7, 5, 3 und 1 nach IEEE 802.1p/Q und Diffserv/ToS 1, 3, 5 und 7 nach RFC 2474 – 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, 256, 512, 1024, 1280 und 1518 Byte.Die Burst-Size betrug hierbei 1 beziehungsweise 100 Frames. Als Maximalbandbreiten haben wir für die höchste Priorität VLAN beziehungsweise Diffserv/ToS 7 10 Prozent, für VLAN beziehungsweise Diffserv 5 20 Prozent, für VLAN beziehungsweise Diffserv 3 30 Prozent und für VLAN beziehungsweise Diffserv 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. Dass er Bandbreitenmanagement souverän beherrscht, konnte der Alcatel-Switch bei unseren Layer-2-Messungen deutlich machen. So schwankten die durchschnittlichen Abweichungen vom Sollwert über alle Prioritäten zwischen 0,19 Prozent bei der Messung mit den kleinsten Pakten und 0,04 Prozent bei der Messung mit den größten Frames. Diese Ergebnisse waren mit beiden Burst-Formaten gleich. Mehr Probleme hatte der Switch von Allied Telesyn speziell mit kleineren Frames. So war eine Abweichung von durchschnittlich 7,55 Prozent vom Sollwert festzustellen, wenn wir 64- Byte-Frames verwendeten. Mit zunehmender Frame-Größe arbeitete dann auch dieser Switch präziser.Ab 512 Byte Frame-Größe lag die durchschnittliche Abweichung vom Sollwert dann unter 1 Prozent. Die Burst-Größe spielte auch hier keine Rolle.

Fast gleiche Messergebnisse erzielte der Omniswitch- 6800-48 von Alcatel bei unser Messung mit Layer-3-Priorisierung und Bandbreitenmanagement. Hier betrug der Mittelwert der Abweichungen vom Sollwert bei unserer Messung mit 64-Byte-Frames erneut 0,19 Prozent. Verwendeten wir die größten Frames, konnten wir noch eine durchschnittliche Abweichung von 0,05 Prozent ermitteln. Auch bei der Layer-3-Priorisierung arbeitete das Bandbreitenmanagement des Allied-Telesyn- 9924T unpräziser. Bei der Messung mit den kleinsten Frames war hier ein Mittelwert von 8,74 Prozent zu messen. Bei der Messung mit 512- Byte-Frames betrug die durchschnittliche Abweichung vom Mittelwert noch 1,11 Prozent. Und bei der Messung mit den größten Frames ging dieser Wert dann auf 0,34 Prozent zurück. Die Umstellung auf eine Burst-Size von 100 Frames brachte bei keinem der beiden Switches eine signifikante Änderung der Messergebnisse.

Fazit

Beide getesteten Switches haben Schwächen. So verliert der Omniswitch-6800-48 von Alcatel bei den Messungen mit Strict-Priority und einer Burst-Size von 100 Frames noch zu viele Daten. In dieser Disziplin hat das System von Allied Telesyn eindeutig die Nase vorn.Der Allied-Telesyn- 9924T priorisiert wirklich »strict« und lässt sich auch von einer Burst-Größe von 100 Frames nicht irritieren. Die Disziplin Bandbreitenmanagement beherrscht dagegen der Alcatel-Switch eindeutig besser. Probleme in diesem Modus hatte der Switch von Allied Telesyn insbesondere bei unseren Messungen mit kleineren Frames.

Auch wenn beide Switches noch nicht ohne nachweisbare Schwächen arbeiten, kommen sie in unserem Standard-Switch-Test-Verfahren auf die Wertung »A -« und ziehen so mit unserem bisherigen Testsieger und Referenz-Switch des Jahres 2005, dem D-Link DXS-3350SR, gleich. Alcatel ist dies auf Anhieb gelungen, Allied Telesyn hat ihr System nachgebessert und ist so von »B -« auf »A -« aufgestiegen. Es besteht also doch noch Hoffnung, dass sich die Qualität der IT-Systeme bessert und die Branche als solche wieder gesünder wird.

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