Verstehen von Warteschlangenbeschränkungen und Ausgabeverlusten auf Cisco IOS-Softwareplattformen

Einführung

Dieses Dokument gilt nur für Cisco IOS® Softwareplattformen, die im Allgemeinen Router der Serien Cisco 7200VXR und Cisco ISR 3800, 2800 und 1800 sowie ältere Cisco Access Router einschließlich 3700, 3600, 2600 und 170 umfassen. Router der Serie 0.

Voraussetzungen

Anforderungen

Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:

• Konfigurationsleitfaden für Quality of Service-Lösungen von Cisco IOS

• QoS - Hierarchical Queueing Framework (HQF)

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf den folgenden Softwareversionen:

• Für Pre-HQF: Cisco Router mit Cisco IOS Software Release 12.3(26)

• Für HQF: Cisco Router mit Cisco IOS Software-Version 12.4(22)T

Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Konventionen

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

Klassenbasiertes Weighted Fair Queueing Primer

In IOS-Images vor der HQF wird in der Regel jede Klasse mit einem Bandbreitenbefehl gegenüber Klassen ohne Bandbreite oder Priorität basierend auf dem Gewicht der Klassen priorisiert. Um den CBWFQ-Scheduling-Algorithmus (Class-Based Weighted Fair Queueing) zu verstehen, müssen Sie zunächst das Konzept eines Gewichts verstehen, das für Flow Based Fair Queues (Flow-Based Fair-Warteschlangen) und Class-Specific (Class Based Weighted Fair Queue) für einzelne klassenbasierte Warteschlangen Flow-spezifisch ist.

Die Formel zur Ableitung des Gewichts für eine Flow-Based Fair Queue lautet:

32384 / (IP Prec + 1)

Benutzerdefinierte Klassen in einer klassenbasierten Weighted Fair-Warteschlange leiten ihre jeweiligen Gewichte als Funktion des in der Klasse konfigurierten Bandbreitenbefehls als Teil des SUM aller Bandbreitenklassen in der Class Based Queue ab. Die genaue Formel ist urheberrechtlich geschützt.

In HQF-Images werden Flow-basierte Fair-Queues, die sowohl in benutzerdefinierten Klassen als auch in Klassenstandardwerten mit Fair-Queue konfigurierbar sind, gleich geplant (anstelle von Weight). Darüber hinaus wird in HQF die Planungspriorität einer klassenbasierten Warteschlange basierend auf dem HQF-Scheduler und nicht auf der Legacy Weight-Formel der Klassen bestimmt.

Hinweis: Dieser Abschnitt ist nicht als umfassende Verhaltensanalyse für klassenbasierte Warteschlangenvorgänge vorgesehen. Hierbei handelt es sich um eine kurze Schulung, da die CBWFQ für das Verständnis von Warteschlangengrenzen und Ausgabeverlusten gilt.

Verstehen von Warteschlangengrenzen und Ausgabeverlusten

Benutzerdefinierte Klassen, die mit dem Befehl "priority" konfiguriert wurden

Für benutzerdefinierte MQC-Klassen, die mit einer beliebigen Variante des Priority-Befehls konfiguriert sind, einschließlich Priority, Priority <kbps> und Priority%.

Verhalten vor HQF

Obwohl keine CLI vorhanden und nicht konfigurierbar ist, existiert eine "versteckte" Systemwarteschlange, die von allen Daten der Prioritätsklasse gemeinsam genutzt wird. Diese Funktion dient als Holdingbereich für Prioritätsdaten, nachdem sie klassifiziert wurden und von der überlastungssensitiven Polizei zugelassen wurden. LLQ-Pakete werden in diese "versteckte" Systemwarteschlange gestellt, wenn sie nicht direkt im Übertragungsring der Ausgangsschnittstelle während des Empfangs-Interrupts platziert werden können, der auch als funktionale Überlastung bezeichnet wird. Da in dieser Situation funktionale Überlastungen bestehen, wird das Paket während des Empfangs-Interrupt anhand der LLQ-bedingten Richtlinien ausgewertet, obwohl es noch im Besitz des Treibers der empfangenden Schnittstelle ist. Wenn das Paket nicht durch den bedingten Policer der LLQ verworfen wird, wird es in diese "versteckte" LLQ-Systemwarteschlange gestellt, und der Empfangs-Interrupt wird freigegeben. Aus diesem Grund haben alle in dieser "versteckten" Systemwarteschlange platzierten Pakete die Richtlinie für die überlastungssensitive LLQ erfüllt und werden sofort vom LLQ/CBWFQ-Scheduler in die Warteschlange zum Übertragungsring der Ausgangsschnittstelle dewartbar gemacht.

