VIP-CPU mit 99 % und Rx-Side-Buffering

Einführung

In diesem Dokument wird erläutert, warum die VIP-CPU (Versatile Interface Processor) mit 99 % ausgeführt wird und was Rx-seitige Puffer sind.

Voraussetzungen

Anforderungen

Für dieses Dokument bestehen keine speziellen Anforderungen.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardwareversionen beschränkt.

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

Rx-Side-Pufferung ist der Prozess, der auftritt, wenn die ausgehende Schnittstelle:

• ist überlastet.

• verwendet die First in, First Out (FIFO)-Warteschlangenstrategie.

Der VIP-Prozessor (Inbound Versatile Interface Processor) verwirft das Paket nicht sofort. Stattdessen puffert es das Paket in seinem Paketspeicher, bis Puffer für die ausgehende Schnittstelle verfügbar sind. Je nach VIP-Typ kann der Paketspeicher Static RAM (SRAM) oder Synchronous Dynamic RAM (SDRAM) sein.

Architekturgrundlagen der Cisco Serie 7500

Jeder Schnittstellenprozessor (Legacy-IP oder VIP) verfügt über eine Verbindung zu einem erweiterten Hochgeschwindigkeits-Systembus, dem so genannten CyBus. Route/Switch Processors (RSPs) sind mit zwei CyBuses verbunden (siehe Abbildung 1).

Abbildung 1: Architektur der Cisco Serie 7500

Arten von Paketpuffern

In diesem Abschnitt werden die verschiedenen Arten von Paketpuffern beschrieben.

• System-Puffer im Prozessorspeicher des RSP

  Diese Puffer werden für prozessgesteuerte Pakete verwendet. Sie können diese Puffer in der Ausgabe der show-Schnittstellen (Eingabe- und Ausgabewarteschlangen) und in der Anzeige von Puffern-Befehlen sehen. Ein Cisco Router der Serie 7500 darf nicht viel Prozessumschaltung leisten. Wenn Sie also Probleme mit Systempuffern haben, bedeutet dies, dass zu viele Pakete an die Prozessebene gesendet werden. Dies kann auf zahlreiche Faktoren zurückzuführen sein, z. B.:

  • Ein Broadcast-Sturm

  • Instabilität des Netzwerks, die Routing-Updates verursacht

  • Ein DoS-Angriff (Denial of Service)

  • Eine Funktion, die im Fast-Switching-Pfad nicht unterstützt wird (z. B. X.25)

  • IP-Pakete mit Optionen

  Weitere Informationen zur Fehlerbehebung bei übermäßigem Prozesswechsel finden Sie in den folgenden Dokumenten:

  • Fehlerbehebung bei hoher CPU-Auslastung auf Cisco Routern

  • Fehlerbehebung: Verwerfen von Eingangswarteschlangen und Ausfall von Ausgabewarteschlangen

• Paketspeicher auf RSP (MEMD)-Puffern

  Die MEMD-Größe ist auf dem RSP7000, RSP1, RSP2 und RSP4 auf 2 MB festgelegt. Auf dem RSP8 und dem RSP16 beträgt die MEMD-Größe 8 MB. Das MEMD wird zum Zeitpunkt des Hochfahrens auf alle Schnittstellen verteilt, wenn es eine Online Insertion and Removal (OIR), ein Neuladen des Mikrocodes, eine Änderung der maximalen Übertragungseinheit (MTU) oder einen Bus-Komplex gibt. Weitere Informationen zum Buskomplex finden Sie unter What Causes a "%RSP-3-RESTART: cbus complex"?. Sie können den Befehl show controller cbus verwenden, um den Status von MEMD-Puffern zu überprüfen.

  Wenn MEMD zugewiesen wird, werden folgende Strukturen erstellt:

  • Eine lokale freie Warteschlange (lfriq) - Diese wird jeder Schnittstelle zugewiesen und für Pakete verwendet, die auf dieser Schnittstelle empfangen werden.

  • Eine globale freie Warteschlange (gfriq) - Sie wird ebenfalls zugewiesen, und eine Schnittstelle kann innerhalb einiger Grenzen auf diese Warteschlange zurückgreifen.

  • Eine Übertragungswarteschlange (txqueue oder txq) - Diese wird jeder Schnittstelle zugewiesen und für Pakete verwendet, die diese Schnittstelle durchlaufen.

  • The Transmit Akkumulator (txacc) - Dieser Wert stellt die Anzahl der Elemente in der Ausgabeschnittstellen-Übermittlungswarteschlange (txqueue) dar. Wenn der Übertragungs-Akkumulator (txacc) der Übertragungsgrenze (txlimit) entspricht, werden alle Puffer freigegeben. Wenn der txacc 0 ist, ist die Warteschlange voll, und es ist keine Warteschlange mehr zulässig.

