Inhalt

Einleitung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Konventionen

Hintergrundinformationen

BGP-Prozesse verstehen

Hohe CPU durch BGP-Scanner

Hohe CPU aufgrund des BGP-Router-Prozesses

Leistungsverbesserungen

Warteschlange zu TCP-Peer-Verbindungen

BGP-Peer-Gruppen

Pfad-MTU und Befehl ip tcp path-mtu discovery

Vergrößern der Schnittstellen-Eingabewarteschlangen

Zusätzliche Verbesserungen beim Cisco IOS

Fehlerbehebungsverfahren

Zugehörige Informationen

Einleitung

In diesem Dokument wird beschrieben, wie bei Verwendung des BGP-Scanners oder -Routers eine Fehlerbehebung für die Ursache von hohen CPU-Werten durchgeführt wird.

Voraussetzungen

Anforderungen

Dieses Dokument erfordert Kenntnisse zur Interpretation des Befehls show process cpu.

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf der Cisco IOS® Softwareversion 12.0.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle verstehen.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).

Hintergrundinformationen

In diesem Dokument werden Situationen beschrieben, in denen ein Cisco IOS-Router aufgrund des Border Gateway Protocol (BGP)-Routerprozesses oder des BGP-Scannerprozesses eine hohe CPU-Auslastung erleben kann, wie in der Ausgabe des Befehls show process cpu dargestellt. Die Dauer des hohen CPU-Zustands hängt von einer Reihe von Bedingungen ab, insbesondere von der Größe der Internet-Routing-Tabelle und der Anzahl der Routen, die ein bestimmter Router in seinen Routing- und BGP-Tabellen unterhält. Der Befehl show process cpu gibt die durchschnittliche CPU-Auslastung der letzten fünf Sekunden, eine Minute und fünf Minuten an. Die CPU-Auslastungszahlen liefern keine echte lineare Anzeige der Auslastung in Bezug auf die angebotene Auslastung.

Dies sind einige der Hauptgründe:

- In einem realen Netzwerk muss die CPU verschiedene Systemwartungsfunktionen wie das Netzwerkmanagement verarbeiten.

- Die CPU muss regelmäßige und ereignisgesteuerte Routing-Updates verarbeiten.

- Es gibt weitere interne Systemoverhead-Vorgänge, z. B. das Polling der Ressourcenverfügbarkeit, die nicht proportional zur Datenverkehrslast sind.

Sie können auch den Befehl show process cpu verwenden, um einen Hinweis auf die CPU-Aktivität zu erhalten.

Anmerkung: Weitere Informationen zu den Anzeigebefehlen finden Sie in der Befehlsreferenz zu den Grundlagen der Cisco IOS-Konfiguration.

BGP-Prozesse verstehen

Ein Cisco IOS-Prozess besteht im Allgemeinen aus den einzelnen Threads und den zugehörigen Daten, die Aufgaben wie Systemwartung, Switching-Pakete und Implementierung von Routing-Protokollen ausführen. Mehrere auf dem Router ausgeführte Cisco IOS-Prozesse ermöglichen die Ausführung des BGP. Verwenden der Anzeigeprozess-CPU | BGP-Befehl einschließen, um die CPU-Auslastung aufgrund von BGP-Prozessen anzuzeigen.

Diese Tabelle listet die Funktion der BGP-Prozesse auf und zeigt, dass jeder Prozess zu unterschiedlichen Zeiten ausgeführt wird und diese Zeiten von den Aufgaben abhängen, die behandelt werden, da der BGP-Scanner und der BGP-Router-Prozess für eine große Anzahl von Berechnungen verantwortlich sind, können Sie aufgrund eines dieser Prozesse hohe CPUs sehen. In den nächsten Abschnitten werden diese Prozesse genauer beschrieben.

Prozessname

Beschreibung

Intervall

BGP offen

Führt BGP-Peer-Einrichtung durch.

Bei der Initialisierung, wenn eine TCP-Verbindung mit einem BGP-Peer hergestellt wird.

BGP-E/A

Behandelt BGP-Pakete, die sich in der Warteschlange befinden und verarbeitet werden, z. B. UPDATES und KEEPALIVES.

