Policy Map und Class Map: Cisco QoS Schritt-für-Schritt

Wer Cisco QoS in der Praxis umsetzen möchte, stößt sehr schnell auf zwei zentrale Bausteine: Policy Map und Class Map. Beide gehören zur sogenannten Modular QoS CLI (MQC) und bilden das Fundament, um Datenverkehr zu klassifizieren, zu markieren und bei Engpässen gezielt zu priorisieren. Gerade für VoIP, Videokonferenzen, geschäftskritische Anwendungen oder stark schwankende WAN-Links ist es entscheidend, dass nicht „alles gleich“ behandelt wird. Gleichzeitig ist QoS kein Zauberstab: Es erzeugt keine zusätzliche Bandbreite, sondern steuert, wie Pakete behandelt werden, wenn Ressourcen knapp werden. Damit das funktioniert, brauchen Sie eine saubere Schritt-für-Schritt-Vorgehensweise: Zuerst müssen Sie definieren, welche Traffic-Arten überhaupt relevant sind (z. B. Voice, Video, Critical Data, Best Effort). Danach wird diese Logik technisch in Class Maps (Erkennung) und Policy Maps (Aktion) übersetzt und schließlich an einem Interface oder einem Tunnel per Service Policy aktiviert. Dieser Leitfaden erklärt praxisnah und leicht verständlich, wie Sie Policy Map und Class Map in Cisco QoS aufbauen, typische Best Practices anwenden, häufige Fehler vermeiden und die Wirkung mit Verifikationsbefehlen zuverlässig prüfen.

MQC in einem Satz: Was Class Map und Policy Map leisten

Die MQC folgt einem einfachen Prinzip: Sie beschreiben zunächst welcher Traffic zu einer Klasse gehört und anschließend was mit dieser Klasse passieren soll. Daraus ergibt sich ein klarer Baukasten:

• Class Map: definiert, wie Traffic erkannt wird (z. B. DSCP, ACL, Protokoll, Ports).
• Policy Map: definiert, welche QoS-Aktionen auf diese Klassen angewendet werden (z. B. priority, bandwidth, police, shape, set dscp).
• Service Policy: bindet die Policy Map an ein Interface (input oder output) oder an andere Stellen wie Tunnel-Interfaces.

Wenn Sie diese Logik verinnerlichen, wird QoS-Konfiguration deutlich strukturierter. Als Einstieg in Cisco QoS-Überblicke eignet sich der Anchor-Text Cisco QoS Übersicht. Für das DiffServ-Konzept (DSCP) ist der Anchor-Text RFC 2474 (DiffServ) hilfreich.

Vor dem Start: Wo QoS wirklich wirkt

QoS ist nur an Engpässen relevant. Wenn ein Link dauerhaft mehr Traffic sieht, als er übertragen kann, entstehen Warteschlangen, Drops, Latenz und Jitter. Genau dort steuert QoS, wer bevorzugt wird.

• Typische Engpässe: WAN-Uplinks, Internetanschlüsse, VPN-Tunnel, WLAN-Uplinks, überlastete Trunks.
• Typische QoS-Ziele: Voice stabil halten, Video priorisieren, kritische Apps absichern, Bulk-Traffic kontrollieren.

Best Practice: Setzen Sie QoS dort um, wo Congestion entsteht. Eine perfekte Policy im Campus hilft wenig, wenn der Engpass am WAN liegt und dort keine Queueing-/Shaping-Policy aktiv ist.

Schritt 1: Klassenmodell definieren

Ein häufiger Fehler ist ein zu komplexes Modell. Für den Einstieg reicht ein überschaubares Klassenmodell, das sich später erweitern lässt. Ein bewährter Start:

• VOICE: RTP/Voice (sehr latenz- und jitterkritisch)
• VIDEO: Video/Collaboration (bandbreitenintensiv, aber wichtig)
• CRITICAL: geschäftskritische Anwendungen (z. B. VDI, ERP, Transaktionen)
• DEFAULT: Best Effort
• SCAVENGER: Hintergrundtraffic (z. B. Backups/Updates) bewusst niedriger

Der wichtigste Punkt ist Konsistenz: Nutzen Sie einheitliche Markierungen (DSCP/CoS) und eine klare Trust Boundary, damit nicht beliebige Clients „hoch“ markieren.

Schritt 2: Traffic erkennen mit Class Maps

Eine Class Map ist die Erkennungslogik. Sie können nach Markierungen (DSCP), nach ACLs, nach Protokollen oder nach Ports matchen. Praktisch ist DSCP oft der skalierbarste Ansatz, weil Markierungen Ende-zu-Ende transportiert werden.

Class Map nach DSCP (typisches Muster)

configure terminal
class-map match-any VOICE
match dscp ef
class-map match-any VIDEO
match dscp af41
class-map match-any CRITICAL
match dscp af31
class-map match-any SCAVENGER
match dscp cs1
end

