Inhalt

Einführung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Konventionen

Hintergrundinformationen

Grundlagen der IPC-Terminologie

IPC-Adressformat

Welche Informationen müssen über IPC übertragen werden?

Übertragung von IPC-Nachrichten

Cisco Serie 7500

Cisco Serie 12000

Schritte zur Behebung von Problemen, bekannten Fehlern und Verbesserungen

Schritt 1: Optimieren des IPC-Cache

Schritt 2: Einstellen des IPC-Durchsatzes

Liste der IPC-Erweiterungen

Cisco Serie 7600

Sammeln von Informationen zur Fehlerbehebung für das Cisco TAC

Zugehörige Informationen

Einführung

In diesem Dokument wird erläutert, warum Ihr Router IPC-bezogene Protokollmeldungen meldet und wie dieses Problem behoben werden kann. In diesem Dokument wird auch die IPC-Terminologie überprüft.

Voraussetzungen

Anforderungen

Die Leser dieses Dokuments sollten folgende Themen kennen:

- Cisco Router-Administration

- IPC und seine Terminologie

Verwendete Komponenten

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

- Alle Cisco IOS® Softwareversionen, die die Cisco Router der Serien 12000, 1000, 7600 und 7500 unterstützen.

- Cisco Router der Serien 12000, 1000, 7600 und 7500

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 (Technische Tipps zu Konventionen von Cisco).

Hintergrundinformationen

Das Cisco IOS Software Inter-Process Communication (IPC)-Modul stellt eine Kommunikationsinfrastruktur bereit, über die Prozesse in einem verteilten System miteinander interagieren können. Darüber hinaus wird eine transparente Kommunikation zwischen Backplane, Netzwerken und gemeinsam genutztem Speicher ermöglicht.

IPC-Dienste dienen als Mittel, mit dem Line Cards (LCs) und der zentrale Routingprozessor (RP) in einem verteilten System miteinander kommunizieren, indem IPC-Nachrichten ausgetauscht werden, die vom RP an die LCs sowie zwischen aktiven und Standby-RPs gesendet werden. Diese Meldungen enthalten Konfigurationsbefehle und Antworten auf diese Befehle sowie "Ereignisse", die vom LC an den RP gemeldet werden müssen.

Die Cisco Serien 1200, 1000, 7600 und 7500 verwenden eine verteilte Architektur, die auf IPC-Meldungen basiert. In seltenen Fällen können diese Router folgende IPC-bezogene Protokollmeldungen melden:

- Cisco Serie 1200 - %IPC-3-NOBUFF: Der Hauptcache für den IPC-Header ist geleert.

- Cisco Serie 7500 - %IPC_RSP_CBUS-3-NOBUF: Keine IPC-Memd-Puffer mehr zum Übertragen der IPC-Nachricht

Hinweis: IPC wird auch für die Cisco Serien 6400 und 7304 verwendet.

Grundlagen der IPC-Terminologie

Häufigere IPC-Terminologien sind:

- IPC = Inter-Process Communication.

- IPC-Adresse - Ein 32-Bit-Wort, das aus einer 16-Bit-Platz-ID und einer 16-Bit-Port-ID besteht.

- IPC-Client - Ein Softwaremodul, das IPC-Dienste verwendet.

- IPC-Port - Ein Kommunikationsendpunkt innerhalb von IPC, der als Quelle und Ziel der gesamten Kommunikation verwendet wird.

- IPC-Platz - Ein IPC-Arbeitsplatz ist ein Rechenelement, z. B. ein Prozessor, das mithilfe von IPC kommuniziert werden kann. Ein IPC-Arbeitsplatz ist der Ort, an dem sich IPC-Clients und -Ports befinden.

- IPC-Sitzung - Eine IPC-Sitzung ist ein aktiver Simplex-Kommunikationskanal zwischen zwei IPC-Ports.

Alle Kommunikationen, die IPC verwenden, erfolgen zwischen IPC-Ports. Ein Port ist ein Kommunikationsendpunkt in IPC. Jeder IPC-Port ist einer logischen Adresse zugeordnet, die als IPC-Adresse bezeichnet wird. IPC verwendet die IPC-Adresse eines IPC-Ports als Rücksendeadresse, wenn IPC-Nachrichten gesendet werden, oder als Zieladresse, wenn IPC-Nachrichten empfangen werden.

IPC-Adressformat

IPC-Adressen werden den IPC-Ports vom lokalen IPC-Platz-Manager zugewiesen. Ein Arbeitsplatz ist der Prozessor, auf dem das IPC-Protokoll derzeit ausgeführt wird. Ein Arbeitsplatz-Manager ist ein Prozess, der eine Liste der lokalen IPC-Ports und einen lokalen Namensdienst verwaltet und auch offene IPC-Kommunikationssitzungen durchführt.

Wenn ein IPC-Port erstellt wird, weist der IPC-Client dem IPC-Port einen Portnamen zu. Andere IPC-Clients können dann einen Portnamen verwenden, wenn sie sich auf den neu erstellten IPC-Port beziehen. Ein Portname ist eine Zeichenfolge aus Zeichen, die aus einem Sitznamen und einer Portfunktion oder -beschreibung besteht.

Cisco IPC bietet drei verschiedene Zuverlässigkeitsstufen für die Zustellung an einen Port. wird beim Öffnen des Ports definiert.

- Zuverlässig: Die Zustellung der Nachricht ist garantiert. Bei einem Ausfall wird die Lieferung erneut versucht.

- Unzuverlässig: Die Lieferung ist ein bestmöglicher Versuch. Es gibt keinen Hinweis, ob die Lieferung fehlschlägt.