Als BGP-Steuerungspakete werden empfangen.

BGP-Scanner

Führt die BGP-Tabelle durch und bestätigt die Erreichbarkeit der nächsten Hops. Der BGP-Scanner überprüft auch das bedingte Advertisement, um zu ermitteln, ob das BGP Zustandspräfixe meldet und eine Routenreduzierung durchführt. In einer MPLS-VPN-Umgebung importiert und exportiert der BGP-Scanner Routen in eine bestimmte VPN-Routing- und -Weiterleitungsinstanz (VRF).

Einmal pro Minute.

BGP-Router

Berechnet den besten BGP-Pfad und verarbeitet jede Route-Abwanderung. Es sendet und empfängt Routen, stellt Peers her und interagiert mit der Routing Information Base (RIB).

Einmal pro Sekunde und beim Hinzufügen, Entfernen oder Soft-Konfigurieren eines BGP-Peers.

Hohe CPU durch BGP-Scanner

Eine hohe CPU aufgrund des BGP-Scannerprozesses kann bei Routern mit einer großen Internet-Routing-Tabelle für kurze Zeiträume erwartet werden. Der BGP-Scanner führt einmal pro Minute die BGP-RIB-Tabelle durch und führt wichtige Wartungsaufgaben durch. Diese Aufgaben umfassen die Prüfung des Next-Hop, auf den in der BGP-Tabelle des Routers verwiesen wird, und die Überprüfung, ob die Next-Hop-Geräte erreicht werden können. Daher benötigt eine große BGP-Tabelle eine entsprechend große Zeitspanne, um ausgeführt und validiert zu werden.

Da der BGP-Scanner-Prozess die gesamte BGP-Tabelle durchläuft, variiert die Dauer der hohen CPU-Bedingung je nach Anzahl der Nachbarn und der Anzahl der pro Nachbar abgefragten Routen. Verwenden Sie die Befehle show ip bgp summary und show ip route summary, um diese Informationen zu erfassen. Der BGP-Scanner-Prozess leitet die BGP-Tabelle, um Datenstrukturen zu aktualisieren, und leitet die Routing-Tabelle zu Routen-Umverteilungszwecken. (In diesem Kontext wird die Routing-Tabelle auch als Routing Information Base (RIB) bezeichnet, die der Router ausgibt, wenn Sie den Befehl;show ip route ausführen). Beide Tabellen werden separat im Speicher des Routers gespeichert und können groß sein und CPU-Zyklen verbrauchen.

Die nächste Beispielausgabe des Befehls debug ip bgp updates erfasst und führt einen BGP-Scanner aus:

router#

2d17h: BGP: scanning routing tables

2d17h: BGP: 10.0.0.0 computing updates, neighbor version 8,

table version 9, starting at 0.0.0.0

2d17h: BGP: 10.0.0.0 update run completed, ran for 0ms, neighbor

version 8, start version 9, throttled to 9, check point net 0.0.0.0

2d17h: BGP: 10.1.0.0 computing updates, neighbor version 8,

table version 9, starting at 0.0.0.0

2d17h: BGP: 10.1.0.0 update run completed, ran for 4ms, neighbor

version 8, start version 9, throttled to 9, check point net 0.0.0.0

router#

Während der BGP-Scanner ausgeführt wird, müssen Prozesse mit niedriger Priorität längere Zeit auf den Zugriff auf die CPU warten. Ein Prozess mit niedriger Priorität steuert ICMP-Pakete (Internet Control Message Protocol) wie Pings. Pakete, die für den Router bestimmt sind oder vom Router stammen, können eine höhere Latenz aufweisen als erwartet, da der ICMP-Prozess hinter dem BGP-Scanner warten muss. Der Zyklus besteht darin, dass der BGP-Scanner einige Zeit läuft und sich selbst unterbricht, und dann ICMP ausgeführt wird. Im Gegensatz dazu müssen Pings, die über einen Router gesendet werden, über Cisco Express Forwarding (CEF) umgeschaltet werden und dürfen keine zusätzliche Latenz aufweisen. Wenn Sie regelmäßige Spitzen bei der Latenz beheben, vergleichen Sie die Weiterleitungszeiten für über einen Router weitergeleitete Pakete mit Paketen, die direkt von der CPU auf dem Router verarbeitet werden.

