Grundlegendes zu QoS-Richtlinien und Marking für Catalyst 3550

Einleitung

Die Regelungsfunktion bestimmt, ob der Datenverkehrslevel innerhalb des angegebenen Profils oder Vertrags liegt, und ermöglicht Ihnen, Out-of-Profile-Datenverkehr entweder zu verwerfen oder auf einen anderen Differenzial Services Code Point (DSCP)-Wert herabzustufen. Dadurch wird ein vertraglich vereinbarter Service-Level erzwungen.

DSCP ist ein Maß für den Quality of Service (QoS)-Grad des Pakets. Neben DSCP werden auch IP-Rangfolge und Class of Service (CoS) verwendet, um die QoS-Ebene des Pakets zu übermitteln.

Richtlinien sind nicht mit Traffic-Shaping zu verwechseln, obwohl beide gewährleisten, dass der Datenverkehr innerhalb des Profils oder Vertrags bleibt.

Die Richtlinie puffert den Datenverkehr nicht, sodass die Richtlinie die Übertragungsverzögerung nicht beeinflusst. Statt Out-of-Profile-Pakete zu puffern, werden sie von der Richtlinie entweder verworfen oder mit verschiedenen QoS-Stufen gekennzeichnet (DSCP-Markdown).

Traffic Shaping puffert Out-of-Profile-Datenverkehr und gleicht Datenverkehrsspitzen aus, wirkt sich jedoch auf die Verzögerung und die Verzögerungsvariation aus. Shaping kann nur auf die ausgehende Schnittstelle angewendet werden, während Policing sowohl auf die eingehende als auch auf die ausgehende Schnittstelle angewendet werden kann.

Der Catalyst 3550 unterstützt die Richtlinienvergabe für eingehende und ausgehende Anrufe. Traffic Shaping wird nicht unterstützt.

Durch die Markierung wird die QoS-Ebene des Pakets gemäß einer Richtlinie geändert.

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 Netz Live ist, überprüfen Sie, ob Sie die mögliche Auswirkung jedes möglichen Befehls verstehen.

Konventionen

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

Hardware- und Softwareversionen

Richtlinien und Marking für den Catalyst 3550 werden von allen Softwareversionen unterstützt. Hier finden Sie den aktuellen Konfigurationsleitfaden. Informationen zu allen unterstützten Funktionen finden Sie in dieser Dokumentation.

• Konfigurieren von QoS

QoS-Überwachungs- und Markierungsparameter

Um die Richtlinienvergabe einzurichten, müssen Sie die QoS-Richtlinienzuordnungen definieren und auf die Ports anwenden. Dies wird auch als portbasierte QoS bezeichnet.

Anmerkung:  VLAN-basierte QoS wird derzeit von Catalyst 3550 nicht unterstützt.

Die Richtlinienvergabe wird anhand von Rate- und Burst-Parametern sowie der Aktion für Out-of-Profile-Datenverkehr definiert.

Diese beiden Arten der Überwachung werden unterstützt:

• Aggregieren

• Individuell

Die Aggregation Policer wirkt auf den Datenverkehr in allen Instanzen ein, in denen sie angewendet wird. Die individuelle Richtlinienvergabe agiert separat auf den Datenverkehr in jeder Instanz, in der sie angewendet wird.

Hinweis: Auf dem Catalyst 3550 kann die Aggregation Policer-Methode nur auf verschiedene Klassen derselben Richtlinie angewendet werden. Aggregiertes Policing über mehrere Schnittstellen oder Richtlinien wird nicht unterstützt.

Wenden Sie beispielsweise die Aggregation Policer an, um den Datenverkehr der Klassen customer1 und customer2 in derselben Richtlinienzuordnung auf 1 Mbit/s zu begrenzen. Eine solche Überwachung ermöglicht zusammen 1 Mbit/s Datenverkehr in Klasse customer1 und customer2. Wenn Sie die individuelle Richtlinienvergabe anwenden, begrenzt die Richtlinienvergabe den Datenverkehr für Klasse customer1 auf 1 Mbit/s und für Klasse customer2 auf 1 Mbit/s. Daher ist jede Instanz des Policers separat.

Diese Tabelle fasst die QoS-Aktion für das Paket zusammen, wenn es sowohl von Eingangs- als auch von Ausgangsrichtlinien behandelt wird:

Hinweis: Es ist möglich, Markierungen und Markierungen innerhalb derselben Datenverkehrsklasse derselben Richtlinie vorzunehmen. In diesem Fall wird der gesamte Datenverkehr für die jeweilige Klasse zuerst markiert. Richtlinien und Markdown werden für bereits markierten Datenverkehr durchgeführt.

Die QoS-Richtlinien auf dem Catalyst 3550 entsprechen diesem Konzept der undichten Stellen:

Die Anzahl der Token, die proportional zu den Paketgrößen des eingehenden Datenverkehrs sind, wird in einen Token-Bucket eingefügt. Die Anzahl der Token entspricht der Größe des Pakets. In einem regelmäßigen Intervall wird eine definierte Anzahl von Token, die aus der konfigurierten Rate abgeleitet werden, aus dem Bucket entfernt. Wenn der Bucket keinen Platz für ein eingehendes Paket bietet, gilt das Paket als Out-of-Profile und wird entsprechend der konfigurierten Regelungsaktion verworfen oder nach unten markiert.

Dieses Konzept wird in diesem Beispiel veranschaulicht:

Hinweis: Der Datenverkehr wird nicht im Bucket gepuffert, wie in diesem Beispiel gezeigt. Der tatsächliche Verkehr fließt überhaupt nicht durch den Eimer; Der Bucket wird nur verwendet, um zu entscheiden, ob sich das Paket im Profil oder außerhalb des Profils befindet.

Hinweis: Die Implementierung der Richtlinienzuweisung auf Hardwarebasis kann variieren, entspricht aber funktional weiterhin diesem Modell.

Diese Parameter steuern den Vorgang der Richtlinienzuweisung:

• Rate: Legt fest, wie viele Token in jedem Intervall entfernt werden. Dadurch wird die Regelungsrate effektiv festgelegt. Der gesamte Datenverkehr, der unter der Übertragungsrate liegt, wird im Profil berücksichtigt. Die unterstützten Übertragungsraten liegen zwischen 8 Kbit/s und 2 Gbit/s und steigen um 8 Kbit/s.

• Intervall: Legt fest, wie oft Token aus dem Bucket entfernt werden. Das Intervall ist auf 0,125 Millisekunden (oder 8000 Mal pro Sekunde) festgelegt. Dieses Intervall kann nicht geändert werden.

• Burst (Burst): Definiert die maximale Anzahl an Token, die der Bucket jederzeit enthalten kann. Unterstützte Bursts reichen von 8000 Byte bis 2000000 Byte und werden um 64 Byte erhöht.

Hinweis: Obwohl die Befehlszeilenhilfezeichenfolgen einen großen Wertebereich aufweisen, darf die Option rate-bps die konfigurierte Portgeschwindigkeit nicht überschreiten, und die Burst-Byte-Option darf 2000000 Byte nicht überschreiten. Wenn Sie einen größeren Wert eingeben, lehnt der Switch die Richtlinienzuordnung ab, wenn Sie sie an eine Schnittstelle anhängen.

Um die angegebene Datenverkehrsrate aufrechtzuerhalten, darf der Burst nicht kleiner als die Summe dieser Gleichung sein:

Burstmin (bits) = Rate (bps) / 8000 (1/sec) 

Berechnen Sie beispielsweise den minimalen Burst-Wert, um eine Rate von 1 Mbit/s aufrechtzuerhalten. Die Rate wird als 1.000 Kbit/s definiert, daher ist der erforderliche minimale Burst die Summe dieser Gleichung:

1000 (Kbps) / 8000 (1/sec) =125 (bits) 

Die mindestens unterstützte Burst-Größe beträgt 8.000 Byte, d. h. mehr als der berechnete minimale Burst.

Hinweis: Aufgrund der Präzision der Hardware-Überwachung werden die genaue Rate und der Burst-Wert auf den nächstgelegenen unterstützten Wert gerundet.

