QoS-Design auf Cisco-Routern für Echtzeit-Anwendungen: VoIP, Video und SaaS

QoS auf Cisco-Routern für Echtzeit-Anwendungen ist dann wirksam, wenn es den Engpass kontrolliert: typischerweise der WAN-Uplink. VoIP, Video (Teams/Zoom) und geschäftskritische SaaS reagieren empfindlich auf Packet Loss, Jitter und Latenzspitzen. Ohne QoS konkurrieren Echtzeitpakete im gleichen Queueing mit Bulk-Traffic (Backups, Updates) – die Folge sind abgehackte Calls und schlechte Meetingqualität. Dieses Tutorial zeigt ein praxistaugliches QoS-Design: Klassifizierung/Markierung, WAN-Shaping, Priorisierung und End-to-End-Verifikation mit Cisco-CLI.

QoS-Grundprinzip: QoS löst nur Engpässe

QoS ist keine „Performance-Optimierung“ im LAN, sondern Queue-Management am Engpass. Wenn kein Engpass existiert, bringt QoS wenig. Wenn der Engpass beim Provider liegt, müssen Sie am Router shapen, damit Queueing bei Ihnen statt beim Provider passiert.

• Engpass typischerweise: WAN-Uplink (Upstream/Downstream)
• Ziel: Drops in Echtzeitklassen vermeiden, Jitter senken
• Mittel: Shaping am WAN-Egress + Prioritätsklassen
• Messung: Drops/Queue Drops, RTT/Loss, Call-Qualität unter Last

Traffic-Klassen: Minimaler Enterprise-Standard

Ein einfaches, robustes Klassenschema ist meist besser als viele kleine Klassen. Nutzen Sie wenige Klassen, die Ihre wichtigsten Anwendungstypen abbilden.

• REALTIME: VoIP (RTP), ggf. Call-Signaling separat
• VIDEO/UC: Video/Conferencing (Teams/Zoom), interaktiv
• BUSINESS: geschäftskritische SaaS/Apps (ERP/CRM/VDI je nach Bedarf)
• DEFAULT: Best Effort (Web, allgemeiner Traffic)
• BULK: Backups, Updates, große Downloads

Markierung: DSCP/CoS als Basis für konsistente Priorität

QoS funktioniert am besten, wenn Traffic bereits korrekt markiert ist (DSCP). In Enterprise-Umgebungen wird Markierung möglichst nah an der Quelle gesetzt (Telefon, Client, Access-Switch). Der Router sollte markieren, wenn Quellen unzuverlässig sind, und „schädliche“ Markierungen korrigieren.

• Trust Boundary: wo wird DSCP vertraut (Telefon/Switch) vs. neu markiert?
• VoIP: typischerweise DSCP EF (46) für RTP
• Video/UC: oft AF41/AF42 (je Standard), konsistent definieren
• SaaS/Business: AFxx nach Policy, nicht „alles priorisieren“

Designkern: Shaping am WAN-Egress (damit QoS wirkt)

Wenn Sie nicht shapen, queue’t häufig der Provider – und Ihre Router-Queues greifen nicht. Shaping sollte sich an CIR/Upload orientieren, oft leicht darunter, um Burst/Policing abzufangen.

• Shaping-Rate: nahe Upload, aber etwas unter CIR (praktischer Puffer)
• Priorität: Echtzeit bekommt bevorzugte Behandlung (Low Latency Queue)
• Schutz: Bulk wird begrenzt, damit Echtzeit nicht verdrängt wird

QoS-Template: Klassen + Policy Map (praxistauglich, konzeptionell)

Dieses Beispiel zeigt die Struktur: Class-Maps für DSCP, eine Policy mit Priority für VoIP und Bandwidth für Video/Business, und Shaping im Parent. Parameter (Raten) müssen zur WAN-Bandbreite passen.

Class-Maps (DSCP-basiert)

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

match dscp af41 af42
class-map match-any CM-BUSINESS

match dscp af31 af32
class-map match-any CM-BULK

match dscp cs1

Child Policy (Priorisierung/Queues)

policy-map PM-WAN-CHILD
 class CM-REALTIME
  priority percent 10
 class CM-VIDEO
  bandwidth percent 20
 class CM-BUSINESS
  bandwidth percent 20
 class CM-BULK
  bandwidth percent 5
 class class-default
  fair-queue

Parent Policy (Shaping am WAN)

policy-map PM-WAN-PARENT
 class class-default
  shape average 50000000
  service-policy PM-WAN-CHILD

Policy am WAN-Egress anwenden

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

QoS für SaaS: Priorität ja, aber selektiv

SaaS ist oft breit und schwer exakt zu klassifizieren. Statt „SaaS pauschal priorisieren“ sollten Sie nur kritische Applikationen aufnehmen oder SaaS als Business-Klasse behandeln – ohne Echtzeit zu verdrängen.

• Nur kritische SaaS priorisieren (ERP/VDI/CRM), nicht „alles Cloud“
• Business-Klasse begrenzen, damit Echtzeit nicht leidet
• Bulk bewusst drosseln (Updates/Backups), um Jitter zu senken

QoS-Designfallen: Häufige Fehlerbilder

Viele QoS-Projekte scheitern an falscher Engpassannahme oder fehlender Verifikation. Nutzen Sie diese Liste als Review-Check.

• Kein Shaping: Provider queue’t, QoS wirkt nicht
• Zu viele Klassen: Betrieb komplex, Fehlklassifizierung häufig
• Alles priorisiert: Priorität verliert Wirkung, Drops wandern
• Falsche Markierung: EF für Nicht-VoIP, QoS wird „vergiftet“
• Keine Tests unter Last: QoS nur „auf dem Papier“

End-to-End-Verifikation: Wie Sie QoS nachweisen

QoS ist nur dann abgenommen, wenn Klassen Traffic sehen und Echtzeit unter Last stabil bleibt. Verifizieren Sie Policy-Zähler, Drops und Nutzererfahrung (Call-Test) während Last.

• Policy-Zähler steigen in den erwarteten Klassen
• Keine auffälligen Drops in REALTIME/VIDEO
• Unter Last: Call/Meeting stabil, Jitter/Loss niedrig
• Monitoring: Output Drops/Queue Drops sichtbar

CLI: QoS-Verifikation (Pflicht)

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

Abnahme (ATP/UAT): Testszenarien für Echtzeit-Anwendungen

Planen Sie UAT-Szenarien, die realistisch sind: gleichzeitige Meetings und Bulk-Transfers. Dokumentieren Sie Pass/Fail und Evidence (Policy-Outputs).

• Test 1: VoIP-Call während Bulk-Download (REALTIME stabil)
• Test 2: Teams/Zoom Meeting während Backup (VIDEO stabil)
• Test 3: SaaS-Transaktion während Last (BUSINESS akzeptabel)
• Test 4: Drops/Queues prüfen, ggf. Parameter nachjustieren

Operability: Monitoring und Alerting für QoS

QoS muss überwacht werden, sonst bleibt Congestion unbemerkt. Definieren Sie Alarme für WAN-Drops/Queue Drops und für anhaltende Auslastung nahe Shaping-Rate.

• Alarme: Queue Drops auf WAN, sustained utilization, CPU high (QoS/crypto)
• KPIs: Drops in REALTIME/VIDEO, Call-Quality Incidents, MTTR
• Runbook: „QoS wirkt?“ Checkset im Betrieb

Runbook-Snapshot (Copy/Paste)

show policy-map interface
show interfaces | include output drops|queue
show processes cpu sorted
show logging | last 50

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.