Anmerkung: Ping-Befehle, die IP-Optionen angeben, z. B. Record Route, erfordern, dass die CPU sie direkt verarbeitet. Dies kann zu längeren Weiterleitungsverzögerungen führen.

Verwenden des Anzeigeprozesses | Befehl bgp scanner eingeben, um die CPU-Priorität anzuzeigen. Der Wert von LSI in der nächsten Beispielausgabe verwendet L, um auf einen Prozess mit niedriger Priorität zu verweisen.

6513#show processes | include BGP Scanner

172 Lsi 407A1BFC       29144     29130    1000 8384/9000  0 BGP Scanner

Hohe CPU aufgrund des BGP-Router-Prozesses

Der BGP-Router-Prozess wird etwa einmal pro Sekunde ausgeführt, um die Arbeit zu überprüfen. BGP-Konvergenz definiert die Dauer zwischen dem Zeitpunkt, zu dem der erste BGP-Peer eingerichtet wird, und dem Punkt, an dem das BGP konvergiert wird. Um die kürzeste Konvergenzzeit sicherzustellen, benötigt der BGP-Router alle freien CPU-Zyklen. Nach dem Start wird die CPU jedoch periodisch abgesetzt (oder unterbrochen).

Die Konvergenzzeit ist eine direkte Messung der CPU-Auslastung des BGP-Routers, nicht der Gesamtdauer. Dieses Verfahren zeigt eine hohe CPU-Bedingung während der BGP-Konvergenz und tauscht BGP-Präfixe mit zwei externen BGP (eBGP)-Peers aus.

1. Erfassen Sie eine Basislinie für die normale CPU-Auslastung, bevor Sie den Test starten.

router#show process cpu

CPU utilization for five seconds: 0%/0%; one minute: 4%; five minutes: 5%

2. Nach dem Start des Tests erreicht die CPU eine Auslastung von 100 Prozent. Der Befehl zur Schrittfolge zeigt, dass der hohe CPU-Zustand durch den BGP-Router verursacht wird, der in der nächsten Ausgabe mit 139 (der Cisco IOS-Prozess-ID für den BGP-Router) gekennzeichnet ist.

router#show process cpu

CPU utilization for five seconds: 100%/0%; one minute: 99%; five minutes: 81%

!--- Output omitted.

139     6795740   1020252       6660 88.34% 91.63% 74.01%   0 BGP Router

3. Sie können mehrere Ausgaben der show ip bgp summary überwachen und erfassen und zu diesem Zeitpunkt Prozess-CPU-Befehle anzeigen. Der Befehl show ip bgp summary erfasst den Zustand der BGP-Nachbarn.

router#show ip bgp summary

Neighbor    V    AS  MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down State/PfxRcd

10.0.0.0    4  64512  309453  157389    19981    0  253 22:06:44 111633

10.1.0.0  4  65101  188934    1047    40081   41    0 00:07:51 58430

4. Wenn der Router den Präfix-Austausch mit seinen BGP-Peers beendet, kehren die CPU-Nutzungsraten auf das normale Niveau zurück. Die berechneten Ein- und Fünf-Minuten-Durchschnittswerte können sich ebenfalls zurücksetzen und für einen längeren Zeitraum als die Fünf-Sekunden-Rate höhere Werte als normale Werte anzeigen.

router#show process cpu

CPU utilization for five seconds: 3%/0%; one minute: 82%; five minutes: 91%

5. Verwenden Sie die erfasste Ausgabe der vorherigen Befehle zum Anzeigen, um die BGP-Konvergenzzeit zu berechnen. Verwenden Sie insbesondere die Spalte Nach oben/Nach</strong> des Befehls show ip bgp summary, und vergleichen Sie die Start- und Stoppzeiten der hohen CPU-Bedingung. In der Regel kann die BGP-Konvergenz mehrere Minuten in Anspruch nehmen, wenn eine große Internet-Routing-Tabelle vorhanden ist. ausgetauscht