Hinweis: Die DSCP-Werte sind Beispielwerte, die in vielen Designs genutzt werden. Entscheidend ist, dass Ihre Endgeräte bzw. Ihr Edge-Markierungskonzept diese Werte konsistent setzt.

Class Map mit ACL (wenn Markierungen fehlen oder nicht vertrauenswürdig sind)

Wenn Markierungen unklar sind, können Sie über eine ACL nach Quell-/Zielnetzen oder Ports klassifizieren. Beispiel: SIP-Signalisierung (TCP/5060 oder UDP/5060) aus einem Voice-VLAN zu einem Call-Manager-Netz.

configure terminal
ip access-list extended ACL-VOICE-SIG
permit udp 10.10.40.0 0.0.0.255 10.10.30.0 0.0.0.255 eq 5060
permit tcp 10.10.40.0 0.0.0.255 10.10.30.0 0.0.0.255 eq 5060
exit
class-map match-any VOICE-SIG
match access-group name ACL-VOICE-SIG
end

Best Practice: Wenn möglich, klassifizieren Sie nach Markierungen und sorgen am Netzrand für korrektes Marking. ACL-basierte Klassifizierung ist valide, aber wartungsintensiver.

Schritt 3: Aktionen definieren mit Policy Maps

In der Policy Map legen Sie fest, wie jede Klasse behandelt wird. Typische Aktionen:

• priority: Low Latency Queue (LLQ) für Echtzeittraffic, mit Rate-Limit
• bandwidth: garantierte Bandbreite für eine Klasse
• police: harte Begrenzung (Drops oder Remarking bei Überschreitung)
• shape: glättet Traffic; wichtig am WAN, damit der Router der Engpass ist
• set dscp: Markierung setzen oder korrigieren

Beispiel: einfache WAN-Policy mit LLQ und garantierter Bandbreite

configure terminal
policy-map WAN-OUT
class VOICE
priority percent 10
class VIDEO
bandwidth percent 20
class CRITICAL
bandwidth percent 20
class SCAVENGER
bandwidth percent 5
class class-default
fair-queue
end

Warum ist priority begrenzt? Weil eine unlimitierte Priority Queue andere Klassen verdrängen kann. VoIP braucht geringe Latenz, aber meist keine riesige Bandbreite. Eine limitierte LLQ ist daher Standard-Best-Practice.

Schritt 4: Service Policy anwenden (input vs. output)

Eine Policy wirkt erst, wenn sie gebunden ist. In MQC geschieht das per service-policy. Sie können Policies inbound oder outbound anwenden. In der Praxis ist QoS für Congestion oft outbound entscheidend, weil der Engpass beim Senden auf einen begrenzten Link entsteht.

Beispiel: Policy outbound am WAN-Interface

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

Best Practice: Nutzen Sie outbound Policies dort, wo der Link wirklich „dicht“ läuft. Inbound Policies sind oft eher für Marking/Policing interessant, z. B. um untrusted Markierungen zu korrigieren.

Schritt 5: Shaping als Parent/Child (sehr häufig im WAN)

Viele VoIP- und Echtzeitprobleme entstehen, weil Congestion nicht auf dem Router passiert, sondern im Provider-Edge oder im Modem. Dann kann Ihre Queueing-Policy nicht sauber wirken. Shaping sorgt dafür, dass der Router selbst der Engpass wird. Ein verbreitetes Muster ist die Parent/Child-Policy: Parent shaped auf die vertragliche Rate, Child enthält die Klassen (LLQ, bandwidth, etc.).

Beispiel: Parent/Child mit Shaping

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

configure terminal
interface GigabitEthernet0/0
service-policy output WAN-PARENT
end

Die Rate (hier 50.000.000 bps) sollte in der Praxis knapp unter der real verfügbaren Provider-Bandbreite liegen, damit Drops und Queueing kontrolliert auf dem Router stattfinden.

Marking mit Policy Maps: DSCP bewusst setzen oder korrigieren

QoS scheitert häufig an inkonsistenten Markierungen. Eine pragmatische Lösung ist Edge-Markierung: Das Netz setzt DSCP selbst, statt Endgeräten blind zu vertrauen.

Beispiel: Marking-Policy am Eingang (untrusted Bereich)

configure terminal
class-map match-any VOICE-RTP
match access-group name ACL-RTP
policy-map MARK-IN
class VOICE-RTP
set dscp ef
class class-default
set dscp default
end

Wichtig: Dieses Muster setzt voraus, dass Sie RTP (oder Voice) zuverlässig erkennen können (z. B. per DSCP vom Telefon oder per klarer ACL/Signatur). Marking sollte nicht zu großzügig erfolgen, sonst „verschmutzen“ Sie die Priority-Klasse.

Policing in Policy Maps: Missbrauch stoppen, ohne Voice zu zerstören

Policing begrenzt Traffic hart. Das ist nützlich, um untrusted Bereiche daran zu hindern, zu viel „hoch priorisierten“ Traffic zu erzeugen. Für Voice selbst ist hartes Policing oft riskant, weil Drops hörbar sind. Häufiger ist Policing sinnvoll für Scavenger- oder Bulk-Klassen.