• Paketspeicher

  Auf einem VIP enthält der Paketspeicher Paketpuffer (Partikel), die für Pakete verwendet werden, die von einer VIP-Schnittstelle empfangen oder an diese gesendet werden. Abbildung 2 zeigt den Paketfluss.

  Abbildung 2: Paketfluss

  

  Dieser Abschnitt konzentriert sich auf ein VIP, bei dem verteiltes Switching aktiviert ist, da die Rx-seitige Pufferung normalerweise erfolgt, wenn ein Paket diesem Switching-Pfad folgt. Es sind verschiedene Szenarien möglich, die hier erläutert werden:

  Szenario 1: Wenn die ausgehende Schnittstelle nicht überlastet wird.

  • Ein Paket wird auf einem Port-Adapter (PA) empfangen und in einen Paket-Puffer im Paketspeicher verschoben.

  • Wenn das VIP das Paket nicht verteilen-kann, leitet es das Paket an den RSP weiter, der die Switching-Entscheidung trifft.

  • Wenn das VIP die Switching-Entscheidung treffen kann und sich die ausgehende Schnittstelle im selben VIP befindet, wird das Paket an die ausgehende Schnittstelle gesendet. Das Paket wird im VIP als "lokal geswitcht" bezeichnet, da es den Bus nicht überquert.

  • Wenn das VIP die Switching-Entscheidung treffen kann und sich die ausgehende Schnittstelle in einem anderen Steckplatz befindet, versucht das VIP, das Paket über den Bus in die txqueue (in MEMD) der ausgehenden Schnittstelle zu kopieren.

  • Das Paket wird dann über den Bus in die ausgehende (V)IP kopiert und an die Leitung gesendet.

  Szenario 2: Wenn die ausgehende Schnittstelle überlastet ist.

  Es gibt zwei Möglichkeiten:

  • Wenn die Warteschlangenverwaltung für die ausgehende Schnittstelle konfiguriert wird, überträgt der VIP das Paket in die txqueue in MEMD, und das Paket wird sofort vom Warteschlangencode aus der Warteschlange gezogen.

    • Wenn RSP-basierte Warteschlangen konfiguriert sind, wird das Paket in die Systempuffer im Prozessorspeicher des RSP kopiert.

    • Wenn VIP-basierte Warteschlangen verwendet werden, wird das Paket in den Paketspeicher des ausgehenden VIP kopiert.

  • Wenn die Warteschlangenstrategie der Ausgangsschnittstelle FIFO lautet, verwirft die Schnittstelle das Paket nicht sofort (dies geschieht normalerweise mit FIFO, wenn eine ausgehende Schnittstelle überlastet wird). Stattdessen puffert das eingehende VIP das Paket im Paketspeicher, bis wieder einige Puffer für die ausgehende Schnittstelle verfügbar sind. Dies wird als Rx-Side-Pufferung bezeichnet.

Verwenden Sie den Befehl show controller vip akkumulator, um den Status der Rx-Side-Pufferung zu überprüfen. Der Status zeigt Folgendes an:

• Die Anzahl der im Router vorhandenen Ausgabeschnittstellen.

• Anzahl der Pakete, die für diese Schnittstellen im VIP im Rx-Puffer gepuffert wurden

• Warum das VIP gepuffert hat.

• Wie viele Pakete hat das VIP verworfen, und warum?

VIP läuft bei CPU-Auslastung von 99 %