Anmerkung: Die hohe CPU auf dem Gerät kann auch auf die Instabilität der BGP-Tabelle zurückzuführen sein. Dies geschieht, wenn der Router zwei Kopien der Routing-Tabelle empfängt, eine davon vom EBGP-Peering mit dem ISP und die andere vom IBGP-Peering im Netzwerk. Die Hauptursache dafür ist die Speicherkapazität auf dem Gerät. Cisco empfiehlt mindestens 1 GB RAM für eine einzelne Kopie der Internet-Routing-Tabelle. Um diese Instabilität zu umgehen, erhöhen Sie den RAM auf dem Gerät, oder filtern Sie die Präfixe so, dass die BGP-Tabelle und der von ihr belegte Speicher entlastet werden.

Leistungsverbesserungen

Mit steigender Anzahl von Routen in der Internet-Routing-Tabelle nimmt auch die Zeit zu, die für die Konvergenz des BGP erforderlich ist. Im Allgemeinen wird Konvergenz als Prozess definiert, bei dem alle Routing-Tabellen in einen Zustand der Konsistenz gebracht werden. BGP gilt als konvergent, wenn diese Bedingungen zutreffen:

- Alle Routen wurden akzeptiert.

- Alle Routen wurden in der Routing-Tabelle installiert.

- Die Tabellenversion für alle Peers entspricht der Tabellenversion der BGP-Tabelle.

- InQ und OutQ für alle Peers sind Null.

In diesem Abschnitt werden einige Leistungsverbesserungen des Cisco IOS beschrieben, die zur Verkürzung der BGP-Konvergenzzeit führen. Dies führt aufgrund eines BGP-Prozesses zur Verringerung eines hohen CPU-Zustands.

Warteschlange zu TCP-Peer-Verbindungen

BGP stellt Daten jetzt für jeden Peer aggressiv vom BGP OutQ in den TCP-Socket ein, bis die OutQs vollständig gelöscht sind. Da BGP jetzt schneller sendet, wird das BGP schneller konvergiert.

BGP-Peer-Gruppen

Sie vereinfachen zwar die BGP-Konfiguration, aber auch die Skalierbarkeit von BGP-Peer-Gruppen. Alle Mitglieder einer Peer-Gruppe müssen eine gemeinsame Richtlinie für ausgehende Anrufe gemeinsam nutzen. Daher können dieselben Aktualisierungspakete an jedes Gruppenmitglied gesendet werden, wodurch die Anzahl der CPU-Zyklen reduziert wird, die das BGP zum Anzeigen von Routen an Peers benötigt. Mit anderen Worten: Bei Peer-Gruppen leitet das BGP die BGP-Tabelle nur über den Peer-Gruppenleiter, filtert die Präfixe durch die ausgehenden Richtlinien und generiert Updates, die es an den Peer-Gruppenleiter sendet. Der Leiter wiederum repliziert die Updates an Gruppenmitglieder, mit denen er synchronisiert ist. Ohne Peer-Gruppen muss das BGP die Tabelle für jeden Peer durchlaufen, Präfixe durch ausgehende Richtlinien filtern und Updates generieren, die nur an den einen Peer gesendet werden.

Pfad-MTU und Befehl ip tcp path-mtu discovery

Alle TCP-Sitzungen werden durch eine Beschränkung der Byteanzahl begrenzt, die in einem einzigen Paket übertragen werden kann. Dieser Grenzwert, der als maximale Segmentgröße (MSS) bezeichnet wird, beträgt standardmäßig 536 Byte. Mit anderen Worten, TCP teilt Pakete in einer Übermittlungswarteschlange in 536-Byte-Chunks auf, bevor es Pakete an die IP-Ebene weiterleitet. Verwenden Sie die show ip bgp neighbors. | Befehl max data zur Anzeige der MSS von BGP-Peers einschließen:

Router#show ip bgp neighbors | include max data

Datagrams (max data segment is 536 bytes):

Datagrams (max data segment is 536 bytes):

Datagrams (max data segment is 536 bytes):

Datagrams (max data segment is 536 bytes):

