Edge-Switches intern auf den Zahn fühlen

Im Testaufbau »Fully Meshed« geht es darum, herauszufinden, ob die Edge-Switches intern mit Leitungsgeschwindigkeit arbeiten. Dazu erzeugte das Laborpersonal mit einem Lastgenerator/Analysator »Smartbits 6000C« von Spirent die Last. Das Gerät sendete die Pakete zu allen 20 Gigabit-Ethernet-Eingangsports des zu testenden Edge-Switches. Die Datenströme flossen an die jeweils 19 anderen Gigabit-Ethernet-Ports desselben Switches. Sie wurden dann mit dem Smartbits analysiert.

Der Aufbau für den Test »Fully Meshed«, um die interne Leistungsgeschwindigkeit der Edge-Switches zu überprüfen

Hier haben 20 Gigabit-Ethernet-Ports gleichzeitig an alle anderen Ports gesendet und von diesen zugleich Datenströme empfangen. Überlast entsteht bei dieser Szenerie nicht, so dass hier keine Datenverluste zu erwarten sind. Dies gilt unter der Vorraussetzung, dass der belastete Switch mit Leitungsgeschwindigkeit arbeitet.

Die Burst-Size betrug bei diesem Test ein Frame. Die Frame-Formate waren nacheinander 64, 128, 256, 512, 1024 und 1518 Byte. Junipers [2] »EX 4200 [3]« zeigte sich hier von seiner besten Seite: Er leistete sich unabhängig von den verwendeten Frame-Formaten auch unter Volllast keinerlei Datenverluste. Er übertrug also mit voller Leitungsgeschwindigkeit. Gleiches gilt auch bei Zyxels [4] »XGS-4528F [5]«. Er offenbarte bei diesen Messungen ebenfalls keine Schwächen. Die messbaren Datenverluste blieben bei allen Messungen unter 0,01 Prozent.

Die Core-Switch-Performance kontrollieren

Um den Datendurchsatz im Core-Switch zu überprüfen, kamen alle drei Switches (Core- und zwei Systeme) zum Einsatz. Diese waren jeweils über 10-Gigabit-Ethernet mit einander verbunden. Der Smartbits sendete Pakete auf jeweils zwölf Eingangsports der beiden Edge-Switches. Beide Edge-Switches übertrugen die Datenströme dann via 10-Gigabit-Ethernet-Uplink an den Core-Switch. Dieser leitete die Datenströme dann über den 10-Gigabit-Ethernet-Downlink an den jeweils anderen Edge-Switch weiter. Dort gingen die Datenströme dann von den zwölf Gigabit-Ethernet-Ausgangsports zum Smartbits.

Der Testaufbau, um den Datendurchsatz der Edge- und des Core-Switches zu überprüfen

Die Burst-Size betrug auch bei diesem Test einen Frame. Nach einander wurden die Frame-Formate 64, 128, 256, 512, 1024 und 1518 Byte erzeugt. Bei diesem Test ist der Flaschenhals der 10-Gigabit-Ethernet-Uplink: Sein Bruttodatendurchsatz liegt nominell um zwei GBit/s unter der Durchsatzleistung der zwölf Gigabit-Ethernet-Ports. Bei 100 Prozent Last auf den Gigabit-Ethernet-Eingangs-Ports sollten also theoretisch 83,33 Prozent Durchsatz möglich sein. Anders herum gedacht, ergibt sich bei Leitungsgeschwindigkeit theoretisch ein Frame-Loss von 16,67 Prozent.

Junipers Teststellung mit dem Core-Switch »MX480 [6]« zeigte sich auch in diesem Testaufbau mustergültig. Erste geringfügige Datenverluste traten bei einer Last von 84 Prozent auf. Er arbeite also intern mit Leitungsgeschwindigkeit. Auch Zyxels Systeme schlugen sich bei diesem Aufbau wacker. Bei 83 Prozent Eingangslast waren noch keine Datenverluste nachweisbar. Bei 84 Prozent blieben die Verluste noch unter einem Prozent. Lediglich bei der Messung mit den größten Frames stieg hier die Verlustrate auf knapp über ein Prozent an.

Edge-Switch-Verhalten bei Unicast-Paketen

