von Redaktion IT-A…
Lesezeit
3 Minuten
Priorisierung des Netzverkehrs auf den OSI-Schichten 2 und 3 (2)
Virtuelle LANs – kurz VLANs – bieten die einfachste Methode zur Steuerung der Datenströme im Netzwerk. Dabei muss jedoch beachtet werden, dass es sich bei diesem Ansatz mehr um ein Sicherheitskonzept handelt als um eine Verbesserung der Dienstqualität. Aus diesem Grund wird dieses Konzept in der Regel mit anderen Bandbreitenmanagement-Mechanismen kombiniert, etwa der Priorisierung auf den Schichten 2 und 3. Im zweiten Teil der Workshopserie machen wir uns an das aktive Testen der Priorisierung und erklären, warum ohne Hintergrundlast keine echte Priorisierungsmessung möglich ist.
Aktives Testen der Priorisierung
Die Datenanalyse gibt jedoch keine Auskunft darüber, ob die gemessene Priorisierung auch auf einer Ende-zu-Ende-Basis funktioniert. Erst eine VoIP-Simulation der Echtzeitdatenströme bietet die Grundlage, um die Priorisierung richtig zu testen. Bei diesem Messverfahren wird überprüft, ob an jeder erforderlichen Netzwerkkomponente im Datenpfad zwischen Sender und Empfänger die übermittelten Pakete entsprechend den Vorgaben priorisiert werden und keine Fehler aufweisen.
Für die Simulation von Echtzeitanwendungen in einer Netzwerkumgebung müssen Sie den VoIP-Simulator entsprechend den QoS-Vorgaben (UDP-Ports, TOS/ DiffServ-Byte, VLAN-Tag mit Priorisierung) konfigurieren. Anschließend werten Sie die entsprechenden VoIP-Lasten (Referenzfile, Anzahl paralleler Gespräche, Länge der Telefongespräche) auf das zu untersuchende Netzwerk beziehungsweise die zu untersuchende Teilstrecke und das empfangene Referenzsignal aus.
Dabei ist darauf zu achten, dass der VoIP-Simulator ein getrenntes Messen von Sende- und Empfangsrichtung ermöglicht. Normalerweise wird nur in eine Richtung (vom Sender zum Empfänger) gemessen. Da es sich bei einer VoIP-Verbindung quasi um zwei Halbduplex-Verbindungen handelt, ist es notwendig, dass Sie getrennte Messungen in Sende- und Empfangsrichtung vornehmen und eine separate Bewertung beider Messrichtungen erstellen. Dadurch erkennen Sie auf einem Blick, ob der QoS-Fehler in der Hin- oder Rückrichtung entsteht.
Treten Fehler auf der Übertragungsstrecke auf, müssen Sie die Fehlerquelle beziehungsweise -ursache ermitteln. Im Normalfall handelt es sich dabei um eine falsch konfigurierte, falsch arbeitende oder defekte Komponente. Am einfachsten ermitteln Sie den Fehler durch das Verschieben der Messpunkte. Hierbei versetzen Sie den VoIP-Simulator sukzessiv um einen Hop (Koppelpunkt) in Richtung des Empfängers und testen somit die Funktionalität von Teilstrecke zu Teilstrecke. Letztendlich wird die Fehlerquelle gefunden und die Fehlerursache kann beseitigt werden.
Bei QoS-Messungen über WAN-Strecken müssen Sie darauf achten, wie der Verkehr beziehungsweise die einzelnen Verkehrsklassen priorisiert werden. DiffServ definiert beispielsweise die folgenden Qualitätsklassen:
Die reservierte Bandbreite lässt sich im Regelfall aus den mit dem WAN Service Provider vereinbarten SLAs entnehmen. Aus der garantierten Bandbreite lässt sich die Anzahl paralleler VoIP-Verbindungen auf Basis eines bestimmten Codecs errechnen. Diese VoIP-/Priorisierungstests sollten Sie automatisiert über einen längeren Zeitraum durchführen. Durch das wiederholte Messen ermitteln Sie eine Vielzahl an Messergebnisse und können somit praxisnah das Einhalten und/oder Fehler in der Priorisierung nachweisen.
Bild 1: Das DiffServ-Feld besteht aus 6 Bits, wovon zwei jedoch nicht genutzt werden
Ohne Hintergrundlast keine echte Priorisierungsmessung
Damit eine Datenpriorisierung überhaupt stattfindet, muss die zu überprüfende Netzstrecke belastet werden. Erst ab einem bestimmten Schwellenwert beginnen die Koppelkomponenten mit der Priorisierung der Datenströme. Dies bedeutet, dass die Koppelkomponenten im Datenpfad erst bei einer gewissen Last entscheiden müssen, welche Pakete vorrangig behandelt werden und welchen Paketen weniger Bandbreite zugeteilt wird. Unter Umständen werden bestimmte Pakete in einem Puffer zwischengespeichert oder sogar verworfen.
Um die Priorisierungsmechanismen testen zu können, müssen Sie über die Netzwerkstrecke zusätzlich zu den parallelen VoIP-Verbindungen auch Hintergrundlasten erzeugen. Unter dem Begriff Hintergrundlast wird eine Last verstanden, die zum Austesten der Kapazitätsgrenzen zusätzlich zur Nutzlast (in unserem Fall die simulierten VoIP-Ströme) im Hintergrund auf das Netzwerk generiert wird. Die im Hintergrund erzeugte Last belegt auf dem Netzwerk eine bestimmte Bandbreite und ermöglicht, das Verhalten des Netzwerks bei einer Überlast zu ermitteln.
Die Hintergrundlast muss während der VoIP-Simulation die im Hintergrund erzeugte Datenrate stufenweise auf 100 Prozent der theoretischen Bandbreite des Übertragungskanals erhöhen. Durch diesen Test stellen Sie fest, ob die Priorisierung ordnungsgemäß funktioniert und die in den Koppelkomponenten (Router, Switches, Firewalls et cetera) eingestellten Traffic Shaping-Mechanismen korrekt arbeiten. Bei einem Test mit priorisierten VoIP-Gesprächen darf die Übertragungsqualität aufgrund der Hintergrundlast nicht beeinträchtigt werden.
Mathias Hein, Benjamin Kolbe und Prof. Dr. Bernhard Stütz/jp/ln
Die Datenanalyse gibt jedoch keine Auskunft darüber, ob die gemessene Priorisierung auch auf einer Ende-zu-Ende-Basis funktioniert. Erst eine VoIP-Simulation der Echtzeitdatenströme bietet die Grundlage, um die Priorisierung richtig zu testen. Bei diesem Messverfahren wird überprüft, ob an jeder erforderlichen Netzwerkkomponente im Datenpfad zwischen Sender und Empfänger die übermittelten Pakete entsprechend den Vorgaben priorisiert werden und keine Fehler aufweisen.
Für die Simulation von Echtzeitanwendungen in einer Netzwerkumgebung müssen Sie den VoIP-Simulator entsprechend den QoS-Vorgaben (UDP-Ports, TOS/ DiffServ-Byte, VLAN-Tag mit Priorisierung) konfigurieren. Anschließend werten Sie die entsprechenden VoIP-Lasten (Referenzfile, Anzahl paralleler Gespräche, Länge der Telefongespräche) auf das zu untersuchende Netzwerk beziehungsweise die zu untersuchende Teilstrecke und das empfangene Referenzsignal aus.
Dabei ist darauf zu achten, dass der VoIP-Simulator ein getrenntes Messen von Sende- und Empfangsrichtung ermöglicht. Normalerweise wird nur in eine Richtung (vom Sender zum Empfänger) gemessen. Da es sich bei einer VoIP-Verbindung quasi um zwei Halbduplex-Verbindungen handelt, ist es notwendig, dass Sie getrennte Messungen in Sende- und Empfangsrichtung vornehmen und eine separate Bewertung beider Messrichtungen erstellen. Dadurch erkennen Sie auf einem Blick, ob der QoS-Fehler in der Hin- oder Rückrichtung entsteht.
Treten Fehler auf der Übertragungsstrecke auf, müssen Sie die Fehlerquelle beziehungsweise -ursache ermitteln. Im Normalfall handelt es sich dabei um eine falsch konfigurierte, falsch arbeitende oder defekte Komponente. Am einfachsten ermitteln Sie den Fehler durch das Verschieben der Messpunkte. Hierbei versetzen Sie den VoIP-Simulator sukzessiv um einen Hop (Koppelpunkt) in Richtung des Empfängers und testen somit die Funktionalität von Teilstrecke zu Teilstrecke. Letztendlich wird die Fehlerquelle gefunden und die Fehlerursache kann beseitigt werden.
Bei QoS-Messungen über WAN-Strecken müssen Sie darauf achten, wie der Verkehr beziehungsweise die einzelnen Verkehrsklassen priorisiert werden. DiffServ definiert beispielsweise die folgenden Qualitätsklassen:
- Expedit Forwarding (EF, RFC 3246): Diese Qualitätsklassen mit strikter Priorität über alle anderen Klassen bieten geringsten Paketverlust, sehr geringe Verzögerung und kleinen Jitter. Jeder Router reserviert einen bestimmten Prozentsatz seiner Kapazität für diesen Verkehr. Für die Anforderungen von VoIP-Verkehr in Richtung geringer Verzögerung eignen sich diese Qualitätsklassen ganz besonders.
- Assured Forwarding (AF, RFC 2597): Innerhalb dieses Dienstes werden vier unterschiedliche Qualitätsklassen und drei Levels für den Paketverwurf pro Qualitätsklassen definiert. AF belegt daher 12 DSCP-Werte und dient für Verkehr, der sensitiv auf Paketverluste reagiert.
- Best Effort (BE): In dieser Qualitätsklasse gibt es keine Dienstgarantie und die verbleibende Bandbreite wird für die Übertragung verwendet.
Die reservierte Bandbreite lässt sich im Regelfall aus den mit dem WAN Service Provider vereinbarten SLAs entnehmen. Aus der garantierten Bandbreite lässt sich die Anzahl paralleler VoIP-Verbindungen auf Basis eines bestimmten Codecs errechnen. Diese VoIP-/Priorisierungstests sollten Sie automatisiert über einen längeren Zeitraum durchführen. Durch das wiederholte Messen ermitteln Sie eine Vielzahl an Messergebnisse und können somit praxisnah das Einhalten und/oder Fehler in der Priorisierung nachweisen.
Bild 1: Das DiffServ-Feld besteht aus 6 Bits, wovon zwei jedoch nicht genutzt werden
Ohne Hintergrundlast keine echte Priorisierungsmessung
Damit eine Datenpriorisierung überhaupt stattfindet, muss die zu überprüfende Netzstrecke belastet werden. Erst ab einem bestimmten Schwellenwert beginnen die Koppelkomponenten mit der Priorisierung der Datenströme. Dies bedeutet, dass die Koppelkomponenten im Datenpfad erst bei einer gewissen Last entscheiden müssen, welche Pakete vorrangig behandelt werden und welchen Paketen weniger Bandbreite zugeteilt wird. Unter Umständen werden bestimmte Pakete in einem Puffer zwischengespeichert oder sogar verworfen.
Um die Priorisierungsmechanismen testen zu können, müssen Sie über die Netzwerkstrecke zusätzlich zu den parallelen VoIP-Verbindungen auch Hintergrundlasten erzeugen. Unter dem Begriff Hintergrundlast wird eine Last verstanden, die zum Austesten der Kapazitätsgrenzen zusätzlich zur Nutzlast (in unserem Fall die simulierten VoIP-Ströme) im Hintergrund auf das Netzwerk generiert wird. Die im Hintergrund erzeugte Last belegt auf dem Netzwerk eine bestimmte Bandbreite und ermöglicht, das Verhalten des Netzwerks bei einer Überlast zu ermitteln.
Die Hintergrundlast muss während der VoIP-Simulation die im Hintergrund erzeugte Datenrate stufenweise auf 100 Prozent der theoretischen Bandbreite des Übertragungskanals erhöhen. Durch diesen Test stellen Sie fest, ob die Priorisierung ordnungsgemäß funktioniert und die in den Koppelkomponenten (Router, Switches, Firewalls et cetera) eingestellten Traffic Shaping-Mechanismen korrekt arbeiten. Bei einem Test mit priorisierten VoIP-Gesprächen darf die Übertragungsqualität aufgrund der Hintergrundlast nicht beeinträchtigt werden.
Seite 1 von 2 Nächste Seite>>
Mathias Hein, Benjamin Kolbe und Prof. Dr. Bernhard Stütz/jp/ln
