Traffic Shaping vs. Policing: Cisco Unterschiede erklärt

Wer Quality of Service (QoS) in Cisco Netzwerken ernsthaft betreibt, kommt an zwei Mechanismen nicht vorbei: Traffic Shaping und Policing. Beide begrenzen Datenverkehr, beide werden in Policy Maps eingesetzt, und beide werden im Alltag häufig verwechselt. Das führt zu typischen Problemen: VoIP klingt trotz QoS schlecht, weil am WAN kein Shaping aktiv ist. Oder Anwendungen brechen sporadisch ab, weil ein zu aggressiver Policer Pakete verwirft. Um die richtigen Entscheidungen zu treffen, müssen Sie verstehen, was hinter den Begriffen steckt: Shaping ist „sanftes“ Begrenzen durch Puffern und Glätten, Policing ist „hartes“ Begrenzen durch Verwerfen oder Herabstufen bei Überschreitung. In diesem Artikel werden die Cisco Unterschiede erklärt – inklusive klarer Praxisbeispiele, wann Shaping sinnvoller ist (typisch am WAN-Edge), wann Policing die bessere Wahl ist (z. B. gegen Missbrauch oder zur Einhaltung eines Provider-Profils) und wie Sie beide Mechanismen in Cisco MQC (Class Map/Policy Map/Service Policy) korrekt konfigurieren und verifizieren. Ziel ist, dass Sie Traffic Shaping vs. Policing nicht nur theoretisch unterscheiden, sondern im Betrieb gezielt einsetzen, um Latenz, Jitter und Packet Loss unter Kontrolle zu behalten.

Begriffsdefinition: Was ist Traffic Shaping?

Traffic Shaping ist eine QoS-Maßnahme, bei der ein Gerät (Router, L3-Plattform, teilweise auch Switch) den ausgehenden Datenverkehr auf eine definierte Rate „glättet“. Technisch bedeutet das: Wenn kurzfristig mehr Traffic anliegt als erlaubt, wird der Überschuss nicht sofort verworfen, sondern in einer Warteschlange gepuffert und später gesendet. Shaping ist damit ein Mechanismus, der Burst-Verhalten abfedert und einen gleichmäßigeren Datenstrom erzeugt.

• Wirkprinzip: Puffern und verzögertes Senden, um eine Zielrate einzuhalten.
• Typischer Einsatz: Ausgangsrichtung (Egress), vor allem an WAN-Uplinks.
• Stärke: Reduziert Drops, kontrolliert Congestion am eigenen Gerät.
• Schwäche: Erhöht bei Überlast die Verzögerung (Queueing Delay), wenn zu viel Traffic gepuffert wird.

Begriffsdefinition: Was ist Policing?

Policing ist eine QoS-Maßnahme, bei der ein Gerät den Datenverkehr auf eine definierte Rate begrenzt, indem es bei Überschreitung sofort reagiert – typischerweise durch Drop (verwerfen) oder Remarking (Herabstufen der Markierung, z. B. DSCP). Im Gegensatz zum Shaping wird beim Policing nicht „geglättet“, sondern „abgeschnitten“: Was über dem Limit liegt, wird nicht nachträglich gesendet, sondern unterdrückt oder schlechter behandelt.

• Wirkprinzip: Messen gegen eine Rate; Überschreitung führt zu Drop oder Herabstufung.
• Typischer Einsatz: Eingang (Ingress) oder Ausgang (Egress), oft als Schutz-/Kontrollmechanismus.
• Stärke: Setzt harte Grenzen, verhindert Missbrauch, hält Profile ein.
• Schwäche: Drops können TCP massiv bremsen, Jitter/Qualität bei Echtzeittraffic verschlechtern.

Der zentrale Unterschied in einem Satz

Shaping verzögert und puffert überzählige Pakete, um einen gleichmäßigen Datenstrom zu erzeugen; Policing verwirft oder markiert Pakete bei Überschreitung sofort neu, um eine harte Obergrenze durchzusetzen.

