Vergleich von Traffic-Policing und Traffic-Shaping zur Bandbreitenbegrenzung

Einleitung

In diesem Dokument werden die funktionalen Unterschiede zwischen Shaping und Policing des Datenverkehrs erläutert, die beide die Ausgaberate begrenzen.

Voraussetzungen

Anforderungen

Es gibt keine spezifischen Anforderungen für dieses Dokument.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Hintergrundinformationen

In diesem Dokument werden die funktionalen Unterschiede zwischen Traffic Shaping und Richtlinienzuweisung erläutert. Beide schränken die Datenverkehrsausgabe ein. Beide Mechanismen verwenden einen Token-Bucket als Datenverkehrsmesser, um die Paketrate zu messen. Weitere Informationen zu Tokenbuckets finden Sie unter Was ist ein Tokenbucket?

Die Konzepte in diesem Dokument bleiben für das Verständnis von Cisco QoS-Designs relevant. Traffic Shaping und Traffic Policing werden weiterhin eingesetzt, um maximale Datenverkehrsraten durchzusetzen und Überlastungen zu verwalten. Für neue Bereitstellungen empfiehlt Cisco die Verwendung von klassenbasiertem Modular QoS Command-Line (MQC)-Shaping und klassenbasiertem Policing, sofern diese von der Plattform unterstützt werden. Ältere Mechanismen wie Generic Traffic Shaping (GTS), Frame Relay Traffic Shaping (FRTS), Committed Access Rate (CAR) und der Befehl "rate limit" werden für historische Kontexte oder zur Unterstützung plattformspezifischer Diskussionen verwendet.

Richtliniendurchsetzung im Vergleich zu Shaping

Traffic Policing propagiert Bursts. Wenn die Datenverkehrsrate die konfigurierte maximale Rate erreicht, wird überschüssiger Datenverkehr verworfen (oder markiert). Das Ergebnis ist eine Produktionsrate, die wie ein Sägezahn mit Kämmen und Trögen erscheint. Im Gegensatz zum Policing behält Traffic Shaping überzählige Pakete in einer Warteschlange bei und plant die überzähligen Pakete dann für eine spätere Übertragung über einen bestimmten Zeitraum. Das Ergebnis des Traffic Shaping ist eine geglättete Paketausgangsrate.

Das nächste Diagramm veranschaulicht die wichtigsten Unterschiede zwischen den beiden Datenverkehrsoptionen.

Richtlinien VS-Shaping

Shaping impliziert das Vorhandensein einer Warteschlange und eines ausreichenden Arbeitsspeichers, um verzögerte Pakete zu puffern, während das Policing dies nicht tut. Warteschlangen sind ein ausgehendes Konzept. Pakete, die eine Schnittstelle verlassen, werden in die Warteschlange gestellt und können geformt werden. Auf eingehenden Datenverkehr über eine Schnittstelle kann nur die Richtlinienzuweisung angewendet werden. Stellen Sie sicher, dass Sie beim Aktivieren des Shaping über ausreichend Speicher verfügen. Darüber hinaus erfordert das Shaping eine Funktion, die die spätere Übertragung von verzögerten Paketen plant. Mit dieser Zeitplanfunktion können Sie die Shaping-Warteschlange in verschiedene Warteschlangen organisieren. Beispiele für diese Funktion sind Class Based Weighted Fair Queuing (CBWFQ) und Low Latency Queuing (LLQ).

Auswahlkriterien

In der nächsten Tabelle werden die Unterschiede zwischen Shaping und Richtlinienzuweisung aufgelistet, um Ihnen bei der Auswahl der richtigen Datenverkehrslösung zu helfen.

	Traffic Shaping	Datenverkehrs-Policing