Eine Folge der Rx-Side-Pufferung ist, dass das VIP mit einer CPU-Auslastung von 99 % ausgeführt wird. Das VIP überwacht kontinuierlich den Status der txqueue der ausgehenden Schnittstelle und kopiert das Paket, sobald ein freier Puffer vorhanden ist, über den Bus in die txqueue.

Es gibt an sich nichts Alarmierendes, wenn das VIP bei einer Rx-Pufferung mit 99 % ausgeführt wird. Das bedeutet nicht, dass das VIP überlastet ist. Wenn das VIP etwas Wichtigeres erhält (z. B. ein anderes Paket zum Switch), wird dies von der hohen CPU nicht beeinflusst.

Im Folgenden finden Sie einen einfachen Test, der Sie im Labor durchführen können, um dies zu veranschaulichen:

Die Taktrate für den seriellen 2/0/0-Switch beträgt 128 Kbit/s und empfängt Datenverkehr mit Leitungsgeschwindigkeit. Der Datenverkehr wird auf Serial 10/0 umgestellt, wobei die Taktrate 64 Kbit/s und die Warteschlangenstrategie FIFO lautet. Die einzige Option besteht darin, Pakete zu verwerfen.

router#show controller cbus 

MEMD at 40000000, 8388608 bytes (unused 697376, recarves 6, lost 0) 

RawQ 48000100, ReturnQ 48000108, EventQ 48000110 

BufhdrQ 48000130 (21 items), LovltrQ 48000148 (15 items, 2016 bytes) 

IpcbufQ 48000158 (24 items, 4096 bytes) 

IpcbufQ_classic 48000150 (8 items, 4096 bytes) 

3570 buffer headers (48002000 - 4800FF10) 

pool0: 8 buffers, 256 bytes, queue 48000138 

pool1: 2940 buffers, 1536 bytes, queue 48000140 

pool2: 550 buffers, 4512 bytes, queue 48000160 

pool3: 4 buffers, 4544 bytes, queue 48000168 

slot2: VIP2, hw 2.11, sw 22.20, ccb 5800FF40, cmdq 48000090, vps 8192 

software loaded from system 

IOS (tm) VIP Software (SVIP-DW-M), Version 12.0(21)S, EARLY DEPLOYMENT RELEASE 
SOFTWARE (fc1) 

ROM Monitor version 122.0 

Mx Serial(4), HW Revision 0x3, FW Revision 1.45 

Serial2/0/0, applique is V.35 DCE 

received clockrate 2015232 

gfreeq 48000140, lfreeq 480001D0 (1536 bytes) 

rxlo 4, rxhi 336, rxcurr 16, maxrxcurr 293 

txq 48001A00, txacc 48001A02 (value 294), txlimit 294 

Serial2/0/1, applique is V.35 DTE 

received clockrate 246 

gfreeq 48000140, lfreeq 480001D8 (1536 bytes) 

rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 

txq 48001A08, txacc 48001A0A (value 6), txlimit 6 

Serial2/0/2, applique is Universal (cable unattached) 

received clockrate 246 

gfreeq 48000140, lfreeq 480001E0 (1536 bytes) 

rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 

txq 48001A10, txacc 48001A12 (value 6), txlimit 6 

Serial2/0/3, applique is Universal (cable unattached) 

received clockrate 246 

gfreeq 48000140, lfreeq 480001E8 (1536 bytes) 

rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 

txq 48001A18, txacc 48001A1A (value 6), txlimit 6 

slot10: FSIP, hw 1.12, sw 20.09, ccb 5800FFC0, cmdq 480000D0, vps 8192 

software loaded from system 

Serial10/0, applique is V.35 DTE 

gfreeq 48000140, lfreeq 48000208 (1536 bytes) 

rxlo 4, rxhi 336, rxcurr 1, maxrxcurr 1 

txq 48000210, txacc 480000B2 (value 2), txlimit 294 

Serial10/1, applique is Universal (cable unattached) 

gfreeq 48000140, lfreeq 48000218 (1536 bytes) 

rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 

txq 48000220, txacc 480000BA (value 6), txlimit 6 

Serial10/2, applique is Universal (cable unattached) 

gfreeq 48000140, lfreeq 48000228 (1536 bytes) 

rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 