Warum diese Unterscheidung in Cisco Netzwerken so wichtig ist

In Enterprise-Umgebungen liegt der Engpass oft am WAN oder Internetanschluss. Wenn Congestion außerhalb Ihrer Kontrolle entsteht (z. B. im Provider-Edge oder im Modem), helfen lokale Prioritätsqueues nur eingeschränkt. Shaping ist hier häufig der Schlüssel, weil der Router den Engpass „zu sich zieht“: Er shaped knapp unter der realen Rate und kann dann interne Warteschlangen (LLQ, bandwidth) sauber bedienen. Policing ist dagegen eher ein Mittel, um Grenzen zu erzwingen – etwa für Gäste, IoT oder unerwünschte Markierungen. Wer Shaping und Policing verwechselt, erhält häufig das Gegenteil des gewünschten Effekts: Statt weniger Drops entstehen mehr Drops, statt stabiler Voice wird Voice schlechter.

Typische Einsatzorte: WAN, Campus, Zugang, Provider

Damit Sie schnell eine richtige Entscheidung treffen können, hilft eine Einordnung nach Einsatzort:

• WAN Edge (Router): Shaping ist meist die erste Wahl, weil es Queueing kontrolliert und Echtzeittraffic schützt.
• Campus Access (Switchport): Policing ist häufig sinnvoll, um einzelne Ports zu begrenzen (Ingress-Limit) oder Missbrauch zu verhindern.
• Provider-Übergabe (MPLS/Ethernet Hand-off): Shaping zur Einhaltung der CIR/EIR-Profile, Policing zum Abfangen von Überschreitungen (je nach Vertrag).
• Untrusted Bereiche (Guest/IoT): Policing und Remarking sind oft sinnvoll, weil man nicht „puffern“, sondern begrenzen will.

Wie Shaping und Policing technisch „messen“

Beide Mechanismen basieren auf der Idee, Datenraten über Zeit zu bewerten. In der Praxis spielen dabei Burst-Parameter eine Rolle: Datenverkehr kommt selten als perfekte, gleichmäßige Linie, sondern in Bursts. Ein Shaper kann Bursts puffern, ein Policer bewertet Bursts gegen Token/Burst-Parameter und verwirft bei Überschreitung.

• Shaping: Bursts werden in einer Queue zwischengespeichert; der Shaper entleert die Queue mit der Zielrate.
• Policing: Bursts werden gegen zulässige Burst-Größen geprüft; Überschreitung wird gedroppt oder herabgestuft.

In der Praxis bedeutet das: Ein zu kleiner Burst beim Policing kann „unnötige“ Drops verursachen, selbst wenn die durchschnittliche Rate moderat ist. Ein zu großer Puffer beim Shaping kann dagegen Latenz verursachen, wenn dauerhaft zu viel Traffic anliegt.

Shaping in Cisco MQC konfigurieren

In Cisco MQC (Modular QoS CLI) wird Shaping typischerweise in einer Policy Map mit shape average eingesetzt. Besonders verbreitet ist das Parent/Child-Muster: Eine Parent-Policy shaped auf die Linkrate, und darunter liegt eine Child-Policy mit den eigentlichen Klassen (Voice, Video, Critical, Default).

Beispiel: Child-Policy mit LLQ für Voice

class-map match-any VOICE
match dscp ef

policy-map WAN-CHILD
class VOICE
priority percent 10
class class-default
fair-queue

Beispiel: Parent-Policy mit Shaping und Child-Policy

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

Beispiel: Anwendung auf dem WAN-Interface

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

Praxislogik: Der Router shaped auf 50 Mbit/s und wird damit selbst zum Engpass. Dadurch kann er Voice in der Priority Queue bevorzugt bedienen, statt dass Congestion beim Provider entsteht und Pakete unkontrolliert droppen. Als Einstieg in Cisco QoS-Konzepte eignet sich der Anchor-Text Cisco QoS Übersicht.

Policing in Cisco MQC konfigurieren

