WRED und MDRR auf dem Cisco Internet Router der Serie 1200 mit einer Kombination aus Unicast-, Multicast- und Sprachdatenverkehr - Konfigurationsbeispiel

Einführung

In diesem Dokument wird erläutert, wie Sie eine Line Card der Cisco Serie 1200 für Weighted Random Early Detection (WRED) konfigurieren, die in RFC 2309 in einer Umgebung mit mehreren Diensten beschrieben wird.

Voraussetzungen

Anforderungen

Die Leser dieses Dokuments sollten über folgende Punkte Bescheid wissen:

• Verständnis und Konfiguration von MDRR und WRED auf dem Cisco Internet Router der Serie 12000

• Lesen der Ausgabe der Registerkarte "show controller" | Tab-Warteschlangenbefehle auf einem Cisco Internet Router der Serie 12000

• Type of Service in the Internet Protocol Suite, Precedence (RFC-1349)

• Weighted Random Early Detection

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf den folgenden Software- und Hardwareversionen:

• Jede Cisco IOS® Softwareversion, die den Cisco Internet Router der Serie 12000 unterstützt. In der Regel sind dies die Versionen 12.0S und 12.0ST.

• Alle Cisco 12000-Plattformen werden in diesem Dokument behandelt. Dazu gehören die 12008, 12012, 12016, 12404, 12406, 12410 und 12416.

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 in den Cisco Technical Tips Conventions.

Hintergrundinformationen

Die Cisco Serie 12000 ist eine der beliebtesten Plattformen für den Aufbau eines IP-Core-Netzwerks mit hoher Bandbreite. Diese Plattform bietet die exklusive Möglichkeit, Quality of Service (QoS) zu konfigurieren.

Da es immer häufiger vorkommt, verschiedene Arten von IP-Datenverkehr (z. B. Voice over IP - VoIP - und Multicast) im gleichen Netzwerk zu kombinieren, werden die Anforderungen an die Priorisierung und ein kontrolliertes Verwerfungsverhalten extrem wichtig. In vielen Fällen besteht der Unterschied zwischen Erfolg und Misserfolg bei der Einführung eines neuen Dienstes wie VoIP.

Die Netzwerkanforderungen für verschiedene Arten von IP-Datenverkehr werden in diesem Dokument nicht behandelt. Dieses Dokument konzentriert sich auf Labortests, die durchgeführt wurden, um eine Konfiguration zu finden, die für verschiedene Linecards geeignet ist, einschließlich der Cisco Line Card der Serie 12000 mit 3-Port Gigabit Ethernet (GbE mit 3 Ports). Die Ergebnisse dieser Tests zeigen, dass die GbE Engine 2 Line Card mit 3 Ports für eine Netzwerkumgebung mit einer Kombination aus Sprach-, Daten- und Multicast-Datenverkehr geeignet ist. Es beweist auch, dass die Konfiguration von QoS einen echten Unterschied in einem überlasteten Netzwerk darstellt.

Im Test verwendete Prioritätsklassen

Die Prioritätswerte, die verschiedenen Klassen zugewiesen werden, müssen im gesamten Netzwerk gleich sein. Sie müssen eine generische Richtlinie festlegen.

Klasse	Rangfolge	Datenverkehr
böser Datenverkehr		Alle nicht identifizierten externen Datenverkehr (Off-Net)
On Net — On Net	1	Datenverkehr, der innerhalb des SP-Netzwerks verbleibt (On-Net)
Internetdienstanbieter (ISP)-Services	2	ISP-Datenverkehr, SMTP, POP, FTP, DNS, Telnet, SSH, www, https
KMU (kleine und mittlere Unternehmen)	1	Enterprise-Kunden, ein Goldservice
Echtzeit, keine Sprachübertragung	4	Fernsehen, Echtzeit-Gaming
Sprache	5	RTP-VOIP-Datenverkehr
Netzwerksteuerungsnachrichten	6-7	Border Gateway Protocol (BGP) und andere Kontrollmeldungen

Färben der IP-Pakete

