Zugschlusbeobachtungen

Da der neue Standort mit relativ sportlichem Zeitplan produktiv werden soll, und der TK-Anlagen-Lieferant am liebsten seine eigenen Switche verkauft anstelle seinen Kunden bei der Konfiguration fremdgelieferter Switche zu helfen, wird zunächst für die Telefonie eine getrennte Infrastruktur aufgebaut: Neben dem Gigabit-Link für das Datennetz wird auf einem zweiten Fasernpaar mit Hilfe von Medienwandlern und einem uralten HP4000M eine zweite Verbindung zwischen den beiden Gebäuden realisiert, die ausschließlich für die Telefonie genutzt wird. Im alten Standort kommen zwar beide Links auf demselben Switch und demselben VLAN raus, aber in dieser Konfiguration ist wenigstens sichergestellt, dass das Datennetz nicht die Telefonie behindern kann (es sei denn, man überlastet die Backplane des Switches, auf dem die beiden Links in den neuen Standort ankommen und an den auch die TK-Anlage angeschlossen ist).

Das hat jetzt anderthalb Jahre lang prima funktioniert. Nun soll der alte HP4000 weg und durch einen moderneren Switch ersetzt werden, und bei der Gelegenheit hätte man gerne auch gleich etwas Redundanz, Ring und Spanning Tree. Und ich spiele ein wenig mit der IP-Telefonie und versuche, etwas über ihr Verhalten auf einem überlasteten Netz zu lernen.

Leider hat der Kunde keine Reserve-TK-Anlage, was mich dazu zwingt, die Tests mit der produktiven Anlage zu machen und sicherzustellen, dass meine Tests den Produktivbetrieb des Kunden nicht behindern. Also nehme ich mir einen Stapel Switche unter den Arm und fahre hin.

Das Bild zeigt mein Testlab, das mit dem produktiven Officenetzswitch des Kunden und der TK-Anlage auch Infrastruktur umfasst, die besser nicht ausfallen sollte. Mein Testclient A kommt neben die TK-Anlage; über einen dot1q-Trunk Gigabit Ethernet verbinde ich meinen Test-Switch 1 mit der Infrastruktur des Kunden. Mein Testclient B kommt an Test-Switch 1. Test-Switch 2 mit Testclient C und einem Alcatel-IP-Telefon wird über einen dot1q-Trunk mit Test-Switch 1 verbunden. Der Trunk zwischen Test-Switch 1 und Test-Switch 2 wird beidseitig auf 10 Mbit Fullduplex geschaltet, um es später bei der Simulation eines überlasteten Netzes einfacher zu haben. Alle anderen Links im Spiel sind Fast Ethernet.

Das Test-Setup funktioniert: Alle Testclients sehen einander, die TK-Anlage und das Telefon; das Telefon bucht sich sauber in die TK-Anlage ein und ich kann telefonieren. Als Testgesprächspartner dient zunächst die unter einer normalen Baden-Badener Ortsrufnummer erreichbare SWR3-Stauhotline, die den Vorteil hat, dass ein Automat einen geduldig minutenlang vollsabbelt und man auf diese Weise prima entscheiden kann, ob das Telefonat noch ordentlich funktioniert oder nicht.

Die Alcatel-Anlage benutzt für die Kommunikation mit ihren IP-Telefonen ein Wireshark nicht weiter bekanntes, auf UDP aufsetzendes Protokoll, das sich weder als SIP noch als H.323 identifizieren lässt. Wird also mit einiger Wahrscheinlichkeit leider etwas proprietäres sein. Oder ich habe nur den richtigen Standard nicht gefunden. Das schöne an Standards ist dass es so viele davon gibt.

