Kenntnis der Warteschlangengrenzen und Ausgabeverringerungen auf IOS-Softwareplattformen

Einleitung

In diesem Dokument werden Warteschlangenbegrenzungen und Output Drops auf Cisco IOS®-Softwareplattformen und älteren Access Routern beschrieben.

Voraussetzungen

Anforderungen

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

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

• QoS - Hierarchical Queueing Framework (HQF)

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf folgenden Software-Versionen:

• Für vor dem HQF: Cisco Router mit Cisco IOS Software-Version 12.3(26)

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

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle verstehen.

Konventionen

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

Hintergrundinformationen

Dieses Dokument gilt nur für Cisco IOS® Software-Plattformen, die im Allgemeinen Cisco Router der Serien 7200VXR und 3800, 2800 und 1800 sowie ältere Cisco Access Router, darunter 3700, 3600, 2600 und 1700, umfassen. Routern.

Klassenbasierter Weighted Fair Queueing-Primer

In Cisco IOS-Images vor HQF kann jede Klasse mit einem bandwidth -Befehls kann in der Regel anhand von Klassen ohne Bandbreite oder Priorität priorisiert werden, die auf dem Gewicht der Klassen basieren. Um den CBWFQ-Terminierungsalgorithmus (Class-Based Weighted Fair Queueing) zu verstehen, müssen Sie zunächst das Konzept einer Gewichtung verstehen, die flussspezifisch für Flow-Based Fair Queues und klassenspezifisch für einzelne Class-Based Queues innerhalb der Class-Based Weighted Fair Queue ist.

Die Formel zum Ableiten der Gewichtung für eine Flow Based Fair Queue lautet:

32384 / (IP Prec + 1)

Benutzerdefinierte Klassen innerhalb einer klassenbasierten Weighted Fair-Warteschlange leiten ihre jeweiligen Gewichtungen in Abhängigkeit von den bandwidth -Befehl, der in der Klasse als Anteil an der Summe aller Bandbreitenklassen in der klassenbasierten Warteschlange konfiguriert wird. Die genaue Formel ist proprietär.

In HQF-Images werden Flow-basierte Fair-Queues, die sowohl in benutzerdefinierten Klassen als auch in Klassenstandardwerten mit Fair-Queue konfigurierbar sind, zu gleichen Teilen (nicht nach Gewicht) geplant. Darüber hinaus wird in HQF die Scheduling-Priorität einer Class Based Queue basierend auf dem HQF-Scheduler und nicht basierend auf der Legacy-Gewichtungsformel der Klassen bestimmt.

Hinweis: Dieser Abschnitt ist nicht als umfassende Verhaltensanalyse für Class Based Queueing-Vorgänge gedacht. Dadurch soll erklärt werden, wie CBWFQ Warteschlangenbegrenzungen anwendet und Ausgabeverringerungen durchführt.

Verstehen von Warteschlangengrenzen und Ausgabeverringerungen

Mit dem Befehl "priority" konfigurierte benutzerdefinierte Klassen

Für benutzerdefinierte MQC-Klassen, die mit einer beliebigen Variante des priority mit  priority , priority  und priority percent  enthalten.

Verhalten vor HQF

Obwohl keine CLI vorhanden und nicht konfigurierbar ist, existiert technisch gesehen eine "versteckte" Systemwarteschlange, die von allen Prioritätsklassendaten gemeinsam genutzt wird. Dies fungiert nach der Klassifizierung und Genehmigung durch die überlastungssensitive Richtlinienvergabe als temporäre RESOURCE für Prioritätsdaten. LLQ-Pakete werden in diese "versteckte" Systemwarteschlange gestellt, wenn sie während des Empfangs-Interrupts, der sonst als funktionale Überlastung bezeichnet wird, nicht direkt auf dem Übertragungsring der Ausgangsschnittstelle platziert werden können. In dieser Situation wird das Paket, da eine funktionale Überlastung besteht, während des Empfangs-Interrupts mit der bedingten LLQ-Richtlinie abgeglichen, während es sich noch im Besitz des empfangenden Schnittstellentreibers befindet. Wenn das Paket von der bedingten LLQ-Richtlinie nicht verworfen wird, wird es in diese "versteckte" LLQ-Systemwarteschlange gestellt, und der Empfangs-Interrupt wird freigegeben. Aus diesem Grund haben alle Pakete, die sich in dieser "versteckten" Systemwarteschlange befinden, die Überlastungsrichtlinie für LLQs konform und können sofort vom LLQ-/CBWFQ-Scheduler aus der Warteschlange für den Übertragungsring der Ausgangsschnittstelle entfernt werden.

