Fehlerbehebung - Ausgabeverringerungen mit Priority Queueing

Einleitung

In diesem Dokument finden Sie Tipps zur Fehlerbehebung bei Ausgabelücken, die sich aus der Konfiguration eines priorisierten Warteschlangenmechanismus auf einer Router-Schnittstelle ergeben.

Voraussetzungen

Anforderungen

Leser dieses Dokuments sollten mit den folgenden Konzepten vertraut sein:

• priority-group oder frame-relay priority-group - Aktiviert den Mechanismus für ältere Prioritätswarteschlangen von Cisco. Unterstützt bis zu vier Prioritätswarteschlangen-Ebenen.

• ip rtp priority or frame-relay ip rtp priority - Trifft auf UDP-Portnummern für RTP-Datenverkehr (Real-Time Protocol) zu, 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 bei der Konfiguration einer dieser Methoden Ausgabefälle melden, es gibt jedoch wichtige funktionale Unterschiede zwischen den Methoden und den Ursachen für die jeweiligen Fehler.

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 Sie in einem Live-Netzwerk arbeiten, stellen Sie sicher, dass Sie die potenziellen Auswirkungen jedes Befehls kennen, bevor Sie ihn verwenden.

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 sich Ihr Netzwerk in der Produktionsumgebung befindet, müssen Sie sich bei jedem Befehl zunächst dessen potenzielle Auswirkungen vor Augen führen.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter In technischen Tipps von Cisco verwendete Konventionen.

Drops mit IP-RTP-Priorität und LLQ

Der Cisco IOS-Konfigurationsleitfaden warnt vor Ausgabeverlusten mithilfe der folgenden Prioritätswarteschlangenmechanismen:

• ip rtp priority: Da der Befehl ip rtp priority absoluten Vorrang vor anderem Datenverkehr hat, sollte er mit Vorsicht verwendet werden. Wenn der Datenverkehr bei einer Überlastung die konfigurierte Bandbreite überschreitet, wird der gesamte überschüssige Datenverkehr verworfen.

• priority-Befehl und LLQ: Wenn Sie den priority-Befehl für eine Klasse angeben, wird ein Bandbreitenargument verwendet, das die maximale Bandbreite angibt. Bei einer Überlastung werden Pakete mithilfe von Richtlinien bei Überschreitung der Bandbreite verworfen.

Diese beiden Mechanismen verwenden eine integrierte Überwachung, um die Datenverkehrsflüsse zu überwachen. Der Zweck der Richtlinienvergabe besteht darin, sicherzustellen, dass die anderen Warteschlangen vom Scheduler für die Warteschlange verarbeitet werden. Bei der Funktion "cisco original priority queueing", die die Befehle "priority-group" und "priority-list" verwendet, bediente der Scheduler immer zuerst die Warteschlange mit der höchsten Priorität. Befand sich stets Datenverkehr in der Warteschlange mit hoher Priorität, mangelte es den Warteschlangen mit niedrigerer Priorität an Bandbreite und Paketen, die an Warteschlangen ohne Priorität weitergeleitet wurden.

Drops mit Legacy-Prioritätswarteschlange

Priority Queueing (PQ) ist der älteste Prioritätswarteschlangenmechanismus 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 ändert sich die Ausgabewarteschlangenanzeige, wie unten dargestellt. Vor dem Prioritätswarteschlangen verwendet die Ethernet-Schnittstelle eine einzelne Warteschlange mit Ausgabewarteschlange und einer standardmäßigen Warteschlangengröß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 Warteschlangengrenzen, wie in der folgenden 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

Der Befehl priority-list {list-number} wird verwendet, um Datenverkehrsflüsse einer bestimmten Warteschlange zuzuweisen. Wenn die Pakete an einer Schnittstelle eintreffen, werden die Prioritätswarteschlangen an dieser Schnittstelle in absteigender Reihenfolge nach Paketen durchsucht. Die Warteschlange mit hoher Priorität wird zuerst gescannt, dann die Warteschlange mit mittlerer Priorität usw. Das Paket am Anfang der Warteschlange mit der höchsten Priorität wird für die Übertragung ausgewählt. Dieser Vorgang wird bei jedem Senden eines Pakets wiederholt.

