In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
In diesem Dokument werden Warteschlangenbegrenzungen und Output Drops auf Cisco IOS®-Softwareplattformen und älteren Access Routern beschrieben.
Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:
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.
Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).
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.
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.
Für benutzerdefinierte MQC-Klassen, die mit einer beliebigen Variante des priority
mit priority
, priority
und priority percent
enthalten.
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.
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.
Für benutzerdefinierte MQC-Klassen, die mit einer beliebigen Variante des bandwidth
mit bandwidth
, bandwidth percent
und bandwidth remaining percen t
enthalten.
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.
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:
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
Das Verhalten entspricht dem im Abschnitt zu Pre-HQF beschriebenen.
HQF-Warteschlangenlimit: 64 Pakete, einstellbar über Warteschlangenlimit.
Dies entspricht dem vor dem HQF.
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 isbeing
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.
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.
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.
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
2.0 |
19-Jan-2023 |
Aktualisiertes Format und korrekte CCW-Warnungen. Rezertifizierung. |
1.0 |
26-Aug-2009 |
Erstveröffentlichung |