QoS auf Cisco: MQC (Class-Map/Policy-Map) für Profis

QoS auf Cisco ist dann wirklich wirksam, wenn Sie es nicht als „ein paar DSCP-Werte“ betrachten, sondern als durchgängiges System aus Klassifizierung, Markierung, Queueing, Shaping/Policing und konsequenter Verifikation. In Enterprise- und Service-Provider-Netzen entstehen QoS-Probleme selten, weil „QoS fehlt“, sondern weil MQC-Policies (Class-Map/Policy-Map) nicht zur Plattform-Pipeline passen, Trust Boundaries unklar sind oder weil man versucht, Bandbreitenprobleme durch Markierungen zu heilen. Das Ergebnis sind typische Symptome: Voice klingt nur zu Stoßzeiten schlecht, Videokonferenzen haben sporadische Freezes, kritische Applikationen „ziehen den Kürzeren“, oder die Datenebene wirkt stabil, während einzelne Flows unerklärlich droppen. Die Modular QoS CLI (MQC) ist der zentrale Cisco-Mechanismus, um solche Anforderungen präzise und wiederholbar umzusetzen. Sie definiert in class-maps den Traffic, in policy-maps das Verhalten und bindet die Policy in den richtigen Richtungskontext (Ingress/Egress) an Interfaces. Dieser Artikel zeigt MQC für Profis: wie Sie Klassen sauber schneiden, welche Aktionen auf welcher Ebene sinnvoll sind, wie Sie Trust Boundaries und DSCP-Strategien aufbauen, welche Fallstricke bei Shaping/Policing und Queueing typischerweise auftreten und wie Sie QoS so testen, dass es im Day-2-Betrieb belastbar bleibt.

MQC-Grundprinzip: Class-Map, Policy-Map, Service-Policy – und warum Richtung alles ist

MQC besteht aus drei Bausteinen, die oft korrekt konfiguriert, aber falsch angewendet werden: Klassifizierung (class-map), Policy-Definition (policy-map) und Bindung (service-policy). Entscheidend ist, dass jede QoS-Aktion einen Ort hat, an dem sie sinnvoll ist. Markieren ist typischerweise Ingress-nahe sinnvoll (damit der Rest des Netzes konsistent arbeiten kann), Queueing und Shaping sind Egress-nah sinnvoll (weil Auslastung am Ausgang entsteht). Wenn Sie diese Logik verdrehen, bekommen Sie Policies, die „richtig aussehen“, aber operativ wenig bringen.

• class-map: Definiert, welcher Traffic in eine Klasse fällt (z. B. DSCP EF, bestimmte Ports, bestimmte Subnetze).
• policy-map: Definiert, was mit dieser Klasse passieren soll (z. B. set dscp, priority, bandwidth, police, shape).
• service-policy: Bindet die Policy an ein Interface (in oder out), manchmal auch an andere Kontexte (plattformabhängig).

Für Cisco-spezifische Syntax und Plattformvarianten sind die offiziellen Guides die zuverlässigste Quelle, z. B. die Cisco IOS XE Configuration Guides und die Cisco Nexus 9000 (NX-OS) Configuration Guides.

QoS ist kein „DSCP-Thema“: Das mentale Modell für Profis

Wer QoS nur als DSCP-Setzen versteht, erzeugt fast zwangsläufig Enttäuschungen. DSCP ist ein Klassifizierungs- und Signalisierungsmechanismus, aber ohne konkrete Warteschlangen- und Drop-Strategie bleibt es Etikettierung ohne Wirkung. Ein praxistaugliches QoS-Modell betrachtet fünf Schritte:

• Classify: Traffic identifizieren (möglichst nah an der Quelle).
• Mark: DSCP/CoS konsistent setzen (Trust Boundary definieren).
• Queue: Egress-Warteschlangen mit Priorität und Mindestbandbreiten definieren.
• Congestion Avoidance: Drops intelligent steuern (z. B. WRED in Best-Effort/AF-Klassen).
• Police/Shape: Traffic begrenzen oder glätten, wo es erforderlich ist (Edge/WAN-Übergang).

DSCP selbst ist in DiffServ-Standards beschrieben, insbesondere in RFC 2474 und RFC 2475. Für die EF-Per-Hop-Behavior-Klasse (typisch für Echtzeit/Voice) ist RFC 3246 eine verbreitete Referenz.

Trust Boundary: Wo darf markiert werden und wem wird vertraut?