Primärverhalten	Puffert überschüssige Pakete über die zugesicherten Raten und stellt sie in die Warteschlange.	Löscht (oder merkt) überzählige Pakete über die vereinbarten Raten. Puffert nicht.*
Token-Aktualisierungsrate	Token werden in jedem Tc-Intervall periodisch aufgefüllt. Zu Beginn jedes Intervalls fügt der Shaper Bc-Token bis zur konfigurierten Eimergrenze hinzu. Tc unterliegt plattformspezifischen Beschränkungen.	Token werden basierend auf der zwischen den Paketeingängen verstrichenen Zeit aufgefüllt. Der Policer berechnet die Anzahl der Token, die hinzugefügt werden sollen mit: ((t - t1) * policer_rate_bps) / 8, wobei t - t1 die Zeit seit dem vorherigen Paket ist.
Tokenwerte	Konfiguriert in Bit pro Sekunde (Bit/s).	Konfiguriert in Byte.
Konfigurationsoptionen	Shape-Befehl in MQC zum Implementieren von klassenbasiertem Shaping. Frame-Relay-Verkehrsform-Befehl zur Implementierung von FRTS. Verkehrsform-Befehl zur Implementierung von GTS	Richtlinienbefehl im MQC zum Implementieren der klassenbasierten Richtlinienzuweisung. Rate-limit-Befehl zur Implementierung der CAR
Typische Richtung	Ausgehend	Eingehend oder ausgehend, plattformabhängig
Spitzen	Steuert Bursts und glättet die Ausgaberate über mindestens acht Zeitintervalle. Dabei werden Token Bucket Metering und überschüssige Pakete in die Warteschlange gestellt. Die Pakete in der Warteschlange werden im Laufe der Zeit freigegeben, was einen Glättungseffekt ähnlich einem undichten Bucket erzeugt.	Ermöglicht Bursts innerhalb der konfigurierten Burst-Grenzwerte. Es puffert keine Pakete, um die Übertragungsrate zu glätten.
Vorteile	Geringere Wahrscheinlichkeit, dass überzählige Pakete verworfen werden, da überzählige Pakete gepuffert werden (Puffert Pakete bis zur Länge der Warteschlange. Wenn der überschüssige Datenverkehr mit hohen Übertragungsraten anhält, kann es zu Verlusten kommen.) In der Regel werden Neuübertragungen aufgrund verlorener Pakete vermieden.	Steuert die Ausgaberate bei Paketverlusten. Vermeidet Verzögerungen aufgrund von queuing.
Nachteile	Mögliche Verzögerung aufgrund von queuing, insbesondere langen Warteschlangen.	Überschüssige Pakete werden bei entsprechender Konfiguration verworfen, TCP-Fenstergrößen werden gedrosselt, und die Gesamtausgabe der betroffenen Datenverkehrsströme wird reduziert. Übermäßig aggressive Burst-Größen können zu übermäßigen Paketverlusten führen und die Gesamtausgabe drosseln, besonders bei TCP-basierten Datenflüssen.
Optionale Paketkennzeichnung	Nein	Ja, abhängig von den konfigurierten MQC-Richtlinienaktionen und der Plattformunterstützung kann es optional Pakete senden, verwerfen oder markieren, einschließlich IP-Rangfolge oder DSCP-Aktionen.

Token-Aktualisierungsrate

Ein wesentlicher Unterschied zwischen Shaping und Policing ist die Rate, mit der Token aufgefüllt werden. Sowohl Shaping als auch Policing verwenden die Metapher des Token-Buckets. Ein Token-Bucket selbst hat keine Verwerfungs- oder Prioritätsrichtlinie.

Mit Token-Bucket-Funktionalität: 

• Token werden mit einer bestimmten Geschwindigkeit in den Eimer gelegt.

• Jedes Token gibt der Quelle die Berechtigung, eine bestimmte Anzahl von Bits in das Netzwerk zu senden.

• Um ein Paket zu senden, muss der Verkehrsregler in der Lage sein, eine Anzahl von Token, die der Paketgröße entspricht, aus dem Bucket zu entfernen.