- Unzuverlässig bei Benachrichtigung: Die Zustellung der Nachricht ist nicht garantiert. Der Absender erhält jedoch eine Benachrichtigung über den Ausfall.

Der Befehl show ipc knoten zeigt die in einem so genannten IPC-Bereich vorhandenen IPC-Plätze an.

Router#show ipc nodes

There are 3 nodes in this IPC realm.

ID Type       Name                         Last  Last

Sent  Heard

10000 Local      IPC Master                   0      0

1030000 RSP-CY     RSP IPC card slot 3          7      7

1000000 RSP-CY     RSP IPC card slot 0          10     10

Wenn ein Slave-RP vorhanden ist, wird im Befehl show ipc knoten die Slave-RP-Adresse aufgelistet, wie in dieser Beispielausgabe von einem Cisco Router der Serie 1000 gezeigt:

10k-2#show ipc nodes

There are 5 nodes in this IPC realm.

ID   Type       Name                      Last  Last

Sent  Heard

10000   Local      IPC Master                0     0

20000   UDP        C10K Line Card slot 2/0   3     3

30000   UDP        C10K Line Card slot 3/0   3     3

40000   UDP        C10K Line Card slot 1/0   3     3

50000   Ethernet   Slave                     18    45

Nachdem ein IPC-Port erstellt wurde, kann ein IPC-Client seinen Portnamen mit dem vom IPC Master gesteuerten globalen Namensdienst registrieren.

Eine Zusammenstellung von IPC-Sitzen, die miteinander kommunizieren, wird als Zone bezeichnet. Für jede IPC-Zone wird ein einziger IPC-Arbeitsplatz als IPC Zone Manager oder Master bzw. kurz IPC Master festgelegt. Logischerweise sind alle IPC-Sitzverbindungen im IPC-Protokoll Punkt-zu-Punkt-Verbindungen. Die gesamte IPC-Sitzkommunikation erfolgt in der Regel zwischen dem aktiven RP und einer Linecard oder dem Standby-RP. Die Kommunikation von Line Card zu Line Card ist möglich.

Ein Gerät muss lokale Ports erstellen und Zielports suchen, bevor es IPC-Nachrichten austauscht. Obwohl ein Gerät lokale Ports erstellt, werden diese Ports nicht als Quell-Ports betrachtet, da die IPC-Kommunikation simplex ist. Wenn der RP mit einem LC kommunizieren möchte, öffnet er zuerst einen Port auf dem LC (der LC muss den Port erstellt und beim IPC Master - RP registriert haben). Wenn der offene Vorgang erfolgreich ist, kann der normale IPC-Nachrichtenverkehr starten.

In den Cisco Serien 1200 und 7500 fungieren der Routingprozessor, entweder ein Gigabit Route Processor (GRP) oder ein Route Switch Processor (RSP), und die intelligenten Line Cards als IPC-Endpunkte. Ein "IPC Master" steuert eine Gruppe von Prozessoren. Wenn der Router initialisiert wird, erkennt der IPC Master die IPC-Endpunkte, die auf den Linecards im System vorhanden sind. Dazu scannt der IPC Master alle Steckplätze, identifiziert den Controller-Typ und bestimmt, ob der Controller über IPC-Funktionen verfügt.

Verwenden Sie den Befehl show ipc ports, um diese Ports anzuzeigen. In einem IPC-Slave listet dieser Befehl die Ports auf, die auf diesem speziellen IPC-Platz erstellt wurden. Wenn dieser Befehl auf dem IPC Master ausgegeben wird, werden die Ports angezeigt, die auf dem Master erstellt wurden, sowie die Ports, die von den IPC-Slaves (LCs) registriert wurden. Darüber hinaus listet der Befehl show ipc ports open die Ports auf, die von diesem IPC-Platz aus geöffnet wurden. Hier ein Beispiel für die Ausgabe:

router#show ipc ports

There are 87 ports defined.

Port ID Type Name

10000.1 unicast IPC Master:Zone

10000.2 unicast IPC Master:Echo

10000.3 unicast IPC Master:Control

10000.4 unicast IPC Master:Init

port_index = 0 seat_id = 0x1020000 last sent = 0 last heard = 1

port_index = 1 seat_id = 0x1010000 last sent = 0 last heard = 1

port_index = 2 seat_id = 0x1040000 last sent = 0 last heard = 1

port_index = 3 seat_id = 0x1050000 last sent = 0 last heard = 1

port_index = 4 seat_id = 0x1060000 last sent = 0 last heard = 1

port_index = 5 seat_id = 0x1070000 last sent = 0 last heard = 1

port_index = 6 seat_id = 0x1080000 last sent = 0 last heard = 1

port_index = 7 seat_id = 0x1090000 last sent = 0 last heard = 1

port_index = 8 seat_id = 0x10A0000 last sent = 0 last heard = 1

port_index = 9 seat_id = 0x10B0000 last sent = 0 last heard = 1

port_index = 10 seat_id = 0x1030000 last sent = 0 last heard = 1

10000.5 unicast Remote TTY Server Port

port_index = 0 seat_id = 0x1070000 last sent = 0 last heard = 2

port_index = 1 seat_id = 0x1010000 last sent = 0 last heard = 2

port_index = 3 seat_id = 0x1040000 last sent = 0 last heard = 2

port_index = 4 seat_id = 0x1050000 last sent = 0 last heard = 2

Port ID Type Name

port_index = 5 seat_id = 0x1060000 last sent = 0 last heard = 3

port_index = 6 seat_id = 0x1080000 last sent = 0 last heard = 2