Trotz der Existenz dieser Warteschlange ist das Verhalten anders als bei IOS-Warteschlangen, die für nicht-LLQ-Daten erstellt wurden (z. B. Fair-Queue und Bandbreitenwarteschlangen), da keine zusätzliche Warteschlangenlatenz (oberhalb der Übertragungs-Ring-Latenz) entsteht, da die Pakete in dieser Warteschlange vom LLQ/CBWFQ-Scheduler sofort in den Übertragungsring geleitet werden. Wenn ein Prioritätsklassenpaket während des Empfangs-Interrupts nicht von der bedingten Richtlinie verworfen wird, existiert dieses LLQ-Paket kurz in dieser "versteckten" Systemwarteschlange, bevor es in die Warteschlange zum Übertragungsring der Ausgangsschnittstelle dewartbar wird. In diesem Fall zeigt der LLQ/CBWFQ-Planer das Paket sofort an den Übertragungsring der Ausgangsschnittstelle an. Der Conditional Policer wurde ausgeführt, bevor das Paket für die LLQ/CBWFQ zugelassen wurde. Dadurch wird die LLQ auf die konfigurierte Prioritätsrate beschränkt.

Zusammenfassend wird empfohlen, LLQ-Daten, die die Prioritätsrate in Zeiten von Überlastung überschreiten, zu löschen, anstatt zusätzliche Latenz bei der Warteschlangenverwaltung zu verursachen. Dies ist eine grundlegende Komponente von LLQ. Dieser bedingte Richtlinienmechanismus ermöglicht eine Warteschlange mit strikter Priorität, ohne dass die Prioritätswarteschlange die Monopolisierung des gesamten Schnittstellen-PLIM zulässt. Dies ist eine Verbesserung gegenüber der älteren Prioritätswarteschlangen-Funktion von IOS.

• Warteschlangenlimit vor HQF: NA

• Vor HQF "priority" (Priorität) + "random-detect"-Verhalten: NA, WRED in LLQ nicht zulässig.

• Vor HQF "priority" (Priorität) + "fair queue" (faires Warteschlangenverhalten): NA, Fair-Queue in LLQ nicht zulässig.

• Vor HQF "priority" (Priorität) + "random-detect" + "fair-queue"-Verhalten: NA, weder Fair-Queue noch Random-Detection unterstützt in LLQ.

HQF-Verhalten

Wie vor HQF, außer die versteckte Warteschlange ist nicht mehr verborgen, die Warteschlangenbeschränkung ist jetzt konfigurierbar und beträgt standardmäßig 64 Pakete.

• HQF-Warteschlangenlimit: 64 Pakete

• HQF "priority" (Priorität) + "random-detect"-Verhalten: NA, WRED in LLQ nicht zulässig.

• HQF "priority" (Priorität) + "fair queue" (faires Warteschlangenverhalten): NA, Fair-Queue in LLQ nicht zulässig.

• HQF "priority" (Priorität) + "random-detect" + "fair-queue"-Verhalten: NA, weder Fair-Queue noch Random-Detection unterstützt in LLQ.

Benutzerdefinierte Klassen, konfiguriert mit dem Befehl "bandwidth"

Für benutzerdefinierte MQC-Klassen, die mit einer beliebigen Variante des Bandbreitenbefehls konfiguriert sind, einschließlich Bandbreite <kbps>, Bandbreitenprozentsatz und Bandbreitenverbleibprozentsatz.

Verhalten vor HQF