txq 48000230, txacc 480000C2 (value 6), txlimit 6 

Serial10/3, applique is Universal (cable unattached) 

gfreeq 48000140, lfreeq 48000238 (1536 bytes) 

rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 

txq 48000240, txacc 480000CA (value 6), txlimit 6 

Serial10/4, applique is Universal (cable unattached) 

gfreeq 48000140, lfreeq 48000248 (1536 bytes) 

rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 

txq 48000250, txacc 480000D2 (value 6), txlimit 6 

Serial10/5, applique is Universal (cable unattached) 

gfreeq 48000140, lfreeq 48000258 (1536 bytes) 

rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 

txq 48000260, txacc 480000DA (value 6), txlimit 6 

Serial10/6, applique is Universal (cable unattached) 

gfreeq 48000140, lfreeq 48000268 (1536 bytes) 

rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 

txq 48000270, txacc 480000E2 (value 6), txlimit 6 

Serial10/7, applique is Universal (cable unattached) 

gfreeq 48000140, lfreeq 48000278 (1536 bytes) 

rxlo 4, rxhi 336, rxcurr 0, maxrxcurr 0 

txq 48000280, txacc 480000EA (value 6), txlimit 6 

router# 

Der Wert 2 bedeutet, dass nur zwei Puffer übrig bleiben. Bei der Rx-Pufferung werden Pakete im MEMD nicht in eine Warteschlange gestellt, wenn die Taktzahl unter 4 liegt.

Der Befehl show controller vip 2 tech-support vom VIP zeigt, dass er mit einer CPU von 99 % ausgeführt wird:

router#show controllers vip 2 tech-support 

show tech-support from Slot 2: 

------------------ show version ------------------ 


Cisco Internetwork Operating System Software 

IOS (tm) VIP Software (SVIP-DW-M), Version 12.0(21)S, EARLY DEPLOYMENT RELEASE 
SOFTWARE (fc1) 

Copyright (c) 1986-2000 by cisco Systems, Inc. 

Compiled Tue 18-Jul-00 22:03 by htseng 

Image text-base: 0x600108F0, data-base: 0x602E0000 


ROM: System Bootstrap, Version 11.1(4934) [pgreenfi 122], INTERIM SOFTWARE 


VIP-Slot2 uptime is 1 week, 23 hours, 27 minutes 

System returned to ROM by power-on 

Running default software 



cisco VIP2 (R4700) processor (revision 0x02) with 32768K bytes of memory. 

Processor board ID 00000000 

R4700 CPU at 100Mhz, Implementation 33, Rev 1.0, 512KB L2 Cache 

4 Serial network interface(s) 

Configuration register is 0x0 

... 

------------------ show process cpu ------------------ 

CPU utilization for five seconds: 99%/97%; one minute: 70%; five minutes: 69% 

Das VIP arbeitet mit einer CPU-Auslastung von 99 %, obwohl es nur 128 Kbit/s empfängt. Dies zeigt, dass die CPU-Auslastung nicht mit der Anzahl der Pakete pro Sekunde verknüpft ist. Der Grund hierfür ist, dass ein VIP 2 viel mehr Pakete als diese verteilen kann. Es ist einfach ein Zeichen für Rx-Side-Pufferung.

Führen Sie folgende Befehle aus, um zu überprüfen, welche Rx-Side-Pufferung funktioniert:

router#show controllers vip 2 accumulator

show vip accumulator from Slot 2:

Buffered RX packets by accumulator:
...
Serial10/0: 
 MEMD txacc 0x00B2: 544980 in, 2644182 drops (126 paks, 378/376/376 bufs) 1544kbps   
   No MEMD acc: 544980 in      
      Limit drops  : 2644102 normal pak drops, 80 high prec pak drops      
      Buffer drops : 0 normal pak drops, 0 high prec pak drops   
   No MEMD buf: 0 in      
      Limit drops  : 0 normal pak drops, 0 high prec pak drops      
      Buffer drops : 0 normal pak drops, 0 high prec pak drops
...
Interface x: 
MEMD txacc a: b in, c drops (d paks, e/f/g bufs) h kbps 
No MEMD acc: i in
      Limit drops  : j normal pak drops, k high prec pak drops      
      Buffer drops : l normal pak drops, m high prec pak drops