port_index = 7 seat_id = 0x1090000 last sent = 0 last heard = 2

port_index = 8 seat_id = 0x10A0000 last sent = 0 last heard = 2

port_index = 9 seat_id = 0x10B0000 last sent = 0 last heard = 2

[output omitted]

Das port_index-Feld ist die Sitzungs-ID, die vom Ziel-IPC bei der Verarbeitung eingehender Nachrichten verwendet wird. Wenn ein Slave-RP vorhanden ist, zeigt der Befehl show ipc ports Informationen zum Standby-Port an, wie in dieser Beispielausgabe veranschaulicht:

10k-2#show ipc ports

There are 16 ports defined.

Port ID       Type       Name

10000.1     Unicast    IPC Master:Zone

10000.2     Unicast    IPC Master:Echo

10000.3     Unicast    IPC Master:Control

10000.4     Unicast    Microcode Server

10000.5     Unicast    RFS Server Port

10000.6     Unicast    Remote File System Server Port

10000.7     Unicast    Master : TTY Server Port

port_index = 0  seat_id = 0x50000   last sent = 0     last heard = 0

10000.8     Unicast    C10K Line Card API

port_index = 0  seat_id = 0x20000   last sent = 0     last heard = 58521

port_index = 1  seat_id = 0x30000   last sent = 0     last heard = 64235

port_index = 2  seat_id = 0x40000   last sent = 0     last heard = 13486

50000.3     Unicast    Slave IPC:Control

50000.9     Unicast    Secondary RFS Server Port

50000.A     Unicast    Secondary Old RFS Server Port

50000.8     Unicast    Slave : TTY Client Port

50000.7     Unicast    Secondary Services Port

50000.B     Unicast    IF-con server port

50000.C     Unicast    RF : Standby

50000.D     Unicast    CF : Standby

Welche Informationen müssen über IPC übertragen werden?

IPC-Nachrichten sind die grundlegende Kommunikationseinheit, die zwischen IPC-Clients ausgetauscht wird. Im Normalbetrieb interagieren der RP und die Linecards häufig über IPC-Nachrichten. Eine Nachricht enthält einen Header, Quell- und Zieladressierungsinformationen sowie die Nachrichtendaten.

Im IPC-Header definiert IPC mehrere verschiedene Nachrichtenflags, die die Empfangsverarbeitung einer IPC-Nachricht verändern. Von den definierten Markierungen beziehen sich vier Flags auf die verwendete Kommunikationsart (unzuverlässig, unzuverlässig mit Benachrichtigung, zuverlässig), weitere vier beziehen sich auf das Remote Procedure Call (RPC)-Messaging oder die interne Kontrollverarbeitung, und zwei Flags werden überhaupt nicht verwendet.

Hier einige IPC-Clients:

- Vom RP gesendete Befehle, um die Linecards nach Informationen wie Version, Speichervolumen, Schnittstellenstatistiken, Änderungen des Schnittstellenstatus und Konfigurationsdaten abzufragen.

- Antworten auf die Befehle vom RP, die von der Linecard an den RP gesendet werden. Beispiele für Informationen in IPC-Meldungen sind zeitgesteuerte Statistiken-Updates und Windows-Meldungen, die angeben, wie viele IPC-Nachrichten die Linecard in die Warteschlange stellen kann.

- Asynchrone Generierung von Ereignissen oder Nachrichten Beispiele hierfür sind die Meldung von Fehlern wie Eingabefehlern, Runts und Giganten sowie die Meldung von Statistiken und anderen Rechnungsinformationen, z. B. Byte- und Paketzählungen.

- Nachrichten zwischen einem aktiven und einem Standby-RP für den ordnungsgemäßen Betrieb des Prüfpunkts.

- Einige Cisco IOS-Softwareprozesse müssen Informationen zwischen Linecards und dem Routingprozessor austauschen. Diese Prozesse werden als IPC-Anwendungen betrachtet. Beispiele hierfür sind Cisco Express Forwarding (CEF) und Remote-Dateisysteme für den Austausch von Images zwischen Routingprozessoren der Cisco Serie 12000.

In Tabelle 1 sind die Ebenen des IPC-Protokoll-Stacks aufgeführt:

Tabelle 1: Ebenen des IPC-Protokoll-Stacks

IPC-Protokoll-Stack

IPC-Anwendungen

IPC-Mechanismus selbst

Switch Fabric (Serie 1200) oder CBUS (Serie 7500) Daten-Layer

Übertragung von IPC-Nachrichten

Sowohl die Router der Serie 7500 als auch die Router der Serie 12000 weisen einen speziellen Satz von Puffern zum Speichern von IPC-Nachrichten zu, die zur Übertragung in die Warteschlange gestellt werden und auf die Bestätigung vom Ziel-IPC-Port warten.

Cisco Serie 7500

Die 7500-Serie verwendet einen speziellen Satz von Puffern im Systempaket-Speicher (MEMD). Weitere Informationen zu MEMD und der 7500-Architektur finden Sie unter What Cause a "%RSP-3-RESTART: cbus komplex"? und VIP-CPU mit 99 % und Rx-Side-Buffering.

Auf der 7500-Serie befinden sich die IPC-Warteschlangen im Prozessorspeicher. In einigen Versionen von Cisco IOS (siehe Beispielausgabe unten) kann der gesamte IPC-Pufferspeicher im Prozessorspeicher mithilfe des Befehls ipc cache size eingestellt werden. Das MEMD enthält einige begrenzte Puffer, die nicht eingestellt werden können. Wenn eine IPC-Meldung gesendet wird, die im Prozessorspeicher in die Warteschlange gestellt wird, und wenn ein freier Speicherplatz im MEMD vorhanden ist, werden die IPC-Nachrichten vom Prozessorspeicher in das MEMD "verschoben", bevor sie an den LC gesendet werden.