Die Standardgrenze für Warteschlangen ist 64 Pakete, die einstellbar sind. Wenn Sie während des Empfangs-Interrupt ein Paket in die Warteschlange stellen müssen, das > 64 Pakete in der Warteschlange enthalten würde, wird das Paket als Tail verworfen.

• Warteschlangenlimit vor HQF: 64 Pakete, einstellbar über Warteschlangenlimit.

• Verhalten vor HQF "Bandbreite" + "willkürliche Erkennung":

  Beispiel:

  policy-map PRE_HQF_BANDWIDTH_WRED
   class 1
     bandwidth 32
     random-detect

  Wenn eine beliebige Variante der Bandbreite zusammen mit einer beliebigen Variante der zufälligen Erkennung konfiguriert wird, ignorieren Sie jede CLI mit Warteschlangenbegrenzung, die praktisch alle Puffergrenzen in der Klasse entfernt. Anders ausgedrückt schließen sich Zufallserkennungs- und Warteschlangenbegrenzungen in Bildern vor der HQF gegenseitig aus. Wenn die aktuelle Warteschlangengröße mithilfe von "random detect as drop" als Drop-Strategie verwendet wird, ist sie nicht beschränkt und kann theoretisch jeden Puffer belegen, der der klassenbasierten Fair-Queue zugewiesen wurde. Hierbei wird die Anzahl der Puffer, die der klassenbasierten Fair-Queue zugewiesen wurden, basierend auf dem Attach für Service-Richtlinien abgeleitet:

  • Physische Schnittstelle: 1000 Pakete, einstellbar mit CLI-Hold-Queue-Out

  • ATM-PVC: 500 Pakete, einstellbar mit PVC CLI VC-Hold-Queue

  • Frame-Relay-Zuordnungsklasse: 600 Pakete, einstellbar mit Frame-Relay Map-Class CLI Frame-Relay Holdq

  • Klassenbasierte Shaping-Richtlinie angewendet auf (Sub-)Schnittstelle (vor HQF): 1000 Pakete, einstellbar mit CLI der MQC-Klasse, gestalten max-buffers.

  Hinweis: Bei allen Frame-Relay- und Class-Based-Shaping-Beispielen wird davon ausgegangen, dass die Summe der Shaper die Taktfrequenz der Schnittstelle nicht überschreitet.

  Hinweis: Achten Sie bei Bildern vor HQF, wenn eine Class-Based Shaping-Richtlinie auf eine (Sub-)Schnittstelle angewendet wird, auf die Geschwindigkeit der zugrunde liegenden physischen Schnittstelle, da die Schnittstellen <2Mbit/s standardmäßig auf eine Weighted Fair Queue (Weighted Fair-Warteschlange) umgestellt werden und Schnittstellen >2Mbit/s FIFO als Standardeinstellung verwenden. Vor dem HQF leitet die Shaping-Warteschlange die Warteschlange für die Warteschlange für die Warteschleife der Schnittstellen ein, unabhängig davon, ob die Shaping-Richtlinie an die Subschnittstelle oder die Ebene der physischen Schnittstelle angefügt ist.

  Während des Empfangs-Interrupt wird jedes Mal, wenn ein Paket zur Kandidatin für die Ausgabewarteschlange einer Schnittstelle wird, die durchschnittliche WRED-Warteschlangengröße mit dieser Formel berechnet:

  Average Queue Size = (old_average * (1-1/2^n)) + (current_queue_size * 1/2^n)

  Wenn die resultierende durchschnittliche Warteschlangengröße:

  • Kleiner als der WRED-Mindestschwellenwert, stellen Sie die Warteschlange für das Paket ein, und lassen Sie den Empfangs-Interrupt los.

  • Zwischen dem WRED-Min.-Schwellenwert und dem WRED-Max-Schwellenwert kann das Paket mit höherer Wahrscheinlichkeit verworfen werden, da die durchschnittliche Warteschlangengröße näher am WRED-Max-Schwellenwert liegt. Wenn die durchschnittliche Warteschlangengröße genau der WRED-max-threshold entspricht, wird das Paket entsprechend dem Nennwert der Wahrscheinlichkeit verworfen. Der Nennwert für die Wahrscheinlichkeit der Markierung dient außerdem als Ausgangsbasis, um zu bestimmen, welcher Prozentsatz der Pakete verworfen wird, wenn der Grenzwert für die durchschnittliche Warteschlange nicht genau dem maximalen WRED-Schwellenwert entspricht, sondern über dem WRED-Mindestwert liegt. Dies ist ein grafisches Beispiel:

    

    Wenn das Paket verworfen wird, wird der Empfangs-Interrupt freigegeben und ein Random-Drop erhöht. Wenn das Paket nicht verworfen wird, wird das Paket in die Warteschlange gestellt, und der Empfangs-Interrupt wird freigegeben.

  • Höher als der maximale WRED-Schwellenwert, verwerfen Sie das Paket, geben Sie den Empfangsinterrupt frei und inkrementieren Sie einen Tail Drop.

