Wie Sprachpakete an der Warteschlange vorbeikommen

Wo QoS wirkt: nur am Engpass und nur bei Stau

QoS verändert die Reihenfolge, in der Pakete aus einer Warteschlange gesendet werden. Gibt es keine Warteschlange, gibt es nichts zu ordnen. Ein Paket, das auf einen freien Port trifft, wird sofort gesendet, ganz gleich, wie es markiert ist. Deshalb bewirkt eine Priorisierung auf einem kaum ausgelasteten 10-Gbit-Uplink im Campus fast nichts, während dieselbe Policy auf einer 50-Mbit-Leitung zum Provider den Unterschied zwischen klarem Gespräch und Aussetzern macht.

Engpässe entstehen dort, wo schnelle Verbindungen in langsamere übergehen: vom LAN ins WAN, vom Access-Switch zum WLAN-Access-Point, vom Standortrouter in die Internetleitung. Auch im LAN gibt es Momente, in denen viele Ports gleichzeitig auf einen Uplink senden und kurzzeitig Warteschlangen entstehen. Auf Catalyst-Switches sind deshalb Hardware-Warteschlangen mit Priorität für Sprache sinnvoll, entscheidend ist aber meist die WAN-Edge.

Ein Sonderfall ist die Download-Richtung einer Internetleitung. Die Warteschlange für den Download liegt beim Provider, und der wertet deine Markierungen in der Regel nicht aus. Du kannst nur deinen eigenen Upload ordnen. Für den Download helfen Priorisierung beim Provider, wenn der Vertrag sie enthält, eine eigene Leitung für Sprache oder ein SD-WAN, das Sprache auf die weniger belastete Leitung legt.

Wie viel Bandbreite ein Gespräch braucht

Die Priority Queue muss groß genug für alle gleichzeitigen Gespräche sein, sonst verwirft ihr eigener Policer bei Stau Sprachpakete. Die Rechnung ist einfach. Bei G.711 mit 20 Millisekunden pro Paket trägt jedes Paket 160 Byte Sprache, dazu kommen 40 Byte für IP-, UDP- und RTP-Header. Das sind 200 Byte pro Paket bei 50 Paketen pro Sekunde, also 80 kbit/s auf IP-Ebene. Mit Ethernet-Header und Prüfsumme von 18 Byte kommen 87,2 kbit/s heraus.

Bei G.729 sind es nur 20 Byte Sprache pro Paket. Mit denselben 40 Byte Headern ergibt das 24 kbit/s auf IP-Ebene. Hier ist der Header doppelt so groß wie der Inhalt, und genau deshalb lohnt sich bei schmalen Leitungen die Header-Kompression. Moderne Codecs in Webex oder Teams arbeiten mit variabler Rate, für die Planung rechnest du mit dem Wert, den der Hersteller als Obergrenze angibt.

DSCP-Tabelle: EF, CS5, AF41, CS3, Default

DSCP ist ein 6-Bit-Feld im IP-Header, definiert in RFC 2474. Expedited Forwarding, kurz EF, ist in RFC 3246 beschrieben und steht für Verkehr mit geringer Verzögerung, geringem Jitter und geringem Verlust. RFC 4594 ordnet den Werten Dienstklassen zu und empfiehlt EF für die Sprache selbst und CS5 für die Signalisierung. Cisco hat in älteren Designempfehlungen CS3 für die Signalisierung verwendet, deshalb findest du in gewachsenen Netzen oft beide Werte.

Microsoft Teams nutzt laut Microsoft Learn EF 46 für Audio, AF41 34 für Video, AF21 18 für Bildschirmfreigabe und CS5 40 für die Signalisierung. Mac- und Mobilclients setzen für Audio fest EF und für Video und Bildschirmfreigabe fest AF41. Eine class-map für Signalisierung sollte daher CS5 und CS3 gemeinsam erfassen, wenn im Netz verschiedene Systeme laufen.

Für Verkehr mit niedriger Priorität, etwa Backups, empfahl RFC 4594 ursprünglich CS1. RFC 8622 hat das durch Lower Effort mit dem Wert 1 ersetzt. Wer heute eine Klasse für Massenverkehr unterhalb von Default anlegt, sollte beide Werte erfassen.

Die WAN-Edge mit Shaper und Kind-Policy

In den meisten Standorten ist das Interface zum Provider schneller als die bestellte Leitung. Damit die Warteschlange im eigenen Router entsteht und nicht im Modem, gehört ein Shaper auf die vertragliche Rate davor. Er wird in einer übergeordneten Policy konfiguriert, und die eigentliche Sprach-Policy hängt als Kind darunter. Die Prozentwerte der Kind-Policy beziehen sich dann auf die geshapte Rate, nicht auf das physische Interface.