Für die QoS-Messungen schaute sich das Laborpersonal zuerst das QoS-Verhalten der Edge-Switches bei Unicast-Datenverkehr an. Im Betriebsmodus »Unicast-Gigabit-Ethernet intern« gingen die Daten des Smartbits auf 16 Gigabit-Ethernet-Eingangsports des Core-Switches. Dieser schickte sie dann über vier Gigabit-Ethernet-Ports an den Lastgenerator/Analysator zurück. Dabei ergab sich maximal die vierfache Überlast. Die Frame-Formate waren wieder 64, 128, 256, 512, 1024 und 1518 Byte.

Testaufbau, um das QoS-Verhalten der Edge-Switches bei Unicast-Datenverkehr zu untersuchen

Die Burst-Size betrug zunächst einen Frame. In einer zweiten Messreihe war es dann ein Burst-Size von 100 Frames. Zusätzlich kamen beim Burst-Size 1 Datenströme im »Imix«-Format zum Einsatz. Das ist eine Mischung aus allen Frame-Formaten, die der Verteilung des Datenverkehrs in realen Netzen entspricht.

Junipers EX-4200 verhielt sich auch bei der Messung mit festen Frame-Formaten und einem Burst-Size 1 mustergültig. Er arbeitete nach dem Strict-Priority-Verfahren und verwarf die niedrig priorisierten Datenströme zu Gunsten der höher priorisierten – wenn nötig jeweils vollständig. Bei Volllast bedeutete das Totalverlust in drei von vier Queues, außer der mit der höchsten Priorität.

Bei einem Burst-Size von 100 ging der Switch dazu über, die Datenverluste zwischen der zweithöchsten und der zweitniedrigsten Priorität aufzuteilen. Bei der Imix-Messung mit Burst-Size 1 priorisierte die Juniper-Teststellung nicht ganz so exakt. Die Datenströme der höchsten Priorität blieben allerdings grundsätzlich frei von ungebührlichen Datenverlusten.

Andererseits waren die Datenverluste der niedrigeren Prioritäten nicht ganz »strict«, sondern teilten sich auf jeweils zwei Prioritäten auf. Dieses Verhalten hatte verfrühte Datenverluste in den höheren Prioritäten zur Folge. Dadurch kommt es andererseits nicht so bald zum Totalverlust der niedrigeren Prioritäten.

Zyxels XGS-4528F arbeitete nicht ganz so exakt unter Überlast. Bei den kleinsten Frames kam es schon bei 100 Prozent Last zu Datenverlusten in allen Prioritäten mit Ausnahme der höchsten. Mit größeren Frames kam der Zyxel-Switch dann deutlich besser zurecht. Bei den Messungen mit den 1024 und 1518 Byte großen Frames kam es dann auch zu Datenverlusten in der höchsten Priorität von gut 50 beziehungsweise 21 Prozent.

Probleme bekam der Zyxel-Switch dann bei den Messungen mit einem Burst-Size von 100 Frames. Bei kleineren Frames blieben die außerplanmäßigen Datenverluste noch im moderaten Bereich. Bei den größten Frame-Formaten entstanden dann außerplanmäßige Verluste in der höchsten Priorität von jeweils gut 50 Prozent. Bei Imix-Datenströmen und dem Burst-Size 1 ergaben dagegen ohne Auffälligkeiten.

Core-Switch auf dem Prüfstand für Unicast-Pakete

Nach den Edge-Switches mussten nun die Core-Switches zeigen, wie es mit ihrem QoS-Verhalten bei Unicast-Datenverkehr aussieht. Die Datenströme gehen jetzt auf 16 Ports des ersten Edge-Switches. Dieser sendet sie über den 10-Gigabit-Uplink zum Core-Switch und von dort auf vier Gigabit-Ethernet-Interfaces des zweiten Edge-Systems. Auch hier lag eine maximale Überlast von 400 Prozent an. Junipers Switches arbeiteten auch in diesem Testaufbau normkonform und korrekt. Es ließen sich ihnen bei den festen Frame-Formaten und einem Burst-Size 1 keinerlei ungebührliche Datenverluste nachweisen.

Testaufbau, um das QoS-Verhalten des Core-Switches bei Unicast-Verkehr zu überprüfen

