Fehlerbehebung bei Ausgabeausfällen mit Prioritätswarteschlange

Einführung

Dieses Dokument enthält Tipps zur Fehlerbehebung bei Ausgabeverwerfungen, die aus einer Konfiguration des Prioritätswarteschlangenmechanismus auf einer Router-Schnittstelle resultieren.

Voraussetzungen

Anforderungen

Die Leser dieses Dokuments sollten mit den folgenden Konzepten vertraut sein:

• priority-group oder frame-relais priority-group: Aktiviert den Mechanismus für die Prioritätswarteschlange von Cisco. Unterstützt bis zu vier Prioritätswarteschlangen.

• ip rtp priority oder frame-relais ip rtp priority - Gleicht UDP-Portnummern für RTP-Datenverkehr (Real-Time Protocol) ab, der VoIP-Pakete kapselt, und platziert diese Pakete in einer Prioritätswarteschlange.

• priority (Priorität): Aktiviert die LLQ-Funktion (Low Latency Queueing) von Cisco und verwendet die Befehlsstruktur der modularen QoS-Befehlszeilenschnittstelle (CLI).

Ein Router kann Ausgabeverfahren melden, wenn eine dieser Methoden konfiguriert ist. Es gibt jedoch wichtige funktionale Unterschiede zwischen den Methoden und den Gründen für Verwerfen in jedem Fall.

Die in diesem Dokument enthaltenen Informationen wurden aus Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Sie in einem Live-Netzwerk arbeiten, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen, bevor Sie ihn verwenden.

Verwendete Komponenten

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

Die in diesem Dokument enthaltenen Informationen wurden aus Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Sie in einem Live-Netzwerk arbeiten, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen, bevor Sie es verwenden.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Konventionen, die in technischen Tipps von Cisco verwendet werden.

Dropdown mit ip rtp priority und LLQ

Der Cisco IOS-Konfigurationsleitfaden warnt vor Ausgabeverwerfungen mithilfe der folgenden Prioritätswarteschlangen:

• ip rtp priority: Da der Befehl ip rtp priority absolute Priorität gegenüber anderem Datenverkehr hat, sollte er mit Vorsicht verwendet werden. Wenn bei einer Überlastung der Datenverkehr die konfigurierte Bandbreite überschreitet, wird der gesamte übermäßige Datenverkehr verworfen.

• priority command and LLQ: Wenn Sie den Priority-Befehl für eine Klasse angeben, wird ein Bandbreitenargument verwendet, das maximale Bandbreite bereitstellt. Im Fall einer Überlastung werden Pakete mithilfe von Richtlinien verworfen, wenn die Bandbreite überschritten wird.

Diese beiden Mechanismen verwenden eine integrierte Überwachung, um die Datenverkehrsflüsse zu messen. Der Zweck der Richtlinie besteht darin, sicherzustellen, dass die anderen Warteschlangen vom Warteschlangenplaner bedient werden. In der ursprünglichen Prioritätswarteschlangenfunktion von Cisco, die die Befehle für Prioritätsgruppen und Prioritätslisten verwendet, hat der Scheduler stets zuerst die Warteschlange mit der höchsten Priorität bedient. Wenn immer Datenverkehr in der Warteschlange mit hoher Priorität vorhanden war, wurde den Warteschlangen mit niedriger Priorität die Bandbreite und den Paketen, die an Warteschlangen ohne Priorität gesendet wurden, vorenthalten.

Löscht mit Prioritätswarteschlange

Priority Queueing (PQ) ist der Mechanismus für die Warteschlangenverwaltung mit älterer Priorität von Cisco. Wie unten gezeigt, unterstützt PQ bis zu vier Warteschlangenebenen: hoch, mittel, normal und niedrig.

Durch Aktivieren der Prioritätswarteschlange auf einer Schnittstelle wird die Anzeige der Ausgabewarteschlange wie unten gezeigt geändert. Vor der Prioritätswarteschlange verwendet die Ethernet-Schnittstelle eine einzelne Ausgabewarteschlange mit der Standardwarteschlangengröße von 40 Paketen.

