Cisco Router der Serien 12000, 1000, 7600 und 7500: Fehlerbehebung bei IPC-3-NOBUFF-Nachrichten

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:

Ü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.

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

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

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