Das Beispiel gilt für eine Leitung mit 100 Mbit/s Upload. Der Shaper liegt bei 95 Mbit/s, damit Overhead und Schwankungen auf der Provider-Seite keinen Stau im Modem erzeugen. Sprache bekommt bis zu 20 Prozent in der Priority Queue, Video und Signalisierung bekommen garantierte Anteile, der Rest teilt sich fair, was übrig bleibt.

class-map match-any VOICE
 match dscp ef
class-map match-any SIGNALING
 match dscp cs5 cs3
class-map match-any VIDEO
 match dscp af41
!
policy-map WAN-EDGE
 class VOICE
  priority percent 20
 class SIGNALING
  bandwidth percent 5
 class VIDEO
  bandwidth percent 30
 class class-default
  fair-queue
!
policy-map WAN-SHAPER
 class class-default
  shape average 95000000
  service-policy WAN-EDGE
!
interface GigabitEthernet0/0/0
 description Internet 100/100
 service-policy output WAN-SHAPER

Trust Boundary am Access-Port

Eine Markierung ist nur so viel wert wie das Vertrauen in die Quelle. Wenn jeder PC EF setzen darf und das Netz der Markierung folgt, kann jede Anwendung ihre Pakete in die Priority Queue schieben, und der Policer verwirft dann echte Sprache. Die Trust Boundary legt fest, ab welchem Punkt das Netz Markierungen glaubt. Sinnvoll ist sie so nah an der Quelle wie möglich, also am Access-Port.

Catalyst-9000-Switches vertrauen laut Cisco standardmäßig der DSCP-Markierung eingehender Pakete. Das ist bequem, aber für Ports mit beliebigen PCs zu großzügig. Für Ports mit Cisco-IP-Telefonen gibt es trust device cisco-phone, das nur vertraut, solange per CDP ein Telefon erkannt wird. Für PC-Ports mit Softphones bewährt sich eine Eingangspolicy, die nur Pakete aus den bekannten Quellports der Sprachanwendung als EF markiert und alles andere auf Default setzt.

ip access-list extended ACL-TEAMS-AUDIO
 10 permit udp any range 50000 50019 any
!
class-map match-all TEAMS-AUDIO
 match access-group name ACL-TEAMS-AUDIO
!
policy-map ACCESS-MARKING-IN
 class TEAMS-AUDIO
  set dscp ef
 class class-default
  set dscp default
!
interface GigabitEthernet1/0/10
 description Arbeitsplatz mit Softphone
 service-policy input ACCESS-MARKING-IN

QoS über Internet und SD-WAN: was ankommt

Im Internet ist DSCP eine Bitte, keine Zusage. Provider dürfen die Markierung ignorieren, zurücksetzen oder für eigene Zwecke verwenden, und die meisten tun eines davon. Microsoft schreibt in der Teams-Dokumentation entsprechend, dass QoS nur auf Verbindungen wirkt, die du selbst verwaltest, und rät davon ab, Echtzeitverkehr durch ein VPN zu leiten, weil der Tunnel zusätzlichen Overhead und Verzögerung bringt.

Wirksam bleibt deine Policy an der eigenen Upload-Kante, und das ist oft schon die halbe Lösung. Bei IPsec-Tunneln kopiert der Router die DSCP-Markierung in den äußeren Header, sonst könnten Geräte auf dem Weg die verschlüsselten Pakete nicht unterscheiden. In einem SD-WAN kommt die Wegewahl dazu: Cisco Catalyst SD-WAN misst Verlust, Latenz und Jitter auf jedem Tunnel und kann Sprache per Application-Aware Routing auf den Weg legen, der gerade die Grenzwerte einhält. QoS ordnet die Warteschlange, das SD-WAN wählt die Leitung, und beides ergänzt sich.

Kontrolle mit show policy-map interface

show policy-map interface zeigt je Klasse, wie viele Pakete getroffen wurden, wie viele in der Warteschlange stehen und wie viele verworfen wurden. Drops in class-default bei Last sind normal und gewollt, Drops in VOICE sind ein Alarmzeichen. Steigen sie, ist entweder die Priority Queue zu klein oder es landet Verkehr darin, der dort nicht hingehört.

Für den Gegenbeweis eignet sich ein Mitschnitt. Mit dem Wireshark-Anzeigefilter ip.dsfield.dscp == 46 siehst du alle Pakete mit EF, mit rtp und dem RTP-Stream-Analyzer unter Telephony die Laufzeiten, Jitter und Verluste eines Gesprächs. Ein Mitschnitt vor und hinter dem Router zeigt, ob die Markierung erhalten bleibt.

R1# show policy-map interface GigabitEthernet0/0/0 output
 GigabitEthernet0/0/0
  Service-policy output: WAN-SHAPER
    Class-map: class-default (match-any)
       shape (average) cir 95000000
      Service-policy : WAN-EDGE
        Class-map: VOICE (match-any)
          184211 packets, 36842200 bytes
          Match: dscp ef (46)
          Priority: 20% (19000 kbps), burst bytes 475000, b/w exceed drops: 0
        Class-map: class-default (match-any)
          Queueing
          (total drops) 1842