• Hinweis: IP Precedence-basiert (Standard) und DSCP-basiertes WRED ermöglichen eine unterschiedliche Definition des Min-Schwellenwert, des max-threshold und des Mark-Wahrscheinlichkeitsbezeichner für verschiedene Werte. Hier wird die Weighted-Komponente der Random Early Detection angezeigt. Sie können bestimmte ToS-Werte im Vergleich zu anderen Werten schützen, indem Sie deren relative Schwellenwerte abstimmen und Wahrscheinlichkeitsnenner markieren.

  Wenn willkürliche Erkennungs- und Bandbreitenvorgänge zusammen konfiguriert werden, kann die Current Queue Size zu einem beliebigen Zeitpunkt größer sein als der maximale WRED-Grenzwert. Der Grund hierfür ist, dass die Mindest- und Höchstwerte für WRED nur auf Basis der durchschnittlichen (nicht aktuellen) Warteschlangengröße aktiv werden. Dies bietet die Möglichkeit, alle der Class-Based-Warteschlange zugewiesenen Puffer zu löschen. Dies kann dazu führen, dass an einer beliebigen Stelle innerhalb der Class-Based-Fair-Warteschlange keine Puffer verloren gehen (siehe Cisco Bug-ID CSCsm94757).

• "Bandbreite" vor HQF + "Fair-Queue"-Verhalten: NA, Fair-Queue nicht erlaubt in der Bandbreitenklasse.

• Vor HQF "Bandbreite" + "Zufallserkennung" + "Fair-Queue"-Verhalten: NA, Fair-Queue ist in der Bandbreitenklasse nicht zulässig.

HQF-Verhalten

Das Verhalten entspricht dem, was im Abschnitt vor HQF beschrieben wird.

• HQF-Warteschlangenlimit: 64 Pakete, einstellbar über Warteschlangenlimit.

  Dies entspricht dem vor dem HQF.