Wenn QoS im Netzwerkkern implementiert werden soll, muss der Service Provider den Rangfolgewert aller im Netzwerk übertragenen IP-Pakete vollständig kontrollieren können. Die einzige Möglichkeit hierfür besteht darin, alle Pakete beim Betreten des Netzwerks zu kennzeichnen, ohne zu unterscheiden, ob sie vom Kunden-/Endbenutzerstandort oder vom Internet stammen. Im Kern sollte keine Markierung oder Färbung vorgenommen werden.

Erwartete Ergebnisse

Das Ziel dieses Designs besteht darin, ein echtes WRED-Verhalten in den Klassen 0-3 zu erreichen. Das heißt, wir möchten eine Situation haben, in der wir anfangen, während der Überlastung Vorrang 0 Pakete zu verwerfen. Danach sollten wir auch beginnen, Vorrang 1 zu verwerfen, wenn die Überlastung anhält, und dann auch Vorrang 2 und 3. All dies wird in der Grafik unten beschrieben.

Die Latenz für Sprachpakete sollte so gering wie möglich sein, während Sprach- und Multicast-Datenverkehr überhaupt nicht verloren geht.

Netzwerkeinrichtung

Zum Testen und Auswerten der Konfiguration wurde ein Cisco 12410 mit einem Paket-Generator von Agilant verwendet. Auf dem Cisco 12000-Router wird eine technische Version ausgeführt, die auf der Cisco IOS-Softwareversion 12.0(21)S1 basiert.

GbE Engine 2-Warteschlangenimplementierung mit 3 Ports

Modul-2-Karten verfügen in der Regel über acht Formularwarteschlangen und eine Warteschlange mit niedriger Latenz sowie acht Tofab-Warteschlangen pro Zielsteckplatz. Es gibt auch eine separate tofab-Multicast-Warteschlange. Auf der GbE-Karte mit 3 Ports ist pro physischem Port nur eine Fromfab-Warteschlange vorhanden. Im Test gibt die angewendete Konfiguration mehr Warteschlangen an. Die Ergebnisse zeigen, dass die GbE-Karte mit 3 Ports diese Konfiguration akzeptiert, und die Warteschlangen werden automatisch den verfügbaren Warteschlangen zugeordnet.

Engine 2-WRED-Algorithmus in der Cisco IOS-Software

Sie müssen den Algorithmus für WRED in der Line Card Engine 2 vollständig verstehen, wenn Sie die Mindest- und Höchstwerte für die Warteschlangentiefe konfigurieren. Der konfigurierte Mindestwert spielt für den Code keine Rolle. Stattdessen verwendet er eine eigene Formel (basierend auf dem konfigurierten Maximalwert), um den Mindestwert festzulegen.

Formel:

Mindestwert = Höchstwert - (die höchste Leistung von 2, die kein negatives Ergebnis erzeugt)

Die in diesem Test verwendeten Werte führten zu den folgenden Mindestwerten, die für den Application Specific Integrated Circuit (ASIC) programmiert wurden:

Rangfolge	Konfigurierter Mindestwert	Maximal konfiguriert	Höchste Leistung von 2	Mindestwert in ASIC
0	50	5000	4096	5000-4096=904
1	60	6000	4096	6000-4096=1904
2	70	7000	4096	7000-4096=2904
1	80	8000	4096	8000-4096=3904

Wenn Sie diese Formel zur Berechnung des Mindestwerts verwenden, können Sie am Ende ein falsches Paketverarbeitungsverhalten feststellen, wenn Sie dies bei der Konfiguration Ihrer WRED-Parameter nicht berücksichtigen. Dies wird im folgenden Beispiel gezeigt:

Rangfolge	Konfigurierter Mindestwert	Maximal konfiguriert	Höchste Leistung von 2	Mindestwert in ASIC
0	50	150	128	150-128=22
1	75	225	128	225-128=97
2	100	300	256	300-256=44
1	125	375	256	375-256=119

Dies bedeutet, dass Sie, obwohl die Werte so konfiguriert sind, dass sie zunächst gemäß Regel 0, dann 1, 2 und zuletzt 3 (oben) verfallen, wenn die Werte in die ASIC geschrieben werden, tatsächlich mit dem Verwerfen von Rangfolge 0, dann Rangfolge 2, dann Rangfolge 1 und zuletzt Rangfolge 3 beginnen. Es ist nicht erkennbar, welche Werte im ASIC auf einer Engine 2-Karte konfiguriert wurden. Wenn Sie die Konfiguration auf eine Engine 3-Karte anwenden, werden die in der Konfiguration angezeigten Werte als tatsächliche Werte (der neu berechnete Mindestwert) angezeigt.

