Grundlegende Probleme mit dem Border Gateway Protocol
Inhalt
Einleitung
In diesem Dokument wird die Behebung der häufigsten Probleme mit dem Border Gateway Protocol (BGP) beschrieben. Darüber hinaus werden grundlegende Lösungen und Richtlinien vorgestellt.
Voraussetzungen
Anforderungen
Es sind keine besonderen Voraussetzungen erforderlich, um den Inhalt dieses Dokuments nachzuvollziehen. Grundlegende Informationen zum BGP-Protokoll sind nützlich. Weitere Informationen finden Sie im BGP-Konfigurationsleitfaden.
Verwendete Komponenten
Dieses Dokument ist nicht auf bestimmte Software- und Hardwareversionen beschränkt, sondern umfasst Befehle für Cisco IOS® und Cisco IOS® XE.
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 kennen.
Hintergrundinformationen
Dieses Dokument beschreibt einen grundlegenden Leitfaden zur Fehlerbehebung bei den häufigsten Problemen mit dem Border Gateway Protocol (BGP), bietet Abhilfemaßnahmen, nützliche Befehle/Fehlerbehebungen zum Erkennen der Problemursache sowie Best Practices zur Vermeidung potenzieller Probleme. Berücksichtigen Sie dabei alle möglichen Variablen und Szenarien, die nicht berücksichtigt werden können. Eine detailliertere Analyse kann durch das Cisco TAC erforderlich werden.
Topologie
Verwenden Sie dieses Topologiediagramm als Referenz für die in diesem Dokument bereitgestellten Ausgaben.
Szenarien und Probleme
Adjazenz ausgefallen
command. Wenn eine BGP-Sitzung offline ist, führen Sie show ip bgp all summary aus. Dies gibt den aktuellen Status der Sitzung an:
- Wenn die Sitzung nicht aktiv ist, kann sie zwischen IDLE und ACTIVE variieren (dies hängt vom Finite State Machine-Prozess ab).
- Wenn die Sitzung online ist, können Sie die Anzahl der empfangenen Präfixe sehen.
R2#show ip bgp all summary For address family: IPv4 Unicast BGP router identifier 198.51.100.2, local AS number 65537 BGP table version is 19, main routing table version 19 18 network entries using 4464 bytes of memory 18 path entries using 2448 bytes of memory 1/1 BGP path/bestpath attribute entries using 296 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 7208 total bytes of memory BGP activity 18/0 prefixes, 18/0 paths, scan interval 60 secs 18 networks peaked at 11:21:00 Jun 30 2022 CST (00:01:35.450 ago) Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 10.0.23.3 4 65537 6 5 19 0 0 00:01:34 18 198.51.100.1 4 65536 0 0 1 0 0 never Idle
Keine Verbindung
Die erste Voraussetzung ist die Verbindung zwischen beiden Peers. Daher wird die TCP-Sitzung auf Port 179 eingerichtet. Entweder sind sie direkt verbunden oder nicht), und Sie können einen Ping verwenden. Wenn Peering zwischen Loopback-Schnittstellen eingerichtet wird, muss ein Loopback-zu-Loopback-Ping durchgeführt werden. Wenn ein Ping-Test ohne ein bestimmtes Loopback als Quellschnittstelle durchgeführt wird, wird die IP-Adresse der ausgehenden physischen Schnittstelle anstelle der IP-Adresse des Routers als Quell-IP-Adresse des Pakets verwendet.
Wenn der Ping-Test nicht erfolgreich ist, berücksichtigen Sie folgende Gründe:
- Kein verbundener Routen-Peer oder überhaupt keine Route; Führen Sie den Befehl show ip route peer_IP_address aus.
- Layer-1-Problem: Physische Schnittstelle, SFP (Stecker), Kabel oder externes Problem (Transport und ggf. Provider) müssen berücksichtigt werden.
- Überprüfen Sie alle Firewalls oder Zugriffslisten, die Ihre Verbindung blockieren können.
Wenn der Ping erfolgreich ist:
Konfigurationsprobleme
- Falsche IP-Adresse oder konfiguriertes AS: Bei falschen IP-Adressen wird keine Meldung angezeigt. Stellen Sie jedoch sicher, dass die richtige Konfiguration abgeschlossen ist. Bei einem falschen AS muss eine Meldung angezeigt werden, die dem Befehl show logging ähnelt.
%BGP-3-NOTIFICATION: sent to neighbor 198.51.100.1 passive 2/2 (peer in wrong AS) 2 bytes 1B39
Überprüfen Sie die BGP-Konfiguration auf beiden Seiten, um die AS-Nummern oder die Peer-IP-Adresse zu korrigieren.
- Doppelte Router-ID:
%BGP-3-NOTIFICATION: sent to neighbor 198.51.100.1 passive 2/3 (BGP identifier wrong) 4 bytes 0A0A0A0A
Überprüfen Sie die BGP-ID an beiden Enden, indem Sie den Befehl show ip bgp all summary ausführen und das doppelte Problem beheben. Dies kann manuell mit dem globalen Befehl bgp router-id X.X.X.X unter der bgp-Router-Konfiguration erreicht werden. Als Best Practice sollten Sie sicherstellen, dass für die Router-ID manuell eine eindeutige Nummer festgelegt wird.
- BGP-Quelle und TTL:
Die meisten iBGP-Sitzungen werden über Loopback-Schnittstellen konfiguriert, die über ein IGP erreichbar sind. Diese Loopback-Schnittstelle muss explizit als Quelle definiert werden. Sie können dies vervollständigen, indem Sie den Befehl neighbor ip-address update-source interface-id ausführen.
Bei direkt mit dem eBGP-Peer verbundenen Schnittstellen werden die meisten für Peering verwendet. Es wird geprüft, ob Cisco IOS/Cisco IOS XE diesen Zweck erfüllt, oder es wird nicht versucht, eine Sitzung herzustellen. Wenn auf direkt verbundenen Routern versucht wird, ein eBGP von Loopback zu Loopback durchzuführen, kann diese Prüfung für einen bestimmten Nachbarn auf beiden Seiten deaktiviert werden, indem der Befehl neighbor ip-address disable-connected-check ausgeführt wird.
Wenn es jedoch mehrere Hops zwischen den eBGP-Peers gibt, ist eine korrekte Hop-Anzahl erforderlich. Stellen Sie sicher, dass die Nachbaradresse ebgp-multihop [Hop-Count] mit der richtigen Hop-Anzahl konfiguriert ist, damit jede Sitzung hergestellt werden kann. Wenn Sie keinen Hop-Count angeben, beträgt der TTL-Standardwert für iBGP-Sitzungen 255, während der TTL-Standardwert für eBGP-Sitzungen 1 beträgt.
Probleme mit TCP-Sitzungen
Eine nützliche Aktion zum Testen von Port 179 ist ein manuelles Telnet von einem Peer zum anderen:
R1#telnet 198.51.100.2 179 Trying 198.51.100.2, 179 ... Open [Connection to 198.51.100.2 closed by foreign host]
Entweder die offene Verbindung oder die Verbindung wurde geschlossen, oder die Verbindung, die vom Remote-Host abgelehnt wurde, weist darauf hin, dass die Pakete das Remote-Ende erreicht haben. Stellen Sie dann sicher, dass es keine Probleme mit der Kontrollebene am anderen Ende gibt. Wenn andernfalls die Meldung Destination Unreachable (Ziel nicht erreichbar) angezeigt wird, überprüfen Sie die Firewall oder die Zugriffslisten, die den TCP-Port 179, BGP-Pakete blockieren können, oder ob auf dem Pfad Paketverluste auftreten.
Wenn die Authentifizierung ein Problem darstellt, werden folgende Meldungen angezeigt:
%TCP-6-BADAUTH: Invalid MD5 digest from 198.51.100.1(179) to 198.51.100.2(20062) tableid - 0 %TCP-6-BADAUTH: No MD5 digest from 198.51.100.1(179) to 198.51.100.2(20062) tableid - 0
Überprüfen Sie die Authentifizierungsmethoden, das Kennwort und die zugehörigen Konfigurationen, und finden Sie weitere Informationen zur Fehlerbehebung im Leitfaden zur MD5-Authentifizierung zwischen BGP-Peers - Konfigurationsbeispiel.
Wenn die TCP-Sitzung nicht online ist, verwenden Sie die folgenden Befehle zur Isolierung:
show tcp brief all
show control-plane host open-ports
debug ip tcp transactions
Adjazenz-Bounces
Wenn die Sitzung unregelmäßig ist, suchen Sie nach dem Show-Protokoll, und Sie können einige Szenarien finden.
Schnittstellen-Flap
%BGP-5-ADJCHANGE: neighbor 198.51.100.2 Down Interface flap
Der Grund für diesen Fehler liegt in der "Down Interface Flap"-Meldung. Achten Sie auf physische Probleme mit dem Port/SFP, dem Kabel oder den getrennten Verbindungen.
Haltezeit abgelaufen
%BGP-3-NOTIFICATION: sent to neighbor 198.51.100.2 4/0 (hold time expired) 0 bytes
Dies ist üblich, und der Router hat vor Ablauf des Haltezeitgebers keine Keepalive-Nachricht empfangen/verarbeitet oder die Nachricht aktualisiert. Das Gerät sendet eine Benachrichtigungsmeldung und schließt die Sitzung. Die häufigsten Gründe für dieses Problem sind:
- Schnittstellenprobleme: Suchen Sie nach Eingabefehlern, Verwerfungen der Eingabewarteschlange oder physischen Problemen an beiden Schnittstellen mit Peer-Verbindung. Dazu kann der Befehl show interface verwendet werden.
- Paketverlust bei der Übertragung: Manchmal können Hello-Pakete während der Übertragung verworfen werden, um sicherzustellen, dass dies eine Paketerfassung auf Schnittstellenebene ist:
- Verwenden Sie die integrierte Paketerfassung auf Cisco IOS- und Cisco IOS XE-Geräten.
- Wenn Pakete auf Schnittstellenebene erkannt werden, stellen Sie sicher, dass sie die Kontrollebene, EPC auf Kontrollebene erreichen, oder führen Sie den Befehl debug bgp [vrf name] ipv4 unicast keepalives aus.
- Hohe CPU: Ein hoher CPU-Zustand kann zu Drops auf der Kontrollebene führen. Der Befehl show processes cpu [sorted|history] kann bei der Identifizierung dieser Probleme helfen. Die nächsten Schritte zur Fehlerbehebung finden Sie auf Basis der Plattform im CPU-Referenzhandbuch.
- Probleme mit CoPP-Richtlinien: Die Methoden zur Fehlerbehebung variieren je nach Plattform und werden im vorliegenden Dokument nicht behandelt.
- MTU-Abweichung: Wenn im Pfad MTU-Diskrepanzen bestehen und ICMP-Nachrichten im Pfad von der Quelle zum Ziel blockiert werden, funktioniert die PMTUD nicht ordnungsgemäß und kann zu Sitzungsflaps führen. Updates werden mit dem ausgehandelten MSS-Wert und einem DF-Bit-Satz gesendet. Wenn ein Gerät im Pfad oder am Ziel die Pakete mit einer höheren MTU nicht akzeptieren kann, sendet es eine ICMP-Fehlermeldung zurück an den BGP-Sprecher. Der Zielrouter wartet auf den BGP-Keepalive, oder das BGP aktualisiert das Paket auf seinen Hold-Down-Timer.
Sie können die ausgehandelte MSS überprüfen, indem Sie den Befehl show ip bgp neighbors ip_address ausführen.
Ein Ping-Test an einen bestimmten Nachbarn mit festgelegter DF kann zeigen, ob die MTU entlang des Pfads gültig ist:
ping 198.51.100.2 size max_seg_size df
Wenn MTU-Probleme festgestellt werden, muss die Konfiguration genau überprüft werden, um sicherzustellen, dass die MTU-Werte im gesamten Netzwerk konsistent sind.
AFI/SAFI-Probleme
%BGP-5-ADJCHANGE: neighbor 198.51.100.2 passive Down AFI/SAFI not supported
%BGP-3-NOTIFICATION: received from neighbor 198.51.100.2 active 2/8 (no supported AFI/SAFI) 3 bytes 000000
Address-Family Identifier (AFI) ist eine Funktionserweiterung, die vom Multi-Protocol BGP (MP-BGP) hinzugefügt wird. Es korreliert mit einem bestimmten Netzwerkprotokoll, z. B. IPv4, IPv6 usw. Zusätzliche Präzision durch einen nachfolgenden Address-Family Identifier (SAFI), z. B. Unicast und Multicast Diese Trennung wird bei MBGP mit den BGP-Pfadattributen (PAs) MP_REACH_NLRI und MP_UNREACH_NLRI erreicht. Diese Attribute werden in BGP-Aktualisierungsnachrichten übertragen und dienen dazu, Informationen über die Netzwerkerreichbarkeit für verschiedene Adressfamilien zu übertragen.
Die Nachricht enthält die Nummern der von der IANA registrierten AFI/SAFI:
- Überprüfen Sie die BGP-Konfiguration für die Adressfamilien auf beiden Seiten, um unerwünschte Adressfamilien zu korrigieren.
- Führen Sie den Befehl neighbor ip-address dont-ability-negotiate auf beiden Seiten aus. Weitere Informationen finden Sie im Leitfaden Nicht unterstützte Funktionen verursachen BGP-Peerfehlfunktion.
Pfadinstallation und -auswahl
Weitere Informationen zum BGP und zur Auswahl des besten Pfads finden Sie unter BGP Best Path Selection Algorithm.
Nächster Hop
Damit eine Route in die Routing-Tabelle installiert werden kann, muss der nächste Hop erreichbar sein. Andernfalls wird das Präfix, selbst wenn es sich in der Loc-RIB-BGP-Tabelle befindet, nicht in die RIB verschoben. Als Schleifenvermeidungsregel ändert iBGP in Cisco IOS/Cisco IOS XE das Attribut next hop nicht, da AS_PATH beim erneuten Schreiben des nächsten Hop und stellt seinen AS_PATH voran.
Sie können den nächsten Hop überprüfen, indem Sie den Befehl show ip bgp [prefix] ausführen, da dieser den nächsten Hop und ein nicht zugreifbares Wort bereitstellt. In diesem Beispiel ist dies ein Präfix, das R1 über eBGP an R2 übermittelt und R3 über die iBGP-Verbindung von R2 erhält:
R3#show ip bgp 192.0.2.1
BGP routing table entry for 192.0.2.1/32, version 0
Paths: (1 available, no best path)
Not advertised to any peer
Refresh Epoch 1
65536
198.51.100.1 (inaccessible) from 10.0.23.2 (10.2.2.2)
Origin incomplete, metric 0, localpref 100, valid, internal
rx pathid: 0, tx pathid: 0
Updated on Jul 1 2022 13:44:19 CST
Am Ausgang ist der nächste Hop die ausgehende Schnittstelle von R1, die R3 nicht kennt. Um diese Situation zu beheben, können Sie den nächsten Hop über IGP, statische Route ankündigen oder den Befehl neighbor ip-address next-hop-self auf dem iBGP-Peer ausführen, um die Next-Hop-IP (die direkt verbunden ist) zu ändern. Im Beispieldiagramm muss diese Konfiguration auf R2 sein. der Nachbar in Richtung R3 (Nachbar 10.0.23.3 Next-Hop-Self.)
Als Ergebnis wechselt der nächste Hop (nach einem leeren IP BGP 10.0.23.2 Soft) zur direkt verbundenen Schnittstelle (erreichbar) und das Präfix wird installiert:
R3#show ip bgp 192.0.2.1
BGP routing table entry for 192.0.2.1/32, version 24
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
65536
10.0.23.2 from 10.0.23.2 (10.2.2.2)
Origin incomplete, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0
Updated on Jul 1 2022 13:46:53 CST
RIB-Ausfall
Dies ist der Fall, wenn eine Route nicht in der globalen RIB installiert werden kann, was zu einem RIB-Ausfall führt. Häufige Gründe sind, wenn sich dasselbe Präfix bereits auf der RIB für ein anderes Routing-Protokoll mit geringerer administrativer Distanz befindet, der genaue Grund für einen RIB-Ausfall jedoch mit dem Befehl show ip bgp rib-failure angezeigt wird.
Race Condition
Das häufigste Problem tritt auf, wenn IGP in einem Szenario mit gegenseitiger Umverteilung gegenüber eBGP bevorzugt wird. Wenn eine IGP-Route in das BGP umverteilt wird, gilt sie als vom BGP lokal generiert und erhält standardmäßig ein Gewicht von 32.768. Allen von einem BGP-Peer empfangenen Präfixen wird standardmäßig die lokale Gewichtung 0 zugewiesen. Wenn also dasselbe Präfix verglichen werden muss, wird das Präfix mit der höheren Gewichtung in der Routing-Tabelle basierend auf dem Prozess zur Auswahl des besten BGP-Pfads installiert. Aus diesem Grund wird die IGP-Route auf der RIB installiert.
Die Lösung für dieses Problem besteht darin, eine höhere Gewichtung für alle Routen festzulegen, die vom BGP-Peer unter der Router-BGP-Konfiguration empfangen werden:
neighbor ip-address weight 40000
Sonstige Fragen
BGP: langsamer Peer
Ein Peer kann nicht mit der Rate mithalten, mit der ein Absender Aktualisierungsnachrichten generiert. Es gibt viele Gründe für einen Kollegen, dieses Problem aufzuzeigen. hohe CPU in einem der Peers, übermäßiger Datenverkehr, Datenverlust auf einer Verbindung, Bandbreitenressourcen usw.
Arbeitsspeicherprobleme
BGP verwendet Speicher, der dem Cisco IOS-Prozess zugewiesen ist, um Netzwerkpräfixe, optimale Pfade, Richtlinien und alle zugehörigen Konfigurationen für den ordnungsgemäßen Betrieb zu verwalten. Die Gesamtprozesse werden durch den Befehl show processes memory sorted angezeigt:
R1#show processes memory sorted
Processor Pool Total: 2121414332 Used: 255911152 Free: 1865503180 reserve P Pool Total: 102404 Used: 88 Free: 102316 lsmpi_io Pool Total: 3149400 Used: 3148568 Free: 832 PID TTY Allocated Freed Holding Getbufs Retbufs Process 0 0 266231616 81418808 160053760 0 0 *Init* 662 0 34427640 51720 34751920 0 0 SBC main process 85 0 9463568 0 8982224 0 0 IOSD ipc task 0 0 34864888 25213216 8513400 8616279 0 *Dead* 504 0 696632 0 738576 0 0 QOS_MODULE_MAIN 518 0 940000 8616 613760 0 0 BGP Router 228 0 856064 345488 510080 0 0 mDNS 82 0 547096 118360 417520 0 0 SAMsgThread 0 0 0 0 395408 0 0 *MallocLite*
Der Prozessorpool ist der verwendete Speicher. im Beispiel bei ca. 2,1 GB. Als Nächstes müssen Sie in der Spalte "Holding" den Unterprozess identifizieren, der den größten Teil davon ausmacht. Anschließend müssen Sie die vorhandenen BGP-Sitzungen, die Anzahl der empfangenen Routen und die verwendete Konfiguration überprüfen.
Allgemeine Schritte zum Reduzieren der Speicherkapazität durch BGP:
- BGP-Filterung: Wenn keine vollständige BGP-Tabelle benötigt wird, filtern Sie die Routen mithilfe von Richtlinien, und installieren Sie nur die benötigten Präfixe.
- Weiche Neukonfiguration: Suchen Sie nach der Soft-Reconfiguration der IP-Adresse des Nachbarn, die unter der BGP-Konfiguration eingeht. Mit diesem Befehl können Sie alle Präfixe anzeigen, die vor jeder eingehenden Richtlinie (Adj-RIB-in) empfangen wurden. Diese Tabelle benötigt jedoch ungefähr die Hälfte der aktuellen lokalen BGP-RIB-Tabelle, um diese Informationen zu speichern. Sie können diese Konfiguration also umgehen, wenn sie nicht zwingend erforderlich ist oder Ihre aktuellen Präfixe nur wenige sind.
Hohe CPU-Auslastung
Router verwenden unterschiedliche Prozesse für den Betrieb des BGP. Führen Sie den Befehl show process cpu sorted aus, um zu überprüfen, ob der BGP-Prozess die Ursache für eine hohe CPU-Auslastung ist.
R3#show processes cpu sorted CPU utilization for five seconds: 0%/0%; one minute: 0%; five minutes: 0% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 163 36 1463 24 0.07% 0.00% 0.00% 0 ADJ background 62 28 132 212 0.07% 0.00% 0.00% 0 Exec 2 39 294 132 0.00% 0.00% 0.00% 0 Load Meter 1 0 4 0 0.00% 0.00% 0.00% 0 Chunk Manager 3 27 1429 18 0.00% 0.00% 0.00% 0 BGP Scheduler 4 0 1 0 0.00% 0.00% 0.00% 0 RO Notify Timers 63 4 61 65 0.00% 0.00% 0.00% 0 BGP I/O 83 924 26 35538 0.00% 0.03% 0.04% 0 BGP Scanner 96 142 11651 12 0.00% 0.00% 0.00% 0 Tunnel BGP 7 0 1 0 0.00% 0.00% 0.00% 0 DiscardQ Backgro
Dies sind die gängigen Prozesse, Ursachen und allgemeinen Schritte zur Vermeidung einer hohen CPU-Auslastung aufgrund des BGP:
- BGP-Router: Wird einmal pro Sekunde ausgeführt, um eine schnellere Konvergenz sicherzustellen (dies ist ein wichtiger Thread). Er liest die BGP-Aktualisierungsmeldungen, validiert die Präfixe/Netzwerke und Attribute, aktualisiert die Tabelle und die Attributtabelle für AFI/SAFI-Netzwerk/Präfix, führt unter anderem eine Berechnung des besten Pfads durch.
Riesige Routenabwanderungen sind ein sehr häufiges Szenario, das zu dieser Situation führt. - BGP-Scanner: Prozess mit niedriger Priorität wird standardmäßig alle 60 Sekunden ausgeführt. Bei diesem Prozess wird die gesamte BGP-Tabelle auf Next-Hop-Erreichbarkeit geprüft und die BGP-Tabelle entsprechend aktualisiert. Sie wird zu Weiterverteilungszwecken über die Routing Information Base (RIB) geleitet. Prüfen Sie die Plattformgröße, da mehr Präfixe und Routen installiert und TCAM verwendet werden, da mehr Ressourcen benötigt werden.
- BGP-E/A: Wird ausgeführt, wenn BGP-Steuerungspakete empfangen werden, und verwaltet die Warteschlangenzuweisung und Verarbeitung von BGP-Paketen. Wenn die BGP-Warteschlange über einen längeren Zeitraum übermäßig viele Pakete enthält oder ein TCP-Problem auftritt, zeigt der Router Symptome einer hohen CPU-Auslastung aufgrund des BGP-E/A-Prozesses. In der Regel ist der BGP-Router in dieser Situation ebenfalls hoch. Überprüfen Sie die Nachrichtenanzahl, um einen Peer zu identifizieren, und erfassen Sie Pakete, um die Quelle dieser Nachrichten zu identifizieren.
- BGP offen: Verfahren zur Sitzungserstellung; kein häufig auftretendes Problem mit hoher CPU, es sei denn, eine Sitzung ist im Zustand "Offen".
- BGP-Ereignis: Ist für die Next-Hop-Verarbeitung verantwortlich. Suchen Sie nach Flaps auf empfangene Präfixe für den nächsten Hops.
Zugehörige Informationen
- Technischer Support und Dokumentation für Cisco Systeme
- BGP-Konfigurationsleitfaden
- MD5-Authentifizierung zwischen BGP-Peers - Konfigurationsbeispiel
- Integrierte Paketerfassung
- BGP Neighbor Flaps mit MTU - Fehlerbehebung
- Nicht unterstützte Funktionen verursachen BGP-Peer-Fehlfunktion
- BGP – Algorithmus für die Auswahl des besten Pfads
- Verständnis des BGP-RIB-Ausfalls und des Befehls "bgp suppress-inactive"
- Die Bedeutung des BGP-Weight-Pfadattributs in Netzwerk-Failover-Szenarien
- Beheben von Problemen mit langsamem Peer mithilfe der BGP-Funktion "Slow Peer"
- Konfiguration von BGP-Routern für optimale Leistung und reduzierten Arbeitsspeicherbedarf
- Fehlerbehebung bei hoher CPU-Auslastung durch den BGP-Scanner- oder Router-Prozess
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
5.0 |
02-Sep-2026
|
Durch die Rezertifizierung wurden die Rechtschreibung/Grammatik aktualisiert, horizontale Linien wurden zur besseren Lesbarkeit in separate Abschnitte eingefügt, und CCW-Fehler wurden behoben. |
4.0 |
19-Feb-2025
|
Rezertifizierung |
3.0 |
25-Sep-2023
|
IOS XE aktualisiert (gestrichelter Text entfernt) und Markenbezeichnung, Suchmaschinenoptimierung und Formatierung hinzugefügt. |
2.0 |
21-Feb-2023
|
Rezertifizierung. |
1.0 |
04-Aug-2022
|
Erstveröffentlichung |
Feedback