Policing wird in MQC typischerweise über police umgesetzt, kombiniert mit Aktionen für „conform“ und „exceed“. Im einfachsten Fall droppen Sie Überschreitungen. Alternativ können Sie Überschreitungen neu markieren (Remarking), damit sie in einer niedrigeren QoS-Klasse landen.

Beispiel: Harte Begrenzung (Drop bei Überschreitung)

class-map match-any LIMIT-ALL
match any

policy-map POLICE-20M
class LIMIT-ALL
police 20000000 conform-action transmit exceed-action drop

Anwendung (Ingress auf einem Switchport oder Routerinterface):

interface GigabitEthernet1/0/10
service-policy input POLICE-20M

Beispiel: Überschreitung herabstufen statt droppen

Remarking ist sinnvoll, wenn Sie Ende-zu-Ende-QoS haben und Überschreitungen nicht sofort zerstören, sondern nur „weniger wichtig“ machen wollen.

policy-map POLICE-20M
class LIMIT-ALL
police 20000000
conform-action transmit
exceed-action set-dscp-transmit default

Hinweis: Ob eine bestimmte Remarking-Option verfügbar ist, hängt von Plattform und IOS/IOS XE-Version ab. Die genaue Syntax finden Sie über den Anchor-Text Cisco IOS Command Reference.

Auswirkungen im Betrieb: Latenz, Jitter und TCP-Verhalten

Der Unterschied zwischen Shaping und Policing zeigt sich besonders deutlich bei Echtzeittraffic und bei TCP.

Shaping und Echtzeittraffic

• Shaping erzeugt Pufferung. Bei kurzer Überlast kann das gut sein, weil Drops vermieden werden.
• Bei dauerhafter Überlast kann die Queue wachsen, wodurch Latenz und Jitter steigen.
• Mit Klassen (LLQ) lässt sich Echtzeittraffic priorisieren, sodass Voice weniger puffern muss.

Policing und Echtzeittraffic

• Policing dropt bei Überschreitung. Drops in Voice/RTP sind unmittelbar hörbar.
• Policing eignet sich daher eher als Schutz gegen falsche Markierungen oder in unkritischen Segmenten.
• Wenn Voice policet werden muss, dann nur mit sehr bewusstem Limit und sauberem Marking, damit Voice nicht „zufällig“ gedroppt wird.

Shaping und TCP

• Shaping kann TCP stabilisieren, weil weniger Drops entstehen.
• TCP passt seine Rate über Congestion Control an; Shaping führt eher zu gleichmäßigerem Durchsatz.

Policing und TCP

• Policing verursacht Drops. TCP interpretiert Drops als Congestion und reduziert drastisch die Sendrate.
• Das kann gewünschte Effekte haben (harte Begrenzung), aber auch Performance „unnatürlich“ einbrechen lassen.
• Besonders bei Burst-lastigen Anwendungen kann ein Policer unberechenbare Einbrüche erzeugen, wenn Burst-Parameter nicht passen.

Praxis-Szenarien: Wann Shaping die bessere Wahl ist

• WAN-Link mit Echtzeittraffic: VoIP/Video sollen stabil bleiben, auch wenn Datenverkehr hoch ist.
• Internetanschluss mit schwankender realer Rate: Shaping hilft, Congestion kontrollierbar zu halten.
• VPN/DMVPN/SD-WAN: Tunnel-Overhead und variable Pfade – Shaping ermöglicht konsistente Queueing-Entscheidungen.
• Provider-Profile: Wenn Sie eine vertragliche Rate (CIR) einhalten müssen, ist Shaping oft der „saubere“ Weg.

Faustregel: Wenn Sie Traffic nicht „abschneiden“, sondern „ordnen“ möchten, ist Shaping meist besser.

Praxis-Szenarien: Wann Policing die bessere Wahl ist