• Wenn sich nicht genügend Token im Bucket befinden, um ein Paket zu senden, wartet das Paket entweder, bis der Bucket genügend Token hat (im Fall eines Shapers), oder das Paket wird verworfen oder markiert (im Fall eines Policers).

• Der Eimer selbst hat eine bestimmte Kapazität. Wenn der Puffer voll ist, werden neue Token, die eintreffen, verworfen und stehen zukünftigen Paketen nicht zur Verfügung. Somit ist der größte Burst, den eine Quelle in das Netzwerk senden kann, zu jeder Zeit in etwa proportional zur Größe des Buckets. Ein Token-Eimer erlaubt Geschmeidigkeit, begrenzt sie aber.

Beim Shaping wird der Token-Bucket in zeitlichen Intervallen inkrementiert, die einen Bit-pro-Sekunde (Bit/s)-Wert verwenden. Ein Shaper verwendet die folgende Formel:

Tc = Bc/CIR (in seconds)

In dieser Gleichung:

• BC: Committed Burst. Die Menge an Datenverkehr, die während eines Zeitintervalls gesendet werden darf.

• CIR: Committed Information Rate Die durchschnittliche Datenverkehrsrate, die vom Shaper oder Policer durchgesetzt wird.

• Tc: Committed Time Intervall. Das Zeitintervall, das ein Shaper zum Senden des bestätigten Bursts verwendet, während die konfigurierte CIR in Sekunden beibehalten wird.

Der Bereich für Tc liegt zwischen 10 ms und 125 ms. Bei einigen älteren Plattformen mit Distributed Traffic Shaping (DTS) beträgt der Mindestwert für Tc 4 ms. Der Router berechnet diesen Wert intern auf Basis der CIR- und BC-Werte. Wenn Bc/CIR kleiner als 125 ms ist, wird die aus dieser Gleichung berechnete Tc verwendet. Wenn Bc/CIR größer als oder gleich 125 ms ist, wird ein interner Tc-Wert verwendet, wenn Cisco IOS feststellt, dass der Datenverkehrsfluss in einem kleineren Intervall stabiler sein kann. Verwenden Sie den Befehl show traffic-shape (Verkehrsform anzeigen), um zu bestimmen, ob Ihr Router einen internen Wert für Tc oder den Wert verwendet, den Sie in der Befehlszeile konfiguriert haben.

Ausgabe von Datenverkehr anzeigen

Wenn der Excess Burst (Be) auf einen Wert ungleich 0 eingestellt ist, erlaubt der Shaper die Speicherung von Token im Eimer bis Bc + Be. Der größte Wert, den der Token-Bucket jemals erreichen kann, ist Bc + Be, und Überlauftokens werden verworfen. Die einzige Möglichkeit, mehr als Bc-Token im Bucket zu haben, besteht darin, nicht alle Bc-Token während eines oder mehrerer Tc zu verwenden. Da der Token-Eimer jedes Tc mit Bc-Token aufgefüllt wird, können Sie ungenutzte Token für die spätere Verwendung bis Bc + Be ansammeln.

Klassenbasiertes Policing und Ratenbegrenzung hingegen füllen Token basierend auf der zwischen den Paketankünften verstrichenen Zeit auf. Wenn ein Paket ankommt, berechnet die Richtlinie die Anzahl der Token, die seit dem letzten Paket hinzugefügt werden müssen, sowie die konfigurierte Regelungsrate. Im Einzelnen wird die Token-Ankunftsrate wie folgt berechnet:

Tokens added = ((t - t1) * policer_rate_bps) / 8 bytes

Mit anderen Worten, wenn die vorherige Ankunft des Pakets bei t1 war und die aktuelle Zeit t ist, wird der Bucket mit t-t1 Byte auf der Basis der Token-Ankunftsrate aktualisiert. 

Dieses Beispiel verwendet eine CIR (oder Policer-Rate) von 8.000 bps und einen normalen Burst von 1.000 Byte:

Router(config)#policy-map police-setting 
Router(config-pmap)#class access-match 
Router(config-pmap-c)#police 8000 1000 conform-action transmit exceed-action drop 

Die Token-Buckets beginnen bei 1000 Bytes voll. Wenn ein 450-Byte-Paket eingeht, entspricht das Paket den Vorgaben, da genügend Bytes im Token-Bucket verfügbar sind. Die konforme Aktion (Senden) wird vom Paket ausgeführt, und 450 Byte werden aus dem Token-Bucket entfernt (und belassen Sie 550 Byte). Wenn das nächste Paket 0,25 Sekunden später eingeht, werden dem Token-Bucket 250 Byte gemäß der folgenden Formel hinzugefügt:

(0.25 * 8000)/8

1. Bucket beginnt voll:

   • Normal Burst = 1000 Bytes
   • Erste Token = 1000 Bytes

2. Erstes ankommendes Paket:

   • Paketgröße = 450 Byte
   • Das Paket ist konform, da der Bucket genügend Token enthält.
   • Der Policer entfernt Token im Wert von 450 Byte aus dem Bucket.

   Berechnung: 1000 - 450 = 550 Byte übrig

3. Das nächste Paket kommt 0,25 Sekunden später an:

   • Policer-Rate = 8000 bit/s
   • Token, die in 0,25 Sekunden hinzugefügt wurden:

   (0,25 × 8000) / 8 = 250 Bytes

4. Bucket nach Aktualisierung:

   • Verbleibende vorhandene Token = 550 Bytes
   • Neue Token hinzugefügt = 250 Bytes

   Berechnung: 550 + 250 = 800 Bytes

Bei der Berechnung bleiben 800 Byte im Token-Bucket (Token verbleiben im Policer-Bucket). Wenn das nächste Paket 900 Byte umfasst, überschreitet das Paket und die Aktion zum Überschreiten (Verwerfen) wird ausgeführt. Aus dem Token-Bucket werden keine Bytes entnommen.

Traffic Shaping

Cisco IOS® unterstützt die folgenden Traffic Shaping-Methoden:

• Generisches Traffic Shaping

• Frame-Relay-Traffic-Shaping

• Klassenbasiertes Shaping und verteiltes klassenbasiertes Shaping

Alle Traffic Shaping-Methoden sind in der Implementierung ähnlich, auch wenn sich ihre Befehlszeilenschnittstellen (CLIs) in gewissem Maße unterscheiden, und sie verwenden verschiedene Arten von Warteschlangen, um zurückgestellten Datenverkehr einzudämmen und zu steuern. Cisco empfiehlt ein klassenbasiertes Shaping und verteiltes Shaping, die mit der modularen QoS-CLI konfiguriert werden.

Das nächste Diagramm zeigt, wie eine QoS-Richtlinie Datenverkehr in Klassen einteilt und Pakete in die Warteschlange einordnet, die die konfigurierten Shaping-Raten überschreiten.

Datenverkehrs-Policing

Cisco IOS unterstützt die folgenden Methoden der Datenverkehrsüberwachung:

• Committed Access Rate

• Klassenbasiertes Policing

Die beiden Mechanismen weisen wichtige funktionale Unterschiede auf, wie unter How to Configure Class-Based Policing erläutert. Cisco empfiehlt eine klassenbasierte Richtlinienvergabe sowie andere Funktionen der modularen QoS-CLI, wenn QoS-Richtlinien angewendet werden.

Verwenden Sie den Befehl police, um anzugeben, dass für eine Datenverkehrsklasse eine Höchstgeschwindigkeit festgelegt werden muss. Wenn diese Geschwindigkeit überschritten wird, müssen sofort Maßnahmen ergriffen werden. Mit anderen Worten, mit dem Befehl "police" ist es keine Option, das Paket zu puffern und später zu senden, wie es beim Befehl "shape" der Fall ist.

