QoS auf Cisco konfigurieren: Grundlagen für Router und Switches

Wer Echtzeit-Anwendungen wie VoIP, Videokonferenzen, Remote-Desktop oder kritische Geschäftsanwendungen stabil betreiben möchte, kommt an Quality of Service nicht vorbei. Unter Last entscheidet QoS darüber, ob Sprache noch verständlich bleibt, ob Video ruckelt oder ob ein wichtiger Datenstrom zuverlässig durchkommt. Gerade in gemischten Netzen mit Cloud-Traffic, Backups, Updates und gleichzeitigem Echtzeitverkehr ist QoS auf Cisco konfigurieren ein zentraler Baustein für einen professionellen Betrieb. Wichtig ist dabei eine realistische Erwartung: QoS „macht keine Bandbreite“, sondern steuert die Behandlung von Paketen, wenn Ressourcen knapp werden. Es geht um Priorisierung, Fairness und das Einhalten definierter Serviceziele. Cisco Router und Switches bieten dafür unterschiedliche Mechanismen: Router kümmern sich häufig um Shaping, Policing und Queueing auf WAN-Links, während Switches im Campus vor allem Marking, Trust-Boundaries und Warteschlangen auf den Ports steuern. In diesem Grundlagenartikel erhalten Sie einen strukturierten Einstieg: von DSCP/CoS und Klassifizierung über die Modular QoS CLI (MQC) bis hin zu typischen Best Practices und Verifikationsbefehlen, die Ihnen helfen, QoS nachvollziehbar und betriebssicher einzuführen.

QoS-Grundlagen: Was QoS leistet und was nicht

QoS ist ein Regelwerk zur Paketbehandlung. Ziel ist, dass wichtige Datenströme bei Überlast bevorzugt werden, ohne dass andere Dienste komplett „verhungern“. Das geschieht typischerweise an Engpässen: WAN-Uplinks, Internetanschlüsse, VPN-Tunnel, Wi-Fi-Uplinks oder stark ausgelastete Trunk-Links.

• QoS hilft bei Congestion: Wenn mehr Traffic anliegt, als ein Link übertragen kann, entscheidet QoS, wer zuerst bedient wird.
• QoS ersetzt keine Kapazitätsplanung: Wenn dauerhaft Überlast herrscht, ist ein Upgrade oder eine Traffic-Reduktion oft nötig.
• QoS ist Ende-zu-Ende: Markierungen und Policies müssen über mehrere Geräte hinweg konsistent sein.
• QoS braucht Trust: Sie müssen entscheiden, wo Sie Markierungen akzeptieren und wo Sie neu markieren.

Ein guter Einstieg in Cisco-QoS-Konzepte ist der Anchor-Text Cisco QoS (Übersicht). Für DSCP-Konzepte ist der Anchor-Text RFC 2474 (DiffServ) hilfreich.

Die Bausteine von QoS: Klassifizieren, Markieren, Steuern

QoS besteht in der Praxis aus wiederkehrenden Komponenten. Wenn Sie diese Bausteine verstehen, wird die Konfiguration deutlich einfacher.

• Klassifizierung (Classification): Traffic wird identifiziert (z. B. per DSCP, ACL, NBAR, Ports, Subnetze).
• Markierung (Marking): Pakete werden mit QoS-Labels versehen (DSCP im IP-Header, CoS im 802.1Q-Tag).
• Queueing/Scheduling: Warteschlangen und Prioritäten steuern, wer bei Congestion wann gesendet wird.
• Shaping: Traffic wird geglättet, um einen Link nicht zu überfahren (typisch am WAN-Edge).
• Policing: Traffic wird begrenzt; Überschreitungen werden gedroppt oder neu markiert.
• Congestion Avoidance: Mechanismen wie WRED droppen frühzeitig selektiv, um Staus zu vermeiden.

DSCP und CoS: Markierungen richtig einordnen