Trotz der Existenz dieser Warteschlange unterscheidet sich das Verhalten von Cisco IOS-Warteschlangen, die für Nicht-LLQ-Daten erstellt wurden (z. B. Warteschlangen mit fairer Einstellung und Bandbreitenwarteschlangen), da keine zusätzliche Warteschlangenlatenz (oberhalb der Senderinglatenz) auftreten kann, da Pakete in dieser Warteschlange sofort über den LLQ/CBWFQ-Scheduler an den Sendering weitergeleitet werden können. Wenn ein Paket der Prioritätsklasse von der bedingten Richtlinie während des Empfangs-Interrupts nicht verworfen wird, kann dieses LLQ-Paket in dieser "versteckten" Systemwarteschlange vorhanden sein, bevor es aus der Warteschlange in den Übertragungsring der Ausgangsschnittstelle entfernt wird. In diesem Fall kann der LLQ-/CBWFQ-Scheduler das Paket sofort dem Übertragungsring der Ausgangsschnittstelle präsentieren. Der Conditional Policer wurde ausgeführt, bevor das Paket an die LLQ/CBWFQ gesendet wird. Daher wird die LLQ auf die konfigurierte Prioritätsrate beschränkt.

Zusammenfassend wird empfohlen, LLQ-Daten, die die Prioritätsrate in Zeiten der Überlastung überschreiten, zu verwerfen, anstatt zusätzliche Warteschlangenlatenz zu verursachen, was eine grundlegende Komponente von LLQ ist. Dieser bedingte Richtlinienmechanismus ermöglicht eine Warteschlange mit strikter Priorität und verhindert, dass die Prioritätswarteschlange die gesamte Schnittstelle PLIM monopolisiert. Dies stellt eine Verbesserung gegenüber der älteren Prioritätswarteschlangenfunktion von Cisco IOS dar.

• Grenzwert für Pre-HQF-Warteschlange: NA

• Pre-HQF "priority" + "random-detect" behavior: NA, WRED nicht erlaubt in LLQ.

• Pre-HQF "priority" + "fair-queue" behavior: NA, fair-queue not allowed in LLQ.

• Pre-HQF "priority" + "random-detect" + "fair-queue" behavior: NA, weder fair-queue noch random-detect werden in LLQ unterstützt.

HQF-Verhalten

Wie Pre-HQF, nur dass die ausgeblendete Warteschlange nicht mehr ausgeblendet ist. Die Warteschlangenbegrenzung kann jetzt konfiguriert werden und beträgt standardmäßig 64 Pakete.

• HQF-Warteschlangenlimit: 64 Pakete

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

• HQF-Verhalten "priority" + "fair-queue": NA, fair-queue in LLQ nicht zulässig.

• HQF-Verhalten "priority" + "random-detect" + "fair-queue": NA, weder fair-queue noch random-detect werden in LLQ unterstützt.

Mit dem Befehl "bandwidth" konfigurierte benutzerdefinierte Klassen

Für benutzerdefinierte MQC-Klassen, die mit einer beliebigen Variante des bandwidth mit  bandwidth  ,  bandwidth percent und  bandwidth remaining percen t  enthalten.

Verhalten vor HQF

Der voreingestellte Warteschlangengrenzwert beträgt 64 Pakete und kann angepasst werden. Wenn Sie während des Empfangs-Interrupts ein Paket in eine Warteschlange einreihen müssen, das > 64 Pakete in der Warteschlange ergeben würde, wird das Paket per Tail verworfen.

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

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

Beispiel:

policy-map PRE_HQF_BANDWIDTH_WRED
 class 1
   bandwidth 32
   random-detect