Verwenden Sie den Befehl show ipc queue, um den Status der IPC-Warteschlangen anzuzeigen.

Router#show ipc queue

There are 0 IPC messages waiting for acknowledgment in the transmit queue.

There are 0 IPC messages waiting for a response.

There are 0 IPC messages waiting for additional fragments.

There are 0 IPC messages currently on the IPC inbound.

There are 0 messages currently in use by the system.

Hinweis: Diese Warteschlangen sind von IPC verwaltete Softwarewarteschlangen und dürfen nicht mit den QA-ASIC-Hardware-Warteschlangen der 7500-Serie verwechselt werden.

Cisco Serie 12000

Auf der Serie 12000 sendet die GRP IPC-Nachrichten über die Switch-Fabric. Beim Hochfahren erstellt der Puffercarving-Algorithmus zwei Gruppen von Pools im so genannten Tofab- (Empfangsseite) und Fab-Speicher (Transmit Side). Wie in der Beispielausgabe des Befehls show controller tofab queues (siehe unten) gezeigt, handelt es sich bei den beiden Sets um Non-IPC Free Queues und IPC Queues. Informationen zur Interpretation der Ausgabe finden Sie unter Cisco Internet Router der Serie 12000: Häufig gestellte Fragen.

Auf der Cisco Serie 12000 weist das GRP bei der Initialisierung eine bestimmte Anzahl von Nachrichtenheadern zu. Es wurden mehrere Änderungen vorgenommen, um die Speicherzuweisung für diese Header zu verbessern.

In der Cisco IOS Software-Version 12.0(18)S/ST wurde die Standardanzahl der bei der Initialisierung erstellten Nachrichtenheader auf der GRP und den LCs von 1000 auf 5000 erhöht (siehe folgende Ausgabe). Ab Version 12.0(23)S kann der IPC-Header-Cache dynamisch wachsen. Daher muss es nicht mehr manuell eingestellt werden.

Die LCs verwalten IPC-Nachrichtenheader im Dynamic RAM (DRAM). Darüber hinaus stellten die LCs 100 Puffer im Tofab- und Fromfab-Speicher für IPC-Nachrichten bereit. Bei jeder übertragenen IPC-Nachricht muss der LC einen IPC-Nachrichtenheader aus dem Cache anfordern und dann eine Anfrage an den Fab Buffer Management ASIC (BMA) senden, damit die Nachricht über die Fabric an die GRP gesendet wird.

LC-Slot1#show controllers tofab queues

Carve information for ToFab buffers

SDRAM size: 33554432 bytes, address: 30000000, carve base: 30029100

33386240 bytes carve size, 4 SDRAM bank(s), 8192 bytes SDRAM pagesize, 2 carve(s)

max buffer data size 9248 bytes, min buffer data size 80 bytes

40606/40606 buffers specified/carved

33249088/33249088 bytes sum buffer sizes specified/carved

Qnum        Head    Tail    #Qelem  LenThresh

----        ----    ----    ------  ---------

5 non-IPC free queues:

20254/20254 (buffers specified/carved), 49.87%, 80 byte data size

1          17297   17296    20254    65535

12152/12152 (buffers specified/carved), 29.92%, 608 byte data size

2          20548   20547    12152    65535

6076/6076 (buffers specified/carved), 14.96%, 1568 byte data size

3          32507   38582    6076     65535

1215/1215 (buffers specified/carved), 2.99%, 4544 byte data size

4          38583   39797    1215     65535

809/809 (buffers specified/carved), 1.99%, 9248 byte data size

5          39798   40606    809      65535

IPC Queue:

100/100 (buffers specified/carved), 0.24%, 4112 byte data size

30         72      71       100      65535

Raw Queue:

31         0       17302    0        65535

[output omitted]

Schritte zur Behebung von Problemen, bekannten Fehlern und Verbesserungen

Schritt 1: Optimieren des IPC-Cache

Hinweis: In Tabelle 2 finden Sie eine Liste der IOS-Versionen mit den in diesem Abschnitt aufgeführten Erweiterungen.

In seltenen Fällen (z. B. wenn eine große Menge an Informationen zwischen IPC-Clients ausgetauscht werden muss) kann der IPC-Puffer-Cache erschöpft sein. Die Cisco IOS-Software verwendet diese Protokollmeldungen, um diese Bedingung zu melden:

Oct 7 03:36:49: %RSP-3-RESTART: interface Serial0/0/4:1, not transmitting

Oct 7 03:39:51: %IPC_RSP_CBUS-3-NOBUF: No more IPC memd buffers to transmit

IPC message

Oct 7 03:40:09: %RSP-3-RESTART: interface Serial0/0/2:1, not transmitting

Oct 7 03:40:19: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1/0,

changed state to down

Oct 7 03:40:19: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1/1,

changed state to down

Oct 7 03:40:19: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/1/2,

changed state to down

Oct 7 03:40:19: %LINEPROTO-5-UPDOWN: Line protocol on InterfaceSerial0/1/3,

changed state to down

Oct 7 03:40:21: %IPC_RSP_CBUS-3-NOBUF: No more IPC memd buffers to transmit

IPC message

Oct 7 03:40:26: %FIB-3-FIBDISABLE: Fatal error, slot 0: IPC failure

Oct 7 03:40:26: %FIB-3-FIBDISABLE: Fatal error, slot 1: IPC failure