Der Vorteil einer MSS mit 536 Byte besteht darin, dass Pakete auf einem IP-Gerät entlang des Pfads zum Ziel nicht fragmentiert werden, da die meisten Verbindungen eine MTU von mindestens 1.500 Byte verwenden. Der Nachteil ist, dass kleinere Pakete die für den Transport von Overhead verwendete Bandbreite erhöhen. Da BGP eine TCP-Verbindung zu allen Peers aufbaut, wirkt sich eine MSS mit 536 Byte auf die BGP-Konvergenzzeiten aus.

Die Lösung besteht darin, die PMTU-Funktion (Path MTU) mit dem Befehl ip tcp path-mtu-discovery zu aktivieren. Mit dieser Funktion können Sie dynamisch bestimmen, wie groß der MSS-Wert sein kann, und in der Zwischenzeit keine Pakete erstellen, die fragmentiert werden müssen. Mit PMTU kann das TCP die kleinste MTU-Größe unter allen Verbindungen einer TCP-Sitzung bestimmen. TCP verwendet dann diesen MTU-Wert minus dem Platz für die IP- und TCP-Header als MSS für die Sitzung. Wenn eine TCP-Sitzung nur Ethernet-Segmente überquert, beträgt die MSS 1460 Byte. Wenn es nur Pakete über SONET (POS)-Segmente überträgt, beträgt die MSS 4430 Byte. Die Erhöhung der MSS von 536 auf 1460 oder 4430 Byte reduziert den TCP/IP-Overhead, wodurch das BGP schneller konvergiert.

Nachdem Sie PMTU aktiviert haben, verwenden Sie erneut die show ip bgp neighbors. | enthält den Befehl max data, um den MSS-Wert pro Peer anzuzeigen:

Router#show ip bgp neighbors | include max data

Datagrams (max data segment is 1460 bytes):

Datagrams (max data segment is 1460 bytes):

Datagrams (max data segment is 1460 bytes):

Datagrams (max data segment is 1460 bytes):

Vergrößern der Schnittstellen-Eingabewarteschlangen

Wenn das BGP Tausende von Routen an viele Peers weitergibt, muss TCP kurzfristig Tausende von Paketen übertragen. Die BGP-Peers empfangen diese Pakete und senden TCP-Bestätigungen an den BGP-Sprecher, der ankündigt. Dadurch erhält der BGP-Sprecher in kurzer Zeit eine Flut von TCP-ACKs. Wenn die ACKs eine zu hohe Übertragungsrate für den Routingprozessor erreichen, werden Pakete in eingehenden Schnittstellenwarteschlangen gesichert. Standardmäßig verwenden Router-Schnittstellen eine Eingabewarteschlangengröße von 75 Paketen. Zusätzlich verwenden spezielle Kontrollpakete wie BGP-UPDATES eine spezielle Warteschlange mit Selective Packet Discard (SPD). Diese spezielle Warteschlange enthält 100 Pakete. Wenn BGP-Konvergenz erfolgt, können TCP-ACKs schnell die 175 Spots der Eingangspufferung füllen, und die ankommenden neuen Pakete müssen verworfen werden. Auf Routern mit 15 oder mehr BGP-Peers und dem Austausch der vollständigen Internet-Routing-Tabelle werden pro Schnittstelle pro Minute mehr als 10.000 Trunks angezeigt. Im Folgenden finden Sie ein Beispiel für die Ausgabe eines Routers 15 Minuten nach dem Neustart:

Router#show interface pos 8/0 | include input queue

Output queue 0/40, 0 drops; input queue 0/75, 278637 drops

Router#

Wenn Sie die Tiefe der Schnittstelleneingangswarteschlange (mit dem Befehl hold-queue in command) erhöhen, reduziert dies die Anzahl der ausgelassenen TCP-ACKs, wodurch die Anzahl der Arbeiten, die BGP für die Konvergenz durchführen muss, reduziert wird. Normalerweise löst ein Wert von 1000 Probleme, die durch Verwerfen der Eingabewarteschlange verursacht werden.

Anmerkung: Verwenden Sie diese Option bewusst, da die Inkrementierung der Eingangswarteschlange zu einer gewissen Verzögerung führen kann.

Zusätzliche Verbesserungen beim Cisco IOS

