Dreifaches Spiel im Netz

Der SMC8824M ist ein managebarer, stapelbarer 10/100/100BaseT-Switch mit optionalen 10-Gigabit-Ethernet-Uplinks und vielfältigen Einsatzfunktionen. Dieser »Gigabit Workgroup Aggregator Switch« wurde – so der Hersteller – speziell zur Bewältigung von Anwendungen mit hohem Bandbreitenbedarf entwickelt. Ermöglichen soll das seine 128-GBit/s-Non-blocking-Single-Chip-Switching-Architektur. Der SMC8824M ist der erste SMC-Switch, der über IPv6-Managementfunktionen verfügt.

Der Switch soll kostenbewusstes Gigabit-Ethernet-Switching für Bandbreiten-intensive Netzwerke gewährleisten, an die hohe Anforderungen in den Switching-Funktionen gestellt werden; darunter Quality-of-Service mit acht Prioritätsebenen, Weighted-Fair-Queing und L2/3/4-IP. Mit diesen Funktionen soll der SMC8824M die gleichmäßige Übertragung einsatzkritischer Daten sicherstellen. VLANs, basierend auf Frame-Tag, Port oder Protokoll, die Unterstützung der automatischen GVRP-LAN-Registrierung und von Multiple-Spanning-Tree sollen ein Maximum an Sicherheit und Bandbreiteneffizienz garantieren. Die umfassenden Sicherheitsmerkmale schließen Radius, IEEE802.1x, SSH, SSL, Tacacs+ und ACL ein. Mit hoher Portdichte und nur eine Höheneinheit hoch positioniert SMC diesen Switch als Lösung für den Einsatz in Arbeitsgruppen von Unternehmen.

Testparameter und Verfahren
In unserem standardisierten Testverfahren musste der SMC8824M nun unter Beweis stellen, wie performant er wirklich in Triple-Play-Netzen arbeitet. 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.

Durchgeführt haben wir insgesamt vier Class-of-Service-Testreihen jeweils mit Layer-3-Priorisierung und abwechselnd unter Verwendung der Priorisierungsmechanismen Strict-Priority und Bandbreitenmanagement. In den ersten beiden Test-Setups haben wir die Datenverlustraten sowie Latency und Jitter bei der Datenkommunikation zwischen den Gigabit-Ethernet-Ports untereinander auf einem Switch untersucht. Dabei haben wir in der ersten Testreihe die Switches im Multicast-Modus und in der zweiten Testreihe im Unicast-Modus betrieben. Bei der dritten Testreihe haben wir dann ein Downlink-Szenario aufgebaut. Hierbei sendeten zwei 10-Gigabit-Ethernet-Ports auf die verfügbaren Gigabit-Ethernet-Ports. In der vierten Testreihe hatte das entsprechende Uplink-Szenario von den Gigabit-Ethernet-Ports auf einen 10-Gigabit-Ethernet-Port zum Thema. Die Ergebnisse des vorhergehenden Vergleichstests stellten wir in Network Computing 4 sowie 9-10/2006 vor. Die Resultate unseres aktuellen Nachtests folgen im hiermit vorliegenden Artikel.

Testreihe Multicast
In der ersten Testreihe 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 die niedrigste 8 entspricht. Die Datenströme dieser einzelnen Prioritäten wurden dann in die jeweiligen Hardware-Queues geleitet.

Die 20 übrigen Gigabit-Etherent-Ports abonnierten im Multicast-Modus alle vier Datenströme, so dass bei Volllast an den Eingangsports eine vierfache Überlast an 20 Ausgangsports anlag, was einer Gesamtlast des Switches von 80 GBit/s entspricht. In nacheinander folgenden Messungen hat der Spirent-Lastgenerator Datenströme bestehend aus Datenrahmen von je 64, 128, 256, 512, 1024, 1280 und 1518 Byte erzeugt. Alle Messungen haben wir zunächst mit Burst-Size 1 und dann mit Burst-Size 100 durchgeführt.

Beträgt die Burst-Size einen Frame, bedeutet dies, dass der Lastgenerator die erzeugte Last kontinuierlich auf der Zeitachse verteilt sendet. Der belastete Switch kann so die erzeugte Last kontinuierlich abarbeiten. Im Betrieb mit einer Burst-Size von 100 Frames sendet der Lastgenerator dagegen mit Leitungsgeschwindigkeit 100 Frames nacheinander. Dann folgt eine Pause, so dass der Generator im Mittel die jeweils konfigurierte Durchsatzleistung erzeugt. Während der Sendephase muss der belastete Switch die Datenströme im Pufferspeicher zwischenspeichern und in der folgenden Pause abarbeiten.