Oct 7 03:40:26: %FIB-3-FIBDISABLE: Fatal error, slot 4: IPC failure

Oct 7 03:40:26: %FIB-3-FIBDISABLE: Fatal error, slot 5: IPC failure

Oct 7 03:40:29: %LINEPROTO-5-UPDOWN: Line protocol on Interface

Wie die obige Ausgabe zeigt, deaktiviert der RP CEF auf allen Linecards in diesem Zustand, da er die CEF-Tabellen auf den Linecards nicht mehr mithilfe von IPC aktualisieren kann. Somit werden FIBDISABLE-Nachrichten für alle Linecards gemeldet.

Um diese Fehler zu beheben, muss möglicherweise der IPC-Cache auf RP- und IPC-Speicher auf Linecards erhöht werden. Verwenden Sie dazu den Befehl show ipc status, um zu ermitteln, ob dem RP, dem LC oder beiden die IPC-Puffer fehlen. Nehmen Sie diese Ausgabe, und überprüfen Sie sie sowohl vom RP als auch vom LC.

Ursprünglich war die Standardanzahl der mithilfe von IPC für alle Systeme reservierten Puffer 1.000 zwischengespeicherte Nachrichtenheader, die von ein- und ausgehenden Nachrichten gemeinsam genutzt wurden. Je nach installierter Version der Cisco IOS-Software ist die Anzahl der im IPC-Cache zwischengespeicherten Nachrichtenheader entweder statisch, dynamisch oder kann eingestellt werden.

Hier ist die Ausgabe des Befehls show ipc status von einem Router mit den standardmäßigen 1000 Nachrichtenheadern.

Hinweis: Die Cisco IOS Software Release 12.2T und 12.2S führen Änderungen an der Ausgabe dieses Befehls ein.

router#show ipc status

IPC System Status:

This processor is the IPC master server.

1000 IPC message headers in cache

4049362 messages in, 92615 out, 4048932 delivered to local port,

352 acknowledgments received, 386 sent,

0 NACKS received, 0 sent,

15326 messages dropped on input, 154 messages dropped on output

0 no local port, 110 destination unknown, 0 no transport

0 missing callback or queue, 34 duplicate ACKs, 0 retries,

0 message timeouts.

0 ipc_output failures, 0 mtu failures,

7707 msg alloc failed, 0 emer MSG alloc failed, 0 no origs for RPC replies

0 pak alloc failed, 0 memd alloc failed

0 no hwq, 0 failed opens, 0 hardware errors

Die erforderliche Speicherkapazität hängt vom Kartentyp (RP oder LC, RSP oder VIP) der Plattform und von der Aktivität der Anwendungen ab, die IPC benötigen (z. B. verteiltes CEF).

Aus der Cisco IOS Software Release 12.0(23)S, 12.2(18)S und der neuen IOS-Technologie werden 12.3 und 12.3T übertragen. Der IPC-Nachrichtencache wird dynamisch verwaltet, anstatt statisch den IPC-Cache zuzuweisen. Die vorgeschlagene Lösung für das Problem der Deaktivierung des IPC-Nachrichtencaches aufgrund von sprunghaft ansteigendem IPC-Datenverkehr war die dynamische Erweiterung und Verkleinerung des Nachrichtencaches. Bei der Initialisierung weist das System eine vom System festgelegte Standardanzahl von Meldungen zu. Wenn die Anzahl der freien Nachrichten die "minimalen" Puffer nicht erreicht, wird der kritische Hintergrundprozess benachrichtigt, um den Cache zu vergrößern. Dadurch kann IPC den Cache weiter erweitern, um die Anforderungen seiner Clients zu erfüllen. Wenn die kürzlich zugewiesenen Puffer von IPC für einen bestimmten Zeitraum nicht verwendet werden, beginnt dieser Prozess zu verkleinern. Der Cache hört auf zu schrumpfen, wenn er die Standardgröße erreicht. Diese Leistungssteigerung wurde in CSCdv57496 eingeführt. Mit der Implementierung von CSCdv57496 funktioniert der Befehl ipc cache <size> nicht mehr so, wie er automatisch ausgeführt wird. Dies gilt für alle IPC-Plattformen.

Wichtiger Hinweis: In der Cisco IOS Software, Version 12.3(5.5)T, wurde die Möglichkeit zur manuellen Optimierung des IPC-Cache entfernt. Weitere Informationen finden Sie unter CSCec17505 (nur registrierte Kunden).

Wenn Sie die Ausgabe des Befehls show ipc queue überprüfen, müssen Sie Folgendes sehen:

c7500#show ipc queue

Message waiting for acknowledgement in  Tx queue :       0

Maximum acknowledgement msg usage in Tx queue :          0

Message waiting for additional Fragments      :          0

Maximum message fragment usage                :          0

There are 0 IPC messages waiting for a response.

There are 0 IPC messages currently on the IPC inboundQ.

Messages currently in use                     :          0

Message cache size                            :       1000

Maximum message cache usage                   :       1344

0 times message cache crossed 5000 [max]

Emergency messages currently in use           :          0

Inbound message queue depth 0

Zone inbound message queue depth 0

Wenn der Router eine Cisco IOS-Softwareversion ohne dynamisch verwaltete IPC-Cache-Puffer ausführt, d. h. Bilder vor 12.0(23)S, 12.2(18)S, 12.3 und 12.3T, kann der IPC-Cache auf dem RP und der IPC-Speicher auf Linecards manuell erhöht werden. Verwenden Sie dazu den Befehl show ipc status, um zu prüfen, ob dem RP, LC oder beiden die IPC-Puffer fehlen. Nehmen Sie diese Ausgabe, und überprüfen Sie sie sowohl vom RP als auch vom LC.