Zu Unregelmäßigkeiten kam es dann mit einem Burst-Size 100. Hier gab es Verlustverteilungen, die nicht ganz »strict« waren. Die Datenströme der höchsten Priorität blieben allerdings immer von Verlusten verschont. Zyxels Testaufbau verhielt sich ähnlich wie der einzelne Zyxel-Switch beim vorhergehenden Test. Bei der Messung mit 64-Byte-Paketen entstanden Datenverluste bei 100 Prozent Eingangslast in allen außer der höchsten Priorität. Diese waren theoretisch nicht notwendig.

Bei den Messungen mit den 1024 und 1518 Byte großen Frames kam es dann auch noch zu außerplanmäßigen Datenverlusten in der höchsten Priorität. Dabei gingen um die 40 Prozent Daten in der höchsten Priorität verloren. Der Burst-Size 100 Frames überforderte die Zyxel-Teststellung dann eindeutig. So kam es schon bei 100 Prozent Last teilweise zu deutlichen Datenverlusten, insbesondere bei der Übertragung von größeren Datenpaketen.

Der Edge-Switch »EX 4200« und der Core-Switch »MX480« von Juniper Networks

Bei den 1024-Byte-Paketen und 100 Prozent Last in allen Prioritäten gingen über 40 Prozent verloren. Unter Volllast betrug bei der gleichen Messung der Datenverlust in der höchsten Priorität gut 40 Prozent. Bei den Imix-Messungen verschluckte der Zyxel-Switch dann unter Volllast in der höchsten Priorität immerhin gut 15 Prozent der Pakete.

Der Core-Switch und Multicast-Datenverkehr

Dieser Test entspricht genau dem Aufbau »Unicast-QoS über Core-Switch«. Als einziger Unterschied arbeiteten die belasteten Switches im Multicast-Modus. Jeder Eingangsport sendete also an alle adressierten Ausgangsports. Auch bei dieser Szenerie gab es maximal eine Überlast von 400 Prozent. Junipers Teststellung hatte beim Burst-Size 1 Probleme mit den 64-Byte-Paketen. Hierbei gingen unter Volllast rund 18 Prozent der am höchsten priorisierten Daten verloren.

Testaufbau, um das QoS-Verhalten des Core-Switches bei Multicast-Verkehr zu überprüfen

Mit den größeren Frame-Formaten kam die Juniper-Teststellung dagegen wieder völlig problemlos zurecht. Beim Burst-Size von 100 Frames hatte die Juniper-Teststellung deutlich mehr Probleme. So verschwanden bei der Messung mit dem kleinsten Frame-Format unter Volllast gut 32 Prozent aller Daten in der höchsten Priorität. Im Betrieb mit großen Frames waren dann keine Verluste in der höchsten Priorität mehr festzustellen. Allerdings verteilten sich die Datenverluste ohne Ansehen der Priorität ab 128 Byte gleichmäßig zwischen den drei niedrigeren Prioritäten. Im Test mit Imix-Datenströmen und einer Burst-Size von eins verlor die Juniper-Teststellung dann fast zehn Prozent der hoch priorisierten Daten.

Zyxels Teststellung kam mit diesem Test recht gut zurecht und priorisierte weitgehend standardkonform. Einen Ausreißer leistete sich diese bei der Messung mit 128-Byte-Paketen. Unter Volllast entstanden bei der höchsten Priorität Datenverluste von über 16 Prozent. Hinzu kamen außerplanmäßige in den niedrigeren Prioritäten im Teillastbereich, die mit dem Frame-Format anstiegen.

Der Core- und Edge-Switch »XGS 4528F« von Zyxel

So verlor die Zyxel-Teststellung bei den größten Frame-Format in allen Prioritäten mit Ausnahme der höchsten rund 48 Prozent aller Pakete bei 100 Prozent Eingangslast. Hier waren theoretisch noch gar keine Datenverluste zu erwarten. Die Imix-Messungen mit einem Burst-Size von einem Frame hat die Zyxel-Teststellung dagegen perfekt absolviert.

Umschaltzeiten bei Leitungswegfall prüfen