Die Last an den Eingangsports startete jeweils bei 25 Prozent und wurde dann in entsprechenden Schritten auf 100 Prozent erhöht. Das bedeutete an den Ausgangsports eine Last zwischen 100 und 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 idealtypisches Verhalten zeigen: Bei 100 Prozent Last sollten alle Datenströme ungehindert weiter geleitet werden. Bei zunehmender Last sollten die Switches dann jeweils möglichst viele Daten der niedrigsten Prioritäten verlieren und möglichst viele Daten der hohen Prioritäten unbeschadet passieren lassen. Bei vierfacher Überlast sollte der jeweilige Switch folglich alle Daten mit Ausnahme denen der höchsten Priorität verwerfen.

Für die Tests mit Bandbreitenmanagement haben wir eine einfache Policy definiert, die bestimmten Applikationen Bandbreiten reservieren sollte. Als Maximalbandbreiten haben wir für die höchste Priorität DSCP-Wert 56 10 Prozent, für DSCP-Wert 40 20 Prozent, für DSCP-Wert 24 30 Prozent und für DSCP-Wert 8 40 Prozent gefordert. Ansonsten entsprachen Testaufbau und -durchführung dem mit Strict-Priority.

Aus den Ergebnissen dieser Messungen ist dann 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 hoch priorisierten verwerfen. Ein Datenverlust in der höchsten Priorität dürfte bei allen 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.

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.

Im Multicast-Betrieb mit Strict-Priority und einer Burst-Size von 1 Frame arbeitete der SMC8824M beinahe mustergültig. Lediglich bei der Messung unter Volllast mit dem größten Frame-Format verlor der SMC-Switch auch in der höchsten Priorität 1,56 Prozent an Daten. Ungebührliche Datenverluste leistete er sich dagegen im Betrieb mit einer Burst-Größe von 100 Frames. Hier schwankten schon bei 100 Prozent Last die Datenverluste in der zweithöchsten wie auch in den beiden niedrigen Prioritäten zwischen rund 39 und 95 Prozent. Dabei stiegen die Verlustraten mit zunehmender Frame-Größe an. Lediglich die höchste Priorität kam wie schon zuvor bei der Burst-Size-1-Messung nahezu unbeeinträchtigt durch.

Mit Bandbreitenmanagement kam der SMC8824M dann wieder besser zurecht. Verwendeten wir kleine Frame-Formate, arbeitete das System mustergültig. Mit ansteigender Frame-Größe ging der Switch dann dazu über, die zugewiesenen Bandbreiten anzugleichen. Bei unseren Messungen mit den größten Frames hat er dann über alle Prioritäten hinweg gleich große Verlustraten erzeugt. Dieses Verhalten hatte zur Folge, dass der SMC8824M zunehmend von den Sollwerten abwich. Der Wechsel zwischen den verschiedenen Burst-Formaten änderte nichts am Verhalten des Systems.

Testreihe Unicast
In der zweiten Testreihe unserer Class-of-Service-Testsuite haben wir mit unserem Lastgenerator auf 16 Gigabit-Ethernet-Ports parallel Datenrahmen gesendet und diese an vier Gigabit-Ethernet-Ports adressiert. Dabei sendete jeder Input-Port vier Datenströme der vier Prioritätsklassen an jeden Output-Port. Da 16 Ports gleichzeitig sendeten betrug die Gesamtlast des Systems in diesem Unicast-Betrieb 16 GBit/s. In nacheinander folgenden Messungen hat der Spirent-Lastgenerator Datenströme bestehend aus Datenrahmen von je 64, 128, 256, 512, 1024, 1280 und 1518 Byte erzeugt. Alle Messungen haben wir zunächst mit Burst-Size 1 und dann mit Burst-Size 100 durchgeführt, um auch aussagefähige Ergebnisse in Bezug auf die Kapazität der Pufferspeicher zu erhalten. Auch hier haben wir die Priorisierungsmechanismen Stirct-Priority und Bandbreitenmanagement eingesetzt. Alle weiteren Details entsprechen der ersten Testreihe oben.