Wenn eine beliebige Bandbreitenvariante zusammen mit einer beliebigen Variante der Zufallserkennung konfiguriert wird, ignorieren Sie die Kommandozeile für Warteschlangenbeschränkungen, wodurch die Puffergrenzen in der Klasse entfernt werden. Mit anderen Worten, zufällige Erkennung und Warteschlangenbegrenzung schließen sich in Pre-HQF-Images gegenseitig aus. Bei zufälliger Erkennung als Ablagestrategie ist die aktuelle Warteschlangengröße nicht beschränkt und kann theoretisch jeden Puffer belegen, der der klassenbasierten Fair-Queue zugewiesen ist, wobei die Anzahl der Puffer, die der klassenbasierten Fair-Queue zugewiesen sind, auf der Grundlage des Service-Policy-Attach-Punkts abgeleitet wird:

• Physische Schnittstelle: 1.000 Pakete, einstellbar mit CLI-Hold-Queuout der Schnittstelle

• ATM-PVC: 500 Pakete, einstellbar mit PVC CLI vc-hold-queue

• Frame-Relay Map-Class: 600 Pakete, einstellbar mit Frame-Relay Map-Class CLI Frame-Relay Hold-Queue

• Anwendung einer klassenbasierten Shaping-Richtlinie auf die (Sub-)Schnittstelle (vor HQF): 1.000 Pakete, einstellbar mit MQC-CLI-Shape-Max-Puffern.

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

Hinweis: Wenn eine Class Based Shaping-Richtlinie in Images vor dem HQF auf eine (Sub-)Schnittstelle angewendet wird, achten Sie auf die Geschwindigkeit der zugrunde liegenden physischen Schnittstelle, da Schnittstellen <2Mbps standardmäßig eine Weighted Fair Queue und Schnittstellen >2Mbps standardmäßig FIFO verwenden können. Im Pre-HQF kann die Shaping-Warteschlange die Warteschlange für Schnittstellenzurückstellungen speisen, unabhängig davon, ob die Shaping-Richtlinie auf Subschnittstellen- oder physischer Schnittstellenebene angefügt ist.

Während des Empfangs-Interrupts wird jedes Mal, wenn ein Paket zu einem Kandidaten für eine Schnittstellenausgangswarteschlange wird, die durchschnittliche Warteschlangengröße WRED mit der folgenden Formel berechnet:

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

Wenn sich folgende durchschnittliche Warteschlangengröße ergibt:

• Ist kleiner als der WRED-Mindestschwellenwert, reihen Sie das Paket in die Warteschlange ein, und geben Sie den Empfangs-Interrupt frei.
• Zwischen dem WRED-Min.-Schwellenwert und dem WRED-Max.-Schwellenwert kann das Paket mit erhöhter Wahrscheinlichkeit verworfen werden, wenn die durchschnittliche Warteschlangengröße näher an den WRED-Max.-Schwellenwert herankommt. Wenn die durchschnittliche Warteschlangengröße genau dem maximalen WRED-Schwellenwert entspricht, wird das Paket basierend auf dem Mark-Wahrscheinlichkeitswert verworfen. Der Mark-Wahrscheinlichkeits-Nenner dient auch als Baseline, um zu bestimmen, welcher Prozentsatz von Paketen verworfen werden kann, wenn das Limit der durchschnittlichen Warteschlange nicht genau gleich dem maximalen Schwellenwert WRED, aber höher als der minimale Schwellenwert WRED ist. Dies ist ein grafisches Beispiel:

Der durchschnittliche Warteschlangengrenzwert ist ungleich dem WRED-Max-Grenzwert, aber höher als der WRED-Min-Grenzwert.

• • Wenn das Paket verworfen wird, wird der Empfangs-Interrupt freigegeben und ein Zufallsverwurf inkrementiert. Wenn das Paket nicht verworfen wird, wird es in die Warteschlange gestellt, und der Empfangs-Interrupt wird freigegeben.

  • Ist der Wert höher als der maximale WRED-Schwellenwert, verwerfen Sie das Paket, geben Sie den Empfangs-Interrupt frei, und erhöhen Sie den Wert für "Tail Drop".