Die wichtigste Designentscheidung ist die Trust Boundary. Wenn jedes Endgerät DSCP frei setzen darf, wird QoS entweder wirkungslos (weil alles „High Priority“ wird) oder gefährlich (weil wichtige Klassen verdrängt werden). Wenn dagegen niemand markieren darf, fehlen Ihnen Signale für differenzierte Behandlung. In Enterprise-Umgebungen ist die Trust Boundary typischerweise am Access-Layer.

• Telefon-Port: Häufig darf ein IP-Telefon markieren (oder wird gezielt markiert), weil es ein kontrolliertes Gerät ist.
• PC-Port: Typischerweise kein Trust; Markierungen werden entweder überschrieben oder neu gesetzt (z. B. Best Effort), es sei denn, es gibt einen kontrollierten Client-Stack.
• WLAN: Trust hängt stark von Architektur (WLC, AP, CAPWAP) und Policy ab; oft wird im WLAN-Kern neu klassifiziert.
• Server/Datacenter: Trust ist möglich, aber nur bei kontrollierten Workloads; in Multi-Tenant-Umgebungen wird meist neu markiert.

Ein häufiger Profi-Fallstrick: Trust wird „pro Switch“ entschieden statt pro Porttyp. Dadurch entstehen inkonsistente Markierungen und schwer erklärbare QoS-Effekte. Besser ist ein Template-Ansatz: pro Porttyp definierte Trust- und Markierungsregeln.

Klassen schneiden: Class-Maps, Match-Strategien und „keine Overlaps“

MQC steht und fällt mit der Klassifizierung. Die häufigste Fehlerquelle sind überlappende Klassen oder zu breite Matches, die mehr Traffic erfassen als geplant. Profis definieren Klassen so, dass sie stabil, auditierbar und messbar sind.

Match nach DSCP/CoS: bevorzugt, wenn Trust sauber ist

• Vorteil: Schnell, skalierbar, unabhängig von Applikationsports, gut für verschlüsselte Protokolle.
• Nachteil: Nur so gut wie die Trust Boundary; falsche Markierungen propagieren sich.

Match nach Ports/Protokollen: sinnvoll am Edge, riskant als Dauerstrategie

• Vorteil: Gute Kontrolle, wenn DSCP am Rand noch nicht gesetzt ist.
• Nachteil: Ports ändern sich, Applikationen tunneln, TLS verschleiert Inhalte; Wartungsaufwand steigt.

Match nach Subnetzen/Zonen: hilfreich für Segment-Policies

• Vorteil: Stabil über Zeit, passt zu Zonen-/VRF-Designs, gut für Mindestbandbreiten.
• Nachteil: Innerhalb eines Subnetzes können unterschiedliche Anwendungen existieren; erfordert ggf. zusätzliche Differenzierung.

Policy-Maps: Aktionen richtig wählen (set, priority, bandwidth, police, shape)

In der policy-map definieren Sie das Verhalten pro Klasse. Der Profi-Ansatz ist dabei: nicht „alles aktivieren“, sondern nur das, was an der jeweiligen Stelle wirksam ist. Typische Aktionen:

• set dscp / set cos: Markieren oder Remarken, meist Ingress-nah.
• priority: Low-Latency Queue (LLQ) für Echtzeittraffic (Voice), Egress-nah.
• bandwidth: Mindestbandbreite für eine Klasse, Egress-nah.
• police: Harte Begrenzung, häufig am Edge/WAN; kann Drops erzeugen.
• shape: Glättung/Rate-Limit, typischerweise am WAN-Egress, um Provider-Policer zu „entlasten“.

LLQ richtig einsetzen: Voice priorisieren, aber nicht das Netz blockieren

Die LLQ (priority) ist essenziell für Voice, kann aber bei falscher Dimensionierung andere Klassen verdrängen. Ein Profi-Pattern ist: LLQ klein, streng und nur für echten Echtzeittraffic. Alles, was nicht klar Echtzeit ist, gehört nicht in LLQ.

• Nur EF (oder klar definierte Voice-Klasse): Keine „alles Echtzeit“-Kreativität.
• Policing der LLQ: Viele Designs policen die LLQ implizit oder explizit, um Missbrauch zu verhindern.
• Signalisierung vs. Media: Call-Signalisierung ist wichtig, aber nicht zwangsläufig LLQ; oft reicht eine „kritische“ Klasse mit Mindestbandbreite.

Shaping vs. Policing: Der wichtigste Unterschied im Betrieb