Jede Warteschlange wird durch eine maximale Länge oder durch die maximale Anzahl von Paketen definiert, die in der Warteschlange gespeichert werden können. Wenn ein eingehendes Paket dazu führt, dass die aktuelle Warteschlangentiefe den konfigurierten Warteschlangengrenzwert überschreitet, wird das Paket verworfen. Wie oben erwähnt, sind Ausgabeverträge mit PQ in der Regel auf das Überschreiten des Warteschlangenlimits und nicht auf eine interne Richtlinie zurückzuführen, wie es bei LLQ der Fall ist. Der Befehl priority-list list-number queue-limit ändert die Größe einer Prioritätswarteschlange.

Messung des Datenverkehrs mit einem Token-Bucket

LLQ und IP RTP Priority implementieren die integrierte Richtlinienvergabe mithilfe eines Token-Buckets als Datenverkehrsmesssystem. In diesem Abschnitt wird das Konzept des Token-Buckets behandelt.

Ein Token-Bucket selbst hat keine Verwerfungs- oder Prioritätsrichtlinie. Die Token-Bucket-Metapher funktioniert wie folgt:

• 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 Verkehrsregler in der Lage sein, eine Anzahl von Token aus dem Bucket zu entfernen, die der Paketgröße entspricht.

• Wenn nicht genügend Token im Bucket vorhanden sind, 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 Bucket voll ist, werden neu ankommende Token verworfen und stehen zukünftigen Paketen nicht zur Verfügung. Somit ist der größte Burst, den eine Anwendung in das Netzwerk senden kann, zu jeder Zeit in etwa proportional zur Größe des Buckets. Ein Token-Eimer erlaubt Geschmeidigkeit, aber begrenzt sie.

Betrachten wir ein Beispiel mit Paketen und einer Committed Information Rate (CIR) von 8000 bps.

• In diesem Beispiel beginnen die ersten Token-Buckets mit 1000 Byte voll.

• Wenn ein 450-Byte-Paket eingeht, entspricht das Paket den Vorgaben, da genügend Bytes im konformen Token-Bucket verfügbar sind. Das Paket wird gesendet, und 450 Byte werden aus dem Token-Bucket entfernt, sodass 550 Byte verbleiben.

• Wenn das nächste Paket 0,25 Sekunden später eingeht, werden 250 Byte zum Token-Bucket hinzugefügt (0,25 * 8000)/8), sodass 700 Byte im Token-Bucket verbleiben. Wenn das nächste Paket 800 Byte umfasst, überschreitet das Paket die Größe und wird verworfen. Aus dem Token-Bucket werden keine Bytes entnommen.

Fehlerbehebungsschritte zur Diagnose von Verlusten

Schritt 1: Sammeln von Daten

Die Schritte zum Sammeln von Daten sind unten dargestellt.

1. Führen Sie die folgenden Befehle mehrmals aus, und bestimmen Sie, wie schnell und wie oft die Löschvorgänge inkrementiert werden. Verwenden Sie die Ausgabe, um eine Baseline Ihrer Datenverkehrsmuster und Datenverkehrsebenen zu erstellen. Finden Sie heraus, was die "normale" Drop-Rate auf der Schnittstelle ist.

   • Show Queueing-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 Ladewert. Stellen Sie außerdem sicher, dass die Summe der Anzahl der Verwerfungen pro Warteschlange in der Ausgabe der Anzeigeschnittstelle der Anzahl der Verwerfungen bei der Ausgabe entspricht. Der Zähler zum Zurückwerfen von Ausgabedateien für die Anzeige der Schnittstelle sollte die Gesamtsumme aller Auslassungen auf der Ausgabe anzeigen, einschließlich WRED-Verwerfen, Verwerfen aufgrund von Puffermangel ("keine Pufferfehler") und sogar Verwerfen im integrierten Port-Adapter-Speicher.

     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 ungleich null 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 "Pakete zugeordnet" angezeigt. Dieser Zustand zeigt an, dass eine große Anzahl von Paketen verarbeitet wird, oder dass die Schnittstelle extrem überlastet ist. Beide Bedingungen können dazu führen, dass die Warteschlangenbegrenzung einer Klasse überschritten wird, und 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. Charakterisierung der Datenverkehrsflüsse und der Pakete in diesen Flüssen

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

   • In welche Richtung fließt der MTU-große Frame? Viele Datenverkehrsflüsse sind lastabhängig. Bei einem FTP-Download werden beispielsweise die meisten Pakete in MTU-Größe vom FTP-Server an den Client übertragen. Pakete vom FTP-Client zum Server sind einfache TCP ACKs.

   • Verwenden die Pakete TCP oder UDP? TCP ermöglicht es jedem Fluss, eine autorisierte Anzahl von Paketen zu senden, bevor die Quelle die Übertragung unterbrechen und warten muss, bis das Ziel die übertragenen Pakete bestätigt.