R6-2500# show interface ethernet0 
Ethernet0 is up, line protocol is up 
  Hardware is Lance, address is 0000.0c4e.59b1 (bia 0000.0c4e.59b1) 
  Internet address is 42.42.42.2/24 
  MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255 
  Encapsulation ARPA, loopback not set, keepalive set (10 sec) 
  ARP type: ARPA, ARP Timeout 04:00:00 
  Last input 00:00:03, output 00:00:02, output hang never 
  Last clearing of "show interface" counters never 
  Queueing strategy: fifo 
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops 
  5 minute input rate 0 bits/sec, 0 packets/sec 
  5 minute output rate 0 bits/sec, 0 packets/sec 
     239407 packets input, 22644297 bytes, 0 no buffer 
     Received 239252 broadcasts, 0 runts, 0 giants, 0 throttles 
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
     0 input packets with dribble condition detected 
     374436 packets output, 31095372 bytes, 0 underruns 
     0 output errors, 1 collisions, 13 interface resets 
     0 babbles, 0 late collision, 8 deferred 
     0 lost carrier, 0 no carrier 
     0 output buffer failures, 0 output buffers swapped out

Nach der Aktivierung von PQ verwendet die Ethernet-Schnittstelle nun vier Prioritätswarteschlangen mit unterschiedlichen Warteschlangenbeschränkungen, wie in der unten stehenden Ausgabe gezeigt:

R6-2500(config)# interface ethernet0 
R6-2500(config-if)# priority-group 1 
R6-2500(config-if)# end 
R6-2500# show interface ethernet 0 
Ethernet0 is up, line protocol is up 
  Hardware is Lance, address is 0000.0c4e.59b1 (bia 0000.0c4e.59b1)
  Internet address is 42.42.42.2/24 
  MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255 
  Encapsulation ARPA, loopback not set, keepalive set (10 sec)
  ARP type: ARPA, ARP Timeout 04:00:00 
  Last input 00:00:03, output 00:00:03, output hang never 
  Last clearing of "show interface" counters never 
  Input queue: 0/75/0 (size/max/drops); Total output drops: 0
  Queueing strategy: priority-list 1 
  Output queue (queue priority: size/max/drops): 
     high: 0/20/0, medium: 0/40/0, normal: 0/60/0, low: 0/80/0 
  5 minute input rate 0 bits/sec, 0 packets/sec 
  5 minute output rate 0 bits/sec, 0 packets/sec 
     239411 packets input, 22644817 bytes, 0 no buffer
     Received 239256 broadcasts, 0 runts, 0 giants, 0 throttles 
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
     0 input packets with dribble condition detected 
     374440 packets output, 31095658 bytes, 0 underruns
     0 output errors, 1 collisions, 14 interface resets
     0 babbles, 0 late collision, 8 deferred 
     0 lost carrier, 0 no carrier 
     0 output buffer failures, 0 output buffers swapped out

Mit dem Befehl priority-list {list-number} wird Datenverkehrsflüsse einer bestimmten Warteschlange zugewiesen. Wenn die Pakete an einer Schnittstelle ankommen, werden die Prioritätswarteschlangen an dieser Schnittstelle auf Pakete in absteigender Reihenfolge der Priorität gescannt. Die Warteschlange mit hoher Priorität wird zuerst gescannt, die Warteschlange mit mittlerer Priorität usw. Das Paket an der Spitze der Warteschlange mit der höchsten Priorität wird für die Übertragung ausgewählt. Dieses Verfahren wird jedes Mal wiederholt, wenn ein Paket gesendet werden soll.

Jede Warteschlange wird durch eine maximale Länge oder die maximale Anzahl an Paketen definiert, die die Warteschlange speichern kann. Wenn ein ankommendes Paket dazu führt, dass die aktuelle Warteschlangentiefe die konfigurierte Warteschlangengrenze überschreitet, wird das Paket verworfen. Wie oben bereits erwähnt, sind Ausgabeverwerfungen mit PQ in der Regel darauf zurückzuführen, dass die Warteschlangengrenze überschritten wird und nicht auf eine interne Policer, wie es bei LLQ typischerweise der Fall ist. Der Befehl priority-list list-listqueue-limit ändert die Größe einer Prioritätswarteschlange.

Datenverkehrsmessung mit einem Token-Bucket

Die LLQ- und die IP RTP-Priorität implementieren die integrierte Überwachung mithilfe eines Token-Buckets als Datenverkehrsmesssystem. In diesem Abschnitt wird das Token-Bucket-Konzept behandelt.

Eine Tokenbucket selbst verfügt über keine Rückwurfs- oder Prioritätsrichtlinie. Die Metapher der Token-Buckets funktioniert in folgenden Zeilen:

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

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

• Um ein Paket zu senden, muss der Traffic-Regulator in der Lage sein, eine Anzahl Token aus dem Puffer zu entfernen, die der Paketgröße entsprechen.