No MEMD buf: n in
      Limit drops  : o normal pak drops, p high prec pak drops      
      Buffer drops : q normal pak drops, r high prec pak drops

Schlüssel	Beschreibung
eine	Anschrift der Steuer in MEMD. Es gibt eine Rx-Side-Pufferwarteschlange für jede Taktik im System (bis zu 4096).
b	Anzahl der Pakete, die Rx-gepuffert werden
c	Anzahl der Pakete, die vom VIP verworfen wurden Wenn genügend Paket-Speicherpuffer vorhanden sind, kann das VIP Rx-Puffer für bis zu eine Sekunde des Datenverkehrs erstellen. Wenn die Schnittstelle jedoch ständig überlastet ist, ist es nicht möglich, Verwerfen zu vermeiden.
d	Anzahl der aktuell gepufferten Pakete
e	Anzahl der aktuell gepufferten Partikel. Ein Paket kann aus mehreren Partikeln bestehen.
f	weiche Grenze, d. h. die maximale Anzahl von Partikeln, wenn der VIP-Speicher niedrig ist.
g	Hard limit, d. h. die maximale Anzahl von Teilchen, die jederzeit verwendet werden können.
h	Die Geschwindigkeit der ausgehenden Schnittstelle in Kbit/s.
i	Die Anzahl der Rx-Buffered-Pakete, da im MEMD kein TXACC verfügbar war Dies bedeutet, dass die Ausgabewarteschlange überlastet wurde (in der tx-queue sind keine freien Puffer mehr verfügbar). Die Lösung für dieses Problem ist, die Bandbreite der Ausgabeschnittstelle (wenn möglich) zu erhöhen.
j	Die Anzahl der Pakete mit einer anderen IP-Priorität als 6 oder 7, die nicht gesendet werden konnten, da kein MEMD-Cache vorhanden ist, und die verworfen werden, weil die weiche oder harte Grenze der Partikel erreicht wurde.
k	Wie j, aber für Pakete mit IP-Rangfolge 6 oder 7 (Internetwork und Netzwerk).
l	Die Anzahl der Pakete mit einer anderen IP-Priorität als 6 oder 7, die das VIP im Rx-Puffer speichern möchte, aber aufgrund des Fehlens freier Puffer im Paketspeicher verliert. Ab den Cisco IOS Software-Versionen 12.0(13)S und 12.1(4) können Sie auch den Befehl show controller vip [all / slot#] paket-memory-drop verwenden, um die Anzahl der verworfenen Pakete anzuzeigen. In diesem Fall hilft ein Upgrade des Paketspeichers.
m	Wie l, aber für Pakete mit IP-Rangfolge 6 oder 7 (Internetwork und Netzwerk).
n	Die Anzahl der Pakete, die das VIP in einen Rx-Puffer versucht, da kein MEMD-Puffer vorhanden ist, dies jedoch aufgrund eines Mangels an Paket-Speicherpuffern nicht möglich ist. Aktualisieren Sie in diesem Fall den Paketspeicher. Ab den Cisco IOS Software-Versionen 12.0(13)S und 12.1(4) können Sie auch den Befehl show controller vip [all / slot#] paket-memory-drop verwenden, um zu verstehen, warum die Pakete verworfen wurden.
o	Die Anzahl der gepufferten Rx-Pakete mit einer anderen IP-Rangfolge als 6 oder 7 ohne MEMD-Puffer, die verworfen werden, weil der weiche (f) oder harte (g) Grenzwert erreicht wurde. In dieser Situation hilft ein RSP16, weil er mehr MEMD-Speicher hat (8 MB im Vergleich zu 2 MB bei RSP1, RSP2, RSP4 und RSP7000). In diesem Fall können Sie auch die MTU einiger Schnittstellen (z. B. ATM, POS oder FDDI) reduzieren. Diese Schnittstellen verfügen in der Regel über eine MTU von 4470 Byte, und es können weniger MEMD-Puffer zugewiesen werden, da die Puffer größer sein müssen.
p	Wie o, aber für Pakete mit IP-Rangfolge 6 oder 7 (Internetwork und Netzwerk).
q	Die Anzahl der Pakete mit einer anderen IP-Rangfolge als 6 oder 7, die das VIP versucht, einen Rx-Puffer zu erstellen, da kein MEMD-Puffer vorhanden ist. Dies ist jedoch aufgrund fehlender Paket-Speicherpuffer nicht möglich. In diesem Fall ist eine Aktualisierung des Paketspeichers hilfreich. Ab den Cisco IOS Software-Versionen 12.0(13)S und 12.1(4) können Sie auch den Befehl show controller vip [all / slot#] paket-memory-drop verwenden, um besser zu verstehen, warum die Pakete verworfen wurden.
r	Wie q, aber für Pakete mit IP-Rangfolge 6 oder 7 (Internetwork und Netzwerk).

Wenn der Router eine Cisco IOS Softwareversion vor 12.0(13)ST, 12.1(04)DB, 12.1(04)DC, 12.0(13)S, 12.1(4) 12.1(4)AA 12.1(4)T 012.0(13) ausführt oder 12.0(13)SC, die Ausgabe der Show Controller vip [all / slot#] Akkumulator bietet eine vereinfachte Version der oben. Aufgrund der Rx-Side-Pufferung werden die unterschiedlichen IP-Rangfolgen der verworfenen Pakete nicht berücksichtigt.

Die Ausgabe sieht wie folgt aus:

Serial10/0:
MEMD txacc 0x00B2: 544980 in, 2644182 drops (126 paks, 378/376/376 bufs) 1544kbps
No MEMD acc: 544980 in, 2644182 limit drops, 0 no buffer
No MEMD buf: 0 in, 0 limit drops, 0 no buffer


Interface x: 
MEMD txacc a: b in, c drops (d paks, e/f/g bufs) h kbps 
No MEMD acc: i in, j+k limit drops, l+m no buffer 
No MEMD buf: n in, o+p limit drops, q+r no buffer 

Beispiele für Puffer auf der Rx-Seite

Beispiel 1: Das VIP in Steckplatz 2 empfängt Datenverkehr mit 128 Kbit/s und leitet ihn an serielle 10/0 (64 Kbit/s) weiter.

Serial10/0: 
 MEMD txacc 0x00B2: 544980 in, 2644182 drops (126 paks, 378/376/376 bufs) 1544kbps   
   No MEMD acc: 544980 in      
      Limit drops : 2644102 normal pak drops, 80 high prec pak drops      
      Buffer drops : 0 normal pak drops, 0 high prec pak drops   
   No MEMD buf: 0 in      
      Limit drops : 0 normal pak drops, 0 high prec pak drops      
      Buffer drops : 0 normal pak drops, 0 high prec pak drops 

• Hier werden 544980 Pakete erfolgreich gepuffert und 2644182 fallen gelassen. 80 der 2644182 verworfenen Pakete hatten eine IP-Priorität von 6 oder 7.

• 126 Pakete werden derzeit im Rx-Puffer gepuffert und verwenden 378 Partikel.

• Alle Pakete werden aufgrund des Fehlens eines freien Puffers in der tx-queue in MEMD gepuffert. Dies bedeutet, dass die Ausgabeschnittstelle überlastet ist. Die Verwerfungen treten auf, weil die maximale Anzahl an Rx-gepufferten Paketen erreicht ist. Die typische Lösung besteht darin, die Bandbreite der ausgehenden Schnittstellen zu aktualisieren, einen Teil des Datenverkehrs so umzuleiten, dass die ausgehende Schnittstelle weniger überlastet ist, oder dass einige Warteschlangen den weniger wichtigen Datenverkehr verwerfen können.

Beispiel 2: Rx-Side-Puffer ohne Verluste.

ATM1/0: 
MEMD txacc 0x0082: 203504 in, 0 drops (0 paks, 0/81/37968 bufs) 155520kbps 
No MEMD acc: 85709 in      
      Limit drops  : 0 normal pak drops, 0 high prec pak drops      
      Buffer drops : 0 normal pak drops, 0 high prec pak drops 
No MEMD buf: 117795 in      
      Limit drops  : 0 normal pak drops, 0 high prec pak drops      
      Buffer drops : 0 normal pak drops, 0 high prec pak drops 

• In diesem Beispiel werden 85709 Pakete per Rx gepuffert, da ATM 1/0 überlastet ist, aber keine Pakete verworfen werden.

• 117795-Pakete werden im Rx-Puffer gepuffert, da das VIP keinen MEMD-Puffer erhalten kann. Es werden keine Pakete verworfen. Eine typische Lösung besteht darin, einige MTUs zu verringern, sodass mehr MEMD-Puffer zugewiesen werden können. Ein RSP8 ist ebenfalls hilfreich.

Beispiel 3: Lokales Switching.

SRP0/0/0: 

 local txacc 0x1A02: 2529 in, 0 drops (29 paks, 32/322/151855 bufs) 622000kbps 

Local txacc bedeutet, dass sich diese Ausgabeschnittstelle auf demselben VIP befindet wie die Schnittstelle, an der die Pakete empfangen werden. Diese Pakete werden lokal geswitcht, aber die ausgehende Schnittstelle (in diesem Fall srp 0/0/0 ) ist überlastet. 2529 Pakete werden per Rx gepuffert, und es werden keine Pakete verworfen.

Beispiel 4: Weiterleitungswarteschlangen.

router#show controllers vip 2 accumulator
Buffered RX packets by accumulator: 
 Forward queue 0 : 142041 in, 3 drops (0 paks, 0/24414/24414 bufs) 100000kbps   
   No MEMD buf: 142041 in      
      Limit drops  : 0 normal pak drops, 0 high prec pak drops      
      Buffer drops : 3 normal pak drops, 0 high prec pak drops 
 Forward queue 9 : 68 in, 0 drops (0 paks, 0/15/484 bufs) 1984kbps   
   No MEMD buf: 68 in      
      Limit drops  : 0 normal pak drops, 0 high prec pak drops      
      Buffer drops : 0 normal pak drops, 0 high prec pak drops 
 Forward queue 13: 414 in, 0 drops (0 paks, 0/14/468 bufs) 1920kbps   
   No MEMD buf: 414 in      
      Limit drops  : 0 normal pak drops, 0 high prec pak drops      
      Buffer drops : 0 normal pak drops, 0 high prec pak drops 
 Forward queue 14: 46 in, 0 drops (0 paks, 0/14/468 bufs) 1920kbps   
   No MEMD buf: 46 in      
      Limit drops  : 0 normal pak drops, 0 high prec pak drops      
      Buffer drops : 0 normal pak drops, 0 high prec pak drops

Manche Pakete können nicht verteilt werden. In diesem Fall muss das VIP die Pakete an die Raw-Warteschlange des RSP weiterleiten, der dann die Switching-Entscheidung trifft. Wenn Pakete nicht sofort in MEMD kopiert werden können, puffert das VIP Rx-Paket sie und verfolgt, wie viele Pakete pro eingehender Schnittstelle per Rx-Buffered gepuffert werden.

Die Weiterleitungswarteschlangen sind 0-7 für den ersten Port-Adapter (PA) und 8-15 für den zweiten PA.

Weiterleitungswarteschlangen-Nummer	...zeigt die Anzahl der Rx-gepufferten Pakete, die auf dem..
0	erste Plughole des ersten Port-Adapters (PA)
8	erste Plughole der zweiten PA
9	zweite Durchschnittspur der zweiten PA

Weitere Ursachen für die hohe CPU-Auslastung bei VIPs

Wenn die Rx-Side-Pufferung als inaktiv erachtet wird, kann einer der folgenden Faktoren eine hohe CPU-Auslastung im VIP verursachen:

• 99 % CPU-Auslastung bei VIP, verursacht durch verteiltes Traffic Shaping

  Wenn Distributed Traffic Shaping (dTS) konfiguriert ist, springt die VIP-CPU auf 99 %, sobald ein Paket in die dTS-Warteschlange gelangt.

  Dies ist das richtige und erwartete Verhalten. Wenn dTS konfiguriert ist, dreht sich die VIP-CPU, um zu überprüfen, ob das nächste Zeitintervall (Tc) eintrifft, wenn die CPU nicht ausgelastet ist (d. h. wenn kein Datenverkehr besteht). Andernfalls wird die Überprüfung in den Routinen tx/rx-Interrupt unterstützt. Sie drehen die CPU nur, wenn sie nicht ausgelastet ist. Daher wird die Leistung nicht beeinträchtigt.

  Um zu verstehen, was "nächstes Zeitintervall" bedeutet, lesen Sie Was ist ein Token-Bucket?

  Hinweis: Traffic Shaping wird nur aktiviert, wenn ein Paket in die Shaping-Warteschlange eingestellt werden muss. Mit anderen Worten, wenn der Datenverkehr die Shaping-Rate überschreitet. Dies erklärt, warum die VIP-CPU bei der Konfiguration von dTS nicht immer 99 % beträgt. Weitere Informationen zu dTS finden Sie unter:

  • Verteiltes Traffic Shaping

  • Konfigurieren von verteiltem Traffic Shaping

• Hohe CPU-Auslastung für VIP durch fehlerhafte Speicherzugriffe und Ausrichtungsfehler

  Alignment-Fehler und falscher Speicherzugriff sind Softwarefehler, die durch die Cisco IOS-Software behoben werden, ohne dass das VIP abstürzen muss. Wenn diese Fehler häufig auftreten, führt dies dazu, dass das Betriebssystem viele Korrekturen vornimmt, die zu einer hohen CPU-Auslastung führen können.

  Weitere Informationen zu Ausrichtungsfehlern und unberechtigten Speicherzugriffen finden Sie unter Fehlerbehebung bei unberechtigten Zugriffen, Ausrichtungsfehlern und Funkstörungen.

  Verwenden Sie den Befehl show alignment (Ausrichtung anzeigen), um auf fehlerhafte Speicherzugriffe und Ausrichtungsfehler zu überprüfen. Ein Beispiel für einen solchen Fehler sieht wie folgt aus:

  VIP-Slot1#show alignment
  No alignment data has been recorded.
  No spurious memory references have been recorded.

Weitere Ursachen für die hohe CPU-Auslastung können die Anzahl und der Umfang der aktivierten verteilten Funktionen sein. Wenn Sie vermuten, dass dies der Grund sein könnte, oder wenn Sie eine der in diesem Dokument beschriebenen Ursachen für die hohe CPU-Auslastung nicht identifizieren können, öffnen Sie eine Serviceanfrage beim Cisco Technical Assistance Center (TAC).

Informationen, die beim Öffnen einer TAC-Serviceanfrage gesammelt werden müssen

Wenn Sie nach den oben beschriebenen Schritten zur Fehlerbehebung weiterhin Hilfe benötigen und eine Serviceanfrage (nur registrierte Kunden) beim Cisco TAC öffnen möchten, geben Sie folgende Informationen an:

Ausgabe des Befehls show controller vip [all / slot#] akkumator (show controller vip) Ausgabe des Befehls show technical-support vom relevanten RSP und VIP Bitte fügen Sie die gesammelten Daten Ihrer Serviceanfrage im unverzippten Textformat (.txt) bei. Um Informationen zu Ihrer Serviceanfrage hinzuzufügen, laden Sie sie über das TAC Service Request Tool hoch (nur registrierte Kunden). Wenn Sie nicht auf das Service Request Tool zugreifen können, können Sie die relevanten Informationen zu Ihrer Serviceanfrage hinzufügen und diese mit Ihrer Service-Anfrage-Nummer in der Betreffzeile Ihrer Nachricht an attach@cisco.com senden. Hinweis: Laden Sie den Router nicht manuell neu oder schalten Sie ihn ein, bevor Sie die oben genannten Informationen erfassen (es sei denn, Sie müssen den Netzwerkbetrieb wiederherstellen), da dies zum Verlust wichtiger Informationen führen kann, die zur Bestimmung der Ursache des Problems erforderlich sind.

Zugehörige Informationen

• Produktsupport für Cisco Router
• Fehlerbehebung und Warnmeldungen: Cisco Router der Serie 7500
• Technischer Support und Dokumentation - Cisco Systems

Revisionsverlauf