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), enthält Korrekturmaßnahmen, nützliche Befehle/Fehlerbehebungen zur Ermittlung der Problemursache sowie Best Practices zur Vermeidung potenzieller Probleme. Beachten Sie, dass nicht alle möglichen Variablen und Szenarien berücksichtigt werden können und dass das Cisco TAC eine eingehendere Analyse erforderlich machen könnte.
Topologie
Verwenden Sie dieses Topologiediagramm als Referenz für die in diesem Dokument bereitgestellten Ausgaben.
Szenarien und Probleme
Adjazenz ausgefallen
Wenn eine BGP-Sitzung unterbrochen ist und nicht gestartet wird, geben Sie Folgendes einshow ip bgp all summary command.:
- Wenn die Sitzung nicht aktiv ist, kann sie zwischen IDLE und ACTIVE variieren (abhängig vom Finite State Machine-Prozess).
- Wenn die Sitzung aktiv ist, wird die Anzahl der empfangenen Präfixe angezeigt.
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 Anforderung, die sichergestellt werden muss, ist die Verbindung zwischen beiden Peers, damit eine TCP-Sitzung auf Port 179 hergestellt werden kann. Entweder sind sie direkt verbunden oder nicht. Ein einfacher Ping ist in dieser Angelegenheit nützlich. Wenn Peering zwischen Loopback-Schnittstellen eingerichtet wird, muss ein Loopback-zu-Loopback-Ping durchgeführt werden. Wenn ein Ping-Test ohne spezifisches Loopback als Quellschnittstelle durchgeführt wird, wird die IP-Adresse der ausgehenden physischen Schnittstelle als Quell-IP-Adresse des Pakets und nicht als Loopback-IP-Adresse des Routers verwendet.
Wenn der Ping-Befehl nicht erfolgreich ist, berücksichtigen Sie folgende Ursachen:
- Kein verbundener Routen-Peer oder überhaupt keine Route:
show ip route peer_IP_addressverwendet werden können. - Layer-1-Problem: physischen Schnittstelle, SFP (Stecker), Kabel oder externes Problem (Transport und ggf. Provider) berücksichtigt werden.
- Überprüfen Sie alle Firewalls oder Zugriffslisten, die die Verbindung blockieren können.
Wenn der Ping-Befehl erfolgreich ist, berücksichtigen Sie Folgendes:
Konfigurationsprobleme
- Falsche IP-Adresse oder konfiguriertes AS: Bei einer falschen IP-Adresse wird keine solche Meldung angezeigt, aber stellen Sie sicher, dass die richtige Konfiguration durchgeführt wurde. Bei falschem AS muss eine Meldung wie mit dem
show loggingBefehl angezeigt werden.
%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 AS-Nummern oder 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 auf beiden Seiten übershow ip bgp all summary, und korrigieren Sie das doppelte Problem. Dies kann manuell mit dem globalen Befehl unter der BGP-Router-Konfiguration erreichtbgp router-id X.X.X.Xwerden. Stellen Sie als Best Practice sicher, dass für die Router-ID manuell eine eindeutige Nummer festgelegt wird.
- BGP-Quelle und TTL:
Die meisten iBGP-Sitzungen werden über die Loopback-Schnittstellen konfiguriert, die über ein IGP erreichbar sind. Diese Loopback-Schnittstelle muss explizit als Quelle definiert werden. Führen Sie dies mit dem Befehlneighbor ip-address update-source interface-idaus.
Für eBGP-Peers werden in der Regel direkt verbundene Schnittstellen für Peering verwendet. Dabei wird geprüft, ob Cisco IOS/Cisco IOS XE diesen Zweck erfüllt, oder es wird nicht einmal versucht, eine Sitzung herzustellen. Wenn versucht wird, eBGP von Loopback zu Loopback auf direkt verbundenen Routern zu testen, kann diese Prüfung für einen bestimmten Nachbarn auf beiden Seiten über deaktiviert werdenneighbor ip-address disable-connected-check.
Wenn es jedoch mehrere Hops zwischen den eBGP-Peers gibt, ist eine korrekte Anzahl von Hops erforderlich. Stellen Sie sicher, dass neighbor ip-address ebgp-multihop [hop-count]diese mit der richtigen Anzahl von Hops konfiguriert sind, damit eine Sitzung aufgebaut 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 offene/geschlossene Verbindung oder Verbindung, die vom Remote-Host abgelehnt wird, zeigt an, dass Pakete das Remote-Ende erreichen. Stellen Sie dann sicher, dass es keine Probleme mit der Kontrollebene am Remote-Ende gibt. Andernfalls, wenn ein Ziel nicht erreichbar ist, überprüfen Sie eine Firewall oder eine Zugriffsliste, die TCP-Port 179 oder BGP-Pakete blockieren kann, oder einen Paketverlust auf dem Pfad.
Bei Authentifizierungsproblemen werden die folgenden 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örige Konfiguration, und lesen Sie weitere Informationen zur Fehlerbehebung im Konfigurationsbeispiel für die MD5-Authentifizierung zwischen BGP-Peers.
Wenn die TCP-Sitzung nicht gestartet wird, können Sie die folgenden Befehle für die Isolierung verwenden:
show tcp brief all
show control-plane host open-ports
debug ip tcp transactions
Adjazenz-Bounces
Wenn die Sitzung aktiv oder inaktiv ist, suchen show logSie nach und Sie können einige Szenarien sehen.
Schnittstellen-Flap
%BGP-5-ADJCHANGE: neighbor 198.51.100.2 Down Interface flap
Wie die Meldung anzeigt, liegt der Grund für diesen Fehler im Ausfall der Schnittstelle. Achten Sie auf physische Probleme an Port/SFP, Kabel oder Trennen der Verbindungen.
Haltezeit abgelaufen
%BGP-3-NOTIFICATION: sent to neighbor 198.51.100.2 4/0 (hold time expired) 0 bytes
Es handelt sich um eine sehr gemeinsame Situation. Dies bedeutet, dass der Router vor Ablauf des Haltezeitgebers keine Keepalive-Nachricht oder keine Update-Nachricht empfangen oder verarbeitet hat. Das Gerät sendet eine Benachrichtigungsmeldung und schließt die Sitzung. Die häufigsten Gründe für dieses Problem sind hier aufgeführt:
- Schnittstellenprobleme: Suchen Sie an den verbundenen Schnittstellen beider Peers nach Eingabefehlern, Verwerfungen der Eingabewarteschlange oder physischen Problemen.
show interfacekann für diesen Zweck verwendet werden.
- Paketverlust bei der Übertragung: Manchmal können Hello-Pakete während der Übertragung verworfen werden. Dies ist die beste Möglichkeit, sicherzustellen, dass dies eine Paketerfassung auf Schnittstellenebene ist.
- Sie können Embedded Packet Capture auf Cisco IOS- und Cisco IOS XE-Geräten verwenden.
- Falls Pakete auf Schnittstellenebene erkannt werden, müssen Sie sicherstellen, dass sie die Kontrollebene, EPC auf Kontrollebene erreichen oder
debug bgp [vrf name] ipv4 unicast keepalivesnützlich sind.
- Hohe CPU: Ein hoher CPU-Status kann zu einem Absinken auf der Kontrollebene führen. Dies
show processes cpu [sorted|history]ist hilfreich, um ein Problem zu identifizieren. Basierend auf der Plattform finden Sie den nächsten Schritt zur Fehlerbehebung mit dem CPU-Referenzdokument.
- Probleme mit CoPP-Richtlinien: Die Vorgehensweise zur Fehlerbehebung ist von Plattform zu Plattform unterschiedlich und wird von diesem Dokument nicht abgedeckt.
- MTU-Abweichung: Wenn im Pfad MTU-Diskrepanzen bestehen und ICMP-Nachrichten im Pfad von der Quelle zum Ziel blockiert werden, funktioniert die PMTUD nicht und kann zu Sitzungs-Flaps führen. Updates werden mit dem ausgehandelten MSS-Wert und einem DF-Bit-Satz gesendet. Wenn ein Gerät im Pfad oder selbst das Ziel die Pakete mit höherer MTU nicht akzeptieren kann, sendet es eine ICMP-Fehlermeldung zurück an den BGP-Sprecher. Der Zielrouter wartet entweder auf den BGP-Keepalive oder das BGP-Update-Paket, um seinen Hold-Down-Timer zu aktualisieren.
- Sie können die mit ausgehandelte MSS überprüfen
show ip bgp neighbors ip_address.
- Sie können die mit ausgehandelte MSS überprüfen
Ein Ping-Test an einen bestimmten Nachbarn mit df-Satz kann zeigen, ob eine solche MTU auf dem Pfad gültig ist:
ping 198.51.100.2 size max_seg_size df
Wenn MTU-Probleme gefunden 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., und bietet zusätzliche Granularität durch einen Subsequent Address-Family Identifier (SAFI), z. B. Unicast und Multicast. MBGP erreicht diese Trennung durch die BGP-Pfadattribute (PAs) MP_REACH_NLRI und MP_UNREACH_NLRI. 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 AFI/SAFI, die von der IANA registriert wurden:
- Aktivieren Sie die BGP-Konfiguration für die Adressfamilien auf beiden Seiten, um unerwünschte Adressfamilien zu korrigieren.
- Verwenden Sie
neighbor ip-address dont-capability-negotiateauf beiden Seiten. Weitere Informationen finden Sie unter Nicht unterstützte Funktionen verursachen BGP-Peer-Fehlfunktion
Pfadinstallation und -auswahl
Weitere Informationen zur Funktionsweise von BGP und zur Auswahl des besten Pfads finden Sie unter BGP Best Path Selection Algorithm.
Nächster Hop
Damit eine Route in unserer Routing-Tabelle installiert werden kann, muss der nächste Hop erreichbar sein. Andernfalls wird das Präfix, selbst wenn es sich in unserer LOC-RIB-BGP-Tabelle befindet, nicht in die RIB übertragen. Als Schleifenvermeidungsregel ändert iBGP in Cisco IOS/Cisco IOS XE das Next-Hop-Attribut nicht und lässt AS_PATH in Ruhe, während eBGP den nächsten Hop umschreibt und dessen AS_PATH vorstellt. ATH
Sie können Next Hop mit überprüfenshow ip bgp [prefix].Es gibt Ihnen den nächsten Hop und unzugängliche Wort. Im Beispiel ist dies ein Präfix, das R1 über eBGP an R2 übermittelt und R3 über die iBGP-Verbindung von R2 übermittelt hat.
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 CSTAm Ausgang ist next hop die ausgehende Schnittstelle von R1, die R3 nicht kennt. Um diese Situation zu beheben, können Sie entweder next-hop über IGP, statische Route ankündigen oder den neighbor ip-address next-hop-selfBefehl auf dem iBGP-Peer verwenden, 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 clear ip bgp 10.0.23.2 soft) zu direkt verbundener 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 CSTRIB-Ausfall
Dies ist der Fall, wenn die Route nicht in der globalen RIB installiert werden kann, was zu einem RIB-Ausfall führt. Häufiger Grund ist, dass 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-Fehler wird jedoch mit dem Befehl show ip bgp rib-failure angezeigt. Weitere Informationen finden Sie unter diesem Link:
Race Condition
Das häufigste Problem besteht darin, dass IGP bei wechselseitigen Weiterverteilungsszenarien 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 eine Gewichtung von 32768. 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 Auswahlprozess für den besten BGP-Pfad 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 vom BGP-Peer empfangenen Routen in der Router-BGP-Konfiguration festzulegen:
neighbor ip-address weight 40000
Sonstige Fragen
BGP: langsamer Peer
Dieser Peer kann mit der Rate, mit der der Absender Aktualisierungsnachrichten generiert, nicht mithalten. Es gibt viele Gründe für einen Peer, dieses Problem aufzuzeigen. hohe CPU in einem der Peers, übermäßiger Datenverkehr oder 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 mit folgendem Befehl angezeigtshow processes memory sorted:
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*
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. Verwenden Sie denshow process cpu sorted Befehl, um zu überprüfen, ob der BGP-Prozess die Ursache für die 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
Nachfolgend sind die gängigen Prozesse, Ursachen und allgemeinen Schritte zur Vermeidung einer hohen CPU-Auslastung durch BGP aufgeführt:
- BGP-Router: Wird einmal pro Sekunde ausgeführt, um eine schnellere Konvergenz sicherzustellen. Es ist einer der wichtigsten Threads. 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 vielen anderen Aufgaben 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, falls Änderungen am Pfad vorgenommen werden. 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, mehr Ressourcen erforderlich sind und in der Regel ein überlastetes Gerät in solche Situationen führt.
- 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 vorliegt, zeigt der Router Symptome einer hohen CPU-Auslastung aufgrund des BGP-E/A-Prozesses. (In dieser Situation ist normalerweise auch der BGP-Router hoch. Achten Sie auf die Nachrichtenanzahl, um Peer zu identifizieren, und erfassen Sie Pakete, um die Quelle dieser Nachrichten zu identifizieren.)
- BGP offen: Der bei der Sitzungserstellung verwendete Prozess Kein allgemeines CPU-Problem, es sei denn, die Sitzung ist im offenen Zustand.
- 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 |
|---|---|---|
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