Inhalt

Einleitung

Voraussetzungen

Anforderungen

Konventionen

Verwendete Komponenten

Hintergrundinformationen

Richtliniendurchsetzung und Shaping

Auswahlkriterien

Token-Aktualisierungsrate

Traffic Shaping

Datenverkehrs-Policing

Vergleich zwischen minimaler und maximaler Bandbreitensteuerung

Zugehörige Informationen

Einleitung

In diesem Dokument werden die Funktionsunterschiede zwischen Traffic Shaping und Traffic Policing beschrieben, die die Ausgaberate begrenzen.

Voraussetzungen

Anforderungen

Es gibt keine spezifischen Anforderungen für dieses Dokument.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).

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

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?

Richtliniendurchsetzung und 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 Mulden 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 zeigt 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 Richtlinienvergabe 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 niedrige Latenz Queuing (LLQ)

Auswahlkriterien

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

Formgebung

Richtlinien

Ziel

Puffert überschüssige Pakete über die zugesicherten Raten und stellt sie in die Warteschlange.

Überschüssige Pakete können über die festgelegten Raten verworfen (oder kommentiert) werden. Puffert nicht.*

Token-Aktualisierungsrate

Inkrementiert zu Beginn eines Zeitintervalls. (Die Mindestanzahl von Intervallen ist erforderlich.)

Kontinuierlich basierend auf Formel: 1 / Committed Information Rate

Tokenwerte

Konfiguriert in Bits pro Sekunde.

In Byte konfiguriert.

Konfigurationsoptionen

- shape-Befehl in der modularen QoS-Befehlszeilenschnittstelle (MQC) zur Implementierung von klassenbasiertem Shaping.

- Frame-Relay Traffic-Shape-Befehl zur Implementierung von Frame-Relay Traffic Shaping (FRTS).

- t raffic-shape-Befehl zum Implementieren von Generic Traffic Shaping (GTS).

- Richtlinienbefehl in der MQC, um die klassenbasierte Richtlinienvergabe zu implementieren.

- rate-limit-Befehl zur Implementierung der Committed Access Rate (CAR).

Bei eingehendem Datenverkehr anwendbar

Nein

Ja

Bei ausgehendem Datenverkehr anwendbar

Ja

Ja

Spitzen

Steuert Bursts und glättet die Ausgaberate über mindestens acht Zeitintervalle. Verwendet einen undichten Bucket, um den Datenverkehr zu verzögern, wodurch eine Glättung erreicht wird.

Verteilt Ausbrüche. Keine Glättung.

Vorteile

Geringere Wahrscheinlichkeit, dass überzählige Pakete verworfen werden, da überzählige Pakete gepuffert werden (Puffert Pakete bis zur Länge der Warteschlange. Bei hohen Übertragungsraten kann es zu Verlusten kommen.) In der Regel werden Neuübertragungen aufgrund verlorener Pakete vermieden.

Steuert die Ausgaberate bei Paketverlusten. Vermeidung von Verzögerungen aufgrund queuing.

Nachteile

Verzögerung aufgrund von queuing, insbesondere tiefe Warteschlangen.

Überschüssige Pakete werden bei entsprechender Konfiguration verworfen, TCP-Fenstergrößen werden gedrosselt, und die Gesamtausgabe der betroffenen Datenströ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 (mit älterer CAR-Funktion).

* Obwohl die Richtlinienvergabe keinen Puffer anwendet, queuing Dieser Mechanismus gilt für konforme Pakete, die in Warteschlangen gestellt werden müssen, während sie auf die Serialisierung an der physischen Schnittstelle warten.

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 Tokenbucket-Funktionalität:

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

- Jedes Token ist die Berechtigung für die Quelle, eine bestimmte Anzahl von Bits an 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 sind für zukünftige Pakete nicht verfügbar. 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 steht Bc für den Committed Burst und CIR für Committed Information Rate. (Weitere Informationen finden Sie unter Konfigurieren des Frame Relay-Traffic-Shaping.) Der Wert von Tc definiert das Zeitintervall, in dem die Bc-Bits gesendet werden, um die durchschnittliche CIR-Rate in Sekunden beizubehalten.

Der Bereich für Tc liegt zwischen 10 ms und 125 ms. Beim Distributed Traffic Shaping (DTS) der Cisco Serie 7500 beträgt die Mindestgeschwindigkeit 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 mit einem kleineren Intervall stabiler sein kann. Mit dem Befehl show traffic-shape (Verkehrsform anzeigen) können Sie bestimmen, ob Ihr Router einen internen Wert für Tc oder den Wert verwendet, den Sie in der Befehlszeile konfiguriert haben. Die nächste Beispielausgabe des Befehls show traffic-shape wird in show Commands for Frame Relay Traffic Shaping erläutert.

Verkehrsleistung anzeigen

Wenn der überschüssige 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 Durchsatzratenbasiertelimiting fügt ständig Token zum Bucket hinzu. Die Token-Ankunftsrate wird wie folgt berechnet:

(time between packets<which is equal to t-t1>* policer rate)/8 bits per byte

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. Beachten Sie, dass eine Datenverkehrsüberwachung Burst-Werte verwendet, die in Byte angegeben sind, und dass die vorherige Formel von Bits in Byte konvertiert.

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

Bei der Berechnung bleiben 700 Byte im Token-Bucket. Wenn das nächste Paket 800 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 Warteschlangen einteilt, 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 Klassenbasiertes Policing vergleichen und Zugesicherte Zugriffsrate 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 implementiert die Richtlinie eine konfigurierbare Aktion, 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

Sowohl der Befehl shape als auch der Befehl police beschränken die Ausgaberate auf einen maximalen Kbit/s-Wert. 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 wie Sub-Schnittstellen und Tunnelschnittstellen erfordern eine hierarchische Richtlinie mit den Datenverkehrs-limiting auf der übergeordneten Ebene und Warteschlangenzuweisung auf niedrigeren Ebenen. Der Datenverkehr-limiting reduziert die Ausgaberate und verursacht (vermutlich) eine Überlastung, wie queuing überzählige Pakete.

Die nächste Konfiguration ist nicht optimal und veranschaulicht den Unterschied zwischen der Polizei und dem Shape-Befehl, wenn limiting Aggregierter Datenverkehr, in diesem Fall Klassenstandard, bis zu einer maximalen Rate. 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 den Klassen Voice over IP (VoIP) und Internet Protocol (IP) zugewiesenen Tarife nicht garantiert werden können, da die Polizeifunktion die Garantien der Prioritätsfunktion überschreibt.

Wenn jedoch der Befehl shape verwendet wird, ergibt sich ein hierarchisches Warteschlangensystem, und alle Garantien werden 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 dem Befehl police und dem Befehl shape, wenn dadurch der Gesamtdatenverkehr 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

Anmerkung: Weitere Informationen zu übergeordneten und untergeordneten Richtlinien finden Sie unter QoS Child Service Policy for Priority Class .

Zugehörige Informationen

- Technologischer Support für Quality of Services (QoS)

- Technischer Support und Dokumentation für Cisco Systeme