Fehlerbehebung bei hoher CPU, verursacht durch BGP-Scanner- oder Router-Prozess

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