Bei der Konfiguration der Burst-Rate müssen Sie berücksichtigen, dass einige Protokolle Mechanismen implementieren, die auf den Paketverlust reagieren. Beispielsweise wird durch das Transmission Control Protocol (TCP) das Zeitfenster für jedes verlorene Paket um die Hälfte verringert. Dies verursacht einen "Sägezahn"-Effekt im TCP-Datenverkehr, wenn TCP versucht, auf die Leitungsrate zu beschleunigen, und wird durch die Überwachung gedrosselt. Wird die durchschnittliche Rate des Sägezahnverkehrs berechnet, ist diese Rate viel niedriger als die kontrollierte Rate. Sie können den Burst jedoch erhöhen, um eine bessere Auslastung zu erzielen. Ein guter Anfang ist, den Burst auf das Doppelte des Datenverkehrs einzustellen, der mit der gewünschten Rate während der Round-Trip Time (TCP RTT) gesendet wird. Wenn RTT nicht bekannt ist, können Sie den Wert des Burst-Parameters verdoppeln.

Aus dem gleichen Grund wird nicht empfohlen, den Policer-Betrieb anhand des verbindungsorientierten Datenverkehrs zu vergleichen. Dieses Szenario zeigt im Allgemeinen eine geringere Leistung an, als von der Richtlinienvergabe zugelassen wurde.

Der verbindungslose Datenverkehr kann auch anders auf die Richtlinienvergabe reagieren. Network File System (NFS) verwendet beispielsweise Blöcke, die aus mehr als einem User Datagram Protocol (UDP)-Paket bestehen können. Ein verworfenes Paket kann dazu führen, dass viele Pakete, sogar die gesamte Sperre, erneut übertragen werden.

In diesem Beispiel wird der Burst für eine TCP-Sitzung mit einer Regelungsrate von 64 Kbit/s und 0,05 Sekunden bei TCP RTT berechnet:

<burst> = 2*  *  = 2 * 0.05 [sec] * 64000/8 [bytes/sec] = 800    [bytes] 

In diesem Beispiel ist <burst> für eine TCP-Sitzung vorgesehen. Skalieren Sie diese Zahl, um den Durchschnitt der erwarteten Anzahl von Sitzungen zu erhalten, die durch den Policer geleitet werden.

Hinweis: Dies ist nur ein Beispiel. In jedem Fall müssen Sie die Anforderungen und das Verhalten von Datenverkehr und Anwendungen im Vergleich zu den verfügbaren Ressourcen bewerten, um Richtlinienparameter auszuwählen.

Die Regelungsaktion kann darin bestehen, das Paket zu verwerfen oder den DSCP des Pakets zu ändern (Markdown). Um das Paket zu markdown, muss eine per Richtlinie gesteuerte DSCP-Zuordnung geändert werden. Eine standardmäßig geregelte DSCP-Zuordnung merkt das Paket zu demselben DSCP an. Daher tritt kein Markdown auf.

Pakete können in der falschen Reihenfolge gesendet werden, wenn ein außerhalb des Profils liegendes Paket als DSCP gekennzeichnet wird, der einer anderen Ausgabewarteschlange als der ursprüngliche DSCP zugeordnet ist. Wenn die Reihenfolge der Pakete wichtig ist, werden Out-of-Profile-Pakete mit Markdown an den DSCP derselben Ausgabewarteschlange zugeordnet wie In-Profile-Pakete.

Vom Catalyst 3550 unterstützte Richtlinien- und Markierungsfunktionen

Diese Tabelle bietet eine Übersicht über die vom Catalyst 3550 unterstützten Funktionen für Richtlinien und Marking, aufgeschlüsselt nach Richtung:

Pro Klassenzuordnung wird eine Match-Anweisung unterstützt. Dies sind gültige Übereinstimmungsanweisungen für die Eingangsrichtlinie:

• Zugriffsgruppe abgleichen

• Match-IP-DSCP

• Match-IP-Rangfolge

Hinweis: Auf Catalyst 3550 wird der Befehl match interface nicht unterstützt, und nur ein match-Befehl ist in einer Klassenzuordnung zulässig. Daher ist es schwierig, den gesamten Datenverkehr, der über eine Schnittstelle eingeht, zu klassifizieren und den gesamten Datenverkehr mit einer einzigen Überwachung zu steuern. Weitere Informationen finden Sie im Abschnitt How to Classify All Interface Traffic with a Single Policer.

Dies ist die gültige Abgleichanweisung für die Ausgangs-Policy:

• Match-IP-DSCP

Dies sind gültige Richtlinienaktionen für die Eingangsrichtlinie:

• Polizei

• set ip dscp (Markierung)

• set ip priority (marking)

• Trust-DSCP

• Trust-IP-Rangfolge