• Wenn sich nicht genügend Token im Eimer befinden, um ein Paket zu senden, wartet das Paket entweder, bis der Eimer über genügend Token verfügt (bei einem Shaper), oder das Paket wird verworfen oder ausgezeichnet (bei einem Policer).

• Der Eimer selbst hat eine festgelegte Kapazität. Wenn der Eimer die Kapazität erreicht, werden neu eintreffende Token verworfen und sind für zukünftige Pakete nicht verfügbar. So ist der größte Burst, den eine Anwendung in das Netzwerk senden kann, zu jedem Zeitpunkt ungefähr proportional zur Größe des Eckels. Ein Token-Eimer erlaubt Burstiness, aber grenzt ihn an.

Betrachten wir ein Beispiel für die Verwendung von Paketen und einer Committed Information Rate (CIR) von 8000 bps.

• In diesem Beispiel beginnen die anfänglichen Token-Buckets mit 1000 Byte voll.

• Wenn ein 450-Byte-Paket eingeht, wird das Paket konform, da in der konformen Tokenbucket genügend Bytes verfügbar sind. Das Paket wird gesendet, und 450 Byte werden aus der Tokenbucket entfernt, sodass 550 Byte verbleiben.

• Wenn das nächste Paket 0,25 Sekunden später ankommt, werden dem Tokenbucket 250 Byte hinzugefügt (0,25 * 8000)/8), wobei 700 Byte im Tokenhecket verbleiben. Wenn das nächste Paket 800 Byte beträgt, wird es größer und verworfen. Es werden keine Bytes aus der Tokenbuchse genommen.

Fehlerbehebung Schritte zur Diagnose von Verlusten

Schritt 1: Erfassen von Daten

Die Schritte zum Sammeln von Daten sind nachfolgend dargestellt.

