QoS-Konfiguration auf Cisco-Routern: Priorität für VoIP, Zoom/Teams und Business-Apps

Quality of Service (QoS) auf Cisco-Routern sorgt dafür, dass zeitkritische Anwendungen wie VoIP, Zoom/Teams und geschäftskritische Business-Apps auch bei ausgelasteten WAN-Leitungen stabil funktionieren. In der Praxis geht es weniger um „mehr Bandbreite“, sondern um kontrollierte Warteschlangen: Sprachpakete bekommen Priorität, Video wird bevorzugt, und Bulk-Traffic (Backups, Updates) darf die Leitung nicht verstopfen. Dieser Leitfaden zeigt ein praxisnahes QoS-Design für Büros und Niederlassungen inklusive CLI-Beispielen und erwarteten Ergebnissen.

QoS-Grundlagen: Was QoS leisten kann – und was nicht

QoS kann Verzögerung (Latency), Jitter und Paketverlust reduzieren, wenn die Leitung überlastet ist. QoS kann jedoch keine physische Bandbreite „zaubern“. Der größte Effekt entsteht am WAN-Egress, weil dort die Engstelle liegt.

• Wirkt am besten auf dem ausgehenden WAN-Interface (Egress)
• Priorisierung schützt Echtzeit (Voice) vor Queueing und Drops
• Shaping verhindert Provider-Drops, indem der Router selbst kontrolliert queued
• Ohne korrekte Klassifizierung/Markierung ist QoS wirkungslos

Design-Ansatz für Büro/Filiale: Drei Klassen reichen oft

Für die meisten Standorte genügt ein pragmatisches Modell mit klaren Klassen: Voice (höchste Priorität), Video/Collaboration (bevorzugt) und Business-Apps (garantierte Mindestbandbreite). Alles andere landet in Best Effort oder wird begrenzt.

• Voice: DSCP EF (typisch), strict priority (LLQ)
• Video/Collaboration: DSCP AF41/CS4 (typisch), bevorzugte Queue
• Business-Apps: DSCP AF21/AF31 oder eigene Markierung, garantierte Bandbreite
• Default/Bulk: Best Effort, ggf. begrenzen (Policing) oder niedrige Priorität

Hinweis zu DSCP: Markierung muss end-to-end konsistent sein

QoS funktioniert nur, wenn Markierungen von Endgeräten oder Switches korrekt gesetzt und von Providern nicht entfernt werden. In vielen Umgebungen gilt: im LAN markieren, im WAN vertrauenswürdig übernehmen und am Egress shapen/queuen.

Schritt 1: Traffic klassifizieren (Class-Maps)

Die Klassifizierung erfolgt meist über DSCP. Alternativ können ACLs/Ports genutzt werden, das ist aber wartungsintensiver (Cloud-IPs ändern sich). Für Zoom/Teams ist DSCP-basierter Ansatz mit Unternehmensstandards am stabilsten.

Beispiel: Klassen für Voice, Video und Business

class-map match-any CM-VOICE
 match dscp ef
class-map match-any CM-VIDEO

match dscp af41

match dscp cs4
class-map match-any CM-BUSINESS

match dscp af31

match dscp af21

Schritt 2: Policy bauen (Policy-Map mit LLQ und Bandbreiten)

Die Policy definiert, wie Pakete behandelt werden: Voice erhält eine Priority-Queue (LLQ), Video bekommt garantierte Bandbreite und Business-Apps ebenfalls. Der Default bekommt die restliche Kapazität.

Beispiel: QoS-Policy für WAN-Egress (vereinfachtes Muster)

policy-map PM-WAN-QOS
 class CM-VOICE
  priority percent 10
 class CM-VIDEO
  bandwidth percent 25
 class CM-BUSINESS
  bandwidth percent 20
 class class-default
  fair-queue

Erwartete Ergebnisse

• Voice bleibt stabil bei Auslastung (geringer Jitter, weniger Drops)
• Video/Teams/Zoom wird bevorzugt behandelt und bricht weniger ein
• Business-Apps behalten Mindestbandbreite, selbst wenn Bulk-Traffic läuft

Schritt 3: Shaping am WAN – der wichtigste Praxishebel

Wenn der Provider schneller droppt als der Router queued, entstehen Drops außerhalb Ihrer Kontrolle. Shaping setzt die effektive Sendeleistung leicht unter die Provider-Bandbreite, sodass Queueing im Router statt beim Provider erfolgt.

Beispiel: Parent-Policy mit Shaping + Child-QoS (Hierarchie)

policy-map PM-WAN-PARENT
 class class-default
  shape average 9500000
  service-policy PM-WAN-QOS

Warum „unter der Leitung“ shape’n?