• Treuhandkosten

Diese Tabelle zeigt die unterstützte Matrix der Eingangs-QoS-Richtlinien:

1. Diese Option deckt auch die Übereinstimmung mit der IP-Rangfolge ab.

2. Diese Option deckt CoS, IP-Rangfolge und DSCP als vertrauenswürdig ab.

3. Diese Option umfasst auch das Festlegen der IP-Rangfolge.

Dies ist die gültige Richtlinienaktion für die Ausgangs-Policy:

• Polizei

Diese Tabelle zeigt die unterstützte Matrix der Egress-QoS-Richtlinien:

Durch die Markierung kann die QoS-Ebene des Pakets auf Basis der Klassifizierung oder der Richtlinie geändert werden. Bei der Klassifizierung wird der Datenverkehr für die QoS-Verarbeitung auf Grundlage der definierten Kriterien in verschiedene Klassen aufgeteilt.

Die QoS-Verarbeitung basiert auf dem internen DSCP. Die Maßeinheit für den QoS-Pegel des Pakets. Der interne DSCP wird entsprechend der Vertrauenskonfiguration abgeleitet. Das System unterstützt CoS, DSCP, IP-Rangfolge und nicht vertrauenswürdige Schnittstellen. Trust gibt das Feld an, von dem der interne DSCP für jedes Paket abgeleitet wird:

• Wenn CoS als vertrauenswürdig eingestuft wird, wird die QoS-Ebene vom Layer-2-Header (L2) des Inter-Switch Link Protocol (ISL) oder vom 802.1Q-gekapselten Paket abgeleitet.

• Wenn der DSCP oder der IP-Rangfolge vertraut wird, leitet das System die QoS-Ebene entsprechend vom DSCP- oder IP-Rangfolgefeld des Pakets ab.

Das Vertrauen auf CoS ist nur bei Trunking-Schnittstellen sinnvoll, und das Vertrauen auf DSCP (oder IP-Rangfolge) ist nur für IP-Pakete sinnvoll.

Wenn eine Schnittstelle nicht vertrauenswürdig ist, wird der interne DSCP von der konfigurierbaren Standard-CoS für die entsprechende Schnittstelle abgeleitet. Dies ist der Standardstatus, wenn QoS aktiviert ist. Wenn keine Standard-CoS konfiguriert ist, lautet der Standardwert 0 (null).

Sobald der interne DSCP bestimmt wurde, kann er durch Marking und Richtlinien geändert oder beibehalten werden.

Nachdem das Paket der QoS-Verarbeitung unterzogen wurde, werden seine Felder auf QoS-Ebene (innerhalb des IP/DSCP-Felds für IP und ggf. innerhalb des ISL/802.1Q-Headers) vom internen DSCP aktualisiert. Für die Richtlinienvergabe gibt es folgende spezielle QoS-Zuordnungen:

• DSCP-to-Policed DSCP: Wird verwendet, um den per Richtlinie gesteuerten DSCP abzuleiten, wenn Sie das Paket mit Markup versehen.

• DSCP-to-CoS: Dient zum Ableiten der CoS-Ebene vom internen DSCP zum Aktualisieren des ISL/802.1Q-Headers des ausgehenden Pakets.

• CoS-zu-DSCP: dient zur Ableitung des internen DSCP von der eingehenden CoS (ISL/802.1Q-Header), wenn sich die Schnittstelle im CoS-Modus "Vertrauen" befindet.

Dies sind wichtige implementierungsspezifische Überlegungen:

• Die Richtlinie für den Eingangsservice kann nicht mit der Schnittstelle verknüpft werden, wenn die Schnittstelle für die Vertrauenswürdigkeit einer der QoS-Metriken wie CoS/DSCP oder der IP-Rangfolge konfiguriert ist. Um eine Übereinstimmung mit der DSCP/IP-Rangfolge und der Richtlinie für den Eingang zu erzielen, müssen Sie die Vertrauensstellung für die bestimmte Klasse in der Richtlinie und nicht für die Schnittstelle konfigurieren. Für die Markierung auf Grundlage der DSCP/IP-Rangfolge muss keine Vertrauensstellung konfiguriert werden.