1. Führen Sie die folgenden Befehle mehrmals aus, und legen Sie fest, wie schnell und wie oft die einzelnen Befehle inkrementiert werden. Verwenden Sie die Ausgabe, um eine Baseline für Ihre Datenverkehrsmuster und Datenverkehrsebenen zu erstellen. Ermitteln Sie die "normale" Abbruchrate auf der Schnittstelle.

   • Show Queuing-Schnittstelle

     router# show queueing interface hssi 0/0/0
               Interface Hssi0/0/0 queueing strategy: priority
     
               Output queue utilization (queue/count)
     
                high/12301 medium/4 normal/98 low/27415

   • show interface - Überwachen Sie den in der Ausgabe angezeigten Lastwert. Stellen Sie außerdem sicher, dass die Summe der Drop-Zählungen pro Warteschlange in der Ausgabe der show interface der Anzahl der Ausgabeverwerfen entspricht. Der Zähler show interface output drops sollte die Gesamtsumme aller Ausgabeausfälle anzeigen, einschließlich WRED-Verwerfen, Verwerfen wegen Pufferknappheit ("no buffer"-Fehler) und sogar Rückwürfe im integrierten Port-Adapterspeicher.

     router# show interface serial 4/1/2
     
     Serial4/1/2 is up, line protocol is up 
     Hardware is cyBus Serial 
     Description: E1 Link to 60W S9/1/2 Backup 
     Internet address is 169.127.18.228/27 
     MTU 1500 bytes, BW 128 Kbit, DLY 21250 usec, rely 255/255, load 183/255 
     Encapsulation HDLC, loopback not set, keepalive set (10 sec) 
     Last input 00:00:00, output 00:00:00, output hang never 
     Last clearing of "show interface" counters 5d10h 
     Input queue: 0/75/0 (size/max/drops); Total output drops: 68277 
     Queueing strategy: priority-list 7 
     Output queue: high 0/450/0, medium 0/350/143, normal 0/110/27266, low 0/100/40868 
     5 minute input rate 959000 bits/sec, 419 packets/sec 
     5 minute output rate 411000 bits/sec, 150 packets/sec 
     144067307 packets input, 4261520425 bytes, 0 no buffer 
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 
     42 input errors, 34 CRC, 0 frame, 0 overrun, 1 ignored, 8 abort 
     69726448 packets output, 2042537282 bytes, 0 underruns 
     0 output errors, 0 collisions, 0 interface resets 
     0 output buffer failures, 46686454 output buffers swapped out 
     0 carrier transitions

     Hinweis: Einige Schnittstellen zeigen separate Werte für "txload" und "rxload" an.

     Hssi0/0/0 is up, line protocol is up 
      Hardware is cyBus HSSI 
      MTU 1500 bytes, BW 7500 Kbit, DLY 200 usec, 
      reliability 255/255, txload 138/255, rxload 17/255 
      Encapsulation FRAME-RELAY IETF, crc 16, loopback not set 
      Keepalive set (5 sec) 
      LMI enq sent 4704, LMI stat recvd 4704, LMI upd recvd 0, DTE LMI up 
      LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0 
      LMI DLCI 1023 LMI type is CISCO frame relay DTE 
      Broadcast queue 0/256, broadcasts sent/dropped 8827/0, interface 
      broadcasts 7651 
      Last input 00:00:00, output 00:00:00, output hang never 
      Last clearing of "show interface" counters 06:31:58 
      Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 84 
      Queueing strategy: priority-list 1 
      Output queue (queue priority: size/max/drops): 
      high: 0/20/0, medium: 0/40/0, normal: 0/60/0, low: 0/80/84 
      5 minute input rate 524000 bits/sec, 589 packets/sec 
      5 minute output rate 4080000 bits/sec, 778 packets/sec 
      11108487 packets input, 1216363830 bytes, 0 no buffer 
      Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 
      0 parity 
      0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
      15862186 packets output, 3233772283 bytes, 0 underruns 
      0 output errors, 0 applique, 1 interface resets 
      0 output buffer failures, 2590 output buffers swapped out 
      0 carrier transitions 
      LC=down CA=up TM=down LB=down TA=up LA=down

   • show policy-map interface interface-name - Suchen Sie nach einem Wert, der nicht null ist, für den Zähler "pkts discards".

     Router# show policy-map interface s1/0
      Serial1/0.1: DLCI 100 -
      output : mypolicy
       Class voice
        Weighted Fair Queueing
            Strict Priority
            Output Queue: Conversation 72 
              Bandwidth 16 (kbps) Packets Matched 0
             (pkts discards/bytes discards) 0/0
       Class immediate-data
        Weighted Fair Queueing
            Output Queue: Conversation 73 
              Bandwidth 60 (%) Packets Matched 0
              (pkts discards/bytes discards/tail drops) 0/0/0
              mean queue depth: 0
              drops: class  random   tail     min-th   max-th   mark-prob 
                     0      0        0        64       128      1/10
                     1      0        0        71       128      1/10
                     2      0        0        78       128      1/10
                     3      0        0        85       128      1/10
                     4      0        0        92       128      1/10
                     5      0        0        99       128      1/10
                     6      0        0        106      128      1/10
                     7      0        0        113      128      1/10
                     rsvp   0        0        120      128      1/10

     Hinweis: In der folgenden Beispielausgabe werden übereinstimmende Werte für die Zähler "Pakete" und "Übereinstimmende Pakete" angezeigt. Diese Bedingung weist darauf hin, dass eine große Anzahl von Paketen über den Prozess gewechselt wird oder dass die Schnittstelle extrem überlastet ist. Beide Bedingungen können dazu führen, dass die Warteschlangengrenze einer Klasse überschritten wird. Sie sollten untersucht werden.

     router# show policy-map interface
     
     Serial4/0 
     
     Service-policy output: policy1 
     
     Class-map: class1 (match-all) 
     189439 packets, 67719268 bytes 
     5 minute offered rate 141000 bps, drop rate 0 bps 
     Match: access-group name ds-class-af3 
     Weighted Fair Queueing 
     Output Queue: Conversation 265 
     Bandwidth 50 (%) Max Threshold 64 (packets) 
     (pkts matched/bytes matched) 189439/67719268 
     (depth/total drops/no-buffer drops) 0/0/0

2. Geben Sie die Datenverkehrsflüsse und die Pakete in diesen Flüssen an.

   • Wie groß ist die durchschnittliche Paketgröße?

   • In welche Richtung fließt der Frame der MTU-Größe? Viele Datenverkehrsflüsse sind hinsichtlich der Last asynchron. Bei einem FTP-Download fließen beispielsweise die meisten Pakete mit MTU-Größe vom FTP-Server zum Client. Pakete vom FTP-Client zum Server sind einfache TCP-ACKs.

   • Verwenden die Pakete TCP oder UDP? TCP ermöglicht jedem Datenfluss das Senden einer autorisierten Anzahl von Paketen, bevor die Quelle die Übertragung unterbrechen und warten muss, bis das Ziel die übertragenen Pakete bestätigt.

3. Bestimmen Sie bei Frame Relay, ob die Drops in der Schnittstellenwarteschlange oder in einer VC-Warteschlange auftreten. Das folgende Diagramm zeigt den Paketfluss über einen virtuellen Frame-Relay-Circuit:

   

