Dem Telefonieproblem auf der Spur

Vor einiger Zeit wurde die ComConsult GmbH von einem Kunden beauftragt, die sporadischen Störungen in der VoIP-Telefonie im lokalen Netz zu erkunden. Probleme wie sie im jüngsten Artikel meiner Kollegen genannt wurden, konnten von vornherein ausgeschlossen werden [1]. Es handelte sich dabei um stationäre IP-Telefone, die kaskadiert zwischen Switch und Workstation betrieben werden.

Die Fehleranalyse begann mit einer Ortsbesichtigung der lokalen Infrastruktur, gefolgt von einer Auswertung der Konfiguration der Telefonie-Umgebung sowie der aktiven Netzinfrastruktur. Die Aussagen der Anwender über die Störmeldungen waren sehr diffus. Ein gewisser Anteil konnte auf Störfaktoren außerhalb der lokalen Infrastruktur zurückgeführt werden. Demzufolge wurden Störmeldungen mit externen Teilnehmern insbesondere aus dem Mobilfunknetz ausgeklammert.

Es blieben immer noch genügend Störungen bei Gesprächen zwischen Teilnehmern im internen Netz, die entweder über mehrere Standorte verteilt oder sogar im selben Gebäude gemeldet wurden. Die erste Auswertung ergab kein eindeutiges Bild, sondern es stellten sich mehr Fragen als Antworten:

•    Ist die Telefonanlage auf einem aktuellen Software-Stand?
•    Können Probleme der passiven Infrastruktur ausgeschlossen werden?
•    Sind während der Störungen Probleme auf dem Endgerät des betroffenen Teilnehmers zu erkennen?
•    Sind die vereinzelt eingesetzten Unmanaged Switches ein Problem?
•    Sind Engpässe im lokalen Netz zu erkennen?

Im lokalen Netz des Kunden werden dedizierte Voice VLANs eingesetzt. Aufgrund der Tatsache, dass die IP-Telefonie eine Anwendung von vielen ist, die immer mehr von Softphones auf Endgeräten wahrgenommen wird, erscheint die Verwendung von dedizierten Voice VLANs nicht mehr zeitgemäß. Anlässlich der lokalen Gegebenheit spricht jedoch umgekehrt auch nicht zwangsläufig etwas gegen dieses Design.

Interessanter war hingegen der Einsatz von Quality of Service. Sie kennen bestimmt das Verfahren, bei dem mithilfe einer Klassifizierung die Serviceklasse von Datenpaketen festgelegt und diese anhand von Warteschlangen in einer bestimmten Reihenfolge abgearbeitet werden. Die Klassifizierung erfolgte hier anhand der Markierung durch das Telefonie-Endgerät mit einem DSCP-Wert, der von der Switch-Infrastruktur in einer priorisierten Warteschlange vorrangig abgearbeitet wird. Hier ist Vorsicht geboten, da durch eine falsche Konfiguration auf nur einem Switch die gesonderte Markierung als auch die priorisierte Abarbeitung entfallen und damit der ganze Aufwand zunichte gemacht werden kann. Umgekehrt kann eine priorisierte Warteschlange den restlichen Datenverkehr aushungern. Dies lässt sich mit geeigneten Mitteln, wie der Limitierung der maximalen Datenrate der Prioritätswarteschlange, verhindern.

In der Kundenumgebung funktionierte der beschriebene Ansatz wie gewünscht. Das wurde umso deutlicher, als mit einem Messaufbau ein Stresstest an verschiedenen Standorten durchgeführt wurde. Die Kopplung zwischen zwei Standorten war hier besonders im Fokus, da ein Engpass zu erwarten war. Während der Übertragung von selbst generierten VoIP-Streams wurde die Leitung durch parallel laufende Datenübertragungen unter Last gesetzt. Die Warteschlangenstatistik des betroffenen Switches zeigte verworfene Pakete in der Standardwarteschlange, wohingegen die priorisierte Warteschlange alle Pakete verlustfrei übertragen hatte.

Der nächste Schritt war die Durchführung einer Paketanalyse. Anhand eines Spiegel-Ports an einem Switch wurde der Datenverkehr analysiert. Ein Telefonteilnehmer meldete eine Störung während eines Telefonats mit einem weiteren internen Teilnehmer. Ab einem gewissen Zeitpunkt konnte ein Teilnehmer den anderen nicht mehr hören, umgekehrt jedoch schon.

Die Paketanalyse zeigt, dass während des ungestörten Telefongesprächs Signalisierungsprotokolle zwischen Telefon und Anlage ausgetauscht werden. Alle 5 Sekunden werden Nachrichten vom Telefon zur Anlage und von der Anlage zum Telefon weitergeleitet. Diese Nachrichten enthalten Informationen, die neben der Sprache übertragen werden, um etwa Tastendrücke oder Anzeigen im Display des Telefons zu übermitteln.