• HQF-Verhalten "Bandbreite" + "Zufallserkennung":

  Beispiel:

  policy-map HQF_BANDWIDTH_WRED
   class 1
     bandwidth 32
     queue-limit 512
     random-detect

  Hinweis: Die Standardgrenze für Warteschlangen ist 64 Pakete.

  Das Verhalten entspricht dem des entsprechenden Abschnitts vor HQF, mit einer wichtigen Ausnahme. In HQF-Images können zufällige Erkennungs- und Warteschlangenbegrenzungen gleichzeitig in derselben benutzerdefinierten Klasse (oder Klassenklassenstandard) vorhanden sein, und der Warteschlangenlimit wird in einer Standardkonfiguration aktiviert und auf 64 Pakete eingestellt. Als solche dient der Warteschlangenlimit als maximale aktuelle Warteschlangengröße in einer willkürlich erkannten Klasse und bietet somit einen Mechanismus zur Begrenzung von nicht pufferbaren Verlusten, die im entsprechenden Abschnitt vor der HQF erörtert werden. Aufgrund dieser Hinzufügung muss der konfigurierte Warteschlangenlimit mindestens so groß sein wie der willkürlich ermittelte max-threshold, wobei der Max-Grenzwert für "random-detect" standardmäßig auf 40 Pakete festgelegt wird, oder der Parser lehnt die Konfiguration ab.

  Dadurch wird eine Grenzwertprüfung für aktuelle Warteschlangen in WRED-Klassen eingeführt, bei der, selbst wenn die Berechnung der durchschnittlichen Warteschlangentiefe kleiner als der max. Grenzwert ist, die Current (not Average) Queue Size größer als die Warteschlangengrenze ist, das Paket verworfen, der Empfangsinterrupt freigegeben und ein Tail Drop aufgezeichnet wird. Wenn der Warteschlangenlimit ausreichend hoch eingestellt ist, um die aggregierten Warteschlangenpuffer für die Class-Based Queue auszuschöpfen, können weiterhin Pufferverluste auftreten. Aggregierte Warteschlangenpuffer für HQF werden hier definiert:

  • Physische Schnittstelle: 1000 Pakete, einstellbar mit CLI-Hold-Queue-Out

  • ATM-PVC: 500 Pakete, einstellbar mit PVC CLI VC-Hold-Queue

  • Frame-Relay-Zuordnungsklasse: 600 Pakete, einstellbar mit Frame-Relay Map-Class CLI Frame-Relay Holdq

  • Klassenbasierte Shaping-Richtlinie für physische Schnittstellen im HQF-Code: 1.000 Pakete, einstellbar mit einer Kombination aus CLI-Hold-Queue-Out und Child Policy Queue-Limit, wobei die Obergrenze für die untergeordnete Richtlinie Warteschlange eine Obergrenze für die Warteschlange der Schnittstellen-Haltewarteschlangen enthält.

  • Klassenbasierte Shaping-Richtlinie, die auf die Subschnittstelle im HQF-Code angewendet wird: 512 Pakete, nicht einstellbar (Untersuchung mit NSSTG QoS-Plattform-Team, falls einstellbar)

    Hinweis: Bei allen Frame-Relay- und Class-Based-Shaping-Beispielen wird davon ausgegangen, dass die Summe der Shaper die Taktfrequenz der Schnittstelle nicht überschreitet.

    Hier ein Beispiel aus der Praxis:

    policy-map JACKLYN
     class 1
        bandwidth 64
        queue-limit 500 packets
         random-detect
         random-detect precedence 1 22 300

    Während dieser Ausgabe wird kein Datenverkehr über die Schnittstelle generiert:

    F340.11.25-7200-5_LAC#show policy-map interface | i queue      
          queue limit 500 packets
          (queue depth/total drops/no-buffer drops) 0/387595/0
    
    !--- Current_q_depth is 0
    
            Mean queue depth: 107 packets
    
    !--- last calculation of Average_queue_depth
    
    

    An diesem Punkt wird der Datenverkehr gestartet. Der Stream ist bei 400 PPS unbursty, bestehend aus 1000-Byte-Frames:

    F340.11.25-7200-5_LAC#show policy-map interface | i queue
          queue limit 500 packets
          (queue depth/total drops/no-buffer drops) 461/387641/0
    
    !--- 461 is Current_q_depth > Prec 1 max-thresh of 300 !--- but < "queue-limit 500 packets".
    
            Mean queue depth: 274 packets
    
    !--- Avg_q_depth is rising, Mark Prob Denom is being used.
    
      
    F340.11.25-7200-5_LAC#show policy-map interface | i queue
          queue limit 500 packets
          (queue depth/total drops/no-buffer drops) 363/387919/0
    
    !--- 363 is Current_q_depth and it is falling compared to last !--- iteration because WRED is random dropping packets.
    
            Mean queue depth: 351 packets
    
    !--- Avg_q_depth is now above max_thresh, WRED starts to tail-drop !--- in addition to random-drop.
    
       
    F340.11.25-7200-5_LAC#show policy-map interface | i queue
          queue limit 500 packets
          (queue depth/total drops/no-buffer drops) 199/388263/0
            Mean queue depth: 312 packets
      
    F340.11.25-7200-5_LAC#show policy-map interface | i queue
          queue limit 500 packets
          (queue depth/total drops/no-buffer drops) 303/388339/0
            Mean queue depth: 276 packets
        
    F340.11.25-7200-5_LAC#show policy-map interface | i queue
          queue limit 500 packets
          (queue depth/total drops/no-buffer drops) 325/388498/0
            Mean queue depth: 314 packets
    
    F340.11.25-7200-5_LAC#show policy-map interface | i queue
          queue limit 500 packets
          (queue depth/total drops/no-buffer drops) 298/390075/0
            Mean queue depth: 300 packets

    Beachten Sie, dass bei einem nicht-bursty-Stream die WRED Average Queue-Tiefe schließlich der Current Queue Depth entspricht, d. h. dem erwarteten Verhalten.