4. Priority Queueing unterstützt bis zu vier Ausgabewarteschlangen, eine pro Prioritätswarteschlange, und jede Warteschlange wird durch einen Warteschlangenlimit definiert. Das Warteschlangensystem überprüft die Größe der Warteschlange anhand des konfigurierten Warteschlangenlimits, bevor das Paket in eine Warteschlange gestellt wird. Wenn die ausgewählte Warteschlange voll ist, verwirft der Router das Paket. Versuchen Sie, die Warteschlangengröße mit dem Befehl priority-list {#} queue-limit zu erhöhen und die Überwachung der Wiederaufnahme fortzusetzen.

Schritt 2: Sicherstellen einer ausreichenden Bandbreite

Mit LLQ ermöglicht die Richtlinienvergabe eine gerechte Behandlung anderer Datenpakete in anderen Class-Based Weighted Fair Queuing (CBWFQ)- oder WFQ-Warteschlangen. Um Paketverluste zu vermeiden, sollten Sie der Prioritätswarteschlange unter Berücksichtigung des verwendeten Codec-Typs und der Schnittstellenmerkmale eine optimale Bandbreite zuweisen. Die IP RTP-Priorität lässt keinen Datenverkehr zu, der über die zugewiesene Menge hinausgeht.

Es ist immer am sichersten, der Prioritätswarteschlange etwas mehr Bandbreite zuzuweisen als die bekannte erforderliche Bandbreite. Angenommen, Sie haben der Prioritätswarteschlange 24 Kbit/s Bandbreite zugewiesen, d. h. die Standardmenge, die für die Sprachübertragung erforderlich ist. Diese Zuweisung scheint sicher zu sein, da die Übertragung von Sprachpaketen mit konstanter Bitrate erfolgt. Da das Netzwerk und der Router oder Switch jedoch einen Teil der Bandbreite für Jitter und Verzögerungen verwenden können, gewährleistet die Zuweisung etwas mehr als die erforderliche Bandbreite (z. B. 25 Kbit/s) Konstantheit und Verfügbarkeit.

Die für eine Prioritätswarteschlange reservierte Bandbreite enthält immer den Layer-2-Kapselungs-Header. Die CRC-Prüfung (zyklische Redundanzprüfung) ist nicht enthalten. (Siehe What Bytes are Counted by IP to ATM CoS Queueing? für weitere Informationen.) Obwohl es nur wenige Byte sind, hat CRC eine zunehmende Auswirkung, da die Datenverkehrsflüsse eine größere Anzahl von kleinen Paketen umfassen.

Darüber hinaus enthält die für eine Prioritätswarteschlange reservierte Bandbreite an ATM-Schnittstellen nicht den folgenden Steueraufwand für ATM-Zellen:

• Beliebiges Padding durch die Segmentierung und Reassemblierung (SAR), um die letzte Zelle eines Pakets zu einem gleichmäßigen Vielfachen von 48 Byte zu machen.

• 4 Byte CRC des ATM Adaptation Layer 5 (AAL5) Trailer.

• 5-Byte-ATM-Zellenheader

Wenn Sie die Bandbreite für eine bestimmte Prioritätsklasse berechnen, müssen Sie berücksichtigen, dass Layer-2-Header enthalten sind. Wenn Geldautomaten verwendet werden, müssen Sie berücksichtigen, dass der Steueraufwand für ATM-Zellen nicht enthalten ist. Sie müssen auch Bandbreite für Jitter zulassen, der von Netzwerkgeräten im Sprachpfad eingeführt wird. Weitere Informationen finden Sie unter Übersicht über die Low Latency Queueing-Funktion.

Wenn zur Übertragung von VoIP-Paketen Prioritätswarteschlangen verwendet werden, verwenden Sie Voice over IP - Per Call Bandwidth Consumption (Bandbreitenaufnahme pro Anruf).

Schritt 3: Sicherstellen einer ausreichenden Burst-Größe

Die Behandlung einer Reihe von Paketen, die eine Schnittstelle über eine Prioritätswarteschlange verlassen, hängt von der Größe des Pakets und der Anzahl der Bytes ab, die in der Tokenbuchse verbleiben. Es ist wichtig, die Merkmale des Datenverkehrsflusses zu berücksichtigen, der an die Prioritätswarteschlange weitergeleitet wird, da LLQ einen Policer und keinen Shaper verwendet. Ein Policer verwendet eine Tokenbuchse wie folgt:

• Die Eimer wird mit Token gefüllt, die auf der Klassenrate bis zu einem Maximum des Burst-Parameters basieren.

• Wenn die Anzahl der Token größer oder gleich der Paketgröße ist, wird das Paket gesendet, und die Tokenbuchse wird reduziert. Andernfalls wird das Paket verworfen.

Der standardmäßige Burst-Wert des Token-Bucket-Datenverkehrsmessers von LLQ wird bei der konfigurierten Bandbreitenrate als 200 Millisekunden Datenverkehr berechnet. In einigen Fällen ist der Standardwert unzureichend, insbesondere wenn der TCP-Datenverkehr in die Prioritätswarteschlange geht. TCP-Datenflüsse sind in der Regel Bursts und erfordern möglicherweise eine Burst-Größe, die größer ist als die vom Warteschlangensystem festgelegte Standardgröße, insbesondere bei langsamen Verbindungen.

Die folgende Probenausgabe wurde auf einer ATM-PVC mit einer dauerhaften Zellgeschwindigkeit von 128 Kbit/s generiert. Das Warteschlangensystem passt die Burst-Größe an, sobald sich der mit dem Priority-Befehl angegebene Wert ändert.

7200-17# show policy-map int atm 4/0.500
 ATM4/0.500: VC 1/500 - 
  
Service-policy output: drops 

    Class-map: police (match-all)
      0 packets, 0 bytes 
      5 minute offered rate 0 bps, drop rate 0 bps 
      Match: any 
      Weighted Fair Queueing 
        Strict Priority 
        Output Queue: Conversation 24 
        Bandwidth 90 (%) 
        Bandwidth 115 (kbps) Burst 2875 (Bytes) 
        
!--- Burst value of 2875 bytes is assigned when !--- the reserved bandwidth value is 115 kbps. 

        (pkts matched/bytes matched) 0/0 
        (total drops/bytes drops) 0/0 

    Class-map: class-default (match-any) 
      0 packets, 0 bytes 
      5 minute offered rate 0 bps, drop rate 0 bps 
      Match: any 

7200-17# show policy-map int atm 4/0.500 
 ATM4/0.500: VC 1/500 - 

  Service-policy output: drops 

    Class-map: police (match-all) 
      0 packets, 0 bytes 
      5 minute offered rate 0 bps, drop rate 0 bps 
      Match: any 
      Weighted Fair Queueing 
        Strict Priority 
        Output Queue: Conversation 24 
        Bandwidth 50 (%) 
        Bandwidth 64 (kbps) Burst 1600 (Bytes) 
        
!--- Burst value changes to 1600 bytes when the !--- reserved bandwidth value is changed to 64 kbps. 

        (pkts matched/bytes matched) 0/0 
        (total drops/bytes drops) 0/0 

    Class-map: class-default (match-any) 
      0 packets, 0 bytes 
      5 minute offered rate 0 bps, drop rate 0 bps 
      Match: any

Die Funktionalität von LLQ wurde erweitert, um eine konfigurierbare Committed Burst (Bc)-Größe mit der Funktion Configuring Burst Size in Low Latency Queueing (Konfiguration der Burst Size in Low Latency Queueing) zu ermöglichen. Mit dieser neuen Funktion kann das Netzwerk jetzt temporäre Datenverkehrsspitzen bewältigen und den Netzwerkverkehr effizienter verwalten.

Verwenden Sie den Burst-Parameter mit dem Befehl priority, um den Burst-Wert von 1600 Byte auf 3200 Byte zu erhöhen.

policy-map AV 
  class AV 
  priority percent 50 3200

Hinweis: Ein hoher Wert erhöht die effektive Bandbreite der Prioritätsklasse und kann den Anschein erwecken, dass die Prioritätsklassen mehr als ihren gerechten Anteil an der Bandbreite erhalten.

Darüber hinaus wurde dem Warteschlangensystem ursprünglich ein interner Warteschlangenlimit von 64 Paketen für die Warteschlange mit niedriger Latenz zugewiesen. Wenn ein Burst von 64 Paketen bei der Prioritätswarteschlange einging, ermittelte der Datenverkehrszähler in einigen Fällen, dass der Burst der konfigurierten Rate entsprach, die Anzahl der Pakete jedoch die Warteschlangengrenze überschreitete. Infolgedessen wurden einige Pakete im Tail-Drop verworfen. Die Cisco Bug-ID CSCdr51979 (nur registrierte Kunden) löst dieses Problem, indem die Größe der Prioritätswarteschlange so tief ansteigen kann, wie es die Datenverkehrsanzeige zulässt.

Die folgende Ausgabe wurde in Frame Relay-PVC mit einer CIR-Konfiguration von 56 Kbit/s erfasst. Im ersten Satz der Beispielausgabe beträgt die kombinierte angebotene Rate der Klassen c1 und c2 76 Kbit/s. Der Grund hierfür ist, dass die berechneten Werte der angebotenen Raten abzüglich der Dropraten nicht die tatsächlichen Übertragungsraten darstellen und keine Pakete enthalten, die vor ihrer Übertragung im Shaper sitzen.

router# show policy-map int s2/0.1
  Serial2/0.1: DLCI 1000 - 

   Service-policy output: p 

     Class-map: c1 (match-all) 
       7311 packets, 657990 bytes 
       30 second offered rate 68000 bps, drop rate 16000 bps 
       Match: ip precedence 1 
       Weighted Fair Queueing 
         Strict Priority 
         Output Queue: Conversation 24 
         Bandwidth 90 (%) 
         Bandwidth 50 (kbps) Burst 1250 (Bytes) 
         (pkts matched/bytes matched) 7311/657990 
         (total drops/bytes drops) 2221/199890 

     Class-map: c2 (match-all) 
       7311 packets, 657990 bytes 
       30 second offered rate 68000 bps, drop rate 44000 bps 
       Match: ip precedence 2 
       Weighted Fair Queueing 
         Output Queue: Conversation 25 
         Bandwidth 10 (%) 
         Bandwidth 5 (kbps) Max Threshold 64 (packets) 
         (pkts matched/bytes matched) 7310/657900 
         (depth/total drops/no-buffer drops) 64/6650/0 

     Class-map: class-default (match-any) 
       2 packets, 382 bytes 
       30 second offered rate 0 bps, drop rate 0 bps 
       Match: any

In dieser zweiten Ausgabe wurden die show policy-map-Schnittstellenindikatoren normalisiert. Auf der 56-Kbit/s-PVC sendet die Klasse c1 etwa 50 Kbit/s, und die Klasse c2 sendet etwa 6 Kbit/s.

router# show policy-map int s2/0.1 
  Serial2/0.1: DLCI 1000 - 

   Service-policy output: p 

     Class-map: c1 (match-all) 
       15961 packets, 1436490 bytes 
       30 second offered rate 72000 bps, drop rate 21000 bps 
       Match: ip precedence 1 
       Weighted Fair Queueing 
         Strict Priority 
         Output Queue: Conversation 24 
         Bandwidth 90 (%) 
         Bandwidth 50 (kbps) Burst 1250 (Bytes) 
         (pkts matched/bytes matched) 15961/1436490 
         (total drops/bytes drops) 4864/437760 

     Class-map: c2 (match-all) 
       15961 packets, 1436490 bytes 
       30 second offered rate 72000 bps, drop rate 66000 bps 
       Match: ip precedence 2 
       Weighted Fair Queueing 
         Output Queue: Conversation 25 
         Bandwidth 10 (%) 
         Bandwidth 5 (kbps) Max Threshold 64 (packets) 
         (pkts matched/bytes matched) 15960/1436400 
         (depth/total drops/no-buffer drops) 64/14591/0 

     Class-map: class-default (match-any) 
       5 packets, 1096 bytes 
       30 second offered rate 0 bps, drop rate 0 bps 
       Match: any

Schritt 4: Debug-Priorität

Der Befehl debug priority (Debug-Priorität) zeigt die Ausgabe von Prioritätswarteschlangen an, wenn Pakete aus der Prioritätswarteschlange entfernt werden.

Vorsicht: Bevor Sie Debugbefehle verwenden, lesen Sie Wichtige Informationen über Debugbefehle. Der Befehl debug priority gibt möglicherweise eine große Menge an Fehlerbehebungsausgaben auf einem Produktionsrouter aus. Die Höhe hängt vom Grad der Überlastung ab.

Die folgende Beispielausgabe wurde auf einem Cisco 3640 erstellt.

r3-3640-5# debug priority 
Priority output queueing debugging is on 

r3-3640-5# ping 10.10.10.2 

Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds: 
!!!!! 
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/57/60 ms 
r3-3640-5# 
00:42:40: PQ: Serial0/1: ip -> normal 
00:42:40: PQ: Serial0/1 output (Pk size/Q 104/2) 
00:42:40: PQ: Serial0/1: ip -> normal 
00:42:40: PQ: Serial0/1 output (Pk size/Q 104/2) 
00:42:40: PQ: Serial0/1: ip -> normal 
00:42:40: PQ: Serial0/1 output (Pk size/Q 104/2) 
00:42:40: PQ: Serial0/1: ip -> normal 
00:42:40: PQ: Serial0/1 output (Pk size/Q 104/2) 
00:42:40: PQ: Serial0/1: ip -> normal 
00:42:40: PQ: Serial0/1 output (Pk size/Q 104/2) 
00:42:41: PQ: Serial0/1 output (Pk size/Q 13/0) 
r3-3640-5#no debug priority 
00:42:51: PQ: Serial0/1 output (Pk size/Q 13/0) 
Priority output queueing debugging is off

In der folgenden Debug-Prioritätsausgabe gibt 64 die tatsächliche Prioritätswarteschlangentiefe zum Zeitpunkt des Paketverlusts an.

*Feb 28 16:46:05.659:WFQ:dropping a packet from the priority queue 64
*Feb 28 16:46:05.671:WFQ:dropping a packet from the priority queue 64
*Feb 28 16:46:05.679:WFQ:dropping a packet from the priority queue 64
*Feb 28 16:46:05.691:WFQ:dropping a packet from the priority queue 64

Weitere Ursachen für Drops

Die folgenden Gründe für Ausgabeverwerfungen mit LLQ wurden vom Cisco Technical Assistance Center (TAC) bei der Problembehebung entdeckt und in einem Cisco Bug Report dokumentiert:

• Durch die Erhöhung der gewichteten maximalen Schwellenwerte für die willkürliche Früherkennung (WRED) einer anderen Klasse wurden die verfügbaren Puffer erschöpft und die Prioritätswarteschlange verworfen. Um dieses Problem zu diagnostizieren, ist für eine zukünftige IOS-Version ein Zähler für "No-Puffer Drop" der Prioritätsklasse geplant.

• Wenn der Grenzwert für die Warteschlange der Eingangsschnittstelle kleiner als der Grenzwert für die Warteschlange der Ausgangsschnittstelle ist, werden Pakete auf die Eingabeschnittstelle verschoben. Diese Symptome sind in der Cisco Bug ID CSCdu89226 dokumentiert (nur registrierte Kunden). Lösen Sie dieses Problem, indem Sie die Eingangswarteschlange und die Ausgabewarteschlange entsprechend anpassen, um Eingabeverwerbe zu verhindern und den Mechanismus für die Warteschlangenverwaltung bei ausgehendem Datenverkehr zu aktivieren.

• Wenn eine Funktion aktiviert wird, die im CEF-Switch- oder Fast-Switched-Pfad nicht unterstützt wird, wird eine große Anzahl von Paketen prozessgeschaltet. Bei LLQ werden prozessvermittelte Pakete derzeit geregelt, unabhängig davon, ob die Schnittstelle überlastet ist. Das heißt, selbst wenn die Schnittstelle nicht überlastet ist, misst das Warteschlangensystem prozessvermittelte Pakete und stellt sicher, dass die angebotene Last den mit dem priority-Befehl konfigurierten Bandbreitenwert nicht überschreitet. Dieses Problem ist in der Cisco Bug-ID CSCdv86818 dokumentiert (nur registrierte Kunden).

Prioritätswarteschlangen fallen und Frame-Relay

Frame Relay ist ein Sonderfall bei der Regelung der Prioritätswarteschlange. Die Funktionsübersicht Low Latency Queueing for Frame Relay bietet einen Hinweis auf den folgenden Vorbehalt: "Der PQ wird so geregelt, dass die faire Warteschlange nicht an Bandbreite verliert. Bei der Konfiguration des PQ geben Sie in Kbit/s die maximale verfügbare Bandbreite für diese Warteschlange an. Pakete, die diesen Höchstwert überschreiten, werden verworfen." Anders ausgedrückt: Ursprünglich wurde die Prioritätswarteschlange einer Dienstrichtlinie, die in einer Frame-Relay-Zuordnungsklasse konfiguriert wurde, in Zeiten von Überlastung und nicht überlasteter Umgebung geregelt. IOS 12.2 entfernt diese Ausnahme. PQ wird weiterhin mit FRF.12 überwacht, aber andere nicht konforme Pakete werden nur verworfen, wenn eine Überlastung vorliegt.

Zugehörige Informationen

• QoS-Support-Seite
• Cisco IOS Software Release 12.2 Traffic Policing Feature-Modul
• Technischer Support - Cisco Systems