In IP-Netzen ist DSCP (Differentiated Services Code Point) das häufigste Markierungsfeld. Es sitzt im IP-Header (IPv4 TOS/DS Field, IPv6 Traffic Class). In VLANs kann zusätzlich CoS (Class of Service) im 802.1Q-Tag verwendet werden.

• DSCP: Ende-zu-Ende sinnvoll, weil es auf Layer 3 mitgeroutet wird.
• CoS: relevant auf Trunks und Switchports (Layer 2), wird oft am Access-Port gesetzt oder aus DSCP abgeleitet.

Ein verbreitetes Modell ist die Trennung in Klassen wie „Voice“, „Video“, „Critical Data“, „Best Effort“ und „Scavenger“. In vielen Designs wird Voice mit DSCP EF (Expedited Forwarding) markiert, während Best Effort DSCP 0 bleibt. Entscheidend ist nicht der „perfekte Standardwert“, sondern Konsistenz über das gesamte Netz.

Trust Boundary: Wo dürfen Markierungen „geglaubt“ werden?

Ein zentrales QoS-Designprinzip ist die Trust Boundary: An welcher Stelle akzeptieren Sie Markierungen von Endgeräten? Ohne Trust-Konzept kann jeder Client Traffic als „hoch priorisiert“ markieren, was die Priorisierung entwertet oder sogar die Sprachqualität verschlechtert.

• Access-Port für IP-Telefone: häufig CoS/DSCP vom Telefon vertrauen (trusted), PC dahinter nicht.
• WLAN: Markierungen oft nur aus kontrollierten SSIDs oder per Policy übernehmen.
• Server-Zonen: Markierungen können je nach Governance vom Server übernommen oder am Switch/Router gesetzt werden.
• WAN-Edge: häufig Neu-Markierung nach Unternehmenspolicy, weil Provider/Internet Markierungen nicht garantiert respektiert.

QoS auf Cisco Routern: MQC als Standardwerkzeug

Auf Cisco Routern (und vielen L3-Plattformen) ist die Modular QoS CLI (MQC) das übliche Modell. Die Grundlogik besteht aus class-map (Klassifizieren), policy-map (Aktionen) und service-policy (Anwenden).

Beispiel: Klassen definieren

In der Praxis klassifizieren Sie oft nach DSCP, weil das skalierbar ist:

class-map match-any VOICE
match dscp ef

class-map match-any VIDEO
match dscp af41

class-map match-any CRITICAL
match dscp af31

Beispiel: Policy mit Priority Queue, Bandbreite und Default

policy-map WAN-OUT
class VOICE
priority percent 10
class VIDEO
bandwidth percent 20
class CRITICAL
bandwidth percent 20
class class-default
fair-queue

Wichtig: Die priority-Queue (LLQ) ist für sehr latenz- und jitterempfindlichen Traffic gedacht (Voice). Sie sollte begrenzt sein (z. B. percent oder absolute Rate), damit sie andere Klassen nicht dauerhaft verdrängt.

Beispiel: Policy am WAN-Interface anwenden

interface GigabitEthernet0/0
description WAN-Uplink
service-policy output WAN-OUT

In vielen realen WAN-Szenarien ist zusätzlich Shaping erforderlich, weil Queueing nur dann sinnvoll arbeitet, wenn der Router selbst der Engpass ist (nicht das Modem/Provider-Edge). Das führt zum nächsten Baustein: Shaping.

Shaping vs. Policing: Wann was sinnvoll ist

Shaping und Policing werden häufig verwechselt. Beide begrenzen Traffic, aber mit unterschiedlichen Effekten.

• Shaping: glättet Traffic und puffert kurzzeitig; gut für WAN, weil es Drops reduziert und QoS-Queues sauber arbeiten lässt.
• Policing: begrenzt hart; Überschreitungen werden gedroppt oder herabgestuft; gut, um Missbrauch zu stoppen oder Provider-Profile einzuhalten.

Beispiel: Shaping am WAN-Edge (Parent/Child Policy)

Ein gängiges Muster ist eine Parent-Policy, die auf die vertragliche Rate shaped, und darunter eine Child-Policy mit den QoS-Klassen.

