Site icon bintorosoft.com

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

Red Snapper

Secure Data Sharing Protocol

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.

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:

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.

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

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

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

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:

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.

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.

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“.

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:

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:

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.

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:

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.

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.

Typische MQC-Fallstricke, die Profis vermeiden

Outbound-Referenzen

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:

Lieferumfang:

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.

 

Exit mobile version