Im Unicast-Betrieb mit Strict-Priority und einer Burst-Size von 1 Frame verhielt sich der SMC8824M wieder absolut mustergültig. Probleme hatte er dann wieder bei unseren Messungen mit einer Burst-Size von 100 Frames. Auch hier stiegen die unerwünschten Datenverluste mit der Größe der verwendeten Frames an. Bei unseren Messungen mit 64- und 128-Byte-Frames war die Welt noch völlig in Ordnung. Mit 512-Byte-Frames konnten wir dann schon bei 100 Prozent Last rund 35 Prozent Frame-Loss in der zweithöchsten sowie in den niedrigeren Prioritäten feststellen. In der höchsten Priorität lagen hier die Datenverluste bei gut sechs Prozent. Verwendeten wir noch größere Frames, dann stiegen auch die Verluste weiter an. Insgesamt blieben sie aber etwas unter dem Niveau, das sie im Multicast-Modus erreichten. Unter Volllast schaffte es der SMC-Switch dann auch wieder, die höchste Priorität frei von nennenswerten Verlusten zu halten.

Im Unicast-Betrieb mit Bandbreitenmanagement verhielt sich der SMC8824M dagegen völlig unauffällig. Die festzustellenden Abweichungen von den geforderten Bandbreiten hielten sich in moderaten Grenzen und deren Mittelwerte blieben immer unter einem Prozent.

Testreihe Downlink
In der dritten Testreihe unserer Class-of-Service-Testsuite haben wir mit unserem Lastgenerator auf zwei 10-Gigabit-Ethernet-Ports parallel Datenströme gesendet. Jeder dieser Ports hatte vier Datenströme zu verarbeiten, so dass insgesamt vier Ströme unterschiedlicher Priorität anlagen. Für die Festlegung der Prioritäten haben wir die DSCP-Werte 8, 24, 40 und 56 verwendet, wobei die höchste Priorität 56 und niedrigste 8 entspricht. Die Datenströme dieser einzelnen Prioritäten wurden dann in die jeweiligen Hardware-Queues geleitet.

Die beiden 10-Gigabit-Ethernet-Ports haben dann ihre Datenströme an fünf Gigabit-Ethernet-Ports gesendet, so dass bei Volllast an diesen Ausgangsports eine vierfache Überlast anlag, was einer Gesamtlast des Switches von 20 GBit/s entspricht. In nacheinander folgenden Messungen hat der Spirent-Lastgenerator Datenströme bestehend aus Datenrahmen von je 64, 128, 256, 512, 1024, 1280 und 1518 Byte erzeugt. Alle Messungen haben wir zunächst mit Burst-Size 1 und dann mit Burst-Size 100 durchgeführt. Auch hier haben wir die Priorisierungsmechanismen Stirct-Priority und Bandbreitenmanagement eingesetzt. Alle weiteren Details entsprechen den Testreihen oben.

Im Downlink-Betrieb mit Strict-Priority arbeitete der SMC8824M insgesamt recht unauffällig. – Abgesehen von kleinen Ausrutschern leistete er sich keine ungebührlichen Datenverluste. Rund zehn Prozent verlor er allerdings in der höchsten Priorität bei unserer Messung mit 1518-Byte-Frames und einer Burst-Size von einem Frame unter Volllast. Das gleiche Verhalten konnten wir auch bei der Messung mit einer Burst-Size von 100 Frames feststellen. Hier wurde noch ein weiterer Ausrutscher sichtbar: Bei 200 Prozent Last mit 512-Byte-Paketen verlor der SMC-Switch plötzlich fast 16 Prozent der Daten in der zweithöchsten Priorität, obwohl hier gar keine Datenverluste erforderlich gewesen wären. Die genannten Ausrutscher fallen aber in der Gesamtwertung hier nicht weiter ins Gewicht.

Mit Bandbreitenmanagement arbeitete der SMC8824M wie schon zuvor im Unicast-Betrieb völlig unauffällig. Die von uns gemessenen Abweichungen von den Sollwerten hielten sich bei beiden Burst-Formaten in Grenzen und ihre Mittelwerte blieben immer unter einem Prozent.