• HQF "Bandbreite" + "Fair-Queue"-Verhalten:

  Wenn Bandbreite und Fair-Queue zusammen auf eine HQF User Defined-Klasse angewendet werden, wird jeder Flow-basierten Warteschlange ein Warteschlangenlimit von 0,25 * Warteschlangenlimit zugewiesen. Da der Grenzwert für die Standardwarteschlange 64 Pakete beträgt, werden jeder Flow-basierten Warteschlange in einer fairen Warteschlange 16 Pakete zugewiesen. Wenn vier Datenflüsse diese Klasse durchlaufen, würde jede Datenfluss-Warteschlange standardmäßig 16 Pakete enthalten. Daher würden Sie nie erwarten, dass die Gesamtpakete in die Warteschlange >64 (4 x 16) gestellt werden. Alle Tail-Drops aus einer einzelnen Flow-Queue werden als FlowDrop aufgezeichnet. Wenn die Anzahl der Datenfluss-Warteschlangen ebenso wie die Warteschlangengrenze signifikant hoch war, besteht eine weitere Möglichkeit für ein Verwerfen ohne Puffer. Angenommen, der Richtlinie-Attach-Point ist eine physische Schnittstelle, der 1000 aggregierte Puffer zugewiesen werden:

  policy-map TEST
   class 1
    bandwidth 32
    fair-queue 1024
    queue-limit 128

  In dieser Konfiguration kann bei einem spürbaren Datenverkehr in allen Datenfluss-Warteschlangen aggregierte Schnittstellenpuffer ausfallen und bei anderen benutzerdefinierten Klassen (siehe Cisco Bug-ID CSCsw98427) zum Verwerfen ohne Puffer führen. Das liegt daran, dass 1024 Flow-Warteschlangen, von denen jede mit einem Grenzwert von 32 Paketwarteschlangen ausgestattet ist, die 1000 aggregierte Class Based Queuing-Pufferzuweisung für die Schnittstelle leicht überschreiben können.

• HQF "bandwidth" + "random-detect" + "fair-queue" Verhalten:

  Beispiel:

  policy-map TEST
   class 1
    bandwidth 32
    fair-queue 1024
    queue-limit 128
    random-detect

  Wie Bandbreite und Fair-Queue im Abschnitt, mit Ausnahme der WRED Average Queue Size (Durchschnittliche WAN-Warteschlangengröße) wird jedes Mal berechnet, wenn ein Paket eintrifft, um zu entscheiden, ob das Paket zufällig verworfen oder verworfen werden soll. Wie bei HQF vor der Ausführung teilen sich alle Datenfluss-Warteschlangen eine Instanz der WRED-Schwellenwerte, d. h. alle in alle Datenfluss-Warteschlangen eingestellten Pakete werden zur Berechnung der WRED-Durchschnittl. Warteschlangentiefe verwendet. Bei der Dropdown-Entscheidung werden die Mindest- und Höchstschwellen für WRED auf die aggregierten Pakete in allen Datenflusswarteschlangen angewendet. Eine weitere Abweichung von Bandbreite und Fair-Queue im Abschnitt, da eine Instanz von WRED-Schwellenwerten für alle Flow-basierten Warteschlangen gilt, wird der Warteschlangengrenzwert der einzelnen Flow-Queues (.25 * "queue-limit") ignoriert und stattdessen der Grenzwert für die aggregierte Warteschlangengrenze der Klassen für eine Current Queue Limit-Prüfung beachtet.

Standardverhalten der Klasse

Verhalten vor HQF