• Untrusted Clients/Gäste: Ein Segment soll nicht mehr als X Mbit/s erzeugen.
• Schutz vor Missbrauch: Endgeräte markieren Traffic fälschlich hoch; Policing kann EF/High-Priority begrenzen.
• Ingress-Schutz: Ein Port darf das Netz nicht fluten (z. B. IoT-Gerät mit Fehlverhalten).
• Einhaltung harter Grenzen: In manchen Designs muss ein festes Maximum erzwungen werden, auch wenn das Drops bedeutet.

Faustregel: Wenn Sie eine harte Obergrenze brauchen und Pufferung unerwünscht ist, ist Policing meist die richtige Wahl.

Häufige Fehler: Shaping und Policing falsch eingesetzt

• Nur Policing am WAN: Voice bleibt schlecht, weil Drops entstehen und Congestion nicht kontrolliert wird.
• Shaping ohne Klassen: Alles wird nur geglättet, aber Voice erhält keine echte Priorität.
• Policing auf Voice: Drops werden hörbar; die Maßnahme verschlechtert die Qualität.
• Shaping auf zu hoher Rate: Router ist nicht der Engpass; Congestion entsteht weiterhin beim Provider.
• Falsche Richtung: Policer/Shaper wird input gebunden, obwohl der Engpass output liegt (oder umgekehrt).
• Keine Verifikation: Policy existiert, aber Counters zeigen, dass sie nie matcht.

Verifikation: So sehen Sie, ob Shaping oder Policing wirklich greift

Ohne Messung ist QoS nur Theorie. In Cisco MQC ist der wichtigste Prüf-Befehl:

• show policy-map interface <INTERFACE>

Dort prüfen Sie unter anderem:

• Treffer pro Klasse (Packets/Bytes): Matcht der Traffic?
• Drops: Werden Pakete verworfen (Policing) oder in Queues verwaltet (Shaping/Queueing)?
• Shaping-Status: Sehen Sie die Parent/Child-Struktur und die Shaping-Rate?
• Policer-Statistik: conform/exceed Werte, Drop-Zähler, ggf. Remarking-Zähler.

Ergänzend sind Interface-Statistiken sinnvoll:

• show interfaces <INTERFACE> (Auslastung, Errors, Drops)

Wenn Shaping nicht „sichtbar“ wirkt, liegt häufig keine Congestion vor oder die Shaping-Rate ist so hoch gesetzt, dass der Router nicht der Engpass ist.

Best Practices: Shaping und Policing in einem sauberen QoS-Design kombinieren

In vielen produktiven Designs nutzen Sie nicht „entweder oder“, sondern eine Kombination:

• Shaping am WAN-Uplink: Damit der Router Congestion kontrolliert.
• Queueing/LLQ in der Child-Policy: Damit Voice/Video priorisiert wird.
• Policing für untrusted Traffic: Damit niemand die Priority-Klassen missbraucht.
• Remarking statt Drop: Wo möglich, Überschreitungen herabstufen, statt sie pauschal zu verwerfen.

Zusätzlich ist ein sauberer Marking-Plan (DSCP/CoS) und eine klare Trust Boundary entscheidend, damit die richtigen Pakete in den richtigen Klassen landen. Für konzeptionelle Grundlagen zu DiffServ und DSCP ist der Anchor-Text RFC 2474 hilfreich.

Praxis-Checkliste: Traffic Shaping vs. Policing richtig auswählen

• Wo ist der Engpass tatsächlich (WAN, Trunk, WLAN, Tunnel)?
• Soll der Traffic „geordnet“ werden (Shaping) oder soll eine harte Grenze gelten (Policing)?
• Gibt es Echtzeittraffic (VoIP/Video), der von Drops stark betroffen wäre?
• Ist Shaping am WAN so gesetzt, dass der Router der Engpass ist (knapp unter Provider-Rate)?
• Ist Policing nur dort aktiv, wo Drops akzeptabel sind oder Missbrauch verhindert werden soll?
• Wurde die Wirkung verifiziert (show policy-map interface, Drops, Counter, Queueing)?
• Sind Markierungen und Trust Boundaries konsistent, damit Klassen sauber matchen?

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.