Cisco IOS enthält verschiedene Optimierungen für den BGP-Peer-Gruppencode, um das Packen und die Replikation von Updates zu verbessern. Bevor Sie diese Verbesserungen überprüfen, sollten Sie das Update Packing und die Replikation genauer betrachten.

Ein BGP-Update besteht aus einer Kombination von Attributen (wie MED = 50 und LOCAL_PREF = 120) und einer Liste von NLRI-Präfixen (Network Layer Reachability Information), die diese Kombination von Attributen gemeinsam nutzen. Je mehr NLRI-Präfixe das BGP in einem einzigen Update auflisten kann, desto schneller kann das BGP konvergiert werden, da der Overhead (z. B. IP-, TCP- und BGP-Header) verringert wird. Update Packing bezieht sich auf das Packen von NLRI in BGP Updates. Wenn beispielsweise eine BGP-Tabelle 100.000 Routen mit 15.000 eindeutigen Attributkombinationen enthält, muss das BGP nur 15.000 Updates senden, wenn das NLRI mit einer Effizienz von 100 Prozent gepackt ist.

Anmerkung: Die Verpackungseffizienz von 0 % bedeutet, dass BGP in dieser Umgebung 100.000 Updates senden muss.

Verwenden Sie den Befehl show ip bgp peer-group, um die Effizienz der BGP-Updates anzuzeigen.

Wenn ein Peer-Gruppenmitglied synchronisiert ist, nimmt ein BGP-Router eine für den Peer-Gruppenleiter formatierte Update-Nachricht und repliziert diese für das Mitglied. Es ist weitaus effizienter, ein Update für ein Peer-Gruppenmitglied zu replizieren, als das Update neu zu formatieren. Angenommen, eine Peer-Gruppe besteht aus 20 Mitgliedern, und alle Mitglieder müssen 100 BGP-Nachrichten empfangen. 100 Prozent Replikation bedeutet, dass ein BGP-Router die 100 Nachrichten für den Peer-Gruppenleiter formatiert und diese Nachrichten an die anderen 19 Peer-Gruppenmitglieder repliziert. Um die Replikationsverbesserungen zu bestätigen, vergleichen Sie die Anzahl der replizierten Nachrichten mit der Anzahl der formatierten Nachrichten, wie im Befehl show ip bgp peer-group gezeigt. Diese Verbesserungen bewirken erhebliche Unterschiede bei den Konvergenzzeiten und ermöglichen es dem BGP, eine deutlich größere Anzahl von Peers zu unterstützen.

Verwenden Sie beispielsweise den Befehl show ip bgp peer-group, um die Effizienz des Aktualisierungspakets und der Replikation zu überprüfen. Die nächste Ausgabe stammt aus einem Konvergenztest mit 6 Peer-Gruppen, 20 Peers in jeder der ersten 5 Peer-Gruppen (eBGP-Peers) und 100 Peers in der sechsten Peer-Gruppe (interne BGP (iBGP)-Peers). Außerdem verfügte die verwendete BGP-Tabelle über 36.250 Attributkombinationen.

Die nächste Beispielausgabe der show ip bgp peer-group | enthält replizierten Befehl auf einem Router, der Cisco IOS 12.0(18)S ausführt, zeigt folgende Informationen an:

Update messages formatted 836500, replicated 1668500

Update messages formatted 1050000, replicated 1455000

Update messages formatted 660500, replicated 1844500

Update messages formatted 656000, replicated 1849000

Update messages formatted 501250, replicated 2003750

!-- The first five lines are for eBGP peer groups.

Update messages formatted 2476715, replicated 12114785

!-- The last line is for an iBGP peer group.

Um die Replikationsrate für jede Peer-Gruppe zu berechnen, teilen Sie die Anzahl der replizierten Updates durch die Anzahl der formatierten Updates:

1668500/836500 = 1,99 1455000/1050000 = 1,38 1844500/660500 = 2,79 184 9000/656000 = 2,81 2003750/501250 = 3,99 12114785/2476715 = 4,89

- Wenn BGP perfekt repliziert wurde, haben die eBGP-Peer-Gruppen jeweils eine Replikationsrate von 19, da es 20 Peers in der Peer-Gruppe gibt. Die Aktualisierung wird für den Peer-Gruppenleiter formatiert und dann auf die anderen 19 Peers repliziert. Dies bietet eine optimale Replikationsrate von 19. Die ideale Replikationsrate für die iBGP-Peer-Gruppe wäre 99, da es 100 Peers gibt.