3. Bestimmen Sie mit Frame Relay, ob die Verwerfungen in der Schnittstellenwarteschlange oder in einer VC-spezifischen Warteschlange auftreten. Das folgende Diagramm veranschaulicht den Paketfluss durch einen virtuellen Frame-Relay-Schaltkreis:

   

4. Priority Queueing unterstützt bis zu vier Ausgabewarteschlangen, eine pro Prioritätswarteschlangenebene, und jede Warteschlange wird durch eine Warteschlangenbegrenzung definiert. Das Warteschlangensystem vergleicht die Größe der Warteschlange mit dem konfigurierten Warteschlangenlimit, bevor das Paket in eine Warteschlange gestellt wird. Wenn die ausgewählte Warteschlange voll ist, verwirft der Router das Paket. Erhöhen Sie die Warteschlangengröße mit dem Befehl "priority-list {#} queue-limit", und setzen Sie die Überwachung fort.

Schritt 2 - Gewährleistung einer ausreichenden Bandbreite

Mit LLQ ermöglicht die Richtlinienvergabe eine gerechte Behandlung anderer Datenpakete in anderen CBWFQ- (Class-Based Weighted Fair Queuing) oder WFQ-Warteschlangen. Um Paketverluste zu vermeiden, sollten Sie sicherstellen, dass der Prioritätswarteschlange eine optimale Bandbreite zugewiesen wird, wobei Sie die Art des verwendeten Codecs und die Schnittstelleneigenschaften berücksichtigen. Die IP-RTP-Priorität lässt keinen Datenverkehr zu, der über den zugewiesenen Betrag hinausgeht.

Es ist immer am sichersten, der Prioritätswarteschlange etwas mehr Bandbreite zuzuweisen als die bekannte erforderliche Bandbreite. Angenommen, Sie weisen der Prioritätswarteschlange eine Bandbreite von 24 Kbit/s zu (dies ist die Standardmenge für die Sprachübertragung). Diese Zuweisung erscheint sicher, da die Übertragung von Sprachpaketen mit konstanter Bitrate erfolgt. Da das Netzwerk und der Router bzw. Switch jedoch einen Teil der Bandbreite für Jitter und Verzögerungen nutzen können, gewährleistet die Zuweisung von etwas mehr als der erforderlichen Bandbreite (z. B. 25 Kbit/s) Konstanz und Verfügbarkeit.

Die für eine Prioritätswarteschlange reservierte Bandbreite enthält immer den Layer-2-Kapselungsheader. Dies beinhaltet nicht die zyklische Redundanzprüfung (CRC). (Weitere Informationen finden Sie unter Welche Bytes werden von IP gezählt, bis ATM CoS Queueing.) für weitere Informationen.) Obwohl es nur wenige Byte sind, wirkt sich der CRC verstärkt aus, da der Datenverkehr eine größere Anzahl kleiner Pakete umfasst.

Darüber hinaus umfasst die für eine Prioritätswarteschlange zugewiesene Bandbreite an ATM-Schnittstellen nicht den folgenden ATM-Zellensteueraufwand:

• Beliebige Auffüllung durch die Segmentierung und Reassemblierung (SAR), um die letzte Zelle eines Pakets zu einem geraden Vielfachen von 48 Byte zu machen.

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

• ATM-Zellenkopf mit 5 Byte.

Wenn Sie die Bandbreite berechnen, die für eine bestimmte Prioritätsklasse zugewiesen werden soll, müssen Sie berücksichtigen, dass Layer-2-Header enthalten sind. Bei Verwendung von ATM müssen Sie berücksichtigen, dass der Steueraufwand für ATM-Zellen nicht berücksichtigt wird. Sie müssen außerdem Bandbreite für die Möglichkeit von Jitter zulassen, der von Netzwerkgeräten im Sprachpfad verursacht wird. Weitere Informationen finden Sie im Überblick über die Warteschlangenfunktion mit niedriger Latenz.

Wenn Sie Prioritätswarteschlangen zum Übertragen von VoIP-Paketen verwenden, lesen Sie Voice over IP - Per Call Bandwidth Consumption (VoIP-Bandbreitennutzung 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 im Token-Bucket verbleibenden Bytes ab. Es ist wichtig, die Merkmale des Datenverkehrsflusses zu berücksichtigen, der an die Prioritätswarteschlange weitergeleitet wird, da LLQ eine Überwachung und keinen Shaper verwendet. Ein Policer verwendet einen Token-Bucket wie folgt:

• Der Bucket 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 der Token-Bucket wird dekrementiert. Andernfalls wird das Paket verworfen.

Der Burst-Standardwert der Token-Bucket-Datenverkehrsanzeige von LLQ wird mit der konfigurierten Bandbreitenrate als 200 Millisekunden Datenverkehr berechnet. In einigen Fällen ist der Standardwert unzureichend, insbesondere wenn TCP-Datenverkehr in die Prioritätswarteschlange gelangt. TCP-Datenflüsse treten in der Regel sprunghaft auf und erfordern u. U. eine Spitzen-Größe, die größer ist als die vom Warteschlangensystem zugewiesene Standardgröße, insbesondere bei langsamen Verbindungen.

Die folgende Probenleistung wurde auf einem ATM-PVC mit einer kontinuierlichen Zellrate von 128 kbps erzeugt. Das Warteschlangensystem passt die Burst-Größe an, wenn 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 Configuring Burst Size in Low Latency Queueing Funktion zu ermöglichen. Mit dieser neuen Funktion kann das Netzwerk nun zeitweilige Spitzen im Datenverkehr bewältigen und den Netzwerkverkehr effizienter verarbeiten.

Verwenden Sie den Burst-Parameter mit dem priority-Befehl, 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, die von der Prioritätsklasse verwendet werden kann, und kann den Anschein erwecken, dass die Prioritätsklassen mehr als ihren fairen Anteil an der Bandbreite erhalten.

Außerdem wies das Warteschlangensystem der Warteschlange mit niedriger Latenz ursprünglich eine interne Warteschlangenbegrenzung von 64 Paketen zu. In einigen Fällen, wenn ein Burst von 64 Paketen in der Prioritätswarteschlange eingeht, bestimmt die Datenverkehrsanzeige, dass der Burst der konfigurierten Rate entspricht, aber die Anzahl der Pakete die Warteschlangengrenze überschreitet. Daher wurden einige Pakete per Tail verworfen. Die Cisco Bug-ID CSCdr51979 (nur für registrierte Kunden) löst dieses Problem, indem sie die Größe der Prioritätswarteschlange auf die vom Datenverkehrszähler zugelassene Größe anpasst.

Die folgende Ausgabe wurde auf einem Frame-Relay-PVC mit einer CIR von 56 Kbit/s erfasst. Im ersten Satz der Sample-Ausgabe 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 Abwurfraten nicht die tatsächlichen Übertragungsraten darstellen und keine Pakete enthalten, die sich vor der Übertragung im Shaper befinden.

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 diesem zweiten Ausgabesatz haben sich die Schnittstellenzähler für die Richtlinienzuordnung anzeigen normalisiert. Auf der 56-Kbit/s-PVC sendet die Klasse c1 ca. 50 Kbit/s und die Klasse c2 ca. 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 - Debugging-Priorität

Der Befehl debug priority (Debugpriorität) zeigt die Ausgabe der Prioritätswarteschlange an, wenn Pakete aus der Prioritätswarteschlange verworfen werden.

Vorsicht:  Lesen Sie den Artikel Important Information on Debug Commands (Wichtige Informationen zu Debug-Befehlen), bevor Sie debug-Befehle verwenden. Der Befehl debug priority druckt möglicherweise eine große Menge an Ausgabe von Disruptive Debugs auf einem Produktionsrouter aus. Die Höhe der Überlastung 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 Ausgabe der Debugpriorität gibt 64 die tatsächliche Tiefe der Prioritätswarteschlange 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

Andere Ursachen für Drops

Das Cisco Technical Assistance Center (TAC) hat bei der Fehlerbehebung die folgenden Gründe für verworfene Ausgaben mit LLQ ermittelt und in einem Cisco Fehlerbericht dokumentiert:

• Durch Erhöhen der WRED-Schwellenwerte (Weighted Random Early Detection) für eine andere Klasse wurden die verfügbaren Puffer verbraucht und die Prioritätswarteschlange verworfen. Um dieses Problem zu diagnostizieren, ist für eine zukünftige IOS-Version ein Zähler für das "No-Buffer-Drops" für die Prioritätsklasse geplant.

• Wenn die Warteschlangengrenze der Eingangsschnittstelle kleiner ist als die Warteschlangengrenze der Ausgangsschnittstelle, wird das Paket an die Eingangsschnittstelle übertragen. Diese Symptome sind in Cisco Bug-ID CSCdu89226 dokumentiert (nur für registrierte Kunden). Lösen Sie dieses Problem, indem Sie die Größe der Eingabewarteschlange und der Ausgabewarteschlange anpassen, um Eingabefehler zu verhindern und zu ermöglichen, dass der Mechanismus für ausgehende Prioritätswarteschlangen wirksam wird.

• Das Aktivieren einer Funktion, die im CEF-Switched- oder Fast-Switched-Pfad nicht unterstützt wird, führt dazu, dass eine große Anzahl von Paketen verarbeitet wird. Mit LLQ werden prozessgesteuerte Pakete derzeit überwacht, unabhängig davon, ob die Schnittstelle überlastet ist. Mit anderen Worten: Selbst wenn die Schnittstelle nicht überlastet ist, misst das Warteschlangensystem prozessgesteuerte Pakete und stellt sicher, dass die angebotene Last den mit dem Prioritätsbefehl konfigurierten Bandbreitenwert nicht überschreitet. Dieses Problem ist dokumentiert in Cisco Bug-ID CSCdv86818 (nur registrierte Kunden) .

Verworfene Prioritätswarteschlangen und Frame-Relay

Frame Relay ist ein Sonderfall in Bezug auf das Policing der Prioritätswarteschlange. In der Funktionsübersicht Low Latency Queueing für Frame Relay wird der folgende Vorbehalt aufgezeigt: "Der PQ wird überwacht, um sicherzustellen, dass den fairen Warteschlangen nicht die Bandbreite ausgeht. Bei der Konfiguration der PQ geben Sie die maximale Bandbreite in Kbit/s an, die dieser Warteschlange zur Verfügung steht. Pakete, die dieses Maximum überschreiten, werden verworfen." Anders ausgedrückt: Ursprünglich wurde die Prioritätswarteschlange einer in einer Frame-Relay-Zuordnungsklasse konfigurierten Dienstrichtlinie in Zeiten von Überlastung und Nicht-Überlastung geregelt. IOS 12.2 entfernt diese Ausnahme. PQ wird weiterhin mit FRF.12 geregelt, aber andere nicht konforme Pakete werden nur verworfen, wenn eine Überlastung vorliegt.

Zugehörige Informationen

• QoS-Support-Seite
• Modul: Cisco IOS Software Release 12.2 Traffic Policing-Funktion
• Technischer Support – Cisco Systems