Hinweis: IP Precedence based (Standard) und DSCP-based WRED ermöglichen die unterschiedliche Definition von Mind-threshold, Max-threshold und Mark Proyability Nenner für verschiedene Werte. An dieser Stelle wird die gewichtete Komponente der zufälligen Früherkennung deutlich. Sie können bestimmte ToS-Werte relativ zu anderen Werten schützen, wenn Sie ihre relativen Schwellenwerte anpassen und Wahrscheinlichkeitswerte markieren.

Wenn die Zufallserkennung und die Bandbreite zusammen konfiguriert werden, kann die aktuelle Warteschlangengröße zu einem beliebigen Zeitpunkt größer als der maximale WRED-Schwellenwert sein. Der Grund hierfür ist, dass die WRED-Mindest- und -Höchstwerte nur auf der Grundlage der durchschnittlichen (nicht der aktuellen) Warteschlangengröße wirken. Dies bietet die Möglichkeit, alle der klassenbasierten Warteschlange zugewiesenen Puffer zu verfallen. Dies kann dazu führen, dass innerhalb der klassenbasierten Warteschlange keine Puffer mehr verloren gehen (siehe Cisco Bug-ID CSCsm94757).

• Pre-HQF "bandwidth" + "fair-queue" behavior:NA, fair-queue not allowed in bandwidth class.

• Pre-HQF "bandwidth" + "random-detect" + "fair-queue" Verhalten: NA, fair-queue in Bandbreitenklasse nicht erlaubt

HQF-Verhalten

Das Verhalten entspricht dem im Abschnitt zu Pre-HQF beschriebenen.

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

Dies entspricht dem vor dem HQF.

• HQF-Verhalten für "Bandbreite" + "Zufallserkennung":

Beispiel:

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

Hinweis: Der Warteschlangengrenzwert beträgt standardmäßig 64 Pakete.

Das Verhalten entspricht dem im entsprechenden Abschnitt vor dem HQF, mit einer wichtigen Ausnahme. In HQF-Images können Random-Detect und Warteschlangenlimit gleichzeitig in derselben benutzerdefinierten Klasse (oder Klassenklasse-Default) vorhanden sein, und Warteschlangenlimit kann aktiviert und auf 64 Pakete in einer Standardkonfiguration eingestellt werden. Warteschlangenlimit kann als maximale aktuelle Warteschlangengröße in einer zufällig erkannten Klasse dienen und daher einen Mechanismus bereitstellen, um Pufferverluste, die nicht auftreten, zu begrenzen, die im entsprechenden Abschnitt vor HQF beschrieben werden. Aufgrund dieser Hinzufügung muss die konfigurierte Warteschlangengrenze mindestens so groß sein wie der max-threshold für die Zufallserkennung, wobei der max-threshold für die Zufallserkennung standardmäßig 40 Pakete enthalten kann, andernfalls kann der Parser die Konfiguration ablehnen.

Dadurch wird in WRED-Klassen eine Prüfung der aktuellen Warteschlangenbegrenzung eingeführt. Selbst wenn die Berechnung der durchschnittlichen Warteschlangentiefe kleiner als der maximale Schwellenwert ist, kann das Paket verworfen, der Empfangs-Interrupt freigegeben und ein Tail Drop aufgezeichnet werden, wenn die aktuelle (nicht die durchschnittliche) Warteschlangengröße größer als der Warteschlangengrenzwert ist. Denken Sie daran, dass, wenn der Warteschlangengrenzwert ausreichend hoch eingestellt ist, um die aggregierten Warteschlangenpuffer für die klassenbasierte Warteschlange zu erschöpfen, keine Pufferverluste auftreten können. Aggregierte Warteschlangenpuffer für HQF sind hier definiert:

• Physische Schnittstelle: 1.000 Pakete, einstellbar mit CLI-Hold-Queuout der Schnittstelle

• ATM-PVC: 500 Pakete, einstellbar mit PVC CLI vc-hold-queue

• Frame-Relay Map-Class: 600 Pakete, einstellbar mit Frame-Relay Map-Class CLI Frame-Relay Hold-Queue