Vor HQF, Class Default (Klassenstandard) ist auf Fair-Queue (Fair-Queue) festgelegt, verwenden alle Flow-Warteschlangen das Warteschlangenlimit für die Klasse (Standardwert ist 64), und es gibt keine Bandbreitenreservierung. Mit anderen Worten, die Gesamtzahl der Pakete, die in allen Datenfluss-Warteschlangen in die Warteschlange aufgenommen werden, überschreitet nie die Warteschlangengrenze. Die Anzahl der in jeder Flow-Warteschlange eingestellten Pakete hängt vom berechneten Gewicht der Flow-Warteschlange ab. Wenn Fair-Queue und Random-Detection hingegen in der Klassenstandardeinstellung zusammen verwendet werden, wird der Warteschlangenlimit ignoriert, und alle Flow-Warteschlangen haben dieselben WRED-Schwellenwerte. Daher werden alle Pakete, die derzeit in allen Flow-Warteschlangen in die Warteschlange gestellt werden, zur Berechnung der durchschnittlichen WRED-Warteschlangengröße verwendet. Da die aktuelle Warteschlangengröße in dieser Konfiguration keine Obergrenze aufweist, besteht eine hohe Chance für Verwerfen ohne Puffer (siehe Cisco Bug ID CSCsm94757).

• Das Hinzufügen von Bandbreite zur Klassenstandardeinstellung führt zu einem Verhalten, das im Pre-HQF Behavior - User Defined Classes Configured with the "bandwidth" Command (Benutzerdefinierte Klassen, konfiguriert mit dem Abschnitt "Bandbreite") beschrieben wird.

• Das Hinzufügen von Bandbreite und zufälliger Erkennung zur Klassenstandard-Standardeinstellung führt zu einem Verhalten, das im Abschnitt "Bandbreite vor HQF" + "willkürlich erkenntes Verhalten" des Pre-HQF-Verhaltens beschrieben wird - Benutzerdefinierte Klassen, die mit dem Befehl "Bandbreite" konfiguriert werden.

Hinweis: Vor HQF kann Bandbreite nicht gleichzeitig mit Fair-Queue in Class-default vorhanden sein.

HQF-Verhalten

In HQF wird Class Default auf eine FIFO-Warteschlange festgelegt und eine Pseudo-Bandbreitenreservierung zugewiesen, die auf den verbleibenden Zuweisungen aus benutzerdefinierten Klassen basiert. Daher finden Sie für das Standardverhalten der HQF-Klasse Informationen zum HQF-Verhalten - Benutzerdefinierte Klassen, die mit dem Abschnitt "Bandbreite" konfiguriert sind. Unabhängig von der Konfiguration verfügen Klassenstandardwerte in HQF-Images immer über eine implizite Bandbreitenreservierung, die der ungenutzten Schnittstellenbandbreite entspricht, die von benutzerdefinierten Klassen nicht belegt wird. Standardmäßig erhält die Klasse-Standardklasse mindestens 1 % der Bandbreite der Schnittstelle oder übergeordneten Form. Die CLI der Bandbreite kann auch explizit in der Klassenstandardeinstellung konfiguriert werden.

• Wenn Fair-Queue in Class-Default konfiguriert wird, stimmt das Verhalten mit dem HQF-Abschnitt "Bandbreite" + "Fair-Queue" des HQF-Verhaltens überein - Benutzerdefinierte Klassen, die mit dem Befehl "Bandbreite" konfiguriert wurden.

• Wenn Fair-Queue und Random-Detection zusammen in Class-Default konfiguriert werden, entspricht das Verhalten dem HQF-Abschnitt "Bandbreite" + "Zufallserkennung" + "Fair-Queue" des HQF-Verhaltens - Benutzerdefinierte Klassen, die mit dem Befehl "Bandbreite" konfiguriert werden.

Zugehörige Informationen

• Cisco IOS-Konfigurationsleitfaden für Quality of Service-Lösungen, Version 12.2SR
• QoS - Hierarchical Queueing Framework (HQF)
• QoS-Technologieunterstützung
• Produkt-Support für Router
• Technischer Support und Dokumentation - Cisco Systems