Sie können die folgenden Befehle ggf. verwenden, um die Erinnerungen zu optimieren:

- Der Konfigurationsbefehl ipc cache 5000, um den IPC-Header-Cache auf dem RP zu erhöhen.

- Der ipc-Cache <Größe> [Steckplatz {Name des Steckplatzes} | all}] Befehl, um den Cache auf dem Cisco 12000 LC zu erhöhen.

Hinweis: Wenn Sie mehr Speicher für IPC-Nachrichten reservieren, steht weniger Speicher für andere Prozesse zur Verfügung. Die Größe einer einzelnen IPC-Nachricht variiert je nach Zweigstelle der Cisco IOS-Software. Verwenden Sie den Befehl show memory summary, um zu überprüfen, ob genügend freier Speicher im Prozessorpool vorhanden ist.

Schritt 2: Einstellen des IPC-Durchsatzes

Hinweis: In Tabelle 2 finden Sie eine Liste der IOS-Versionen mit den in diesem Abschnitt aufgeführten Erweiterungen.

In einigen Situationen können Sie auch den IPC-Durchsatz zwischen RP und LC einstellen. Dies ist insbesondere der Fall, wenn der RP eine große CEF-Tabelle in den LC hochladen muss. Dies kann beispielsweise beim Booten des Routers der Fall sein, wenn er eine große Menge an Routing-Informationen von einem BGP-Peer empfängt. Mit dem Befehl ip cef linecard ipc memory xxxxx können Sie zusätzliche IPC-Pufferung auf dem LC konfigurieren, um die IPC-Bandbreite zu erhöhen. Dieser Befehl wurde von CSCds89515 eingeführt (nur registrierte Kunden). Der Wert für diesen Speicher wurde mit CSCdu54205 (nur registrierte Kunden) und CSCuk27162 auf einen akzeptablen Standardwert (nur registrierte Kunden) festgelegt.

Die folgenden Befehle geben beim Ändern dieses Parameters das Ergebnis an:

Router#configure terminal

Enter configuration commands, one per line.  End with CNTL/Z.

Router(config)#ip cef line ipc mem 20000

Router(config)#^Z

Router#show cef state

...

RP state:

Expanded LC ipc memory:             20000 Kbytes

...

or, alternatively:

Router#show cef line

Slot      MsgSent    XDRSent  Window   LowQ   MedQ  HighQ Flags

0           12515      21687     505      0      0      0 up

1           12515      21675     505      0      0      0 up

3           12515      21701     505      0      0      0 up

5           12515      21700     505      0      0      0 up

2           12518      22008     505      0      0      0 up

Router#configure terminal

Enter configuration commands, one per line.  End with CNTL/Z.

Router(config)#ip cef line ipc mem 20000

Router(config)#^Z

Router#show cef line

Slot      MsgSent    XDRSent  Window   LowQ   MedQ  HighQ Flags

0           12538      22097    4966      0      0      0 up

1           12538      22081    4966      0      0      0 up

3           12538      22115    4966      0      0      0 up

5           12538      22114    4966      0      0      0 up

2           12541      22418    4966      0      0      0 up

Liste der IPC-Erweiterungen

Tabelle 2 bietet eine Übersicht über die in der Cisco IOS-Software implementierten Erweiterungen, um IPC-Speicher manuell und dynamisch über verschiedene Plattformen hinweg einzustellen.

Tabelle 2: Erweiterungen der Cisco IOS Software

Cisco Bug-ID

Fest in

Verbesserung

CSCdk75315 (nur registrierte Kunden)

12.0(5)S 12.0(5) 12.0(5)T 11.3(10)AA

Stellt eine IPC-Cache-Größe vor, die mithilfe des Befehls ipc cache <size> konfiguriert werden kann.

CSCds89515 (nur registrierte Kunden)

12.2(4)B 12.1(9)E 12.1(8a)E 12.2(3)T 12.2(2)S 12.1(9) 12.0(14)ST1 12.2(2) 12.2(1)T 12.0(15)S3 12.0 (16)ST 12.0(16)S

Auf einem Cisco Internet Router der Serie 1200 kann die verteilte Cisco Express Forwarding (dCEF) aufgrund des Speicherbedarfs während einer großen Routing-Aktualisierung (z. B. beim Hochfahren) deaktiviert werden. Als Problemumgehung sollte der maximale Pfad im Border Gateway Protocol (BGP) reduziert werden, um die Menge an Informationen zu reduzieren, die CEF an die Linecards weitergibt. Alternativ können Sie die TCP-Fenstergröße reduzieren, um die Geschwindigkeit eingehender BGP-Updates zu verringern. Siehe Optimales Routing und Reduzierung des BGP-Speicherverbrauchs. Alternativ können Sie auch den Schnittstellenkonfigurationsbefehl ip cef linecard ipc memory 0-128000 eingeben. Die Anzahl der Linecard-Prozessoren oder des Hauptspeichers ist auf 50 % des Gesamtspeichers beschränkt. Mit diesem Befehl können Sie der Warteschlange für das CEF-Routing eine größere Menge an Line Card-Prozessorspeicher zuweisen, um Nachrichten zu aktualisieren. Er ermöglicht dem RP, CEF-Updates schneller freizugeben, um Speicher freizugeben, und verhindert, dass der RP einen niedrigen Speicherbedarf aufweist. Aufgrund der Anzahl an VIPs (Versatile Interface Processors) benötigt dCEF eine große Menge an temporärem Speicher auf dem RSP, um IPC-Nachrichten zu puffern, die an das VIP gebunden sind. Dies gilt insbesondere für Fälle, in denen große BGP-Peers verfügbar sind oder wenn die Forwarding Information Base (FIB) nach einem CBUS-Komplex oder einem VIP-Absturz an das VIP weitergeleitet wird (oder wenn die Clear Line) ausgegeben wird).