- Wenn BGP-gepackte Updates perfekt sind, werden nur 36.250 Updates formatiert. Sie müssen nur 36.250 Updates für jede Peer-Gruppe generieren, da dies die Anzahl der Attributkombinationen in der BGP-Tabelle ist. Die iBGP-Peer-Gruppe allein formatiert fast 2.500.000 Updates, während die eBGP-Peer-Gruppen jeweils 500.000 bis 1.000.000 Updates generieren.

Auf einem Router, auf dem Cisco IOS 12.0(19)S ausgeführt wird, zeigt ip bgp peer-group | include replicatedcommand liefert diese Informationen:

Update messages formatted 36250, replicated 688750

Update messages formatted 36250, replicated 688750

Update messages formatted 36250, replicated 688750

Update messages formatted 36250, replicated 688750

Update messages formatted 36250, replicated 688750

Update messages formatted 36250, replicated 3588750

Anmerkung: Update Packing ist optimal. Für jede Peer-Gruppe werden genau 36.250 Updates formatiert. 688750/36250 = 19 68750/36250 = 19 688750/36250 = 19 688750/36250 = 19 688750/36250 = 19 3588750/36250 = 99

Anmerkung: Auch die Update-Replikation ist perfekt.

Fehlerbehebungsverfahren

Gehen Sie folgendermaßen vor, um eine Fehlerbehebung bei einer hohen CPU aufgrund eines BGP-Scanners oder BGP-Routers durchzuführen:

- Sammeln Sie Informationen zur BGP-Topologie. Bestimmen Sie die Anzahl der BGP-Peers und die Anzahl der Routen, die von den einzelnen Peers angekündigt werden. Ist die Dauer des hohen CPU-Zustands abhängig von Ihrer Umgebung angemessen?

- Stellen Sie fest, wann die hohe CPU auftritt. Passt es zu einem regelmäßig geplanten Spaziergang durch die BGP-Tabelle?

- Hat die hohe CPU einer Schnittstellen-Klappe gefolgt? Sie können den Befehl show ip bgp dämpfening flattern-statistics eingeben, wenn Dampening aktiviert ist.

- Pingen Sie durch den Router, und pingen Sie dann vom Router. ICMP-Echos werden als Prozess mit niedriger Priorität behandelt. Im DokumentErläuterungen zu den Befehlen Ping und Traceroute wird dies genauer erläutert. Stellen Sie sicher, dass die reguläre Weiterleitung nicht betroffen ist.

- Sie müssen sicherstellen, dass Pakete einem schnellen Weiterleitungspfad folgen können, wenn Sie überprüfen, ob Fast Switching und/oder CEF auf der Eingangs- und der Ausgangsschnittstelle aktiviert sind. Vergewissern Sie sich, dass der Befehl no ip route-cache cef auf der Schnittstelle oder der Befehl no ip cef in der globalen Konfiguration nicht angezeigt wird. Um CEF im globalen Konfigurationsmodus zu aktivieren, verwenden Sie den Befehl ip cef.

- Überprüfen Sie die Plattformskalierung, da dies in den meisten Fällen auf ein überlastetes Gerät zurückzuführen ist, das in solche Situationen führt. Stellen Sie außerdem sicher, dass auf dem Router der passende Tternary Content Addressable Memory (TCAM)-Speicherplatz verfügbar ist.

- Überprüfen Sie, ob genügend Speicher auf dem Router vorhanden ist. Gemäß der Empfehlung sollten pro BGP-Peer, der die vollständige Internet-Routing-Tabelle sendet, mindestens 1 GB DRAM pro Cisco IOS-Speicherplatz zugewiesen werden. Der hier erwähnte DRAM-Speicher entspricht dem für BGP erforderlichen Speicher. Für andere Funktionen, die auf dem Router ausgeführt werden, kann zusätzlicher Platz erforderlich sein.

Zugehörige Informationen

- IP Routing-Support-Seite

- Technischer Support – Cisco Systems