Darüber hinaus bestimmt der Token-Bucket bei der Richtlinienvergabe, ob ein Paket die angewendete Rate überschreitet oder mit ihr übereinstimmt. In beiden Fällen wird durch die Richtlinienvergabe eine konfigurierbare Aktion implementiert, die die IP-Rangfolge oder den Differentiated Services Code Point (DSCP) umfasst.

Das nächste Diagramm zeigt eine häufige Anwendung der Datenverkehrssteuerung an einem Überlastungspunkt, an dem QoS-Funktionen im Allgemeinen angewendet werden.

Vergleich zwischen minimaler und maximaler Bandbreitensteuerung

Die Form- und Richtlinienbefehle beschränken den Datenverkehr auf eine konfigurierte maximale Rate. In MQC wird die konfigurierte Rate für Shape-Durchschnitt und Richtlinien in Bit/s angegeben, es sei denn, die plattformspezifische Syntax gibt etwas Anderes vor. Wichtig ist, dass keiner der beiden Mechanismen eine garantierte Mindestbandbreite in Zeiten von Engpässen bietet. Verwenden Sie den Befehl bandwidth oder priority (Bandbreite oder Priorität), um solche Garantien bereitzustellen.

Eine hierarchische Richtlinie verwendet zwei Dienstrichtlinien: eine übergeordnete Richtlinie, um einen QoS-Mechanismus auf ein Datenverkehrsaggregat anzuwenden, und eine untergeordnete Richtlinie, um einen QoS-Mechanismus auf einen Fluss oder eine Teilmenge des Aggregats anzuwenden. Logische Schnittstellen, z. B. Subschnittstellen und Tunnelschnittstellen, erfordern eine hierarchische Richtlinie mit der Datenverkehrsfunktionlimiting auf der übergeordneten Ebene und der Warteschlangenverwaltung auf niedrigeren Ebenen. Die Datenverkehrsfunktionlimiting reduziert die Ausgaberate und führt (vermutlich) zu einer Überlastung, wie bei queuing überzähligen Paketen zu beobachten ist.

Die nächste Konfiguration ist nicht optimal und veranschaulicht den Unterschied zwischen dem Befehl "Police" und dem Befehl "shape", wenn limiting ein Datenverkehr auf eine maximale Rate aggregiert wird (in diesem Fall eine Standardklasse). In dieser Konfiguration sendet der Befehl "policy" Pakete aus den untergeordneten Klassen, basierend auf der Größe des Pakets und der Anzahl der Bytes, die in der Übereinstimmungsklasse verbleiben und Token-Buckets überschreiten. (Siehe Traffic Policing.) Dies führt dazu, dass die für die VoIP- (Voice over IP) und IP-Klassen (Internet Protocol) festgelegten Tarife nicht garantiert werden können, da die Polizeifunktion die Garantien der Prioritätsfunktion außer Kraft setzt.

Wird jedoch der Befehl shape verwendet, ergibt sich ein hierarchisches Warteschlangensystem, und es werden alle Garantien gegeben. Mit anderen Worten, wenn die angebotene Last die Formrate überschreitet, wird die Geschwindigkeit der VoIP- und IP-Klassen garantiert, und der Standardklassenverkehr (auf untergeordneter Ebene) geht verloren.

Vorsicht: Diese Konfiguration wird nicht empfohlen und veranschaulicht den Unterschied zwischen Richtlinienbefehl und Shape-Befehl, wenn dadurch die Datenverkehrsmenge begrenzt wird.

class-map match-all IP 
   match ip precedence 3 
class-map match-all VoIP 
   match ip precedence 5 
!  
policy-map child 
  class VoIP 
     priority 128 
   class IP 
     priority 1000 
! 
 policy-map parent 
   class class-default 
     police 3300000 103000 103000 conform-action transmit exceed-action drop 
     service-policy child

Damit die vorherige Konfiguration sinnvoll ist, muss die Richtlinienzuweisung durch Shaping ersetzt werden. Beispiele:

policy-map parent
    class class-default
     shape average 3300000 103000 0
     service-policy child

Verwenden Sie die Schnittstelle show policy-map <Schnittstelle>, um konfigurierte Richtlinien, Klassenzähler, angebotene Rate, Zähler für Verwerfen, Shaping-Rate, Warteschlangentiefe und Zähler für konforme/überschrittene/nicht konforme Richtlinien zu überprüfen.

Router#show policy-map interface gigabitEthernet 0/0/2
 GigabitEthernet0/0/2 

 Service-policy output: parent 
    Class-map: class-default (match-any)  
      0 packets, 0 bytes
      5 minute offered rate 0000 bps, drop rate 0000 bps
      Match: any 
      Queueing
      queue limit 64 packets
      (queue depth/total drops/no-buffer drops) 0/0/0
      (pkts output/bytes output) 0/0
 shape (average) cir 3300000, bc 103000, be 0 target shape rate 3300000 
 Service-policy : child 
        queue stats for all priority classes:
          Queueing
          queue limit 512 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 0/0

        Class-map: VoIP (match-all)  
          0 packets, 0 bytes
          5 minute offered rate 0000 bps, drop rate 0000 bps
          Match: ip precedence 5 
 Priority: 128 kbps, burst bytes 3200, b/w exceed drops: 0           

        Class-map: IP (match-all)  
          0 packets, 0 bytes
          5 minute offered rate 0000 bps, drop rate 0000 bps
          Match: ip precedence 3 
 Priority: 1000 kbps, burst bytes 25000, b/w exceed drops: 0           

        Class-map: class-default (match-any)  
          0 packets, 0 bytes
          5 minute offered rate 0000 bps, drop rate 0000 bps
          Match: any 
          
          queue limit 64 packets
          (queue depth/total drops/no-buffer drops) 0/0/0
          (pkts output/bytes output) 0/0

Anmerkung: Weitere Informationen zu übergeordneten und untergeordneten Richtlinien finden Sie unter QoS: Untergeordnete Dienstrichtlinie für Prioritätsklasse.

Das vorherige Beispiel ist absichtlich suboptimal und dient nur dazu, den Unterschied zwischen Richtlinienvergabe und Shaping in einer hierarchischen QoS-Richtlinie zu veranschaulichen. Bei einem empfohlenen QoS-Design ist der Prioritätsbefehl in der Regel für latenzempfindlichen Echtzeitdatenverkehr wie Sprache reserviert. Für Nicht-Echtzeit-Klassen, die eine garantierte Mindestbandbreite benötigen, wird in der Regel der Befehl bandwidth mit CBWFQ verwendet.

Dieser Ansatz entspricht den Cisco QoS-Designrichtlinien für LLQ und CBWFQ. LLQ ermöglicht eine strenge Prioritätsbehandlung für verzögerungsempfindlichen Datenverkehr, während CBWFQ Bandbreitengarantien für andere Datenverkehrsklassen während Engpässen bereitstellt. Aus diesem Grund ist die IP-Klasse in diesem Beispiel besser mit Bandbreite als mit Priorität dargestellt, es sei denn, diese Klasse überträgt Datenverkehr, für den explizit eine strenge Prioritätsbehandlung erforderlich ist.

policy-map child
 class VoIP
  priority 128
 class IP
  bandwidth 1000

Zugehörige Informationen

• Technologischer Support für Quality of Services (QoS)
• Technischer Support und Dokumentation für Cisco Systeme

Revisionsverlauf

Überarbeitung	Veröffentlichungsdatum	Kommentare
6.0	21-Jul-2026	Rezertifizierung.
4.0	07-Sep-2023	Aktualisierte Branding-Anforderungen, SEO, Grammatik und Formatierung.
3.0	26-Sep-2022	Rezertifizierung
1.0	15-Feb-2002	Erstveröffentlichung