Kennen Sie die Pfade Ihrer Media Sessions im Netz?

Wer kennt den Weg der Sessions durch das Netzwerk? Wenn QoS-Probleme oder Datenverluste auftreten ist es wichtig, dass man zur Fehlersuche die Wege einer Session genau nachvollziehen kann.

Zur Fehlersuche und zur Analyse muss man den Weg seiner Verbindungen kennen. Treten bei Echtzeitverbindungen (VoIP, Video) immer wieder Probleme auf, muss im gesamten Pfad – von Ende zu Ende – das Kommunikationsverhalten aller Koppelkomponenten untersucht werden.

Hierbei muss man sich folgende grundsätzlichen Fragen stellen:

• Wurden Fehler bei der QoS-Konfiguration gemacht?
• Werden die QoS-Markierungen entlang des gesamten Kommunikationspfades eingehalten?
• Werden Pakete in den Router- bzw. Switch- Warteschlangen verworfen?
• Treten auf bestimmten Netzsegmenten überproportional viele Fehler auf oder besteht eventuell eine Duplex-Fehlanpassung die Sprach- und Videoströme negativ beeinflusst?
• Ist der Übertragungsweg nur zu bestimmten Zeitpunkten überlastet oder treten Paketverluste regelmäßig auf?
• Werden die Echtzeitströme über die hierfür vorgesehenen Pfade übermittelt oder werden eventuell falsche Übertragungswege genutzt?

Bei einem meiner Kunden verursachte das Netzwerk angeblich immer wieder hohe Paketverluste. Diese Fehler sorgten dafür, dass die vom eingesetzten Videokonferenzsystem übertragenen Bilder zeitweise "pixelig" wurden. Dies wies darauf hin, dass bei der Videoübertragung irgendwo im Pfad die I-Frames verloren gingen.

Die beiden Videokonferenzsysteme befanden sich in zwei unterschiedlichen Lokationen im gleichen Stadtgebiet. Zwischen den beiden Standorten war eine ausreichend dimensionierte Verbindung vorhanden. Zur Kontrolle der genutzten Wege verwendeten wir das Tool traceroute. Anschließend untersuchten wir alle Verbindungen entlang des Kommunikationspfades

Alle Links arbeiteten sauber

Die nächste Vermutung zur Fehlerursache erstreckte sich auf den Bereich von  Problemen im Bereich des QoS. Es bestand die Möglichkeit, dass die Ursache für Paketverluste in zeitweise übervollen Puffern lag. Das diffuse Fehlerbild sprach jedoch gegen diese Hypothese, denn die bei der Videoübertragung auftretenden Fehler waren weitaus größer als die, die auf das Fehlen von QoS hindeuten würden.

Nach der Überprüfung des gesamten Netzwerks – welches keine  Fehler auswies -  sahen wir uns die Konfiguration des Videokonferenzsystems genauer an. Wir lernten, dass das Sterben der Videosessions mit einem Media-Gateway zu tun hatte. Da sich das Media-Gateway im Internet und nicht innerhalb des Unternehmens befand, traten die Paketverluste in der Hin- und Rückrichtung zum Media Gateway (also im Internet) auf. Nach der Überprüfung der Konfiguration des Media Gateways durch den Provider verbesserte sich die Videoqualität schlagartig.

Die Erkenntnis aus der Fehleranalyse lautete: Zur Validierung eines nicht funktionierenden Videosystems ist traceroute auf jeden Fall nicht ausreichend und wir hätten die Konfiguration des Media Gateways viel früher überprüfen müssen.

Bei einem anderen Kunde analysierten wir langsame Anwendungen (inklusive Sprach- und Videoapplikationen) zwischen zwei entfernten Standorten, die über ein MPLS-System miteinander verbunden waren. Natürlich suchten wir sofort die Ursachen im Netzwerk und im MPLS-System des Carriers.

Wir stellten auf den ausgehenden Router-Interfaces fest, dass diese von Zeit zu Zeit einige Pakete verwarfen. Die Paketverluste (<0,0001% Paketverluste) waren jedoch nicht hoch genug, dass sie die Verschlechterung der Applikations-Performance erklären konnten.

Bei der Kontrolle aller Interfaces entlang des Kommunikationspfads stellen wir eine Schnittstelle (zwischen dem Distribution Switch und der Firewall) fest, die eine hohe Anzahl von FCS-Fehlern und Runts aufwies. Dieses Interface war für den Vollduplex-Betrieb konfiguriert. Das Fehlerbild passte auf ein Interface mit Duplex-Konflikten. Als Runt bezeichnet man in einem Ethernet Netzwerk alle Pakete, die eine Paketlänge von <64 Byte aufweisen und eine gültige CRC-Prüfsumme liefern. Runts sollten in einem funktionierenden Netzwerk nie oder selten vorkommen. Wie in der Praxis üblich, hatten wir aus Sicherheitsgründen keinen Zugriff auf die Firewall-Konfigurationen.

Die Kombination eines Voll-Duplex- Interfaces an einem Ende der Verbindung und einem, auf die automatische Duplex-Erkennung eingestellten Interfaces am anderen Ende der Verbindung kann zu einem sogenannten in Duplex-Mismatch führen. Die im Standard festgelegte Duplex-Erkennung bietet  für ein fest eingestelltes Interface (auf eine fixe Konfiguration festgelegte Schnittstelle)keine Möglichkeit, mit einem anderen Interface, das auf automatische Parameteraushandlung konfiguriert ist, über das Netzt  Konfigurationsparameter auszutauschen. Da das auf die automatische Aushandlung konfigurierte Interface keine Parameter austauschen kann, setzt es sich in den Halbduplex-Modus und aktiviert das Netz-Interface. Somit kommunizierte in unserem Fall ein Halbduplex-Interface mit einem Vollduplex-Interface über die betreffende Verbindung.

Die Erkenntnis aus der Fehleranalyse lautete: Moderne Geräte, die innerhalb der letzten fünf Jahre beschafft wurden, weisen in der Regel keine Probleme mehr bei der Duplex-Aushandlung auf. Aus diesem Grund ist es verwunderlich, dass einige IT-Organisationen immer noch mit veralteten Konfigurationseinstellungen arbeiten und die falsch konfigurierten Ethernet-Interfaces mehr Probleme als nötig bereiten.

Fazit

Zur Fehlersuche im Netzwerk gehört auch das Wissen um den Weg, den die Sessions im Netzwerk nehmen. Durch ein Überwachen aller Links entlang der Datenpfade erhält man umfangreiche Informationen zur Fehleranalyse. Mit Hilfe von Konfigurationsmanagementsystemen stellt man sicher, dass die Parameter in allen Komponenten entlang des Kommunikationspfads korrekt eingestellt sind und zueinander passen. Dadurch wird dafür gesorgt, dass die Datenströme und Anwendungen problemlos in einer Ende zu Ende Beziehung funktionieren.   (mat)