• Ausschließlich IPv4-Datenverkehr ohne IP-Optionen und Ethernet II Advanced Research Projects Agency (ARPA)-Kapselung wird als IP-Datenverkehr vom Hardware- und QoS-Standpunkt aus betrachtet. Der gesamte übrige Datenverkehr gilt als Nicht-IP, einschließlich IP mit Optionen wie SNAP (SubNetwork Access Protocol) gekapseltes IP und IPv6.

• Bei Nicht-IP-Paketen ist "Zugriffsgruppe abgleichen" die einzige Methode zur Klassifizierung, da kein DSCP für Nicht-IP-Datenverkehr zugeordnet werden kann. Zu diesem Zweck wird eine MAC-Zugriffskontrollliste (Media Access Control Access List, ACL) verwendet. Pakete können basierend auf der Quell-MAC-Adresse, der Ziel-MAC-Adresse und dem EtherType abgeglichen werden. Es ist nicht möglich, den IP-Datenverkehr mit der MAC-Zugriffskontrollliste abzugleichen, da der Switch zwischen IP- und Nicht-IP-Datenverkehr unterscheidet.

Konfigurieren und Überwachen des Policing

Die folgenden Schritte sind erforderlich, um die Richtlinienzuweisung in Cisco IOS zu konfigurieren:

1. Definieren eines Policers (für aggregierte Policers)

2. Definieren von Kriterien zur Auswahl von Datenverkehr für die Richtlinienvergabe

3. Definieren einer Klassenzuordnung zum Auswählen von Datenverkehr anhand definierter Kriterien

4. Definieren einer Dienstrichtlinie mithilfe der Klasse und Anwenden einer Richtlinie auf die angegebene Klasse

5. Anwenden einer Servicerichtlinie auf einen Port

Diese beiden Arten der Überwachung werden unterstützt:

• Benanntes Aggregat

• Individuell

Die benannte aggregierte Richtlinie regelt den Datenverkehr, der von allen Klassen innerhalb derselben Richtlinie an den Ort der Anwendung kombiniert wird. Aggregiertes Policing über verschiedene Schnittstellen hinweg wird nicht unterstützt.

Hinweis: Die Aggregation Policer kann nicht auf mehrere Richtlinien angewendet werden. Ist dies der Fall, wird die folgende Fehlermeldung angezeigt:

QoS: Cannot allocate policer for policy map <policy name>

Betrachten Sie dieses Beispiel:

Es gibt einen Datenverkehrsgenerator, der an Port GigabitEthernet0/3 angeschlossen ist und ca. 17 Mbit/s UDP-Datenverkehr mit dem Zielport 111 sendet. Es gibt auch TCP-Datenverkehr von Port 20. Sie möchten, dass diese beiden Datenverkehrsströme auf 1 Mbit/s geregelt werden, und übermäßiger Datenverkehr muss verworfen werden. Dieses Beispiel zeigt, wie dies geschieht:

!--- Globally enables QoS.

mls qos

!--- Defines the QoS policer, sets the burst !--- to 16000 for better TCP performance.

mls qos aggregate-policer pol_1mbps 1000000 16000 exceed-action drop

!--- Defines the ACLs to select traffic.

access-list 123 permit udp any any eq 111
access-list 145 permit tcp any eq 20 any

!--- Defines the traffic classes to be policed.

class-map match-all cl_udp111
  match access-group 123
class-map match-all cl_tcp20
  match access-group 145

!--- Defines the QoS policy, and attaches !--- the policer to the traffic classes.

policy-map po_test
  class cl_udp111	
    police aggregate pol_1mbps 
  class cl_tcp20
    police aggregate pol_1mbps 

!--- Applies the QoS policy to an interface.

interface GigabitEthernet0/3
 switchport
 switchport access vlan 2
 service-policy input po_test
!

Im ersten Beispiel wurde die benannte Aggregation Policer verwendet. Im Gegensatz zur benannten Richtlinie regelt der einzelne Policer den Datenverkehr für jede Klasse, auf die er angewendet wird, separat. Die individuelle Richtlinie wird in der Konfiguration der Richtlinienzuordnung definiert. In diesem Beispiel werden zwei Klassen von Datenverkehr durch zwei individuelle Policers geregelt. cl_udp111 wird auf 1 Mbit/s pro 8-K-Burst geregelt, und cl_tcp20 wird auf 512 Kbit/s pro 32-K-Burst geregelt:

!--- Globally enables QoS.

mls qos

!--- Defines the ACLs to select traffic.