CSCdu21591 (nur registrierte Kunden)

12.0(17)ST4 12.0(18)ST 12.0(18)S

Erhöht auf Routern der Serie 12000 die standardmäßige Cache-Größe für IPC-Nachrichten-Header von 1000 auf 5000. Früher akzeptierte der Parser eine beliebige Zahl zwischen den hartcodierten Werten 1000 und 15000. Heute akzeptiert der Parser nur Zahlen zwischen der plattformdefinierten Mindest- und Maximalgröße des Cache. Darüber hinaus war es ursprünglich nicht möglich, den Befehl ipc cache aus der Konfiguration zu löschen, selbst wenn Sie den Befehl no ipc cache in der Konfiguration ausgeführt haben, um einen benutzerdefinierten IPC-Cache-Wert zu entfernen. Stattdessen wurde ein IPC-Cache-x-Befehl eingefügt, wobei x die aktuell definierte Standardcache-Größe ist. Heute hat der Befehl no ipc cache das erwartete Verhalten. Der Befehl ipc cache wird vollständig aus der Konfiguration entfernt.

CSCdu12540

12.0(19)ST 12.0(19)S

Gilt nur für die Cisco Serie 1200: Ursprünglich funktionierte der Befehl ipc cache <size> nur für den RP IPC-Cache. Der Befehl ipc cache kann jetzt auf LCs wie folgt verwendet werden:

ipc cache <size> [slot {slot_num | all}]

Die Optionen slot_num und alle schließen sich nicht gegenseitig aus. Diese Befehle sind z. B. gültig: ipc cache 4000 Steckplatz alle ipc cache 3000 Steckplatz 5 Diese Befehle erhöhen die Cache-Größe in Steckplatz 5 bis 3000 und für alle anderen Steckplätze auf 4000. Wenn Sie die All-Option verwenden möchten, um vorherige Cache-Größenkonfigurationsanweisungen für LCs zu überschreiben, stellen Sie sicher, dass Sie auch "NOPREFIX" verwenden, um die vorherigen Befehle im nichtflüchtigen RAM (NVRAM) zu löschen, und implementieren Sie die richtigen Ergebnisse. Verwenden Sie im Noprefix-Modus den no ipc cache-Steckplatz {slot_num | all} Befehl, um die Cache-Größe auf den Standardwert zurückzusetzen.

CSCdu54205

12.0(19)ST 12.0(19)S

Gilt nur für die Cisco Serie 1200: Durch diese Erweiterung wurde der Standardwert für die CEF-Aktualisierungsspeicherzuweisung für Linecards in 512 Nachrichten geändert. Es ist nicht mehr erforderlich, den Befehl ip cef linecard ipc memory xxxxx zu verwenden, es sei denn, das Problem wurde festgestellt.

CSCuk27162 (nur registrierte Kunden)

12.2(9)T 12.2(9)S 12.2(9) 12.0(21)ST 12.0(22)S

Durch diese Softwareverbesserung wird die beim Start zugewiesene standardmäßige Anzahl an IP-Puffern für Line Cards pro Plattform geändert. Außerdem wird der RSP-IPC-Speicher pro Plattform von 25 auf 128 IPC-Nachrichten erhöht. Problemumgehung: Verwenden Sie den globalen Konfigurationsbefehl ip cef linecard ipc memory xxxxx, um die Anzahl der Puffer auf den Linecards zu erhöhen.

CSCdv57496

12,0(23)S

Management des IPC-Nachrichtencaches dynamisch anstelle der statischen Zuweisung des IPC-Cache Mit der Implementierung von CSCdv57496 ist der Befehl ipc cache <size> ungültig, da dieser automatisch ausgeführt wird. Dies gilt für alle IPC-Plattformen.

CSCdz77490

12.2(19.7)S 12.0(26.2)S 12.3(1)B 12.3(1)

Mit der Implementierung von CSCdz77490 wird der ipc-Cache <size>-Befehlszeilenschnittstelle aus den Cisco IOS Software-Zügen 12.3 und 12.3T entfernt. Im Cisco IOS 12.3 Train ist dieser Befehl zwar ausgeblendet, aber bei einer Konfiguration vom Terminal wird dem Benutzer eine Nachricht ausgegeben. In der nächsten Hauptversion 12.4 wird dieser Befehl entfernt.

CSCec17505 (nur registrierte Kunden)

Noch nicht festgelegt

Symptome: Die Größe des ipc-Cache ändert sich nicht, wenn Sie den Befehl ipc cache <size> CLI verwenden, um die Cache-Größe zu ändern. Bedingungen: Diese Bedingung ist auf Änderungen der Architektur bei IPC zurückzuführen. Problemumgehung: Die IPC-Cache-Funktionalität wird nun automatisch ausgeführt und kann vom Benutzer in der CLI nicht mehr geändert werden. Diese Erweiterung entfernt den Befehl ipc cache <size> CLI in den Cisco IOS-Softwareversionen, mit dem der Benutzer den IPC-Cache nicht mehr manuell ändern kann. Es sollten keine Probleme mit der Abwärtskompatibilität auftreten, da die CLI weiterhin in Versionen vorhanden ist, in denen der Benutzer den IPC-Cache manuell mit dem Befehl ipc cache <size> CLI ändern kann.

Cisco Serie 7600