Test A0: Testclients A und B tauschen bidirektional über TCP und netcat Daten von /dev/zero nach /dev/null aus. Dabei beschränkt sichTCP selbsttätig auf die Dicke des künstlichen Flaschenhalses zwischen den beiden Test-Switches, und auch das Telefon interessiert sich nicht großartig dafür, dass das Netz gut ausgelastet ist. Das sieht man auch wunderschön im torrus-Plot des Swichports, dessen Auslastung zwar nur knapp, aber doch sichtbar unter 10 Mbit/s bleibt. Auch ohne auf den Switchen konfigurierte Priorisierungsmechanismen funktioniert das Telefon prima und ich muss mir etwas anderes einfallen lassen, um einen Fehler zu erzeugen. Also nehmen wir für die weiteren Tests UDP, das keine ins Protokoll verankerten Durchsatzregelmechanismen hat. Die Wahl zur Erzeugung der Testdaten fällt schnell auf das Paket netperf.

Test A1: Während eines laufenden Telefonats beginne ich, mit netperf massenhaft UDP-Pakete von Testclient C zu Testclient B zu übertragen. Die Netzlast ist also dem Datenstrom, dessen Qualität ich als einziger menschlicher Teilnehmer des Telefonats beurteilen kann, entgegengesetzt. Beim Start der Netzlast verschlechtert sich die Qualität des Telefonats nicht; man hört keine Störungen.

Test B1: Dasselbe, nur andersrum. Diesmal fließen die Netzlastdaten in dieselbe Richtung wie die relevante Richtung des Telefonats, und man bemerkt sofort nach dem Start der Netzlast erhebliche Aussetzer in der Telefonie, als der Switch in seiner Verzweiflung auch massenhaft zum Telefonat gehörende Datagramme verwirft weil sie beim besten Willen nicht mehr auf den saturierten 10-Mbit-Link passen. Nach etwa 30 Sekunden hat das Telefon genug und bootet.

Test A2: Im Setup von Test A1 wird der Flaschenhals entschärft, indem der Link zwischen den beiden Testswitches auf 100 Mbit konfiguriert wird (mehr als 100 Mbit kann mein Test-Switch 2 nicht). Da es auch schon mit 10 Mbit/s funktioniert hat, erstaunt wenig, dass das Testergebnis auch bei einem 100-Mbit-Link zwischen den beiden Testswitches "funktioniert" lautet.

Test B2: Dasselbe wie Test B1, nur mit einem 100-Mbit-Link zwischen den beiden Switches. Auch hier hört man sofort nach Start der Netzlast Störungen, jedoch deutlich weniger als bei Test B1. Auch hier wirft das Telefon nach einiger Zeit (diesmal deutlich länger, einige Minuten) das Handtuch und bootet.

Test A3: Nun führen wir den künstlichen Flaschenhals wieder ein und beschränken die Bitrate auf dem Link zwischen den beiden Testswitches wieder auf 10 Mbit/s. Als Ausgleich dafür erhalten die Switchports, auf denen die TK-Anlage und das Telefon hängt, die Konfigurationsoption "qos priority 4". Die Wirkung bei der Wiederholung von Test A1 auf diesem Setup ist evident, auch bei Betrieb der Lastgeneratoren bleibt ein Telefonat unbeeinflusst. Dies wird auch bei einem längeren Telefonat zwischen Menschen bestätigt; beide Gesprächspartner bemerken keinen Unterschied in der Gesprächsqualität beim Hinzuschalten der Netzlast. Während des etwa zehnminütigen Tests bleibt das Telefon stets eingebucht und benutzbar.

Der Vollständigkeit halber gibt es dann auch noch Test B3, der Test B1 bei konfiguriertem "qos priority 4" wiederholt, mit denselben Ergebnissen wie Test A3.

Diese Testreihe ist aus dem Mai 2008. Bei der ersten Durchführung der Tests im Sommer 2007 hat sich die Anlage noch signifikant anders verhalten: 2007 buchte sich das IP-Telefon bei fast allen Tests, auch bei den Tests mit auf den Switchen aktiviertem QoS trotz qualitativ nicht eingeschränkter Telefonieverbindung nach einigen Sekunden Netzlast aus der Anlage aus und bootete. Im Frühjahr 2008 erhielt die TK-Anlage eine Runderneuerung und auch eine neue Software, was die spontanen Ausbucher der IP-Telefone drastisch verringert hat. Wie oben gezeigt, fliegen die IP-Telefone mit der derzeitigen Software auf der Anlage nur in Situationen weg, wo sie das auch dürfen.