Policing droppt bei Überschreitung sofort. Shaping puffert und sendet geglättet. Für WAN-Übergänge ist Shaping häufig betrieblich stabiler, weil es Burst-Verhalten glättet und Provider-Policer weniger oft triggert. Policing ist sinnvoll, wenn Sie bewusst begrenzen müssen (z. B. Gastnetz) oder wenn Pufferung unerwünscht ist.

• Shaping: Besser für TCP, reduziert Retransmits, erzeugt aber zusätzliche Latenz im Puffer.
• Policing: Geringe Latenz, aber Drops und damit potenziell schlechte Performance bei burstigem Traffic.
• Praxis: Am WAN-Egress oft shape auf CIR/Provider-Rate, in Klassen darunter ggf. police für Missbrauchsschutz.

Hierarchische QoS (HQoS): Wenn ein Policy-Layer nicht reicht

In großen Netzen reicht oft eine flache Policy nicht, insbesondere bei WAN-Links oder bei Service-Provider-Übergängen. Hier kommt HQoS ins Spiel: eine parent-policy (meist shaping) und darunter child-policies (Queueing/Klassen). Das verhindert, dass ein globales Shaping die Klassenlogik „zerdrückt“.

• Parent: Setzt das Gesamtrate-Limit (z. B. WAN-CIR), glättet Traffic.
• Child: Definiert Klassen mit priority/bandwidth/WRED innerhalb des geshapten Rahmens.
• Nutzen: Klassenverhalten bleibt auch bei Gesamtshaping konsistent.

HQoS ist stark plattformabhängig. Prüfen Sie daher immer in den Cisco Plattform-Guides, welche Hierarchie-Modelle und Kombinationen auf Ihrer Hardware/Software unterstützt werden. Ein guter Einstieg ist die QoS-Dokumentation in den IOS XE Guides.

Queueing-Realität: Platform-Pipelines, ASIC-Queues und warum MQC nicht überall gleich wirkt

MQC ist eine CLI-Logik, aber die eigentliche Umsetzung findet in Hardware-Queues, Policern und Scheduler-Pipelines statt. Genau deshalb scheitern viele QoS-Projekte: Die Policy ist syntaktisch korrekt, passt aber nicht zur Plattform. Typische Unterschiede:

• Campus Switches: Oft feste Queue-Anzahl, feste Scheduler-Logik; MQC-Mapping auf Hardware ist entscheidend.
• Router/WAN-Edge: Häufig flexiblere Shaping/Policing-Modelle, aber CPU/Punt-Risiken bei falscher Kombination.
• NX-OS: Andere Syntax- und Policy-Strukturen als IOS XE, oft stärker an Hardware-QoS-Modelle gebunden.

Profis bauen QoS deshalb immer „plattformbewusst“: Erst die Hardwarefähigkeiten verstehen (Queues, Buffer, Scheduler, WRED-Fähigkeit), dann die MQC-Policy so modellieren, dass sie wirklich umgesetzt wird.

Ein praxistaugliches Klassenmodell: Wenige Klassen, klare Semantik

Ein häufiges QoS-Anti-Pattern sind zu viele Klassen. Jede zusätzliche Klasse erhöht Komplexität, Messaufwand und Fehlerwahrscheinlichkeit. Ein praxistaugliches Enterprise-Modell kommt oft mit 4–6 Klassen aus:

• Echtzeit: Voice Media (EF), LLQ.
• Kritisch: Business-kritische Apps, Signalisierung, ggf. interaktive Anwendungen (AF/CS nach Standard).
• Best Effort: Standardverkehr, der „fair“ bedient wird.
• Bulk/Scavenger: Backups, Updates, große Transfers, die niedrig priorisiert werden dürfen.
• Management: Optional als separate Klasse, wenn Managementpfade geschützt werden müssen (mit Vorsicht, um Missbrauch zu vermeiden).

Wichtig ist die Semantik: Jede Klasse braucht eine klare Definition, welche Applikationen hinein dürfen und welche nicht. Ohne diese Semantik wird QoS zur politischen Debatte („meine App ist kritisch“), statt zu einem technischen Standard.

WRED und Congestion Avoidance: Drops steuern statt nur „mehr Priorität“

QoS bedeutet nicht nur Priorisierung, sondern auch kontrolliertes Droppen bei Überlast. WRED (Weighted Random Early Detection) kann in Best-Effort- oder AF-Klassen sinnvoll sein, um TCP frühzeitig zu signalisieren, dass Stau entsteht, und damit globale Synchronisation und harte Tail-Drops zu reduzieren. In Echtzeit-Klassen ist WRED in der Regel nicht sinnvoll; dort wollen Sie minimale Latenz und möglichst keine Drops.