QoS-Konfiguration

Weitere Informationen zur QoS-Konfiguration finden Sie im Dokument Understanding and Configuring MDRR and WRED on the Cisco Internet Router der Serie 12000.

Rx-CoS

rx-cos-slot 2 B2-Table
rx-cos-slot 3 B2-Table
rx-cos-slot 6 B2-Table

In den meisten Fällen können Sie den Befehl rx-cos-slot all verwenden. In unserem Testfall hatten wir einige Karten, die keine Tofab-Warteschlange unterstützten, sodass wir nicht immer den Befehl rx-cos-slot all verwenden konnten. Stattdessen wurde unsere Steckplatztabelle den Line Cards zugewiesen, die im Test verwendet wurden.

!   
slot-table-cos B2-Table  
destination-slot all B2  
multicast B2  
!--- If you don't fulfill the steps above, you will not be able to reach the goal of 0 drops for Multicast traffic. With no rx-cos configured, multicast will be treated in the default queue, meaning it will drop as soon as there is congestion.

!

Tx QoS

Jetzt können Sie Ihre tx-cos konfigurieren. Wählen Sie einen Namen für Ihre tx qos aus, z. B. "cos-queue-group B2".

Jeder Prioritätswert, für den ein Drop-Verhalten konfiguriert werden soll, muss einer separaten willkürlich erkennbaren Bezeichnung zugeordnet werden.

precedence 0 random-detect-label 0  

precedence 1 random-detect-label 1  

precedence 2 random-detect-label 2  

precedence 3 random-detect-label 3

MDRR (Modified Deficit Round Robin): Ordnen Sie jede Priorität einer MDRR-Warteschlange zu. In unserem Beispiel wurde die Priorität 0-3 derselben MDRR-Warteschlange zugeordnet, um Bandbreite für Video (Multicast-Datenverkehr) zu reservieren. Diese Zuordnung stellt das angeforderte Verhalten bereit.

precedence 0 queue 0  

precedence 1 queue 0  

precedence 2 queue 0  

precedence 3 queue 0  

precedence 4 queue 4 

Sprache ist mit Rangfolge 5 gekennzeichnet. Aus diesem Grund wird der Warteschlange mit niedriger Latenz Priorität 5 zugeordnet.

precedence 5 queue low-latency  

precedence 6 queue 6  

precedence 7 queue 6  

Nun müssen Sie das Verwerfungsverhalten für die einzelnen zufällig erkannten Etiketten konfigurieren. Während des Tests wurden diese Zahlen geändert, bis Werte gefunden wurden, die das gewünschte Dropdown-Muster gaben. Weitere Informationen finden Sie im Abschnitt "Erwartete Ergebnisse". Die Warteschlangentiefe wird in der physischen Warteschlange und nicht in der MDRR- oder RED-Label-Warteschlange gemessen.

random-detect-label 0 50 5000 1  

random-detect-label 1 60 6000 1  

random-detect-label 2 70 7000 1  

random-detect-label 3 80 8000 1 

Beim Cisco 12000 ist es möglich, ein Class-Based Weighted Fair Queuing (CBWFQ)-Verhalten zu erstellen, indem den verschiedenen MDRR-Warteschlangen ein Gewicht zugewiesen wird. Das Standardgewicht ist 10 pro Warteschlange. Die Anzahl der Byte, die pro MDRR-Zyklus übertragen werden, hängt vom Gewichtungswert ab. Ein Wert von 1 steht für 1.500 Byte pro Zyklus. Ein Wert von 10 bedeutet 1.500+(9*512) Byte pro Zyklus."

queue 0 20  

queue 4 20  

queue 6 20  

!  

Schnittstellenzuordnung

Jede Schnittstelle muss für WRED konfiguriert werden. Hierzu werden die folgenden Befehle verwendet:

• Terminal konfigurieren

• interface gig 6/0

• tx cos B2

Starten ohne Verluste