Beispiel: Scavenger hart begrenzen

configure terminal
policy-map WAN-OUT
class SCAVENGER
police 2000000 conform-action transmit exceed-action drop
end

Damit verhindern Sie, dass Backups oder große Updates kritische Echtzeitklassen verdrängen.

Class Map Tipps: match-any vs. match-all richtig nutzen

Class Maps unterstützen Logikvarianten:

• match-any: trifft, wenn eine Bedingung passt (OR-Logik)
• match-all: trifft nur, wenn alle Bedingungen passen (AND-Logik)

Praxisregel: match-any ist häufig sinnvoll, wenn Sie mehrere DSCP-Werte oder mehrere Kriterien zusammenfassen möchten. match-all ist nützlich, wenn Sie präzise kombinieren wollen (z. B. bestimmte Quelle UND bestimmter Port).

Reihenfolge und class-default: Was viele übersehen

In einer Policy Map wird Traffic, der keiner Class Map entspricht, in class-default behandelt. Das ist kein „Fehler“, sondern ein wichtiges Sicherheitsnetz. Best Practices:

• class-default bewusst konfigurieren: z. B. fair-queue oder definierte Bandbreite.
• Keine „vergessenen“ Klassen: Wenn ein wichtiger Traffic nicht matcht, landet er im Default und bekommt ggf. nicht die gewünschte Priorität.
• Regelmäßig Counter prüfen: Wenn Default ungewöhnlich viel Traffic sieht, stimmt Klassifizierung oder Marking nicht.

Verifikation Schritt-für-Schritt: So prüfen Sie, ob QoS wirklich greift

MQC bietet sehr klare Verifikationsmöglichkeiten. Der wichtigste Befehl im Betrieb ist:

show policy-map interface <INTERFACE>

Damit prüfen Sie:

• Ob Klassen Treffer (Packets/Bytes) haben
• Ob Drops auftreten (insbesondere in LLQ)
• Ob Shaping aktiv ist (bei Parent/Child)
• Ob Policing greift (conform/exceed Werte)

Weitere hilfreiche Befehle:

• show class-map (Definitionen)
• show policy-map (Policy-Definitionen)
• show running-config | section policy-map und show running-config | section class-map (Konfigcheck)
• show interfaces <INTERFACE> (Auslastung, Errors, Drops)

Häufige Fehler bei Policy Map und Class Map

• QoS matcht nicht: Class Map erkennt Traffic nicht, weil DSCP nicht gesetzt ist oder ACL falsch ist.
• Trust Boundary fehlt: Clients markieren willkürlich hoch; Voice-Klasse wird überladen.
• LLQ zu groß oder unlimitiert: Andere Klassen droppen, Netz fühlt sich instabil an.
• Kein Shaping am WAN: Congestion passiert im Provider-Edge; lokale Queues wirken kaum.
• Zu komplexes Modell: Viele Klassen ohne klare Ownerschaft, Mapping und Verifikation.
• Falsches Interface: Policy ist gebunden, aber nicht am tatsächlichen Engpass.

Best Practices für Cisco QoS mit MQC

• Mit wenigen Klassen starten: Voice, Video, Critical, Default, Scavenger.
• Marking-Plan dokumentieren: DSCP/CoS und Mapping festlegen, Endgeräte oder Edge setzen lassen.
• Trust Boundary definieren: Telefon/Infra ggf. trusted, Clients untrusted.
• LLQ begrenzen: Priority Queue immer mit Rate/Percent limitieren.
• WAN-Shaping einplanen: Router soll den Engpass kontrollieren.
• Regelmäßig verifizieren: Counter und Drops prüfen, nicht nur „Konfig vorhanden“.
• Änderungen schrittweise: Erst matchen/markieren verifizieren, dann Queueing optimieren.

Für weiterführende Cisco-spezifische Beispiele und Plattformunterschiede ist der Anchor-Text Cisco QoS Konfigurationsguides hilfreich. Für DSCP/DiffServ-Konzepte bieten RFC 2474, RFC 2597 (AF) und RFC 3246 (EF) gute Grundlagen.

Praxis-Checkliste: Cisco QoS Schritt-für-Schritt umsetzen

• Ist der Engpass identifiziert (WAN, VPN, WLAN-Uplink, Trunk)?
• Gibt es ein klares Klassenmodell (Voice, Video, Critical, Default, Scavenger)?
• Sind Markierungen konsistent (DSCP/CoS) und ist die Trust Boundary definiert?
• Erkennen die Class Maps den Traffic zuverlässig (DSCP oder ACL/NBAR)?
• Ist die Policy Map sinnvoll (LLQ begrenzt, Bandbreitenanteile plausibel, Default definiert)?
• Ist die Service Policy am richtigen Interface gebunden (input/output passend)?
• Ist am WAN Shaping aktiv, wenn der Provider-Link der Engpass ist?
• Wurde die Wirkung verifiziert (show policy-map interface, Drops, Counter, Qualität)?

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.