Testreihe Uplink
In der vierten Testreihe unserer Class-of-Service-Testsuite haben wir mit unserem Lastgenerator auf 24 Gigabit-Ethernet-Ports parallel Datenrahmen gesendet und diese an einen 10-Gigabit-Ethernet-Port adressiert. Dabei sendete jeder Input-Port vier Datenströme der vier Prioritätsklassen an jeden Output-Port. Da 24 Ports gleichzeitig sendeten betrug die Gesamtlast des Systems in diesem Unicast-Betrieb 24 GBit/s. So entsprach die maximale Last einer 2,4-fachen Überlast.

In nacheinander folgenden Messungen hat der Spirent-Lastgenerator Datenströme bestehend aus Datenrahmen von je 64, 128, 256, 512, 1024, 1280 und 1518 Byte erzeugt. Alle Messungen haben wir zunächst mit Burst-

Size 1 und dann mit Burst-Size 100 durchgeführt, um auch aussagefähige Ergebnisse in Bezug auf die Kapazität der Pufferspeicher zu erhalten. Auch hier haben wir die Priorisierungsmechanismen Strict-Priority und Bandbreitenmanagement eingesetzt. Alle weiteren Details entsprechen den Testreihen oben.

Im Uplink-Betrieb zeigte der SMC-Switch schon bei unseren Messungen mit einer Burst-Size von einem Frame seine Grenzen. So verlor er bei 200 Prozent Last und den größten Frames in der höchsten Priorität gut 1,5 Prozent der Daten. Bei der hier höchsten Last von 240 Prozent und 1518-Byte-Frames gingen dann schon gut 17 Prozent der Daten in der höchsten Priorität verloren. Leistete der SMC-Switch sich hier Ausreißer, die nicht weiter die Wertung beeinflussen, so hatte der Switch im Betrieb mit einer Burst-Size von 100 Frames dann deutlichere Probleme. Schon bei 100 Prozent Last verlor er hier in der höchsten Priorität maximal rund 19 Prozent der Daten. In den niedrigeren Prioritäten waren die zu beklagenden Datenverluste noch deutlich höher. So betrugen sie je nach Frame-Größe in der niedrigsten Priorität zwischen 63 und 94 Prozent. Bei Volllast arbeitete der SMC-Switch dann unauffälliger. Lediglich bei den mindestens 1024 Byte großen Frames kam es zu Datenverlusten in der höchsten Priorität, die bei Verwendung der größten Frames dann aber auch gut 17 Prozent erreichten.

Im Uplink-Modus mit Bandbreitenmanagement und kurzen Frames arbeitete der SMC8824M unabhängig vom Burst-Format recht präzise. Verwendeten wir größere Frames, wichen die Datenverluste deutlicher von den Sollwerten ab. Insgesamt blieben diese Abweichungen aber in einem akzeptablen Bereich. Die Mittelwerte der gemessenen Abweichungen erreichten maximal rund 6,5 Prozent.

Fazit
Trotz feststellbarer, unterschiedlich ausgeprägter Schwächen bei der Verarbeitung von priorisierten Daten in entsprechenden Lastsituationen stand mit dem SMC8824M ein durchaus einsetzbarer Switch in unseren Real-World Labs an der FH Stralsund. Die detaillierte Auswertung der Messergebnisse ergibt ein Ergebnis von 4,19, was eine Note von B + bedeutet. Damit bleibt der SMC-Switch nur knapp hinter der bisherigen diesjährigen Referenz, dem D-Link DXS-3350SR, zurück. dieser erreichte ein Ergebnis von 4,38, was einer Note von A - entspricht.

Die wichtigste Schwäche, die sich der jetzt getestete SMC-Switch mit den meisten anderen Switches heute teilt, liegt in der Verarbeitung von Bursts. Neben zum Teil nicht exakt umgesetzten CoS-Regeln sind vielen Switch-Herstellern insbesondere mangelnde Ressourcen im Puffer-Speicherbereich vorzuwerfen. Diese werden bei unseren Messungen mit einer Burst-Size von 100 Frames deutlich. Und 100 Frames sind für Gigabit-Ethernet-Switches mit 10-Gigabit-Ethernet-Uplinks nicht mehr allzu viel. Da sind die Hersteller wohl wieder einmal davon ausgegangen, dass sie drohenden Engpässen mit »Bandbreite satt« begegnen können. Dabei füllen die neuen Switches auch ihre Pufferspeicher mit der zehnfachen Geschwindigkeit. Von daher wird es sicher für anspruchsvolle Umgebungen sinnvoll sein, in größere Pufferspeicher zu investieren.

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