Um die Reaktion auf den Ausfall beim Ausfall des Uplinks zu messen, waren die beiden Edge-Switches wie bisher über einen 10-Gigabit-Uplink mit dem Core-Switch verbunden. Zusätzlich waren die Edge-Systeme noch über vier Gigabit-Links verknüpft. Der erzeugte bidirektionale Datendurchsatz betrog 1000 Pakete pro Sekunde. Diese hatten ausschließlich eine Frame-Größe von 128 Byte.

Testfall, um die Reaktionszeit beim Ausfall beziehungsweise Wiederherstellung des 10-Gigabit-Uplinks zu messen

Um eine Störung zu simulieren, zog das Laborpersonal einfach den Stecker der 10-Gigabit-Ethernet-Verbindung heraus. Über den gemessenen Datenverlust ließ sich dann die »Break«-Umschaltzeit ermitteln. Dann wurde die 10-Gigabit-Ethernet-Verbindung wieder hergestellt und die »Restore«-Umschaltzeit ermittelt. Sofern die Switches dafür verschiedene, auch proprietäre Mechanismen anbieten, hat Network Computing diese entsprechend eingesetzt.

Junipers Teststellung stellt eine so genannte Virtual-Chassis-Technologie zur Verfügung. Diese ermöglicht es, bis zu zehn Switches zu einem logischen Switch zusammenzuschließen. In diesem Modus kommt die Juniper-Teststellung zu den besten Umschaltzeiten. Bei dem Break-Test ergab sich eine Umschaltzeit von drei Millisekunden. Beim Restore-Test ließen sich keinerlei Datenverluste messen, was einer rechnerischen Umschaltzeit von null Millisekunden entspricht. Nicht ganz so schnell, aber immer noch recht zügig schaltete Zyxels XGS-4528F hin und her. Im »Break«-Test waren es 73 Millisekunden. Die Restore-Umschaltzeit lag bei 39 Millisekunden.

Fazit

Sowohl die Systeme von Juniper als auch von Zyxel lassen sich sinnvoll in UC-Netzwerken einsetzen. Die Messungen haben allerdings gezeigt: Das Design des gesamten Netzes und die intelligente Konfiguration der aktiven Komponenten sind eine wichtige Voraussetzungen für den störungsfreien Betrieb. Die Hersteller sparen weiterhin an den Pufferspeichern, wie auch die Tests gezeigt haben. Das hält die Kosten der Geräte niedrig und die Verzögerung bleibt im grünen Bereich.

Der »Smartbits 6000C Traffic Generator/ Analysor« von Spirent Communications erzeugte die Datenpakete für die verschiedenen Tests.

Wichtig ist allerdings, dass in der Regel die am höchsten priorisierten Datenströme ohne Wenn und Aber durchkamen. Sie erzeugten dabei nennenswerte Datenverluste. Die Grenzen der Switch-Technologie sollten aber alle ITK-Verantwortlichen kennen. Es gilt auf alle Fälle, durch eine entsprechende Konfiguration insbesondere der Edge-Systeme dafür zu sorgen, dass es nicht zu dramatischen Überlasten kommt. Unter diesen Voraussetzungen sind die getesteten Geräte für den Einsatz in UC-Netzen uneingeschränkt einsetzbar.

Das Testverfahren

Als Lastgenerator und Analysator kam in den Real-World Labs ein »Smartbits 6000C Traffic Generator/Analysor« von Spirent Communications zum Einsatz. Das System ist mit der Software »SmartFlow« ausgestattet und mit 24 Gigabit-Ethernet-Kupfer-Ports bestückt. Alle Ports lassen sich per Software für die Lastgenerierung nutzen und/oder als Analysatoreingang verwenden. Die Class-of-Service-Eigenschaften der Switches im Testfeld wurden in verschiedenen Testreihen gemäß RFC 2544 gemessen.

In diesen Tests ging es um die Priorisierung auf Layer-3. Dafür wurden unterschiedlich priorisierte Datenströme von den Eingangsports auf die Ausgangsports gesendet. Durch eine gezielte Überlastung der Switches in diesen Tests war es möglich, das genaue Datenverlustverhalten sowie weitere Testparameter wie Latency oder Jitter zu ermitteln. Weiter ließ sich dadurch das Leistungspotenzial der untersuchten Switches analysieren und deren Eignung für bestimmte Einsatzszenerien prüfen.