access-list 123 permit udp any any eq 111
access-list 145 permit tcp any eq 20 any

!--- Defines the traffic classes to be policed.

class-map match-all cl_udp111
  match access-group 123
class-map match-all cl_tcp20
  match access-group 145

!--- Defines QoS policy, and creates and attaches !--- the policers to the traffic classes.

policy-map po_test2
  class cl_udp111	
    police 1000000 8000 exceed-action drop
  class cl_tcp20
    police 512000 32000 exceed-action drop

!--- Applies the QoS policy to an interface.

interface GigabitEthernet0/3
 switchport
 switchport access vlan 2
 service-policy input po_test2

Dieser Befehl wird verwendet, um den Regelungsvorgang zu überwachen:

cat3550#show mls qos interface g0/3 statistics 
GigabitEthernet0/3
Ingress
  dscp: incoming   no_change  classified policed    dropped (in pkts)
Others: 267718     0          267717     0          0         
Egress
  dscp: incoming   no_change  classified policed    dropped (in pkts)
Others: 590877        n/a       n/a      266303     0         

WRED drop counts:
  qid  thresh1    thresh2   FreeQ
   1 : 0          0         1024      
   2 : 0          0         1024      
   3 : 0          0         8         
   4 : 0          0         1024

Hinweis: Standardmäßig gibt es keine DSCP-bezogenen Statistiken. Catalyst 3550 unterstützt eine schnittstellen- und richtungsabhängige Statistiksammlung für bis zu acht verschiedene DSCP-Werte. Dies wird konfiguriert, wenn Sie den Befehl mls qos monitor ausführen. Um die Statistiken für die DSCPs 8, 16, 24 und 32 zu überwachen, müssen Sie den folgenden schnittstellenspezifischen Befehl ausführen:

cat3550(config-if)#mls qos monitor dscp 8 16 24 32

Hinweis: Mit dem Befehl mls qos monitor dscp 8 16 24 32 wird die Ausgabe des Befehls show mls qos int g0/3 statistics wie folgt geändert:

cat3550#show mls qos interface g0/3 statistics
GigabitEthernet0/3
Ingress
  dscp: incoming   no_change  classified policed    dropped (in pkts)
    8 : 0          0          675053785  0          0         
    16: 1811748    0          0          0          0         ? per DSCP statistics 
    24: 1227820404 15241073   0          0          0         
    32: 0          0          539337294  0          0         
Others: 1658208    0          1658208    0          0         
Egress
  dscp: incoming   no_change  classified policed    dropped (in pkts)
    8 : 675425886     n/a       n/a      0          0         
    16: 0             n/a       n/a      0          0         ? per DSCP statistics
    24: 15239542      n/a       n/a      0          0         
    32: 539289117     n/a       n/a      536486430  0         
Others: 1983055       n/a       n/a      1649446    0         

WRED drop counts:
  qid  thresh1    thresh2   FreeQ
   1 : 0          0         1024      
   2 : 0          0         1024      
   3 : 0          0         6         
   4 : 0          0         1024

Dies ist eine Beschreibung der Felder im Beispiel:

• Eingehend: Zeigt an, wie viele Pakete aus jeder Richtung eingehen.

• NO_change: Zeigt an, wie viele Pakete vertrauenswürdig waren (z. B. nicht geänderte QoS-Ebene)

• Klassifiziert: Zeigt an, wie viele Pakete diesem internen DSCP nach der Klassifizierung zugewiesen wurden.

• Policed (Überwacht): Zeigt an, wie viele Pakete durch die Überwachung gekennzeichnet wurden. DSCP wird vor Markdown angezeigt.

• Dropped: Zeigt an, wie viele Pakete durch Richtlinien verworfen wurden.

Beachten Sie dabei die folgenden implementierungsspezifischen Aspekte:

• Wenn bei der Ausführung des Befehls mls qos monitor acht DSCP-Werte konfiguriert werden, kann der andere Zähler, der bei der Ausführung des Befehls show mls qos int statistics angezeigt wird, unzureichende Informationen anzeigen.

• Es gibt keinen spezifischen Befehl, um die angebotene oder ausgehende Datenverkehrsrate pro Richtlinienvergabe zu überprüfen.