policy-map WAN-PARENT
class class-default
shape average 50000000
service-policy WAN-OUT

Dann wird die Parent-Policy am Interface angewendet:

interface GigabitEthernet0/0
service-policy output WAN-PARENT

Die Zahl (hier 50.000.000 bps) sollte typischerweise etwas unter der realen Provider-Rate liegen, damit der Router der Engpass ist und nicht ein nachgelagertes Gerät.

QoS auf Cisco Switches: Marking, Queues und Trust

Auf Switches ist QoS oft näher am Access-Layer: Telefone, Clients und APs senden Traffic ins Netz, der korrekt markiert werden muss. Je nach Plattform (Catalyst, IOS/IOS XE, NX-OS) unterscheiden sich Details, aber die Prinzipien bleiben gleich:

• Markierungen am Edge setzen oder vertrauen (Trust Boundary)
• CoS/DSCP über Trunks konsistent transportieren
• Queues und Scheduling so konfigurieren, dass Voice/Video priorisiert wird

Für Cisco-Switch-QoS und Plattformbesonderheiten ist der Anchor-Text Cisco QoS Konfigurationsguides eine gute Startseite.

Typisches Access-Port-Muster: IP-Telefon + PC

In vielen Setups hängt ein PC hinter einem IP-Telefon. Das Telefon markiert Voice korrekt, der PC sollte nicht beliebig hoch markieren dürfen. Ein verbreitetes Muster ist:

• Voice VLAN am Port aktivieren
• Trust für Telefon-Traffic (CoS/DSCP) zulassen
• PC-Traffic ggf. neu markieren oder untrusted behandeln

Beispielkonfiguration (plattformabhängig, als Konzept):

interface GigabitEthernet1/0/10
switchport mode access
switchport access vlan 10
switchport voice vlan 40
spanning-tree portfast

Je nach Catalyst-Modell werden QoS-Trust-Mechanismen über spezielle QoS-Befehle umgesetzt. Prüfen Sie dafür die passende Plattformdokumentation in den Cisco Guides.

Ein praxistaugliches QoS-Klassenmodell für den Einstieg

Viele QoS-Projekte scheitern, weil das Klassenmodell zu komplex ist. Für den Einstieg ist ein kleines, gut dokumentiertes Modell besser als zehn Klassen, die niemand verifiziert. Ein bewährter Start umfasst:

• Voice: sehr niedrige Latenz, geringe Bandbreite, höchste Priorität (LLQ)
• Video: hohe Bandbreite, jitterempfindlich, aber nicht „strikte“ Priority
• Critical Data: wichtige Apps (ERP, VDI, Transaktionen) mit garantierter Bandbreite
• Best Effort: Standardtraffic
• Scavenger: Hintergrundtraffic (Backups, große Updates) bewusst niedriger priorisiert

Dieses Modell lässt sich später erweitern, wenn Messdaten und Betriebserfahrung vorliegen.

QoS und VoIP: Besonderheiten, die häufig übersehen werden

Voice ist der Klassiker für QoS, aber auch die Quelle typischer Missverständnisse. Drei praktische Punkte sind entscheidend:

• Marking muss am Rand stimmen: Voice sollte früh markiert werden (z. B. am Telefon oder Access-Switch).
• LLQ begrenzen: Eine unlimitierte Priority Queue kann andere Klassen verdrängen.
• Engpass definieren: QoS wirkt dort, wo Congestion ist. In vielen Netzen ist das WAN, nicht der Campus.

Wenn Voice trotz QoS schlecht ist, liegt die Ursache häufig nicht an „zu wenig QoS“, sondern an falschen Markings, falscher Trust Boundary, zu hoher Überlast oder einem Engpass an einer Stelle, die nicht mit QoS belegt ist.

QoS und WLAN: Marking und Mapping bewusst planen

In WLAN-Umgebungen kommt eine weitere Ebene hinzu: WMM (Wi-Fi Multimedia) und die Abbildung von DSCP/CoS auf WLAN-Klassen. Hier gilt:

• DSCP kann auf dem Client entstehen oder an der WLAN-Infrastruktur gesetzt werden
• DSCP muss korrekt auf WMM-Kategorien gemappt werden, damit Voice/Video im WLAN bevorzugt wird
• Am Übergang zurück ins Kabelnetz müssen Markings konsistent bleiben

Die genauen Einstellungen hängen stark von der WLAN-Plattform ab, aber das Prinzip „End-to-End konsistent“ bleibt gleich.

Verifikation: So prüfen Sie QoS auf Router und Switch

QoS sollte nie „blind“ ausgerollt werden. Sie brauchen Verifikationsbefehle und klare Erfolgskriterien. Typische Fragen: Werden Pakete richtig klassifiziert? Steigen die Counter in der richtigen Klasse? Greift Shaping? Gibt es Drops in der Priority Queue?

Wichtige Router-Befehle

• show policy-map interface <IF> (Counters, Drops, Queue-Stats)
• show class-map und show policy-map (Definitionen prüfen)
• show interfaces <IF> (Auslastung, Errors)

Wichtige Switch-Befehle

• Queue- und QoS-Status (plattformabhängig, z. B. „show qos …“)
• Interface-Statistiken und Queue-Drops
• Trust/Marking-Informationen pro Port

Best Practice: Starten Sie mit einer Messbasis (ohne QoS oder mit minimaler Policy), rollen Sie dann schrittweise aus und vergleichen Sie Ergebnisse. QoS ist ein Betriebsfeature, kein einmaliger „Set-and-Forget“-Change.

Häufige Fehler bei der QoS-Konfiguration

• Marking inkonsistent: Voice ist nicht überall EF, Video wird als Best Effort behandelt.
• Trust falsch gesetzt: Clients können beliebig hoch markieren oder Telefone werden nicht trusted.
• QoS am falschen Punkt: Policy ist im Campus, aber Engpass ist am WAN ohne Shaping.
• LLQ zu groß: Priority Queue frisst Ressourcen; andere Klassen droppen.
• Fehlende Verifikation: Policy existiert, aber Counters zeigen, dass sie nie matched.
• Zu komplexes Klassenmodell: Niemand versteht oder pflegt es; Änderungen werden riskant.

Best Practices für ein stabiles QoS-Design

• Einfach starten: Wenige Klassen, klar dokumentiert, dann iterativ verbessern.
• Trust Boundary definieren: Telefone/Netzkomponenten ggf. trusted, Clients eher nicht.
• DNS/NTP und Management nicht vergessen: QoS ist nicht nur Voice; kritische Betriebsdienste verdienen eine klare Behandlung.
• Shaping am WAN: Router soll Engpass sein, nicht das Modem/Provider-Edge.
• Monitoring etablieren: Drops, Queue-Auslastung und Interface-Utilization regelmäßig prüfen.
• Dokumentation: DSCP-Plan, Klassenmodell, Mapping (CoS/DSCP/WMM) und Verantwortlichkeiten festhalten.

Als ergänzende Orientierung für Betriebsdisziplin, Monitoring und sichere Konfigurationen kann der Anchor-Text CIS Controls hilfreich sein. Für Cisco-spezifische QoS-Implementierungen sind der Anchor-Text Cisco QoS Konfigurationsguides und die Cisco QoS Übersicht gute Einstiegsquellen.

Praxis-Checkliste: QoS auf Cisco konfigurieren (Router und Switches)

• Ist das Klassenmodell definiert (Voice, Video, Critical, Best Effort, Scavenger)?
• Ist festgelegt, wo Marking erfolgt und wo Trust gilt?
• Werden DSCP/CoS konsistent über Trunks, Uplinks und WAN transportiert?
• Ist am WAN ein Shaping-Konzept vorhanden, damit Queueing wirksam ist?
• Gibt es Verifikationsbefehle und klare Erfolgskriterien (Counters, Drops, Qualität)?
• Wird QoS schrittweise ausgerollt und dokumentiert?

copy running-config startup-config

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.