Der generierte Stream verwendet die folgenden Werte, sofern nicht etwas Anderes angegeben wird:

MTU all three data streams 300byte, MTU voice 80byte, MTU MC 1500byte

126Mb MC, 114Mb voip

Dies führt zu einem Hintergrundstream von 240 MB (VoIP und Multicast).

Anschließend fügen wir vier Datenströme derselben Größe hinzu, jedoch mit der Priorität 0-3 (ein Rangfolgewert pro Stream).

Vier Datenströme von je 151 MB

Diese Konfiguration bietet eine Gesamtbandbreite von 844 MB. Die folgende Grafik zeigt, dass 0 Paketverluste und eine sehr geringe Latenz (etwa 50 us - Mikrosekunden - für jeden Stream, einschließlich Voice) vorliegen.

Vier Datenströme von je 160 MB

Diese Konfiguration bietet eine Gesamtbandbreite von 880 MB. Die nachfolgende Grafik zeigt, dass Pakete von der Klasse "Precedence 0" zu verwerfen beginnen und die Latenz für "Voice" auf 6 ms - Millisekunden gestiegen ist.

Vier Datenströme von je 167 MB

Diese Konfiguration bietet eine Gesamtbandbreite von 908 MB. Die Drops beginnen nun auch für die Klasse 1 mit Vorrang. Die Latenz des Sprachdatenverkehrs ist immer noch die gleiche.

Hinweis: Der Stream wurde nicht angehalten, bevor er erhöht wurde, sodass der Unterschied zwischen der Anzahl der Verwerfen im Stream 0 und 1 kumulativ ist.

Vier Datenströme von je 191 MB

Wenn die Gesamtbandbreite zunimmt, beginnen auch die Pakete aus der Prioritätswarteschlange 2 zu fallen. Die Gesamtbandbreite, die wir für die Gigabit Ethernet-Schnittstelle erreichen möchten, beträgt jetzt 1004 MB. Dies wird in den Sequenzfehlerzählern in der Grafik unten veranschaulicht.

Vier Datenströme von je 244 MB

Auch die Sequenzfehler für Rangfolge 3 nehmen zu. Dies ist das erste Zeichen dafür, dass das Herunterfahren aus dieser Warteschlange beginnt. Die Gesamtbandbreite, die wir an die GbE-Schnittstelle senden möchten, beträgt jetzt 1216 MB. Beachten Sie, dass die Verwerfen des Multicast (MC) und der Sprach-Warteschlange immer noch 0 sind und die Latenz der Sprach-Warteschlange nicht angestiegen ist.

Anhalten und Starten

Alle Streams wurden gestoppt und haben angefangen, ein Diagramm zu generieren, das Zähler gelöscht hat. Dies zeigt, wie es bei starker Überlastung aussehen wird. Wie Sie unten sehen können, ist das gewünschte Verhalten das gewünschte.

Alle QoS entfernt

Um zu beweisen, dass QoS die Leistung bei Überlastungen wirklich verbessert, wurde QoS entfernt und die Schnittstelle überlastet. Die Ergebnisse sind unten aufgeführt (der generierte Stream verwendet die folgenden Werte, es sei denn, es wird etwas Anderes angegeben).

MTU all three data streams 300byte, MTU voice 80byte, MTU MC 1500byte

126Mb MC, 114Mb VoIP

Dies führt zu einem Hintergrundstream von 240 MB (VoIP und Multicast).

Anschließend fügen wir vier Datenströme derselben Größe hinzu, jedoch mit der Priorität 0-3 (ein Rangfolgewert pro Stream).

Vier Datenströme von je 153 MB

Dies ergibt insgesamt 852 MB. Es gibt 0 Tropfen, und eine Latenz von weniger als 50 us.

Vier Datenströme von je 158 MB

Wir beginnen mit etwa der gleichen Auslastung wie bei WRED (872 MB). Der Unterschied besteht nun darin, dass die Latenz der Sprachpakete 14 ms beträgt (mehr als doppelt so hoch wie beim WRED-Test), und dass diese Pakete in allen Klassen, einschließlich VoIP und Multicast, gleich verworfen werden.

Hinzufügen der Eingangslast

