Site icon bintorosoft.com

Traffic Shaping vs. Policing: Unterschiede & Cisco Konfiguration

Red Snapper

network of electronic devices concept. 3d illustration

Traffic Shaping und Policing sind zwei grundlegende QoS-Mechanismen, die oft verwechselt werden. Beide kontrollieren Bandbreite, aber mit unterschiedlichem Verhalten: Shaping verzögert Pakete und glättet Bursts, Policing verwirft oder markiert Pakete, die ein Limit überschreiten. Für Unternehmens-WAN und VoIP ist Shaping häufig die erste Wahl, weil es Verluste reduziert und Queueing im Router kontrollierbar macht. Policing ist dagegen sinnvoll, wenn du harte Grenzen erzwingen musst (z. B. Provider-Policies, Missbrauchsschutz) oder wenn du Traffic bewusst droppen/remarken willst.

Der Kernunterschied in einem Satz

Shaping puffert und sendet später, Policing zählt und bestraft sofort (drop/mark). Dieser Unterschied entscheidet darüber, ob du Latenz erhöhst (Shaping) oder Paketverlust erzeugst (Policing).

Merker

Shaping = Delay ,   Policing = Drop/Mark

Traffic Shaping: Was passiert technisch?

Beim Shaping wird Traffic in eine Queue gelegt und so getaktet, dass ein konfiguriertes Durchschnittslimit nicht überschritten wird. Bursts sind kurzfristig möglich, werden aber durch Pufferung „geglättet“. Das ist besonders sinnvoll am WAN-Uplink (Outbound), damit Congestion im Router statt im Provider entsteht.

Beispiel: Shaping auf 10 Mbit/s (MQC)

policy-map PM_SHAPER
 class class-default
  shape average 10000000

Traffic Policing: Was passiert technisch?

Policing misst Traffic gegen ein Token-Bucket-Limit. Wird die Rate überschritten, werden Pakete gedroppt oder auf eine niedrigere Priorität ummarkiert. Policing ist „hart“ und erzeugt bei TCP oft Retransmits, was die effektive Performance verschlechtern kann.

Beispiel: Policing mit Drop bei Überschuss

policy-map PM_POLICE
 class class-default
  police 10000000 conform-action transmit exceed-action drop

Wann nimmst du Shaping, wann Policing?

Die Entscheidung ist meist betrieblich: Willst du Verluste vermeiden und lieber etwas Latenz in Kauf nehmen (Shaping), oder musst du strikt begrenzen und akzeptierst Drops/Remarking (Policing)?

Use-Case 1: WAN-Upload kontrollieren (Best Practice: Shaping)

Wenn dein Provider 10 Mbit/s Upload liefert, willst du oft auf z. B. 9,5 Mbit/s shapen. Damit entstehen Queues im Router, in denen LLQ/CBWFQ priorisieren kann. Ohne Shaping kann Congestion beim Provider entstehen, wo dein Router keine Priorisierung mehr kontrolliert.

Parent Shaper + Child QoS (typisches Muster)

class-map match-any CM_VOICE
 match dscp ef

policy-map PM_CHILD_QOS

class CM_VOICE

priority 1000

class class-default

fair-queue


policy-map PM_PARENT_SHAPER

class class-default

shape average 9500000

service-policy PM_CHILD_QOS


interface gigabitEthernet0/1

service-policy output PM_PARENT_SHAPER

Use-Case 2: Ingress begrenzen oder Missbrauch reduzieren (Policing)

Ingress-Traffic kannst du nicht „shapen“, weil er bereits angekommen ist. Hier ist Policing üblich: du begrenzt und droppst/remarkst Überschuss. Das wird häufig genutzt, um Gastnetze oder nichtkritische Datenströme zu disziplinieren.

Ingress Policer (Beispiel)

policy-map PM_INGRESS_POLICE
 class class-default
  police 5000000 conform-action transmit exceed-action drop

interface gigabitEthernet0/0

service-policy input PM_INGRESS_POLICE

Marking statt Drop: Policing mit Remarking (sanfter)

Statt Überschuss zu droppen, kannst du ihn auf einen niedrigeren DSCP-Wert markieren. Downstream-Queues behandeln diesen Traffic dann schlechter, aber ohne sofortige Verluste am Policer.

Beispiel: Exceed → DSCP auf CS1 setzen

policy-map PM_POLICE_REMARK
 class class-default
  police 10000000 conform-action transmit exceed-action set-dscp-transmit cs1

Throughput und TCP: Warum Policing „langsamer“ wirken kann

TCP reagiert auf Paketverlust mit Congestion Control (Fenster kleiner, Retransmits). Deshalb kann hartes Policing die User-Experience verschlechtern, obwohl „10 Mbit/s“ konfiguriert sind. Shaping erzeugt eher Latenz, aber oft weniger Verlust – und ist daher für TCP-lastige Workloads häufig stabiler.

Verifikation: Wie prüfst du, ob Shaping/Policing greift?

Die wichtigste Kontrolle sind Policy-Counter: Matcht die Klasse? Gibt es Drops? Wird remarkt? Zusätzlich prüfst du Interface-Queues und Drops.

Policy-Counter prüfen

show policy-map interface gigabitEthernet0/1
show policy-map interface gigabitEthernet0/0

Interface-Drops prüfen

show interfaces gigabitEthernet0/1 | include drops|queue
show interfaces gigabitEthernet0/0 | include drops|queue

Typische Fehler und Denkfehler

Viele QoS-Konfigurationen scheitern nicht am Syntax, sondern am Ort: Shaping am falschen Interface, Policing outbound statt inbound, oder fehlende Parent/Child-Struktur am WAN.

Quick-Reference: Minimalbeispiele (Copy & Paste)

! Shaping outbound (10 Mbit/s)
policy-map PM_SHAPER
 class class-default
  shape average 10000000
interface g0/1
 service-policy output PM_SHAPER

! Policing inbound (5 Mbit/s)

policy-map PM_POLICE_IN

class class-default

police 5000000 conform-action transmit exceed-action drop

interface g0/0

service-policy input PM_POLICE_IN

Konfiguration speichern

Router# copy running-config startup-config

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

Sie erhalten

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.

Exit mobile version