• Klassenbasierte Shaping-Richtlinie, die im HQF-Code auf physische Schnittstellen angewendet wird: 1.000 Pakete, einstellbar mit einer Kombination aus CLI-Hold-Queue-Out und untergeordnetem Policy-Queue-Limit, wobei untergeordneter Policy-Queue-Limit eine obere Grenze für Interface-Hold-Queue-Out hat.

• Klassenbasierte Shaping-Richtlinie, angewendet auf Subschnittstelle im HQF-Code: 512 Pakete, nicht einstellbar (Untersuchung beim NSSTG QoS-Plattformteam, muss einstellbar sein)

Hinweis: Bei allen Frame-Relay- und Class-basierten Shaping-Beispielen wird davon ausgegangen, dass die Summe der Shaper die Schnittstellenuhrrate 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

Bei 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 nicht Burst und besteht 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 Non-Burst-Stream die durchschnittliche Warteschlangentiefe von WRED der aktuellen Warteschlangentiefe entsprechen kann, die dem erwarteten Verhalten entspricht.

• HQF-Verhalten für "Bandbreite" + "faire Warteschlange":

Wenn Bandbreite und Warteschlangengröße zusammen auf eine benutzerdefinierte HQF-Klasse angewendet werden, wird jeder Warteschlange auf Datenflussbasis ein Warteschlangenlimit von 0,25 * zugewiesen. Da die standardmäßige Warteschlangenbegrenzung 64 Pakete beträgt, kann jeder Datenfluss-basierten Warteschlange in einer fairen Warteschlange 16 Pakete zugewiesen werden. Wenn vier Flows diese Klasse durchlaufen, hätte standardmäßig jede Flow-Warteschlange 16 Pakete, daher würden Sie niemals erwarten, dass die Gesamtzahl der Pakete in die Warteschlange gestellt wird > 64 (4 * 16). Alle Tail-Drops einer einzelnen Flow-Warteschlange werden als Flow-Drops aufgezeichnet. Wenn die Anzahl der Flow-Warteschlangen ebenso wie das Warteschlangenlimit erheblich war, wird eine weitere Möglichkeit für "no-buffer" verworfen. Wenn Sie beispielsweise davon ausgehen, dass es sich bei dem Richtlinienanschlusspunkt um eine physische Schnittstelle handelt, der 1.000 aggregierte Puffer zugeordnet sind:

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

Bei dieser Konfiguration kann erheblicher Datenverkehr in allen Datenflusswarteschlangen die aggregierten Schnittstellenpuffer unterdrücken und zu Pufferverlusten in anderen benutzerdefinierten Klassen führen (siehe Cisco Bug-ID CSCsw98427). Dies liegt daran, dass 1024 Datenflusswarteschlangen mit jeweils 32 Paketwarteschlangenbegrenzungen die 1000 aggregierte Class Based Queuing-Pufferzuweisung der Schnittstelle leicht überzeichnen können.

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

Beispiel:

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

Wie Bandbreite und Warteschlangengröße in Abschnitt außer WRED Durchschnittliche Warteschlangengröße wird jedes Mal berechnet, wenn ein Paket ankommt, um zu entscheiden, ob das Paket zufällig verworfen oder per Tail verworfen werden muss. Wie bei früheren HQF können alle Flow-Warteschlangen eine Instanz von WRED-Grenzwerten gemeinsam nutzen. Das bedeutet, dass alle in alle Flow-Warteschlangen eingereihten Pakete zur Berechnung der WRED Average Queue Depth verwendet werden. In der Dropentscheidung werden dann die WRED-Mindest- und -Maximalgrenzwerte auf die aggregierten Pakete in allen Flow-Warteschlangen angewendet. Da jedoch eine Instanz von WRED-Schwellenwerten für alle Flow-basierten Warteschlangen gilt, wird das Warteschlangenlimit der einzelnen Flow-Warteschlangen (.25 * "Warteschlangenlimit") ignoriert. Stattdessen wird das aggregierte Warteschlangenlimit der Klassen für eine Prüfung des aktuellen Warteschlangenlimits berücksichtigt.

Standardverhalten der Klasse

Verhalten vor HQF