Bislang war bei allen Tests nur die Übertragung über die Gigabit Ethernet-Schnittstellen enthalten. Um zu überprüfen, wie die Schnittstelle in einer Situation reagiert, in der wir auch die Schnittstelle in die andere Richtung überladen, wurden die folgenden Tests durchgeführt.

Für diesen Test wurde die Gigabit Ethernet-Schnittstelle mit einer Gesamtgröße von 1056 MB geladen. Dies führte zu Unterbrechungen der Prioritätsstufe 0-2, ohne dass Datenverkehr mit Prioritätsstufe 3 verloren ging. (MC und VOIP blieben unverändert, d. h. es gab keine Drops). Dann wurde der Datenverkehr in die andere Richtung hinzugefügt, so viel Datenverkehr, wie der Paketgenerator über die Gigabit Ethernet-Schnittstelle senden konnte. Das Ergebnis ist ziemlich beeindruckend: Die Empfangsüberlastung stört überhaupt nicht die Sendewarteschlange, und die Latenz für den empfangenden Datenverkehr ist extrem gering, bei Voice weniger als 13 us.

12-RP#show-Schnittstellen g 6/0

Sie können die Last auf der Gigabit-Verbindung mit dem Befehl show interfaces überwachen:

Router#show interfaces gig 6/0
GigabitEthernet6/0 is up, line protocol is up
  Hardware is GigMac 3 Port GigabitEthernet, address is 0004.de56.c264 
  (bia 0004.de56.c264)
  Internet address is 178.6.0.1/24
  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, rely 255/255, load 232/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex mode, link type is force-up, media type is SX 
  output flow-control is unsupported, input flow-control is off
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:05, output 00:00:05, output hang never
  Last clearing of "show interface" counters 08:52:40
  Queueing strategy: random early detection (WRED)
  Output queue 0/40, 2174119522 drops; input queue 0/75, 0 drops
  30 second input rate 838969000 bits/sec, 792079 packets/sec
  30 second output rate 910819000 bits/sec, 464704 packets/sec
    7584351146 packets input, 1003461987270 bytes, 0 no buffer
	Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
	0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
	0 watchdog, 514 multicast, 0 pause input
	11167110605 packets output, 2241229569668 bytes, 0 underruns
	0 output errors, 0 collisions, 0 interface resets
	0 babbles, 0 late collision, 0 deferred
	0 lost carrier, 0 no carrier, 0 pause output
	0 output buffer failures, 0 output buffers swapped out

Ändern der Größe von Streams

Um sicherzustellen, dass die Testergebnisse nicht darauf zurückzuführen sind, dass die Bandbreite für alle Streams gleich ist, änderten wir die Streams so, dass sie unterschiedliche Datenmengen übertragen. Wir versuchten auch, die Maximum Transmission Unit (MTU) so zu ändern, dass sie für jeden Stream unterschiedlich war. Bei den konfigurierten Warteschlangenwerten war das Ergebnis immer noch das gleiche, wodurch die Priorität 0 zuerst, dann 1, dann 2 und zuletzt Vorrang 3 verloren ging.

Überprüfen mit einer Gigabit Ethernet Engine 4 Line Card mit 10 Ports

Da die Latenz der VoIP-Warteschlange (Low Latency Queue) im Test relativ hoch war, führten wir denselben Test mit der Gigabit Ethernet Engine 4 Line Card mit 10 Ports durch. Wie erwartet, war das Ergebnis dieser Linecard in Bezug auf die Latenz in der Low Latency Queue (LLQ) deutlich besser. Die Ergebnisse bezüglich des Abwurfs waren identisch. Die Latenz für das LLQ betrug etwa 10 ms, was 1:1000 der Latenz bei der Gigabit Ethernet Engine 2 Line Card mit 3 Ports entspricht.

Zugehörige Informationen

• Verständnis und Konfiguration von MDRR und WRED auf dem Cisco Internet Router der Serie 12000
• Lesen der Ausgabe der Registerkarte "show controller" | Tab-Warteschlangenbefehle auf einem Cisco Internet Router der Serie 12000
• Type of Service in the Internet Protocol Suite, Precedence (RFC-1349)
• Weighted Random Early Detection
• Technischer Support und Dokumentation - Cisco Systems