Umgang mit Microbursts in ASR 920, Unterschiede zwischen Bytes und Prozent mit Warteschlangenlimit
Inhalt
Einleitung
In diesem Dokument wird die Behandlung von Microbursts auf ASR 920-Routern beschrieben, die häufig die Ursache für das Verwerfen von Schnittstellenausgabepaketen sind. Im Detail wird mit dem Befehl queue-limit der Unterschied zwischen der Byteauslastung und dem Prozentwert dargestellt.
Voraussetzungen
Anforderungen
Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:
Router der Serie ASR 920
QoS-Richtlinien
Verwendete Komponenten
Die Informationen in diesem Dokument basieren auf einem ASR 920-Router, auf dem die Softwareversion Cisco IOS-XE 16.9.6 ausgeführt wird.
IXIA wird als Datenverkehrsgenerator für den Labortest verwendet.
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.
Hintergrundinformationen
Microbursts werden als kleine Spitzen im Netzwerkverkehr bezeichnet. In Zugangsnetzwerken von Service Providern beispielsweise tritt dies häufig in Szenarien mit Geschwindigkeitsunterschieden auf, bei denen ein Datenverkehrsfluss von einer Hochgeschwindigkeits-Schnittstelle wie 10 Gigabit Ethernet (GE) in den Router gelangt und über eine Niedriggeschwindigkeits-Schnittstelle wie 1 GE ausgeht.
Das häufigste Problem, das durch Mikrobutts bei ASR 920-Routern verursacht wird, sind verworfene Schnittstellenpakete in Ausgaberichtung. Dies tritt auf, wenn an der Eingangsschnittstelle für einen sehr kurzen Zeitraum (in der Größenordnung von Millisekunden) Bursts auftreten, die höher sind als die Rate der Ausgangsschnittstelle. Während dieser Zeit müssen die Pakete gepuffert werden.
Auf ASR 920/RSP2-Plattformen beträgt der Standardpuffer, der für Warteschlangen auf jeder 1-GE-Schnittstelle reserviert ist, 48 KB, während für die Warteschlangen auf jeder 10-GE-Schnittstelle 120 KB gilt.
Darüber hinaus steht ein gemeinsamer Puffer mit 11,75 MB zur Verfügung. Wenn der Puffer der Standardschnittstelle nicht ausreicht, um einen Paketerfolg zu ermöglichen, kann der freigegebene Puffer verwendet werden.
Um die Verwendung des freigegebenen Puffers für eine Schnittstelle zu aktivieren, muss unter dieser Schnittstelle eine QoS-Richtlinie konfiguriert werden, die den Parameter für das Warteschlangenlimit definiert.
Warteschlangenlimit konfigurieren
Dies ist ein Konfigurationsbeispiel für das Warteschlangenlimit der Schnittstelle GE 0/0/1:
class-map match-all DUMMY
match qos-group 99 <--- it can be any unused group
policy-map QUEUE-LIMIT
class DUMMY
class class-default
queue-limit percent 5
interface GigabitEthernet 0/0/1
service-policy output QUEUE-LIMIT
Diese Richtlinie gleicht keinen Datenverkehr ab und hat daher auch keine Auswirkungen auf diesen Datenverkehr. Diese Richtlinie erhöht lediglich den Warteschlangenpuffer der Schnittstelle GE 0/0/1.
Der Befehl match qos-group 99 ist erforderlich, da die Konfiguration von Warteschlangenlimit in einer Nicht-Endknoten-Klasse nicht unterstützt wird. Daher müssen Sie eine fiktive Klassenzuordnung als übergeordnete Klasse verwenden, um den Befehl queue-limit unter dem Endknoten class-default zu konfigurieren:
ASR-920-1(config)#policy-map QUEUE-LIMIT
ASR-920-1(config-pmap)#class class-default
ASR-920-1(config-pmap-c)# queue-limit percent 5
QOS: queue-limit command not supported in non-leaf classes
queue-limit: platform params check fail
Die Warteschlangenbegrenzung kann auf verschiedene Weise festgelegt werden:
(config-pmap-c)#queue-limit ?
<1-2097152> in bytes, <1-1677721> in us, <1-8192000> in packets by default
percent % of threshol
Parameter und Wert müssen entsprechend Ihren Netzwerkanforderungen ausgewählt werden.
Um diese Parameter zu verstehen und wie sich eine Änderung der Werte auf die Puffernutzung auswirkt, können Sie sich den im nächsten Abschnitt vorgestellten Labortest ansehen.
ASR-920-1(config)#interface port-channel 2
ASR-920-1(config-if)#service-policy output qos-tac
QoS: Configuration failed. Policy-map with Queueing actions not supported on EC main-interface/EFP
QoS: Configuration errors for policymap qos-tac
Unterschiede zu RSP3 und NCS 520
Cisco RSP3 Module QoS-Funktionen:
- Das RSP3-Modul verfügt über 4 GB externe Paketpuffer pro NPU.
- RSP3-Modul unterstützt 48000 Warteschlangen
- Standardmäßig unterstützt das RSP3-Modul bis zu 1 MB Warteschlangenlimit pro Warteschlange
- Der prozentuale Warteschlangengrenzwert wird von 1 GB der Gesamtpuffer als ausreichend angesehen.
Für Router mit RSP3-Supervisoren und NCS 520 ist die Anzahl der konfigurierbaren QoS-Gruppen auf 0-7 beschränkt:
ASR-903-1(config)#class-map match-all qos-tac
ASR-903-1(config-cmap)#match qos-group ?
<0-7> Qos Group value
Im NCS 520 gibt es standardmäßig einen 2 MB großen Warteschlangenpuffer, der von allen Schnittstellen gemeinsam genutzt wird. Auf einen externen 2 GB großen Puffer kann zugegriffen werden, wenn eine Richtlinienzuordnung mit Warteschlangenlimit konfiguriert wurde. Es gibt auch einen Unterschied in den Byte- und us-Parametern für das Warteschlangenlimit:
ASR-520-1(config-pmap-c)# queue-limit ?
<1-8192000> in bytes, <1-40000> in us, <1-8192000> in packets by default
percent % of threshold
Warteschlangenlimit (QL), Lab-Test, Unterschiede zwischen Byte und Prozent
Testumfang und -parameter
Wie bereits erwähnt, beträgt der konfigurierbare Maximalwert für die Warteschlangenbeschränkung in Byte 2097152. Dies entspricht etwa 18 % des gemeinsam genutzten Puffers auf ASR 920-Plattformen (11,75 MB - 45898 x 256 Byte).
Wenn Sie die Warteschlangenbeschränkung jedoch in Prozent konfigurieren, können Sie bis zu 100 % erreichen. Um Prozentwerte und Bytes mit äquivalenten Werten zu vergleichen, nimmt der Test Bytewerte von 117498 bis 2097152 Bytes und Warteschlangengrenzwerte von 1 % bis 18 %:
queue-limit percent 1 <=> queue-limit 117498 bytes
queue-limit percent 2 <=> queue-limit 234996 bytes
queue-limit percent 3 <=> queue-limit 352494 bytes
queue-limit percent 4 <=> queue-limit 469992 bytes
queue-limit percent 5 <=> queue-limit 587490 bytes
queue-limit percent 6 <=> queue-limit 704988 bytes
queue-limit percent 7 <=> queue-limit 822486 bytes
queue-limit percent 8 <=> queue-limit 939984 bytes
queue-limit percent 9 <=> queue-limit 1057482 bytes
queue-limit percent 10 <=> queue-limit 1174980 bytes
queue-limit percent 11 <=> queue-limit 1292478 bytes
queue-limit percent 12 <=> queue-limit 1409976 bytes
queue-limit percent 13 <=> queue-limit 1527474 bytes
queue-limit percent 14 <=> queue-limit 1644972 bytes
queue-limit percent 15 <=> queue-limit 1762470 bytes
queue-limit percent 16 <=> queue-limit 1879968 bytes
queue-limit percent 17 <=> queue-limit 1997466 bytes
queue-limit percent 18 <=> queue-limit 2097152 bytes
Es sind 36 Richtlinienzuweisungen konfiguriert: 18 mit Warteschlangengrenzwerten von 1 % bis 18 % und die anderen 18 mit Warteschlangengrenzwerten von 117498 bis 2097152 Byte.
policy-map QUEUE-LIMIT-PERCENT-X
class DUMMY
class class-default
queue-limit percent X
policy-map QUEUE-LIMIT-BYTES-X
class DUMMY
class class-default
queue-limit Y bytes
=> X values range from 1 to 18
=> Y values range from 117498 to 2097152
Jede Richtlinie wird mit demselben Microburst-Datenverkehr getestet, der mit IXIA generiert wird. Dieser Datenverkehr kommt an einem 10 GE-Port des ASR 920 an und wird an einem 1 GE-Port desselben Routers beendet.
Die Bursts bestehen aus 20000 Paketen mit 4 Gbit/s in Intervallen von 5 Sekunden. Die Burst-Dauer bei einer bestimmten Paketgröße:
1280000 bytes at 64 packet size, Burst duration: 0.00256 second
4000000 bytes at 200 packet size, Burst duration: 0.008 second
6000000 bytes at 300 packet size, Burst duration: 0.012 second
10360000 bytes at 518 packet size, Burst duration: 0.02072 second
16000000 bytes at 800 packet size, Burst duration: 0.032 second
20480000 bytes at 1024 packet size, Burst duration: 0.04096 second
28000000 bytes at 1400 packet size, Burst duration: 0.056 second
Testverfahren
Schritt 1: Wenden Sie die Richtlinienzuweisung QUEUE-LIMIT-BYTES-X (X=1) mit Bytes Y=117498 unter der Ausgangsschnittstelle an.
Schritt 2: Microburst-Datenverkehr 1 Minute lang ausführen.
Schritt 3: Messen Sie die Gesamtzahl der ausgegebenen Pakete und die Anzahl der verworfenen Pakete.
Schritt 4: Berechnen Sie das Verhältnis zwischen verworfenen Paketen und den insgesamt ausgegebenen Paketen.
Schritt 5: Wiederholen Sie Schritt 1. Verwenden Sie diesmal "policy-map QUEUE-LIMIT-PERCENT-X" mit dem Warteschlangenlimit-Prozentsatz X, wobei X=1 ist.
Schritt 6: Wiederholen Sie Schritt 1 mit X=X+1 für Name und Prozentwert der Richtlinienzuordnung, Y=Y+117498 Bytes. Wiederholen Sie, bis X=18 und Y=2097152 ist.
Beispiel
Messung mit der Richtlinienzuordnung QUEUE-LIMIT-BYTES-1:
ASR-920-1#show int Gi0/0/1
GigabitEthernet0/0/1 is up, line protocol is up
Hardware is 24xGE-4x10GE-FIXED-S, address is 70df.2f2f.ed01 (bia 70df.2f2f.ed01)
Internet address is 10.12.10.47/31
MTU 8900 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 4/255, rxload 4/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full Duplex, 1000Mbps, link type is auto, media type is T
output flow-control is unsupported, input flow-control is on
Carrier delay is 0 msec
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:01, output 00:00:02, output hang never
Last clearing of "show interface" counters never
Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 684263427
Queueing strategy: Class-based queueing
Output queue: 0/40 (size/max)
30 second input rate 19475000 bits/sec, 19533 packets/sec
30 second output rate 19157000 bits/sec, 13356 packets/sec
5064106237 packets input, 4333296255278 bytes, 0 no buffer
Received 29 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 726180 multicast, 0 pause input
7829367523 packets output, 4217074973677 bytes, 0 underruns
0 output errors, 0 collisions, 3 interface resets
0 unknown protocol drops
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
ASR-920-1#show policy-map int Gi0/0/1 output
GigabitEthernet0/0/1
Service-policy output: QUEUE-LIMIT-BYTES-1
Class-map: DUMMY (match-all)
0 packets, 0 bytes
30 second offered rate 0000 bps
Match: qos-group 99
Class-map: class-default (match-any)
1044078 packets, 73085460 bytes
30 second offered rate 9759000 bps, drop rate 0000 bps
Match: any
queue limit 117498 bytes
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
Messung nach 1 Minute Microburst-Datenverkehr:
ASR-920-1#show int Gi0/0/1
GigabitEthernet0/0/1 is up, line protocol is up
Hardware is 24xGE-4x10GE-FIXED-S, address is 70df.2f2f.ed01 (bia 70df.2f2f.ed01)
Internet address is 10.12.10.47/31
MTU 8900 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 2/255, rxload 3/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full Duplex, 1000Mbps, link type is auto, media type is T
output flow-control is unsupported, input flow-control is on
Carrier delay is 0 msec
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:01, output 00:00:01, output hang never
Last clearing of "show interface" counters never
Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 684561562
Queueing strategy: Class-based queueing
Output queue: 0/40 (size/max)
30 second input rate 13981000 bits/sec, 19643 packets/sec
30 second output rate 11256000 bits/sec, 12784 packets/sec
5064715137 packets input, 4333338878716 bytes, 0 no buffer
Received 29 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 726190 multicast, 0 pause input
7829753878 packets output, 4217102018968 bytes, 0 underruns
0 output errors, 0 collisions, 3 interface resets
0 unknown protocol drops
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
ASR-920-1#show policy-map int Gi0/0/1 output
GigabitEthernet0/0/1
Service-policy output: QUEUE-LIMIT-BYTES-1
Class-map: DUMMY (match-all)
0 packets, 0 bytes
30 second offered rate 0000 bps
Match: qos-group 99
Class-map: class-default (match-any)
1847215 packets, 129305050 bytes
30 second offered rate 10804000 bps, drop rate 0000 bps
Match: any
queue limit 117498 bytes
(queue depth/total drops/no-buffer drops) 0/387570/0
(pkts output/bytes output) 656508/45955560
Paketverlust-Delta: 684561562-684263427 = 298135
Gesamtpaketausgabedelta: 7829753878-7829367523 = 386355
Verhältnis zwischen Paketverlust und Paketverlust: 298135/386355 = 77 %
Testergebnisse
Wie bereits erläutert, wurden 36 Richtlinienzuweisungen getestet: 18 mit Warteschlangengrenzwerten, die zwischen 1 % und 18 % liegen, wurden mit den anderen 18 Richtlinien verglichen, die mit Warteschlangengrenzwerten konfiguriert wurden, die zwischen 117498 und 2097152 Byte liegen. Jede Richtlinienzuweisung wird mit demselben Microburst-Datenverkehr getestet, der mit IXIA generiert wurde.
In diesem Abschnitt werden die Ergebnisse dieses Tests aufgedeckt, der siebenmal wiederholt wird, um die Ergebnisse mit verschiedenen Paketgrößen in Byte zu überprüfen: 64, 200, 300, 518, 800, 1024, 1400.
Um das Lesen zu erleichtern, werden die Ergebnisse für jede Paketgröße in einer Tabelle angezeigt und grafisch dargestellt.
QL-Prozent vs. Bytes mit 64-Byte-Paketen
-------------------------------------------------------------------
Policy-map | Drop rate with PC | Drop rate with Bytes
-------------------------------------------------------------------
QL Bytes/Percent 1 | 81% | 77%
QL Bytes/Percent 2 | 72% | 31%
QL Bytes/Percent 3 | 61% | 15%
QL Bytes/Percent 4 | 54% | 0%
QL Bytes/Percent 5 | 45% | 0%
QL Bytes/Percent 6 | 38% | 0%
QL Bytes/Percent 7 | 33% | 0%
QL Bytes/Percent 8 | 26% | 0%
QL Bytes/Percent 9 | 22% | 0%
QL Bytes/Percent 10 | 17% | 0%
QL Bytes/Percent 11 | 12% | 0%
QL Bytes/Percent 12 | 8% | 0%
QL Bytes/Percent 13 | 4% | 0%
QL Bytes/Percent 14 | 1% | 0%
QL Bytes/Percent 15 | 0% | 0%
QL Bytes/Percent 16 | 0% | 0%
QL Bytes/Percent 17 | 0% | 0%
QL Bytes/Percent 18 | 0% | 0%
-------------------------------------------------------------------
QL Prozent vs. Bytes mit 200 Bytes Packets
-------------------------------------------------------------------
Policy-map | Drop rate with PC | Drop rate with Bytes
-------------------------------------------------------------------
QL Bytes/Percent 1 | 82% | 80%
QL Bytes/Percent 2 | 72% | 63%
QL Bytes/Percent 3 | 63% | 52%
QL Bytes/Percent 4 | 54% | 39%
QL Bytes/Percent 5 | 46% | 42%
QL Bytes/Percent 6 | 51% | 17%
QL Bytes/Percent 7 | 32% | 18%
QL Bytes/Percent 8 | 27% | 3%
QL Bytes/Percent 9 | 22% | 3%
QL Bytes/Percent 10 | 17% | 3%
QL Bytes/Percent 11 | 12% | 0%
QL Bytes/Percent 12 | 8% | 0%
QL Bytes/Percent 13 | 5% | 0%
QL Bytes/Percent 14 | 1% | 0%
QL Bytes/Percent 15 | 0% | 0%
QL Bytes/Percent 16 | 0% | 0%
QL Bytes/Percent 17 | 0% | 0%
QL Bytes/Percent 18 | 0% | 0%
-------------------------------------------------------------------
QL Prozent vs. Bytes mit 300 Bytes Packets
-------------------------------------------------------------------
Policy-map | Drop rate with PC | Drop rate with Bytes
-------------------------------------------------------------------
QL Bytes/Percent 1 | 84% | 106%
QL Bytes/Percent 2 | 72% | 72%
QL Bytes/Percent 3 | 62% | 63%
QL Bytes/Percent 4 | 54% | 52%
QL Bytes/Percent 5 | 46% | 46%
QL Bytes/Percent 6 | 39% | 34%
QL Bytes/Percent 7 | 33% | 34%
QL Bytes/Percent 8 | 27% | 22%
QL Bytes/Percent 9 | 21% | 21%
QL Bytes/Percent 10 | 23% | 20%
QL Bytes/Percent 11 | 13% | 2%
QL Bytes/Percent 12 | 9% | 2%
QL Bytes/Percent 13 | 5% | 2%
QL Bytes/Percent 14 | 1% | 1%
QL Bytes/Percent 15 | 0% | 2%
QL Bytes/Percent 16 | 0% | 1%
QL Bytes/Percent 17 | 0% | 2%
QL Bytes/Percent 18 | 0% | 0%
-------------------------------------------------------------------
QL Prozent vs. Bytes mit 518 Bytes Packets
-------------------------------------------------------------------
Policy-map | Drop rate with PC | Drop rate with Bytes
-------------------------------------------------------------------
QL Bytes/Percent 1 | 85% | 86%
QL Bytes/Percent 2 | 97% | 81%
QL Bytes/Percent 3 | 62% | 71%
QL Bytes/Percent 4 | 54% | 68%
QL Bytes/Percent 5 | 46% | 84%
QL Bytes/Percent 6 | 52% | 54%
QL Bytes/Percent 7 | 42% | 54%
QL Bytes/Percent 8 | 27% | 43%
QL Bytes/Percent 9 | 21% | 43%
QL Bytes/Percent 10 | 17% | 43%
QL Bytes/Percent 11 | 17% | 34%
QL Bytes/Percent 12 | 8% | 35%
QL Bytes/Percent 13 | 5% | 26%
QL Bytes/Percent 14 | 1% | 23%
QL Bytes/Percent 15 | 0% | 26%
QL Bytes/Percent 16 | 0% | 34%
QL Bytes/Percent 17 | 0% | 26%
QL Bytes/Percent 18 | 0% | 2%
-------------------------------------------------------------------
QL Prozent vs. Bytes mit 800 Bytes Packets
-------------------------------------------------------------------
Policy-map | Drop rate with PC | Drop rate with Bytes
-------------------------------------------------------------------
QL Bytes/Percent 1 | 112% | 117%
QL Bytes/Percent 2 | 74% | 86%
QL Bytes/Percent 3 | 63% | 82%
QL Bytes/Percent 4 | 54% | 75%
QL Bytes/Percent 5 | 47% | 73%
QL Bytes/Percent 6 | 39% | 66%
QL Bytes/Percent 7 | 33% | 88%
QL Bytes/Percent 8 | 27% | 56%
QL Bytes/Percent 9 | 22% | 57%
QL Bytes/Percent 10 | 17% | 57%
QL Bytes/Percent 11 | 13% | 44%
QL Bytes/Percent 12 | 9% | 56%
QL Bytes/Percent 13 | 5% | 43%
QL Bytes/Percent 14 | 2% | 44%
QL Bytes/Percent 15 | 0% | 43%
QL Bytes/Percent 16 | 0% | 43%
QL Bytes/Percent 17 | 0% | 44%
QL Bytes/Percent 18 | 0% | 21%
-------------------------------------------------------------------
QL Prozent vs. Bytes mit 1024 Bytes Packets
-------------------------------------------------------------------
Policy-map | Drop rate with PC | Drop rate with Bytes
-------------------------------------------------------------------
QL Bytes/Percent 1 | 85% | 93%
QL Bytes/Percent 2 | 97% | 89%
QL Bytes/Percent 3 | 82% | 83%
QL Bytes/Percent 4 | 51% | 82%
QL Bytes/Percent 5 | 45% | 78%
QL Bytes/Percent 6 | 39% | 72%
QL Bytes/Percent 7 | 41% | 72%
QL Bytes/Percent 8 | 26% | 62%
QL Bytes/Percent 9 | 20% | 65%
QL Bytes/Percent 10 | 16% | 66%
QL Bytes/Percent 11 | 11% | 68%
QL Bytes/Percent 12 | 7% | 53%
QL Bytes/Percent 13 | 3% | 53%
QL Bytes/Percent 14 | 0% | 52%
QL Bytes/Percent 15 | 0% | 52%
QL Bytes/Percent 16 | 0% | 53%
QL Bytes/Percent 17 | 0% | 52%
QL Bytes/Percent 18 | 0% | 33%
-------------------------------------------------------------------
QL Prozent vs. Bytes mit 1400 Bytes Packets
-------------------------------------------------------------------
Policy-map | Drop rate with PC | Drop rate with Bytes
-------------------------------------------------------------------
QL Bytes/Percent 1 | 101% | 93%
QL Bytes/Percent 2 | 68% | 87%
QL Bytes/Percent 3 | 58% | 86%
QL Bytes/Percent 4 | 50% | 85%
QL Bytes/Percent 5 | 43% | 82%
QL Bytes/Percent 6 | 36% | 75%
QL Bytes/Percent 7 | 27% | 79%
QL Bytes/Percent 8 | 24% | 72%
QL Bytes/Percent 9 | 25% | 76%
QL Bytes/Percent 10 | 14% | 95%
QL Bytes/Percent 11 | 9% | 62%
QL Bytes/Percent 12 | 5% | 62%
QL Bytes/Percent 13 | 1% | 58%
QL Bytes/Percent 14 | 0% | 62%
QL Bytes/Percent 15 | 0% | 85%
QL Bytes/Percent 16 | 0% | 63%
QL Bytes/Percent 17 | 0% | 62%
QL Bytes/Percent 18 | 0% | 50%
-------------------------------------------------------------------
Beziehung zwischen Tropfen und Paketgröße
Wie bereits erwähnt, verfügt der ASR 920 über einen internen Paketpuffer von 11,75 MB, der in 45898 Qnode mit jeweils 256 Byte aufgeteilt ist.
- Für ein Paket mit einer Größe < 256 Byte wird genau 1 Qnode verwendet
- Für ein Paket der Größe 1024 Bytes werden 4 Qnode verwendet
- Bei einem Paket mit der Größe 257 Byte werden 2 Qnode verwendet und die nicht verwendeten 255 Byte gehen verloren
Daher können Sie eine geringere Menge an großen Paketen als die Menge an kleinen Paketen speichern. Die Beziehung zwischen der Verlustrate und der Paketgröße bei entsprechenden Warteschlangengrenzwerten wird erwartet.
Differenz zwischen äquivalenten Bytes und Prozentwerten
Wie bereits erläutert, befinden sich im gemeinsamen 11,75 MB großen Puffer 45898 Qnode, auf 45900 gerundet, um die Berechnung zu vereinfachen.
Bei der Berechnung des Warteschlangengrenzwerts in Prozent wird nicht der Prozentsatz der 11,75 MB, sondern der der 45900 Qnode berechnet. Warteschlangenlimit Prozent 10 bedeutet 10% von 45900, was 4590 Qnodes ergibt.
Darüber hinaus wird der Prozentsatz der zugewiesenen Qnoden als die Anzahl der Pakete betrachtet, die unabhängig von ihrer Größe in der Warteschlange gespeichert werden können. Zurück zum vorherigen Beispiel:
queue-limit percent 10 = 4590 Qnode = 4590 Pakete.
Da diese Berechnung unabhängig von der Paketgröße ist, wird für Pakete mit einer Größe von 256 Byte oder weniger nur ein Qnode verwendet und die Gleichwertigkeit zwischen Qnode und Paketen wird beibehalten:
Warteschlangenlimit Prozent 10 = 4590 Qnode = 4590 Pakete mit 256 Bytes = 4590*256 Bytes = 1,175 MB = 10% des Puffers
Bei größeren Paketen wird jedoch ein großzügigerer Teil des Puffers zugewiesen. Dies ist z. B. die Berechnung für 1024-Byte-Pakete, bei denen jedes Paket 4 Qnode beansprucht:
Warteschlangenlimit Prozent 10 = 4.590 Qnode = 4.590 Pakete mit 1.024 Byte = 4.590*4.256 Byte = 4,7 MB = 40 % des Puffers
Wenn Sie hohe Werte für den Prozentsatz der Warteschlangenbegrenzung konfigurieren, kann eine einzelne Schnittstelle vorübergehend den gesamten freigegebenen Puffer von 11,75 MB belegen.
Schlussfolgerungen
- Es ist deutlich erkennbar, dass die Effizienz von Warteschlangenlimit-Bytes bei kleinen Paketen besser ist - Warteschlangenlimit-Bytes <x> funktionieren bis zu 300 Bytes besser als Warteschlangenlimit <x>
- Bei 300-Byte-Paketen sind Warteschlangenlimit-Bytes und Warteschlangenlimit-Effizienz in Prozent identisch
- Über 300 Byte Paketgröße, Warteschlangenlimit Prozent ist effizienter. Da der Internet-Datenverkehr durchschnittlich 518 Byte beträgt, profitieren reale Szenarien mehr von der prozentualen Warteschlangenbeschränkung, wie die Kunden berichten
- Die Effizienz der Warteschlangenbegrenzung (%) verbessert sich linear in Bezug auf die Paketgröße (je größer die Pakete, desto effizienter ist die Warteschlangenbegrenzung (%) im Vergleich zu den Warteschlangenbegrenzungsbytes).
- Der Warteschlangengrenzwert (%) wird als großzügiger bei der Pufferspeicherzuweisung für Pakete mit einer Größe von über 256 MB implementiert.
Wie man die Prozentwerte in realen Verkehrsszenarien annimmt
Wenn Sie Pakete mit einer Größe von 256 Byte und einem Warteschlangenlimit von 10 % haben, wissen Sie bereits, dass diese Entsprechung gültig ist:
minimum queue-limit = 4590 Qnodes = 4590*256 bytes = 1.175 MB = 10% of the buffer
Bei 512-Byte-Paketen ist die Auslastung nur doppelt so groß, bei 1024-Byte-Paketen ist sie viermal so groß, und so weiter.
Das bedeutet, dass die tatsächliche Warteschlangengrenze mindestens 10 % des Puffers beträgt. Wenn Sie eine maximale MTU von 1.500 Byte annehmen, benötigen Sie 6 Qnodes, um ein einzelnes Paket zu speichern. Dies ergibt eine maximale Warteschlangengrenze von:
maximum queue-limit = 4590*6 Qnodes = 4590*256*6 bytes = 7.05 MB = 60% of the buffer
Auf diese Weise können Sie die unteren und oberen Grenzen der Puffernutzung mit dem Warteschlangengrenzwert in Prozent 10 definieren, sodass die durchschnittliche maximale Puffernutzung im Allgemeinen in etwa wie folgt aussieht:
ceil(avg_pkt_size/256)*((qlimit_percent/45900)*100)
Beispiel aus einem Laborgerät:
GigabitEthernet0/0/1 is up, line protocol is up
Hardware is 24xGE-4x10GE-FIXED-S, address is 70df.2f2f.ed01 (bia 70df.2f2f.ed01)
Internet address is 10.12.10.47/31
MTU 8900 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 25/255, rxload 30/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full Duplex, 1000Mbps, link type is auto, media type is T
output flow-control is unsupported, input flow-control is on
Carrier delay is 0 msec
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:01, output hang never
Last clearing of "show interface" counters 00:11:43
Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 2036062
Queueing strategy: Class-based queueing
Output queue: 0/40 (size/max)
30 second input rate 118520000 bits/sec, 18902 packets/sec
30 second output rate 101646000 bits/sec, 16124 packets/sec
13185272 packets input, 10328798549 bytes, 0 no buffer
Received 0 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 235 multicast, 0 pause input
11247114 packets output, 8870166880 bytes, 0 underruns <<< avg_pkt_size = 8870166880/11247114 = 788.66 bytes
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
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
Sie können avg_pkt_size als 8870166880/11247114 ~ 788 Bytes berechnen.
Bei einer Warteschlangenbeschränkung von 10 % beträgt die durchschnittliche maximale Puffernutzung:
ceil(avg_pkt_size/256)*((45900/100)*qlimit_percent)
Calculation example with Python:
>>> import math
>>> math.ceil(788/256)*((45900/100)*10)
18360.0
=> 18360 Qnodes = 18360 * 256 bytes = 4.7 MB = 40% of the buffer
Überprüfen der Verwendung des Microburst-Puffers
In Cisco IOS-XE-Versionen vor 16.9.3 wurde der gemeinsame Puffer der Schnittstellen für Daten- und Steuerungspakete (z. B. BFD, Routing-Protokolle, ARP, LDP, Punt-Keepalives) verwendet. Um die Verwendung des Sofortpuffers zu überprüfen, können Sie folgenden Befehl verwenden:
ASR-920-1#request platform software sdcli "nile bm reg buffertablefreelistcount show 0 0 0"
Nach 16.9.3 wurden einige Änderungen eingeführt, um die Puffernutzung zu verbessern, und es wurde in 2 aufgeteilt: 1024 Einträge (256 KB) wurden für Kontrolldatenverkehr und der Rest für Datenverkehr reserviert.
Die Puffernutzung kann in diesem Fall mit den folgenden Befehlen überwacht werden:
ASR-920-1#request platform software sdcli "nile bm reg supervisorresourcereservedcounttableaccess sh 0 0 0"
reservedUsedCount = 48 (0x30)
reservedFreeCount = 976 (0x3d0)
ASR-920-1#request platform software sdcli "nile bm reg supervisorresourcereservedcounttableaccess sh 0 2 0"
reservedUsedCount = 8114 (0x1fb2)
reservedFreeCount = 37784 (0x9398)
Da der Puffer Microbursts behandelt, müssen Sie den Befehl mehrmals wiederholen, um den reservierten UsedCount-Wert zu sehen, der sich von 0 unterscheidet.
Die Pufferverwendung kann einfach mit reservedUsedCount/reservedFreeCount berechnet werden, z. B. 8114/37784 = 21,5 % verwendet. Sobald der Burst beendet ist, muss der Puffer schnell auf 0 oder nahe daran zurückfallen.
Ab Cisco IOS-XE Version 17.6.1 ist es möglich, den gesamten Puffer sowohl für Daten- als auch für Kontrolldatenverkehr zu verwenden (vorzugsweise bei einer hohen Kontrolldatenverkehrsrate im Netzwerk) oder den Puffer wie zuvor beschrieben in 2 aufzuteilen. Die Auswahl erfolgt mit der Konfiguration dieser Anweisung (standardmäßig deaktiviert):
ACDC-920-1(config)#platform qos-buffer enhance enable
ACDC-920-1(config)#no platform qos-buffer enhance enable
Ab Cisco IOS-XE Version 17.7.1 kann die Größe, die dem Steuerungsdatenverkehr zugewiesen werden soll, auch ausgewählt werden:
ACDC-920-1(config)#platform qos-buffer enhance [1-4]
Hierbei gilt:
- 1 gibt Steuerungspuffer von 256 KB an
- 2 steht für 500 KB
- 3 steht für 756 KB
- 4 = 1 MB
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
1.0 |
10-Oct-2022 |
Erstveröffentlichung |
Feedback