• Provider-Drops werden reduziert
• QoS-Queues greifen kontrolliert und messbar
• Voice/Video profitieren besonders bei Peak-Last

Schritt 4: Policy am richtigen Interface binden

QoS muss dort aktiv sein, wo die Engstelle ist. In Filialen ist das fast immer das WAN-Interface Richtung ISP. Für Dual-ISP müssen Policies je Uplink konsistent ausgebracht werden.

Beispiel: Service-Policy am WAN-Interface (Egress)

interface GigabitEthernet0/0
 description WAN-ISP
 service-policy output PM-WAN-PARENT

Markierung (Trust Boundary): Wer darf DSCP setzen?

QoS wird instabil, wenn jedes Gerät „irgendwas“ markiert. Definieren Sie eine Trust Boundary: typischerweise am Access-Switch (VoIP-Telefone) und für bekannte Clients. Der Router sollte Markierungen übernehmen, aber nicht blind alles vertrauen, wenn Gäste oder IoT im Netz sind.

• Voice: IP-Phones markieren oft korrekt (EF) – Switch trustt Phone-Port
• Collaboration: Clients markieren teils; Unternehmenspolicy kann per Endpoint-Policy helfen
• Guest/IoT: eher nicht trusten, ggf. auf Best Effort setzen

QoS für Zoom/Teams: Praktische Hinweise

Zoom/Teams bestehen aus mehreren Streams (Audio, Video, Screen Sharing) und reagieren empfindlich auf Verlust und Jitter. Wenn keine stabile DSCP-Markierung existiert, ist eine saubere Unternehmensmarkierung (z. B. per Endpoint/SD-WAN/Access-Switch) empfehlenswert – statt Portlisten im Router zu pflegen.

• Audio ist kritischer als Video: Audio priorisieren (ähnlich Voice)
• Video bevorzugen, aber nicht „strict priority“ wie Voice
• Screen Sharing eher wie Business/Best Effort behandeln

Typische Fehler bei QoS – und wie Sie sie vermeiden

Viele QoS-Projekte scheitern nicht an der Syntax, sondern an falscher Platzierung (LAN statt WAN), fehlendem Shaping oder unrealistischen Prozentwerten. QoS muss zur realen WAN-Bandbreite passen.

• QoS auf falschem Interface (wirkt nicht an der Engstelle)
• Kein Shaping: Provider droppt, Router kann nicht priorisieren
• Priority-Queue zu groß: Voice „frisst“ Bandbreite, andere Apps leiden
• Falsche Markierungen: alles ist „EF“, Priorisierung wird sinnlos
• Fehlende Messung: keine Zählerauswertung, keine Abnahme

Verifikation: Zähler, Drops und Wirkung messen

QoS ist nur dann „fertig“, wenn Sie Wirkung nachweisen können: Klasse-Zähler steigen, Drops sinken und Voice/Video bleiben stabil unter Last. Die folgenden Kommandos gehören in jede Abnahme.

Policy-Zähler und Drops prüfen

show policy-map interface GigabitEthernet0/0
show interfaces counters errors
show interfaces | include output drops|queue

Erwartete Ergebnisse in den Zählern

• CM-VOICE zeigt Pakete/Bytes, Priority-Queue hat keine oder wenige Drops
• CM-VIDEO und CM-BUSINESS zeigen steigende Zähler bei Nutzung
• Default behandelt den Rest, ggf. fair-queue sichtbar

Abnahme-SOP: QoS kontrolliert einführen

Führen Sie QoS in Schritten ein: erst markieren/klassifizieren, dann shaping, dann Bandbreiten feinjustieren. Änderungen sollten während typischer Lastzeiten validiert werden, damit Effekte messbar sind.

• Baseline messen: Auslastung, Drops, Voice/Video-Qualität (vorher)
• QoS aktivieren: Parent Shaping + Child Queues
• Testfälle: VoIP-Call, Teams/Zoom-Meeting, paralleler Download/Backup
• Nachjustieren: Prozentwerte und Shaping an reale Leitung anpassen

Minimaler QoS-Template-Baustein (kompakt)

class-map match-any CM-VOICE
 match dscp ef
class-map match-any CM-VIDEO

match dscp af41

match dscp cs4
class-map match-any CM-BUSINESS

match dscp af31

match dscp af21
policy-map PM-WAN-QOS

class CM-VOICE

priority percent 10

class CM-VIDEO

bandwidth percent 25

class CM-BUSINESS

bandwidth percent 20

class class-default

fair-queue
policy-map PM-WAN-PARENT

class class-default

shape average 9500000

service-policy PM-WAN-QOS
interface GigabitEthernet0/0

service-policy output PM-WAN-PARENT

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.