Bei der Ausführung eines Catalyst-Betriebssystems verwendet der Catalyst 6000/Cisco 7600 eine Supervisor Engine mit einer optionalen Router-Karte, die als Multilayer Switch Feature Card (MSFC) bezeichnet wird. Die CPU auf dem Supervisor und die CPU auf der MSFC kommunizieren über IPC-Nachrichten über einen Ethernet-Out-of-Band-Managementbus. Bei der Ausführung der Cisco IOS-Systemsoftware kommunizieren der RP und der Switch-Prozessor (SP) auch über IPC-Meldungen. Ursprünglich wurden für IPC-Nachrichten 3.000 Puffer erstellt. In seltenen Fällen ist das System nicht in der Lage, IPC-Puffer zu speichern, und es werden folgende Fehlermeldungen ausgegeben:

01:52:13: %ICC-2-NOMEM: No memory available for unregistering card Card2

02:42:08: %IPC-3-NOBUFF: The main IPC message header cache has emptied

-Traceback= 4026779C 40268350 4025F930 40223D34 40221C40 40221EA4 401EAB10

Hinweis: ICC steht für InterCard Communications.

Aus den Cisco IOS Software Releases 12.1(08a)E01 und 12.1(10)E erstellt die Cisco Serie 7600 standardmäßig 6000 IPC-Nachrichtenpuffer. Darüber hinaus tragen die Änderungen in den Versionen 12.1(08a)E und 12.1(09)EC dazu bei, die Deaktivierung von IPC-Headern zu vermeiden, die auf eine große Anzahl von Updates im Zusammenhang mit Virtual LAN (VLAN) zurückzuführen sind. Jede ICC-Nachricht kündigt eine Gruppe von VLAN-Link-State-Änderungen an und nicht jeweils ein VLAN.

Neuere Linecards für die Cisco Serie 7600 unterstützen eine verteilte Feature-Tochterkarte (DFC) für hohe Paketverarbeitungsraten. Die DFC-fähigen Line Cards verwalten lokale Cisco Express Forwarding- und Adjacency-Tabellen und kommunizieren mit dem Supervisor über IPC-Nachrichten.

Einige IPC-Nachrichten sind größer als die maximale Übertragungseinheit (Maximum Transmission Unit, MTU) des Catalyst 6000-Switching-Bus (z. B. IPC-Nachrichten, die verwendet werden, um SONET-Schnittstellenstatistiken in Nachrichten mit einer Kapazität von mehr als 1500 Byte zu melden). Solche Nachrichten müssen fragmentiert werden. In seltenen Fällen ist der Cache des IPC-Fragmentkopfs erschöpft, und das System meldet folgende Fehlermeldung:

%IPC-DFC6-3-NOBUFF: The fragment IPC message header cache has emptied

Durch die Änderungen in den Cisco IOS Software Releases 12.1(08a)E und 12.1(09.05)EC wird die Anzahl der IPC-Fragmentpuffer-Header von 32 auf 128 erhöht.

Diese Meldung kann in der Debug-Ausgabe angezeigt werden, wenn vom IPC-Client doppelte Bestätigungen empfangen werden.

IPC: Originalnachricht für ACK HDR kann nicht gefunden werden:

Doppelte Bestätigungen sind in der Regel auf Medienprobleme zurückzuführen, die dazu führen, dass die Bestätigungsnachrichten verloren gehen. Um diesen Bestätigungsverlust zu beheben, setzen Sie die Linecard wieder ein oder ersetzen Sie sie in die Steckplätze, um Medienprobleme zu vermeiden.

Sammeln von Informationen zur Fehlerbehebung für das Cisco TAC

Wenn Sie nach den oben beschriebenen Schritten zur Fehlerbehebung weiterhin Hilfe benötigen und beim Cisco TAC eine Serviceanfrage erstellen möchten, müssen Sie folgende Informationen zur Fehlerbehebung für IPC-3-NOBUFF-bezogene Fehlermeldungen angeben:

- Die Fehlerbehebung wurde durchgeführt, bevor Sie das Gehäuse geöffnet haben.

- Ausgabe des technischen Supports anzeigen (wenn möglich im Aktivierungsmodus).

- Protokollausgabe oder Konsolenaufzeichnungen anzeigen, falls verfügbar.

Bitte fügen Sie die gesammelten Daten in einem nicht zippierten Textformat (.txt) an Ihr Ticket an. Sie können Informationen zu Ihrem Ticket hinzufügen. Laden Sie das Tool mithilfe des Case Query Tool hoch (nur registrierte Kunden). Wenn Sie nicht auf das Fallabfrage-Tool zugreifen können, können Sie die relevanten Informationen an Ihr Ticket anhängen, indem Sie diese in der Betreffzeile Ihrer Nachricht an attach@cisco.com senden.
Hinweis: Laden Sie den Router vor dem Erfassen der oben genannten Informationen nicht manuell neu, oder starten Sie ihn nur, wenn Sie eine IPC-3-NOBUFF-Ausnahme beheben müssen, da dies dazu führen kann, dass wichtige Informationen, die zur Bestimmung der Ursache des Problems benötigt werden, verloren gehen.

Zugehörige Informationen

- Was verursacht einen "%RSP-3-NEUSTART? cbus komplex"?

- Anzeigen von CPU-Hog-Informationen für IPC-Prozesse

- Cisco Internet Router der Serie 1200: Häufig gestellte Fragen

- Optimales Routing und reduzierte BGP-Speicherbelegung

- Seite für technischen Support für Cisco Internet Router der Serie 1200

- Support-Seite für Cisco Router-Produkte

- Technischer Support - Cisco Systems