QoS - Best Practice

Oft werden die Grundlagen im LAN aber auch gerne übersehen. Vor allem wenn Aussagen wie "wir haben Gigabit satt" zu hören sind. Natürlich ist es auf LAN-Verbindungen schwerer, eine Bandbreite zu saturieren aber es ist nicht unmöglich. Eine hohe "Brutto-"Datendurchsatzrate noch kein Garant für einen störungsfreien VoIP-Betrieb, selbst wenn die für die Telefonie benötigte Bandbreite eher im Bereich von Kilobyte/Sek liegt. Die Priorität, Kontinuität und Verlustfreiheit sind wichtige Themen.

  • Räumliche Nähe
    WAN-Verbindungen sind immer ein "Risiko" und Fehler oft nur sporadisch und damit sehr schwer zu erkennen. Leider lassen sich WAN-Verbindungen nicht immer vermeiden. Wichtig ist dann QoS und eine Überwachung.
  • Keine "ungepflegten" VPNs zwischen Standorten
    Wo direkte WAN-Verbindungen nicht zur Verfügung stehen, werden oft VPN-Verbindungen über das günstigere Internet konfiguriert. Allerdings sind hier Laufzeiten und Bandbreiten überhaupt nicht garantiert. Ein schneller Download von Dateien ist kein Zeichen, dass "genug Bandbreite da wäre. VoIP ist kein Bandbreitenfresser (meist <200kbit) aber benötigt konstante und kurze Laufzeiten.
    Und wenn die gleiche Leitung zum "Surfen" genutzt wird, kann genau so ein schneller Download die Latenzzeit "hörbar" vergrößern.
  • VPN von extern
    Das Einpacken von VoIP-Paketen in VPNs ist aber auch bei Anbindungen von Einzelpersonen(z.B. Unterwegs oder zuhause) ein gerne eingesetztes Mittel. Auch hier sind Laufzeiten eventuell ein Problem. Gerade private DSL-Anschlüsse haben zwar eine relativ hohe Bandbreite für den Download von Dateien, (DSL768 und höher) aber die Gegenrichtung beträgt meist nur ein Bruchteil der Datenrate, so dass es hier zu Engpässen kommen kann. werden dann die Pakete noch durch ein VPN und die entsprechenden Accesspunkten mit einer Verschlüsselung geleitet, kann recht schnell kostbare Laufzeit verloren gehen.
  • Überwachung von Netzwerkfehlern
    Viele Fehler liegen im Netzwerk darunter und sind von oben gar nicht sichtbar. Moderne Netzwerkkarten errechnen selbst CRC-Prüfsummen und fordern verlorene Pakete neu an, so dass diese Fehler in keiner Statistik auf dem Server oder Client erscheinen. Es kann helfen die CRC-offload-Funktion (TCPChimney etc.) temporär abzuschalten. Zwar wird VoIP damit nicht schneller, aber Netzwerkfehler können damit entdeckt werden, die ansonsten für das Betriebssystem verborgen bleibt.
  • Keine Hubs
    Erst Switches segmentieren LANs über die MAC-Adresse. Ein Hub hingegen sendet alle Pakete auf alle Ports und das LAN wird damit schnell ein "shared Medium".
  • Einschränkungen bei Wifi
    Auch hier handelt es sich um ein "shared LAN", welches nicht nur weniger Bandbreite anbietet sondern in dem Störeinflüsse noch viel deutlicher werden
  • Broadcast Domains
    Aber auch mit Switches im LAN gibt es mit den "Broadcasts" immer noch Pakete, die auf allen Ports des gleichen Teilnetzwerkes verteilt werden. Eigene VLANs helfen hier oder zumindest eine Überwachung auf solche Stürme oder aktive Blockade durch Switches.
  • "Stabiles LAN"
    Das mag sich lustig anhören, aber wer viele Switches miteinander betreibt und Spanning Tree einsetzt, sollte schon sicher sein, dass diese Technik "robust" ist.
  • Link-Einstellungen (Halb/Vollduplex)
    Es passiert durchaus, dass ein Port auf dem Switch von einem früheren Device noch "statisch" konfiguriert ist oder Endgerät und Port unpassend eingestellt sind. Ein einfacher "PING" hat damit auch kein Problem. Aber wenn mehr Last anliegt, dann kommen die Probleme.
  • Trunk-Priorisierung
    Wenn Switches miteinander verbunden werden, dann sollte ein Switch dem Traffic, der zu einem Trunk hin oder aus einem Trunk kommt, auf jeden Fall Priorität einräumen.

Wie so oft ist der Fehler aber im Details und kann nur durch eine zielgerichtete Suche mit Analyse der Daten gefunden werden.

Unterstützung durch Net at Work:
Wir können Sie aktiv unterstützen. Rufen Sie einfach unter 0800-MSXFAQ (0800-638 28 96) an.

Weitere Links