Grundlegendes zu hierarchischen Schedulern
Hierarchische Zeitpläne bestehen aus Knoten und Warteschlangen. Warteschlangen beenden die CLI-Hierarchie. Knoten können entweder Root-Knoten, Leaf-Knoten oder interne (Nicht-Leaf)-Knoten sein. Interne Knoten sind Knoten, die andere Knoten als "untergeordnete" Knoten in der Hierarchie haben. Wenn beispielsweise eine interface-set
Anweisung mit einer logischen Schnittstelle (z. B. Einheit 0) und Warteschlange konfiguriert ist, ist dies interface-set
ein interner Knoten auf Ebene 2 der Hierarchie. Wenn jedoch keine Datenverkehrssteuerungsprofile auf logischen Schnittstellen konfiguriert sind, liegt der Schnittstellensatz auf Ebene 3 der Hierarchie.
Tabelle 1 zeigt, wie sich die Konfiguration eines Schnittstellensatzes oder einer logischen Schnittstelle auf die Terminologie hierarchischer Scheduler-Knoten auswirkt.
Root Node (Ebene 1) |
Interner Knoten (Ebene 2) |
Leaf Node (Ebene 3) |
Warteschlange (Ebene 4) |
---|---|---|---|
Physische Schnittstelle |
Schnittstellensatz |
Logische Schnittstellen |
Eine oder mehrere Warteschlangen |
Physische Schnittstelle |
– |
Schnittstellensatz |
Eine oder mehrere Warteschlangen |
Physische Schnittstelle |
– |
Logische Schnittstellen |
Eine oder mehrere Warteschlangen |
Bei Verwendung liegt die Ebene des Schnittstellensatzes der Hierarchie zwischen der physischen Schnittstellenebene (Ebene 1) und der logischen Schnittstelle (Ebene 3). Warteschlangen sind immer Ebene 4 der Hierarchie. Die Scheduler enthalten die Informationen zu den Warteschlangen, der letzten Ebene der Hierarchie. In allen Fällen werden die Eigenschaften für Ebene 4 der hierarchischen Scheduler durch die Scheduler-Karte bestimmt.
Hierarchische Scheduler fügen der neuen Schnittstellensatzebene der Konfiguration CoS-Parameter hinzu. Sie verwenden Verkehrssteuerungsprofile, um Werte für Parameter wie Shaping-Rate (Spitzeninformationsrate [PIR]), garantierte Rate (die zugesagte Informationsrate [CIR] auf diesen Schnittstellen) und Scheduler-Karten (die Dem Datenverkehr zugewiesenen Warteschlangen und Ressourcen) festzulegen.
Die folgende CoS-Konfiguration platziert die folgenden Parameter in Verkehrssteuerungsprofilen auf verschiedenen Ebenen:
Verkehrssteuerungsprofil auf Portebene (
tcp-port-level1
):Eine Shaping-Rate (PIR) von 100 Mbit/s
Eine Verzögerungspufferrate von 100 Mbit/s
Verkehrssteuerungsprofil auf Schnittstellenebene (
tcp-interface-level2
):Eine Shaping-Rate (PIR) von 60 Mbit/s
Eine garantierte Rate (CIR) von 40 Mbit/s
Verkehrssteuerungsprofil auf logischer Schnittstellenebene (
tcp-unit-level3
):Eine Shaping-Rate (PIR) von 50 Mbit/s
Eine garantierte Rate (CIR) von 30 Mbit/s
Eine Scheduler-Karte namens smap1 für verschiedene Warteschlangeneigenschaften (Ebene 4)
Eine Verzögerungspufferrate von 40 Mbit/s
In diesem Fall sehen die Verkehrssteuerungsprofile wie folgt aus:
[edit class-of-service traffic-control-profiles] tcp-port-level1 { # This is the physical port level shaping-rate 100m; delay-buffer-rate 100m; } tcp-interface-level2 { # This is the interface set level shaping-rate 60m; guaranteed-rate 40m; } tcp-unit-level3 { # This is the logical interface level shaping-rate 50m; guaranteed-rate 30m; scheduler-map smap1; delay-buffer-rate 40m; }
Nach der Konfiguration müssen die Datenverkehrssteuerungsprofile auf die richtigen Stellen in der Hierarchie der CoS-Schnittstellen angewendet werden.
[edit class-of-service interfaces] interface-set level-2 { output-traffic-control-profile tcp-interface-level-2; } ge-0/1/0 { output-traffic-control-profile tcp-port-level-1; unit 0 { output-traffic-control-profile tcp-unit-level-3; } }
Schnittstellensätze können als Liste logischer Schnittstellen definiert werden, z. B. Einheit 100, Einheit 200 usw. Service Provider können diese Anweisungen verwenden, um Schnittstellen zu gruppieren, um Planungsparameter wie garantierte Rate und Shaping-Rate auf den Datenverkehr in den Gruppen anzuwenden. Schnittstellensätze werden derzeit nur von CoS verwendet, aber sie werden auf Hierarchieebene [edit interfaces]
angewendet, sodass sie möglicherweise für andere Services verfügbar sind.
Der gesamte Datenverkehrsüberschrift-Downstream muss in einem Schnittstellensatz mit der interface-set
Anweisung auf Der Hierarchieebene [Edit Class-of-Service Interfaces] erfasst werden.
Bereiche werden nicht unterstützt. müssen Sie jede logische Schnittstelle separat auflisten.
Obwohl der Schnittstellensatz auf der Hierarchieebene von [Bearbeiten-Schnittstellen] angewendet wird, werden die CoS-Parameter für den Schnittstellensatz auf der Hierarchieebene [Edit Class-of-Service-Schnittstellen] definiert, normalerweise mit der output-traffic-control-profile profile-name
Anweisung.
Sie können keinen Schnittstellensatz angeben, der die Formulare für die logische Schnittstelle, das S-VLAN oder die interface-set
VLAN-Äußeren Tag-Listen der Anweisung mischt. Eine logische Schnittstelle kann nur zu einem Schnittstellensatz gehören. Wenn Sie versuchen, dieselbe logische Schnittstelle zu verschiedenen Schnittstellensätzen hinzuzufügen, schlägt der Commit fehl.
In diesem Beispiel wird ein Commit-Fehler generiert:
[edit interfaces] interface-set set-one { ge-2/0/0 { unit 0; unit 2; } } interface-set set-two { ge-2/0/0 { unit 1; unit 3; unit 0; # COMMIT ERROR! Unit 0 already belongs to -set-one. } }
Mitglieder eines Schnittstellensatzes können sich nicht über mehrere physische Schnittstellen erstrecken. Nur eine physische Schnittstelle darf in einem Schnittstellensatz angezeigt werden.
Diese Konfiguration wird nicht unterstützt:
[edit interfaces] interface-set set-group { ge-0/0/1 { unit 0; unit 1; } ge-0/0/2 { # This type of configuration is NOT supported in the same interface set! unit 0; unit 1; } }
Sie können viele logische Schnittstellen unter einer Schnittstelle konfigurieren. Allerdings kann nur für eine Teilmenge von ihnen ein Datenverkehrssteuerungsprofil angefügt sein. Sie können beispielsweise drei logische Schnittstellen (Einheiten) über dasselbe Dienst-VLAN konfigurieren, aber Sie können ein Verkehrssteuerungsprofil anwenden, das best-effort und Sprachwarteschlangen auf nur eine der logischen Schnittstelleneinheiten angibt. Datenverkehr von den beiden verbleibenden logischen Schnittstellen wird als verbleibender Datenverkehr betrachtet.
Die Scheduler-Karte, die an einzelnen Schnittstellen (Ebene 3), Schnittstellensätzen (Ebene 2) oder physischen Ports (Ebene 1) konfiguriert ist, definiert das Paketplanungsverhalten auf verschiedenen Ebenen. Sie können logische Schnittstellen in einem Schnittstellensatz gruppieren und die Schnittstellen mit Schedulerkarten konfigurieren. Alle ausgehenden Pakete, die an den physischen oder logischen Schnittstellen ankommen, werden vom schnittstellenspezifischen Scheduler behandelt. Wenn die Schedulerzuordnung nicht auf Schnittstellenebene konfiguriert ist, wird das Paket vom Scheduler behandelt, der auf Schnittstellensatz- oder Portebene konfiguriert ist.