In diesem Dokument wird erläutert, wie Sie eine Fehlerbehebung durchführen können, wenn die Ausgabe des Befehls show interfaces auf einem Cisco Internet Router der Serie 12000 immer mehr ignorierte Fehler anzeigt. Darüber hinaus enthält sie Tipps zur Fehlerbehebung für eine zunehmende Anzahl von nicht fehlenden Speicher in der Ausgabe des Ausführungssteckplatzes<Steckplatz#> Show-Controllers (Fab) | tofab) qm stat-Befehl. Überprüfen Sie bei der Fehlerbehebung, ob der Zähler inkrementiert ist und nicht nur ein Verlaufswert ist.
Hinweis: Eine wachsende Anzahl von Drop-Vorgängen der Eingangswarteschlange, wie in der Ausgabe der show interfaces angezeigt, wird separat unter Troubleshooting Input Drops (Fehlerbehebung) auf dem Cisco Internet Router der Serie 1200 behandelt.
Dieses Dokument erfordert ein Verständnis der Cisco Internet Router-Architektur der Serie 1200, insbesondere der ToFab- und FrFab-Warteschlangen. Siehe How To Read the Output of the show controllers (Ausgabe der Controller lesen) auf der Registerkarte | Befehle für die Warteschlange tofab als Referenz.
Die Informationen in diesem Dokument basieren auf den unten stehenden 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, 12410 und 12416.
Die in diesem Dokument enthaltenen Informationen wurden aus Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Sie in einem Live-Netzwerk arbeiten, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen, bevor Sie es verwenden.
Weitere Informationen zu Dokumentkonventionen finden Sie in den Cisco Technical Tips Conventions.
Der Cisco Internet Router der Serie 12000 verwendet eine verteilte Architektur, um eine optimale Weiterleitungsleistung sicherzustellen. Zur Unterstützung hoher Weiterleitungsraten werden sowohl auf den ein- als auch auf den ausgehenden Linecards Paketpuffer verwaltet. Diese Paketpuffer sind unterschiedlich groß und dienen im Allgemeinen zur Unterstützung von Frames mit MTU-Größe (Maximum Transmission Unit).
Nachdem er die ausgehende Schnittstelle für ein Paket ermittelt hat, führt der Forwarding-Prozessor folgende Schritte aus:
Der Forwarding-Prozessor sendet einen Pointer mit Informationen über das Paket (einschließlich seines Speicherorts) an die virtuelle Ausgabewarteschlange der ausgehenden Schnittstelle.
Der Scheduler der Linecard stellt eine Anfrage an den Scheduler. Der Scheduler gibt einen Zuschuss aus, und das Paket wird vom Pufferspeicher über die Switching-Fabric an die ausgehende Linecard gesendet.
Die ausgehende Line Card puffert die Pakete.
Der L3-Prozessor und die zugehörigen ASICs (Application-Specific Integrated Circuits) am ausgehenden LC übertragen das Paket über die Schnittstelle.
Wenn die ausgehende Schnittstelle überbelegt ist, beginnt sie, die überzähligen Pakete zu puffern. Während Zeiten einer anhaltenden Überbelegung füllen sich die Übertragungswarteschlangen der ausgehenden LCs aus. In dieser Bedingung geschieht je nach ausgehendem LC Folgendes:
Engine Typ des ausgehenden LC | Reaktion auf ausgehende Überlastung | Fehlerzähler |
---|---|---|
Engine 0 und 1 | Sendet ein Rückdrucksignal. Die Schnittstelle für eingehende Anrufe puffert die überzähligen Pakete. | Fehler in der Befehlsausgabe der show interfaces und/oder keine Speicherverluste im Ausführungssteckplatz <Steckplatz#> zeigen Controllern an, um die QM-STATUS-Befehlsausgabe des eingehenden LCs, je nach dessen L3-Weiterleitungs-Engine, auszugeben.¹ |
Engine 2, 3, 4 | Löscht alle überzähligen Pakete am Ausgang. | Keine Speicherverluste im Ausführungssteckplatz <Steckplatz#> zeigen die Controller in der QM-Befehlsausgabe des ausgehenden LCs. |
¹ Fehler für L3-Engines 0, 1 und 2 Eingangs-LCs werden ignoriert. Bei vier, 16 und mehr Ports an LCs der Engine 2 erhöht sich der ignorierte Zähler jedoch nicht.
Wenn eine oder mehrere Hochgeschwindigkeits-Schnittstellen auf einem intelligenten Netzwerkgerät eine Schnittstelle mit relativ niedriger Geschwindigkeit bereitstellen, kommt es zu Abweichungen bei den Schnittstellenraten. Da die Schnittstelle für ausgehenden Datenverkehr mit langsamerer Geschwindigkeit Puffer nicht so schnell zurückgeben kann, wie sie von der Schnittstelle für den schnelleren eingehenden Datenverkehr an die Warteschlange für den Ausgabewarteschlangen gesendet werden, führt eine Verzögerung bei der Pufferrückgabe zu Verwerfungstypen. Dieser Paketfluss unterbricht die Annahme, dass die ausgehende Schnittstelle den Puffer mit der Geschwindigkeit der Puffer-Management-Zeit zurückgibt.
Zusätzlich zu einer Abweichung bei den Schnittstellenraten können ignorierte Fehler zunehmen, wenn die Rate der ankommenden Pakete größer ist, als die CPU sie verarbeiten kann. Diese Bedingung ist beim Cisco 1200 sehr selten und wird in der Regel durch eine große Anzahl sehr kleiner Pakete verursacht. Wenn eine CPU-intensive Funktion, z. B. Zugriffskontrolllisten (ACLs) oder Datenverkehrsüberwachung, auf einem LC aktiviert ist, das diese Funktionen in der Software implementiert. Dies gilt für LCs der Engine 0, bei denen viele Funktionen in der Software implementiert sind. Bei späteren Engines werden jedoch fast alle Funktionen in der Hardware implementiert. Beispielsweise sind die Line Cards Engine 3 (IP Services Engine - ISE) und Engine 4+ für Edge-Anwendungen konzipiert und implementieren erweiterte IP-Services (wie Quality of Service - QoS) in der Hardware, ohne dass die Leistung beeinträchtigt wird. Beispiele für diese Hardware sind die 1-Port CHOC-48 ISE, die 4-Port CHOC-12 ISE, die 16-Port OC-3 POS ISE, die 4-Port OC-12 POS ISE, die 1-Port OC-48 POS ISE und die 1-Port OC-48 POS ISE.
Der ignorierte Zähler kann auch erhöht werden, wenn ein Paket auf einer Eingangs-Linecard eingeht und kein geeigneter Paketpuffer für die Verarbeitung dieses Pakets verfügbar ist. Diese Bedingung ist jedoch sehr selten und wird in diesem Dokument nicht behandelt.
Die Lösung, Fehler zu ignorieren und keine Speicherverluste aufgrund einer Überbelegung der Ausgabeschnittstelle zu vermeiden, ist für jeden L3-Modultyp die gleiche: Pufferspeicherknappheit verhindern. Mit anderen Worten, wir brauchen einen Mechanismus, der verhindert, dass die FrFab-Warteschlangen gefüllt werden.
Einfach ausgedrückt wird der ignorierte Zähler erhöht, wenn ein Paket auf einer Eingangs-Linecard (LC) eingeht und kein geeigneter Paketpuffer für die Verarbeitung dieses Pakets verfügbar ist. Daher weisen ignorierte Pakete in der Regel nicht auf einen Fehler in der Cisco IOS-Software hin.
Hier sehen Sie eine Beispielausgabe des Befehls show interfaces mit einem nicht null ignorierten Zähler auf einem Cisco Router der Serie 12000:
router#show interfaces G3/0 GigabitEthernet3/0 is up, line protocol is up Hardware is GigMac GigabitEthernet, address is 0030.71f5.7980 (bia 0030.71f5.7980) MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, rely 255/255, load 1/255 Encapsulation ARPA, loopback not set Keepalive not set Full-duplex mode, link type is force-up, media type is SX output flow-control is unsupported, input flow-control is unsupported ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters 00:00:07 Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 99000 bits/sec, 74 packets/sec 5 minute output rate 104000 bits/sec, 68 packets/sec 478 packets input, 71057 bytes, 0 no buffer Received 19 broadcasts, 0 runts, 0 giants, 0 throttles 2 input errors, 2 CRC, 0 frame, 0 overrun, 25 ignored !--- Ignored counter is > 0. Ensure it is incrementing. 0 watchdog, 53 multicast, 0 pause input 541 packets output, 139133 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
Wenn es sich bei dem ausgehenden LC um die Engine 0 oder 1 handelt, sendet er eine Rückdruckmeldung an die anderen LCs, die sie auffordert, keine Daten mehr an diesen LC zu senden. Die eingehende Schnittstelle puffert dann die überschüssigen Pakete in ihren ToFab-Warteschlangen, die diesem Zielsteckplatz entsprechen.
Um die wahrscheinlichste Ursache für die Erhöhung des Zählers "Ignoriert" zu ermitteln, müssen Sie sich die ToFab-Warteschlangen des Eingangs-LC ansehen. Sie können den LC entweder über den Maintenance BUS (MBUS) mit dem Befehl Attach (Attach) anschließen oder den Befehl Execute Slot <slot#> Show Controller verwenden, um die ToFab-Warteschlangen zu überprüfen. Führen Sie diesen Befehl mehrmals aus, und achten Sie auf die folgenden Symptome:
Ein abnehmender und niedriger Wert oder Wert von 0 in der #Qelem-Spalte einer nicht IPC-freien Warteschlange
Ein großer Wert in der Spalte #Qelem in einer Warteschlange für Zielsteckplätze.
Linecards, die eine neuere L3-Engine-Architektur verwenden, verwenden keinen Rückdruckmechanismus. Wenn die Schnittstelle überbelegt ist und eine FrFab-Warteschlange erschöpft ist, werden die Pakete stattdessen einfach verworfen, sobald sie auf der Ausgangs-Linecard eintreffen.
LCs der Engine 2 gehen nicht auf den nächsten größeren Pufferpool zurück, wenn ein kleinerer Pool erschöpft ist. Der Rückfallmechanismus wurde nur für LCs der Engine 2 auf der ToFab-Seite (Rx) implementiert. In diesem Fall erhöht sich der Zähler "Bump count" (Sammelanzahl) in der Ausgabe des Befehls Execution-on-Steckplatz "show controller tofab QM stat".
Diese Drops zählen als kein fehlendes Element in der Ausgabe des Befehls Execute-On-Steckplatz <slot#> show controller frab QM stat, wie unten gezeigt:
Router#execute-on slot 1 show controller frfab QM stat ========= Line Card (Slot 1) ======= 174 no mem drop, 0 soft drop, 0 bump count !--- Look for an incrementing value for the "no mem drop" counter 0 rawq drops, 0 global red drops, 0 global force drops 0 no memory (ns), 0 no memory hwm (Ns) no free queue 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 multicast drops Tx Counts Interface 0 8390658710246 TX bytes, 2098330790 TX pkts, 212452 kbps, 6641 pps Interface 1 0 TX bytes, 0 TX pkts, 0 kbps, 0 PPS Interface 2 0 TX bytes, 0 TX pkts, 0 kbps, 0 PPS Interface 3 0 TX bytes, 0 TX pkts, 0 kbps, 0 PPS
Sie müssen einen Weg finden, um zu verhindern, dass die FrFab-Seite die Pakete an den Punkt puffert, an dem der LC entweder die eingehende Schnittstelle sichert oder einfach die Pakete verwirft.
Eine einfache Lösung für alle Linecards, mit Ausnahme von Engine 2-LCs, besteht darin, die Anzahl der Puffer zu reduzieren, die für eine bestimmte ausgehende Schnittstelle in einem LC mit mehreren Schnittstellen verfügbar sind. Standardmäßig kann eine Schnittstelle alle geschnitzten FrFab-Puffer verwenden. Verwenden Sie den Befehl tx-queue-limit, um einen nicht standardmäßigen Wert zu konfigurieren. Dadurch wird verhindert, dass der Egress-LC mehr Pakete als die konfigurierte Anzahl an Paketen in der Schnittstellenwarteschlange für diesen bestimmten Port puffert. Stellen Sie sicher, dass Sie diese Zahl so niedrig konfigurieren, dass sie nicht alle FrFab-Warteschlangen für diese Schnittstelle enthält. Beachten Sie, dass diese Methode nicht zwischen Paketen mit hoher und niedriger Priorität differenziert und für eine bestimmte Schnittstelle lediglich die Tail-Drop-Funktion aggressiver implementiert.
Für Modul 3-Linecards muss anstelle der vorhandenen CLI (Command Line Interface) die modulare QoS-CLI (MQC) verwendet werden. Dieser Befehl wird auf Engine 2-basierten Linecards nicht unterstützt.
Im folgenden Konfigurationsbeispiel wird die Legacy Class of Service (CoS)-Konfiguration verwendet:
interface POS 0/0 tx-queue-limit <max Q length in packets>
Im folgenden Konfigurationsbeispiel wird MQC verwendet:
policy-map TX_QUEUE_LIMIT class class-default queue-limit interface POS 0/0 service-policy out TX_QUEUE_LIMIT
Eine weitere Lösung ist die Implementierung einer schnelleren Ausgabeschnittstelle, was uns eine größere Pipe verschafft. Aber größere Rohre können schnell gefüllt werden. Daher wird empfohlen, auf dem ausgehenden LC Quality of Service (QoS)-Mechanismen zu implementieren.
Die WRED-Funktion (Weighted Random Early Detection) von Cisco implementiert einen differenzierten oder intelligenten Drop-Mechanismus. Es wurde für adaptiven Datenverkehr wie TCP-Datenflüsse entwickelt. Die Warteschlangengröße wird überwacht und eine konsistente durchschnittliche Warteschlangengröße beibehalten, indem Pakete nach dem Zufallsprinzip aus verschiedenen Datenflüssen verworfen werden, wenn die berechnete durchschnittliche Warteschlange einen konfigurierbaren Mindestwert überschreitet.
Wenn WRED auf der Cisco Serie 12000 implementiert wird, kann es verhindern, dass die FrFab-Warteschlangen gefüllt werden, und es ist wichtig, dass ausgewählt wird, welche Pakete verworfen werden. Engine 0-LCs unterstützen WRED in der Software, während Engine 1-LCs WRED überhaupt nicht unterstützen. Die anderen L3-Engine-LCs unterstützen WRED in der Hardware.
Weitere Informationen zum Konfigurieren von WRED finden Sie in den folgenden Dokumenten:
Weighted Random Early Detection auf dem Cisco Router der Serie 12000
Konfigurieren von MPLS CoS auf einem Cisco GSR Router der Serie 1200
Dieser Überlastungsvermeidungsmechanismus funktioniert nur in einer TCP-basierten Umgebung. TCP reagiert angemessen - sogar robust - auf Datenverkehrseinbrüche, indem es die Datenübertragung verlangsamt. Weitere Informationen zur Reaktion von TCP auf Paketverluste finden Sie unter Wie TCP Datenverkehrsverluste verarbeitet und wie der Router mit TCP interagiert.
Ein weiterer unterstützter QoS-Mechanismus bei der Cisco Serie 1200 ist die Datenverkehrsüberwachung mithilfe von Committed Access Rate (CAR) auf LCs der Engine 0 und Engine 1 sowie eine modifizierte Version der CAR, die als Per Interface Rate Control (PIRC) für LCs der Engine 2 bezeichnet wird. Konfigurieren Sie die Datenverkehrsüberwachung an der ausgehenden Schnittstelle.
Diese Situation ist sehr selten!
Sie können mithilfe des Befehls Execute-On-Steckplatz <slot#> show controller tofab queues überprüfen, ob die CPU auf dem eingehenden LC überlastet ist. Wenn Sie eine sehr große Zahl in der Spalte #Qelem der Zeile "Raw Queue" sehen, bedeutet dies, dass zu viele Pakete von der CPU verarbeitet werden sollen (die sich auf dem LC selbst befindet). Sie werden dann ignorierte Pakete erhalten, da die CPU nicht mit der Paketmenge Schritt halten kann. Diese Pakete werden an die CPU des LC und nicht an den Gigabit Route Processor (GRP) weitergeleitet!
Zu diesem Zeitpunkt müssen Sie einen Teil des Datenverkehrs von diesem eingehenden LC verschieben, sodass dessen CPU weniger beeinträchtigt ist.
Sie sollten sich auch die LC-Konfiguration ansehen, um festzustellen, ob einige konfigurierte Funktionen Auswirkungen auf die CPU haben. Einige Funktionen (z. B. CAR, ACL und NetFlow) können die Leistung des LCs beeinträchtigen, wenn sie in der Software implementiert ist (nur bei Engine 0-LCs). In diesem Fall sollten Sie entsprechend handeln, indem Sie entweder die Funktion entfernen oder die Cisco IOS-Software auf eine neuere Version aktualisieren, bei der die gleiche Funktionsimplementierung verbessert wird (z. B. Turbo ACL). In den Versionshinweisen der Cisco Router der Serie 1200 erfahren Sie, welche Funktionen für die verschiedenen LCs implementiert oder verbessert wurden.
Schließlich kann die einzige Lösung darin bestehen, den LC gegen eine neuere zu tauschen, wenn die angeforderte Funktion in der Hardware implementiert ist. Dies hängt vom Modultyp des LC ab.
Sie können den folgenden Befehl verwenden, um den L3-Modultyp eines LC zu bestimmen:
Router#show diag | i (SLOT | Engine) ... SLOT 1 (RP/LC 1 ): 1 port ATM Over SONET OC12c/STM-4c Multi Mode L3 Engine: 0 - OC12 (622 Mbps) SLOT 3 (RP/LC 3 ): 3 Port Gigabit Ethernet L3 Engine: 2 - Backbone OC48 (2.5 Gbps) ...
Hinweis: Line Cards der Engine 3 (IP Services Engine - ISE) und Engine 4+ wurden für Edge-Anwendungen entwickelt und implementieren erweiterte IP-Services (wie QoS) in der Hardware ohne Leistungseinbußen.
Verwenden Sie Turbo ACLs, die die Leistung optimieren, indem der Router die ACLs kompilieren kann, bevor er sie auf den LC-Prozessor herunterlädt.
Vermeiden Sie die Verwendung des Schlüsselworts "log" auf ACLs.
Wenn möglich sollten Sie ausgehende ACLs vermeiden. In einem System mit LCs der Engine 0, 1 und 2 erfolgt die gesamte Verarbeitung von ACLs auf dem eingehenden LC. Auch die Filterung ausgehender ACLs erfolgt auf der eingehenden Karte, sobald bekannt ist, an welche ausgehende Schnittstelle das Paket bestimmt ist. Aus diesem Grund betrifft die Konfiguration einer ausgehenden ACL auf einer Schnittstelle alle LCs im System. Darüber hinaus können Engine-2-LCs eingehende oder ausgehende ACLs ausführen, jedoch nicht beide gleichzeitig im ASIC, der die Hardware-Weiterleitung durchführt. Wenn Sie sowohl eingehende als auch ausgehende ACLs konfigurieren, greift der LC auf die CPU-basierte Weiterleitung für ausgehende Zugriffslisten zurück, was sich auf die Switching-Leistung des LC auswirkt. Neuere Engines wie Engine 3 und Engine 4+ sind jedoch für erweiterte IP-Services wie ACLs und die Verarbeitung ausgehender ACLs auf dem ausgehenden LC hochoptimiert.
Zuweisung von Datenverkehr, der bestimmte Funktionen erfordert, zu einem Satz von LCs
Zuweisen von Datenverkehr, der keine Funktionen erfordert, zu einem anderen Satz von LCs, um die Spitzenleistung bei der Paketweiterleitung aufrechtzuerhalten.
Verwenden Sie LCs mit höherem Modultyp, wenn eine hohe Leistung erforderlich ist.
Entwicklung von Backbone- oder Core-LCs zur Ausführung von Hardware- oder Mikrocode-unterstützten Funktionen
In dieser Fallstudie wird gezeigt, wie Sie Fehler beheben können, wenn Sie in einer LC-Schnittstelle in Steckplatz 6 ignorierte Fehler hinzufügen.
Router#exec slot 6 show controllers tofab queue ========= Line Card (Slot 6) ======= Carve information for ToFab buffers SDRAM size: 134217728 bytes, address: 30000000, carve base: 30019100 134115072 bytes carve size, 4 SDRAM bank(s), 8192 bytes SDRAM pagesize, 2 carve(s) max buffer data size 4544 bytes, min buffer data size 80 bytes 174538/174538 buffers specified/carved 110797216/110797216 bytes sum buffer sizes specified/carved Qnum Head Tail #Qelem LenThresh ---- ---- ---- ------ --------- 4 non-IPC free queues: 88964/88964 (buffers specified/carved), 50.97%, 80 byte data size 1 21120 84604 81074 262143 54076/54076 (buffers specified/carved), 30.98%, 608 byte data size 2 122270 116965 49567 262143 26165/26165 (buffers specified/carved), 14.99%, 1568 byte data size 3 164160 145355 19518 262143 !-- Out of the 26165 buffers that are carved, only 19518 are available 5233/5233 (buffers specified/carved), 2.99%, 4544 byte data size 4 172325 172088 5233 262143 IPC Queue: 100/100 (buffers specified/carved), 0.5%, 4112 byte data size 30 61 60 100 262143 Raw Queue: 31 44229 88895 0 43634 !-- The Raw Queue has a low or 0 value for the #Qelem column, indicating !-- that the CPU is not overwhelmed with packets destined to it. ToFab Queues: Dest Slot 0 73769 60489 0 262143 1 7909 27395 0 262143 2 61416 71346 0 262143 3 80352 14567 0 262143 4 138236 107121 18955 262143 !-- 18955 packets are waiting for space in the outbound queues !-- on the LC in slot 4. 5 4852 48171 0 262143 6 98318 111757 0 262143 7 44229 88895 0 262143 8 0 0 0 262143 9 0 0 0 262143 10 0 0 0 262143 11 0 0 0 262143 12 0 0 0 262143 13 0 0 0 262143 14 0 0 0 262143 15 0 0 0 262143 Multicast 0 0 0 262143
Da die ToFab-Warteschlangenausgabe eine große Anzahl von Warteschlangenpaketen für das LC in Steckplatz 4 anzeigt, überprüfen Sie die FrFab-Warteschlangen in diesem LC.
Router#exec slot 4 show controllers frfab queue ========= Line Card (Slot 4) ======= Carve information for FrFab buffers SDRAM size: 67108864 bytes, address: 20000000, carve base: 2002D100 66924288 bytes carve size, 0 SDRAM bank(s), 0 bytes SDRAM pagesize, 2 carve(s) max buffer data size 4544 bytes, min buffer data size 80 bytes 65534/65534 buffers specified/carved 66789056/66789056 bytes sum buffer sizes specified/carved Qnum Head Tail #Qelem LenThresh ---- ---- ---- ------ --------- 4 non-IPC free queues: 26174/26174 (buffers specified/carved), 39.93%, 80 byte data size 1 10123 4332 14515 65535 19630/19630 (buffers specified/carved), 29.95%, 608 byte data size 2 27898 37167 12279 65535 13087/13087 (buffers specified/carved), 19.96%, 1568 byte data size 3 0 52275 0 65535 !-- Zero buffers available for this pool 6543/6543 (buffers specified/carved), 9.98%, 4544 byte data size 4 60805 60804 6543 65535 IPC Queue: 100/100 (buffers specified/carved), 0.15%, 4112 byte data size 30 75 74 100 65535 Raw Queue: 31 0 80 0 65535 Interface Queues: 0 0 39413 0 65535 1 0 44192 0 65535 2 48426 58230 32111 65535 !-- Interface 2 is using half or 32111 of the carved packet buffers 3 0 41219 0 65535
Ordnen Sie die überbelegte Schnittstelle, die in der Ausgabe der show controller-Gruppenwarteschlange angegeben ist, der Ausgabe der show interfaces für dieselbe Schnittstelle zu. Die folgende Ausgabe bestätigt, dass die Ausgangsschnittstellenrate die Leitungsgeschwindigkeit erreicht und überbelegt ist:
Router#show interfaces POS 4/2 POS4/2 is up, line protocol is up Hardware is Packet over SONET Description: Pacbell OC3 to other ISP... Internet address is 10.10.10.10/30 MTU 4470 bytes, BW 155000 Kbit, DLY 100 usec, rely 255/255, load 156/255 Encapsulation HDLC, crc 32, loopback not set Keepalive set (10 sec) Scramble enabled Last input 00:00:01, output 00:00:03, output hang never Last clearing of "show interface" counters never Queueing strategy: FIFO Output queue 0/300, 0 drops; input queue 0/300, 0 drops 5 minute input rate 20274000 bits/sec, 6263 packets/sec 5 minute output rate 148605000 bits/sec, 28776 packets/sec !-- The output interface rate is at line rate which means that the interface !-- is oversubscribed. 1018621328 packets input, 2339977099 bytes, 0 no buffer Received 0 broadcasts, 1 runts, 0 giants, 0 throttles 0 parity 1 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 378645 packets output, 156727974 bytes, 0 underruns 0 output errors, 0 applique, 0 interface resets 0 output buffer failures, 0 output buffers swapped out 1 carrier transitions
In den Projektmappenabschnitten dieses Dokuments finden Sie die nächsten Schritte zum Beheben von zunehmend ignorierten Fehlern, die auf der Architektur der jeweiligen ausgehenden Schnittstelle basieren. Versuchen Sie beispielsweise, auf einem LC der Engine 0 einen Teil des Datenverkehrs an eine andere Schnittstelle umzuleiten oder, als temporäre Maßnahme, die Anzahl der Paketpuffer zu reduzieren, die diese Schnittstelle aus den freien Warteschlangen der Linecard verwenden kann. Verwenden Sie den folgenden Befehl:
Router(config)#int POS 4/2 Router(config-if)#tx-queue-limit 5000
In manchen Fällen erhöht sich die Zählerzahl aufgrund eines Cisco IOS-Softwarefehlers. Stellen Sie sicher, dass Sie die neueste verfügbare Cisco IOS-Softwareversion in Ihrem Zug ausführen, um alle bereits behobenen Fehler zu beseitigen. Wenn Sie weiterhin ignorierte Pakete sehen und die Informationen in diesem Dokument Ihr Problem nicht beheben, wenden Sie sich an das Cisco Technical Assistance Center (TAC), um Unterstützung zu erhalten.