Kurz vor der vom Teilnehmer wahrgenommenen Störung kommt es zu einer Störung der Kommunikation zwischen dem Telefon der Gegenstelle und der Telefonanlage. Nachrichten des Telefons an die Telefonanlage werden nicht mehr beantwortet. Zudem werden keine Nachrichten der Anlage empfangen. Nach mehreren vergeblichen Versuchen des Telefons, die Anlage zu erreichen, versucht es nun, die logische Verbindung zu trennen. Gleichzeitig beendet das Telefon den RTP-Medienstrom, der die Sprachnachricht enthält. Wenige Sekunden später werden Signalisierungsnachrichten der Anlage am Telefon empfangen und bestätigt. Die Vermutung legt nahe, dass die Anlage die vom Telefon ausgesandten Pakete nicht empfangen oder verarbeitet hat.

Die Übertragungsrichtung vom Telefon zur Anlage war für insgesamt 20 Sekunden gestört, während in Gegenrichtung offensichtlich Daten übertragen wurden. Diese Unterbrechung führte zum einseitigen Abbau der Sprachverbindung.

Beobachtungen im Fehlerzeitraum, wie die Flutung von Paketen durch den Switch aufgrund fehlender Einträge von Stationen in der MAC-Adress-Tabelle, lenkten die weitere Analyse in Richtung des Spanning-Tree-Protokolls.
Das Spanning-Tree-Protokoll verrichtet seit über 30 Jahren in Ethernet-basierten Netzen seine Dienste, um eine schleifenfreie Layer-2-Topologie herzustellen. Zentrales Kommunikationselement sind die sogenannten Bridge Protocol Data Units (BPDUs), die als Multicast-Pakete standardmäßig alle 2 Sekunden versendet werden. Spanning Tree arbeitet mit unterschiedlichen Timern. Einer dieser Timer ist der sogenannte Max Age Timer. Hiermit wird die maximale Zeit definiert, bei der ein Switch seine Konfigurationsinformationen zur BPDU speichert. Dieser Timer beträgt standardmäßig 20 Sekunden.

In unserem beschriebenen Störungsfall hat ein gesetztes Topology Change Flag in den BPDUs dazu geführt, dass die Switches die Einträge in der MAC-Adress-Tabelle löschen. Eine Topologieänderung tritt beispielsweise auf, wenn physische Verbindungen hinzukommen oder ausfallen.

Diese Funktion wird für Switch-zu-Switch-Verbindungen benötigt, da hierdurch redundante Pfade aufgelöst werden oder hinzukommen können, die zum Weiterleiten von Nutzdaten berücksichtigt werden müssen. Für Switch-Verbindungen, an denen Endgeräte angeschlossen werden, ist lediglich sicherzustellen, dass hier die Schleifenfreiheit gewahrt bleibt. Diese Verbindungen sollen jedoch durch Ein- und Ausschalten keine Topologieveränderung bewirken. Damit der Switch diese Verbindungen unterscheiden kann, findet eine Typisierung statt. Dies erfolgt in Abhängigkeit vom Switch-Fabrikat automatisch oder manuell. Switch-Ports, an denen Endgeräte angeschlossen werden, erhalten den Verbindungstyp Edge. Infrastruktur-Verbindungen werden dem Verbindungstyp Network zugewiesen. Verbindungen vom Typ Edge durchlaufen einen beschleunigten Spanning-Tree-Prozess. Dadurch wird die Wartezeit zum Verbindungsaufbau verkürzt, und der Port steht für die Übertragung der Nutzdaten schneller zur Verfügung.

In der Kundenumgebung sind Switch-Ports, die ursprünglich Infrastruktur-Ports waren, zu Endgeräte-Ports umfunktioniert worden. Dabei wurde vergessen, den Typ des Ports von Network auf Edge zu ändern. In dem konkreten Fall war ein Drucker an dem falsch konfigurierten Switch-Port dafür verantwortlich, dass eine Topologieänderung ausgelöst wurde. Da dieser Drucker grundsätzlich eine aktive Verbindung hält und nur aufgrund eines Mitarbeiter-Umzuges abgesteckt wurde, ist diese Störung selten aufgetreten. Tatsächlich konnte diese Fehlkonfiguration an mehreren Switch-Ports mit Druckeranbindungen nachgewiesen werden.

Als Fazit können wir festhalten, dass so manch alter Zopf nicht abgeschnitten, sondern gepflegt werden muss. Das Spanning-Tree-Protokoll ist immer noch allgegenwärtig und wird für Schleifenfreiheit in Layer-2-Topologien benötigt. Dabei ist auf eine homogene und konsequente Anwendung zu achten.

Verweis

[1] https://www.comconsult.com/wlan-bis-zum-endgeraet-oder-ethernet/