Vor HQF ist Class Default standardmäßig auf Fair-Queue (Fair-Queue) festgelegt, und alle Flow-Queues verwenden das Warteschlangenlimit für die Klasse (Standard ist 64). Eine Bandbreitenreservierung ist nicht vorhanden. Mit anderen Worten: Die Gesamtzahl der Pakete, die in allen Datenfluss-Warteschlangen in die Warteschlange gestellt werden, darf den Grenzwert für die Warteschlange niemals überschreiten. Die Anzahl der Pakete, die in jeder Datenflusswarteschlange in die Warteschlange gestellt werden, kann vom berechneten Gewicht der Datenflusswarteschlange abhängen. Wenn Fair-Queue und Random-Detect dagegen zusammen in der Standardklasse verwendet werden, kann das Warteschlangenlimit ignoriert werden, und alle Flow-Queues können die gleichen WRED-Schwellenwerte nutzen. Daher können alle Pakete, die derzeit in alle Datenflusswarteschlangen gestellt werden, zur Berechnung der durchschnittlichen WRED-Warteschlangengröße verwendet werden. Da die aktuelle Warteschlangengröße in dieser Konfiguration keine Obergrenze aufweist, besteht eine große Chance, dass keine Puffer vorhanden sind (siehe Cisco Bug-ID CSCsm94757).

• Wenn Bandbreite zur Standardklasse hinzugefügt wird, kann dies zu einem Verhalten führen, das im Abschnitt Pre-HQF Behavior - User Defined Classes Configured with the "bandwidth" (Benutzerdefinierte Klassen, konfiguriert mit dem Befehl "bandwidth") beschrieben wird.

• Wenn Bandbreite und zufällige Erkennung zur Klassenklasse hinzugefügt werden, kann default zu einem Verhalten führen, das im Abschnitt Pre-HQF "bandwidth" + "random-detect"-Verhalten von "Pre-HQF Behavior - User Defined Classes Configured with the "bandwidth" (Mit dem Befehl "bandwidth" konfiguriert) beschrieben wird.

Hinweis: Vor HQF kann Bandbreite in der Standardklasse nicht gleichzeitig mit einer fairen Warteschlange verwendet werden.

HQF-Verhalten

In HQF ist Class Default standardmäßig eine FIFO-Warteschlange und wird eine Pseudo-Bandbreitenreservierung zugewiesen, die auf den Restzuweisungen aus benutzerdefinierten Klassen basiert. Informationen zum Standardverhalten der HQF-Klassenklasse finden Sie im Abschnitt HQF Behavior - User Defined Classes Configured with the "bandwidth" (HQF-Verhalten - Benutzerdefinierte Klassen, konfiguriert mit dem Befehl "bandwidth). Unabhängig von der Konfiguration kann class-default in HQF-Images jederzeit über eine implizite Bandbreitenreservierung verfügen, die der ungenutzten Schnittstellenbandbreite entspricht, die nicht von benutzerdefinierten Klassen belegt wird. Standardmäßig erhält die Standardklasse mindestens 1 % der Bandbreite der Schnittstelle oder der übergeordneten Form. Es ist auch möglich, die Bandbreite-CLI explizit als Klassenstandard zu konfigurieren.

• Wenn die Fair-Queue in Class-Default konfiguriert ist, stimmt das Verhalten mit dem Abschnitt HQF-Verhalten "bandwidth" + "fair-queue" überein, der den HQF-Abschnitt "Behavior - User Defined Classes Configured with the "bandwidth" (Benutzerdefinierte Klassen, konfiguriert mit dem Befehl "bandwidth") enthält.

• Wenn Fair-Queue und Random-Detect in Class-Default zusammen konfiguriert werden, stimmt das Verhalten mit dem Abschnitt HQF-Verhalten "bandwidth" + "random-detect" + "fair-queue" überein - Benutzerdefinierte Klassen, die mit dem Befehl "bandwidth" konfiguriert werden.

Zugehörige Informationen

• Konfigurationsleitfaden für Cisco IOS Quality of Service-Lösungen, Version 12.2SR
• QoS - Hierarchical Queueing Framework (HQF) [nicht unterstützt]
• Router-Unterstützung
• Technischer Support und Downloads von Cisco