Technisch habe ich das ganze jetzt so verstanden: Durch das Setzen von "qos priority 4" erhalten die über einen so konfigurierten Port empfangenen Ethernet-Frames eine höhere Priorität als die über einen "normalen" Port empfangenen Frames und werden somit bevorzugt innerhalb des Switches weitergeleitet. Bei der Übertragung des Frames über einen dot1q-Trunk wird die Priorisierung des Frames wohl im VLAN-Tag mit transportiert und bleibt somit bis zum Egress-Port und dem Zielendgerät enthalten. Somit ist es möglich, im gleichen VLAN priorisierte und nicht priorisierte Frames zu transportieren, was gegenüber einer VLAN-Priorisierung (die wohl auch irgendwie geht) praktisch ist, wenn in einer gewachsenen Infrastruktur TK-Endgeräte und nicht-TK-Endgeräte im gleichen VLAN leben und man den Traffic von TK-Endgeräten trotzdem priorisieren muss.

Ein Nachteil besteht darin, dass man die Access-Ports der Switche zum Endgerätetyp passend konfigurieren muss und dass ein versehentlich an einem priorisierten TK-Port angeschlossenes Datenendgerät bei hinreichend bösem Willen die Telefonie sabotieren kann. Das lässt sich aber bei dem Schicht-2-QoS, um das es hier im Artikel geht, kaum verhindern. Es sei denn, man macht dot1q bis zum Endgerät, damit das Endgerät seinen Priorisierungswunsch gleich ins VLAN-Tag schreiben kann. Aber das öffnet eine ganz andere Problemklasse aus dem Bereich Security, was ich gerne vermieden habe.

Andere QoS-Verfahren setzen die Priorität aufgrund von "höheren" Protokollinformationen wie Absender- oder Empfänger-IP-Adresse oder TCP/UDP-Portnummern und bilden die so ermittelte Priorität auf die Priorätit des schließlich zu transportierenden Ethernet-Frames ab. Dazu brauchen die Switches aber IP-Intelligenz ("Layer 3 Switches"), was die vorhandenen Switche nur sehr unbefriedigend beherrschen und was ein größeres Netzredesign erzwingt. Das werden wir im konkreten Fall besser beiben lassen.

Fazit: Die Alcatel-IP-Telefonie ist nun auch auf einer gemeinsam mit Datendiensten genutzten Netzwerkplattform nutzbar, weil durch geeignete Konfiguration der Switches sichergestellt werden kann, dass der Einfluss von Datenanwendungen auf die Telefonie minimal ist.

Weiterer Lerninhalt: Es ist verdammt schwer, mit üblichen Protokollen in heutigen LANs eine Lastsituation zu erzeugen, die von zeitkritischen Anwendungen wie Telefonie überhaupt bemerkt werden. Besonders TCP ist da extrem gutmütig und nimmt seinen Datendurchsatz automatisch so weit zurück, dass andere Anwendungen auf derselben Physik nicht signifikant bemerken, dass da eine TCP-Anwendung das Netz füllt. Ich würde erwarten, dass in einem nicht priorisierten LAN der Start einer weiteren TCP-Anwendung in der Praxis keine Auswirkung auf die Telefonie hat. Höchstens bei vielen TCP-Verbindungen würde ich erwarten, dass das Telefonat einmal kurz aussetzt bis die beteiligten TCP-Stacks einander bemerkt haben und ihren Durchsatz entsprechend reduziert haben. Als Problemkinder bleiben also nur Protokolle wie UDP oder ESP, die keinen solchen Mechanismus haben.