• Da die Zähler sequenziell aus der Hardware abgerufen werden, ist es möglich, dass sich die Zähler nicht korrekt addieren. So kann sich beispielsweise die Anzahl der per Richtlinie überwachten, klassifizierten oder verworfenen Pakete leicht von der Anzahl der eingehenden Pakete unterscheiden.

Konfigurieren und Überwachen der Markierung

Die folgenden Schritte sind erforderlich, um die Kennzeichnung zu konfigurieren:

1. Definieren der Kriterien für die Klassifizierung des Datenverkehrs

2. Definition der Verkehrsklassen, die anhand zuvor definierter Kriterien klassifiziert werden sollen

3. Erstellen einer Richtlinienzuordnung, die Markierungsaktionen und Richtlinienaktionen an die definierten Klassen anfügt

4. Konfigurieren der entsprechenden Schnittstelle(n) für den Vertrauensstellungsmodus

5. Richtlinienzuordnung auf eine Schnittstelle anwenden

In diesem Beispiel soll eingehender IP-Datenverkehr als Host 192.168.192.168 mit der IP-Rangfolge 6 markiert und auf 1 Mbit/s geregelt werden. überschüssiger Datenverkehr muss auf die IP-Rangfolge 2 herabgesetzt werden:

!--- Globally enables QoS.

mls qos

!--- Defines the ACLs to select traffic.

access-list 167 permit ip any host 192.168.192.168

!--- Defines the traffic class.

class-map match-all cl_2host
  match access-group 167

!--- Defines QoS policy, and creates and attaches !--- the policers to the traffic classes.

policy-map po_test3
  class cl_2host

!--- Marks all the class traffic with the IP precedence 6.

    set ip precedence 6

!--- Polices down to 1 Mbps and marks down according to the QoS map.

    police 1000000 8000 exceed-action policed-dscp-transmit

!--- Modifies the policed DSCP QoS map, so the !--- traffic is marked down from IP precedence 6 to 2. !--- In terms of DSCP, this is from 48 to 16 (DSCP=IPprec x8).

mls qos map policed-dscp  48 to 16

!--- Applies the QoS policy to an interface.

interface GigabitEthernet0/3
 switchport
 switchport access vlan 2
 service-policy input po_test3

Der gleiche Befehl show mls qos interface statistics wird ausgegeben, um die Markierung zu überwachen. Beispielergebnisse und deren Auswirkungen werden im Abschnitt dieses Dokuments beschrieben.

Klassifizierung des gesamten Schnittstellenverkehrs mit einer einzelnen Richtlinie

Auf Catalyst 3550 wird der Befehl match interface nicht unterstützt, und pro Klassenzuordnung ist nur ein match-Befehl zulässig. Darüber hinaus ermöglicht der Catalyst 3550 nicht, dass der IP-Datenverkehr von den MAC-Zugriffskontrolllisten abgeglichen wird. Daher muss IP- und Nicht-IP-Datenverkehr mit zwei separaten Klassenzuordnungen klassifiziert werden. Dies macht es schwierig, den gesamten Datenverkehr, der an eine Schnittstelle gelangt, zu klassifizieren und den gesamten Datenverkehr mit einer einzigen Überwachung zu steuern. Mit der hier gezeigten Beispielkonfiguration können Sie dies erreichen. In dieser Konfiguration werden IP- und Nicht-IP-Datenverkehr zwei unterschiedlichen Klassenzuordnungen zugeordnet. Beide verwenden jedoch eine gemeinsame Richtlinie für den Datenverkehr.

access-list 100 permit ip any any

class-map ip
match access-group 100

!--- This class-map classifies all IP traffic.


mac access-list extended non-ip-acl
permit any any

class-map non-ip
match access-group name non-ip-acl

!--- Class-map classifies all non-IP traffic only. 


mls qos aggregate-policer all-traffic 8000 8000 exceed-action drop

!--- This command configures a common policer that is applied for both IP and non-IP traffic.


policy-map police-all-traffic
class non-ip
police aggregate all-traffic
class ip
police aggregate all-traffic

interface gigabitEthernet 0/7
service-policy input police-all-traffic

!--- This command applies the policy map to the physical interface.

 

Zugehörige Informationen

• Konfigurieren von QoS auf Catalyst 3550
• Quality of Service-Support-Seiten
• Support-Seite zum Thema LAN-Switching
• Support-Seiten für LAN-Produkte
• Technischer Support und Dokumentation für Cisco Systeme