• Best Effort: WRED kann helfen, TCP stabiler zu halten.
• AF-Klassen: Unterschiedliche Drop-Precedence kann genutzt werden (z. B. AFxy), wenn Sie wirklich Precedence-Logik betreiben.
• Voice/LLQ: Drops vermeiden, nicht „clever droppen“.

QoS und Security: Markierungen sind ein Angriffsvektor, wenn Trust falsch ist

Wenn Clients DSCP frei setzen dürfen, können sie sich effektiv „vordrängeln“. Deshalb ist Trust Boundary auch ein Security-Thema. Ein gutes Enterprise-Design verbindet QoS mit Access-Policies:

• Trusted nur für kontrollierte Geräte: Telefon, definierte Infrastruktur, ggf. Managed Clients.
• Re-Marking am Access: Untrusted Clients werden auf Best Effort oder definierte Klassen zurückgesetzt.
• Monitoring: Anomalien (zu viel EF) sind ein Security- und Betriebsindikator.

Verifikation: QoS ohne Counters ist nur eine Behauptung

Der wichtigste Profi-Satz zu QoS lautet: „Wenn Sie es nicht messen, existiert es nicht.“ MQC liefert Zähler pro Klasse, Policers zeigen Drops, und Queue-Statistiken zeigen, ob Scheduler wirklich greift. Ein Verifikationsstandard sollte Teil jedes QoS-Blueprints sein.

• Class Counters: Treffen die Pakete in der erwarteten Klasse ein?
• Drop Counters: Wo wird gedroppt (Policer, Queue Tail Drop, WRED)?
• Queue Depth/Buffer: Entsteht Stau? Wenn ja, in welcher Klasse und warum?
• End-to-End: Messung entlang des Pfades, nicht nur auf einem Interface. QoS wirkt nur so gut wie das schwächste Glied.

Ein typischer Fehler ist, nur an einem Device zu prüfen und daraus globale Aussagen abzuleiten. In Enterprise-Netzen müssen Sie mindestens an den Engpässen prüfen: WAN-Edge, Internet-Exit, DC-Uplinks, ggf. Wireless-Edge.

Rollout-Strategie: Erst markieren, dann schützen, dann optimieren

QoS scheitert häufig am „Big Bang“. Ein stabiler Rollout ist stufenweise: Zuerst konsistente Markierungen, dann Queueing/LLQ an Engpässen, dann Shaping/Policing dort, wo Provider oder Linklimits es erfordern.

• Phase 1: Trust Boundary definieren und Ingress-Markierung standardisieren.
• Phase 2: Egress-Queueing an den echten Bottlenecks einführen (WAN, Internet-Exit).
• Phase 3: Shaping/Policing ergänzen (HQoS), Drops beobachten und feinjustieren.
• Phase 4: Compliance und Drift-Checks etablieren (Standardklassen, keine „Schatten-Policies“).

Typische MQC-Fallstricke, die Profis vermeiden

• Zu viele Klassen: Komplexität steigt, Nutzen sinkt; End-to-End-Konsistenz bricht.
• LLQ zu groß: Echtzeit verdrängt andere Klassen; bei Missmarkierung wird das Netz instabil.
• Policing statt Shaping am WAN: Unerwartete Drops und schlechte TCP-Performance, besonders bei Burst-Verhalten.
• Trust überall: Jeder kann sich „EF“ geben; QoS wird zum Selbstbedienungsladen.
• Keine Verifikation: Policy existiert, aber Counters zeigen, dass Traffic nie in den Klassen landet.
• Plattformunterschiede ignorieren: MQC-Syntax klappt, Hardware-Pipeline setzt aber nicht wie erwartet um.

Outbound-Referenzen

• Cisco IOS XE: QoS Overview (Network Services) für MQC-Grundlagen, Policy-Modelle und Plattformhinweise.
• Cisco IOS XE Configuration Guides für detaillierte MQC-Konfigurationen und Feature-Varianten.
• Cisco Nexus 9000 (NX-OS) Configuration Guides für NX-OS-spezifische QoS-Modelle und Unterschiede zu IOS XE.
• RFC 2474 und RFC 2475 als DiffServ-Basis (DSCP und Architektur).
• RFC 3246 (EF PHB) als Referenz für die typische Echtzeit-/Voice-Klasse.

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.