In diesem Dokument werden die Konfigurations- und Fehlerbehebungsinformationen zur Border Gateway Protocol (BGP)-Funktion für maximale Präfixe beschrieben.
Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:
Die Informationen in diesem Dokument sind nicht auf bestimmte Software- und Hardwareversionen beschränkt. Die Beispiele basieren jedoch auf Cisco Catalyst Edge-Plattformen der Serie 8500, auf denen die Cisco IOS XE Softwareversion 17.12.x ausgeführt wird.
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.
Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).
Dieses Dokument enthält Informationen zur Konfiguration und Fehlerbehebung der Funktion "Maximales BGP-Präfix". Mit dieser Funktion können Sie steuern, wie viele Präfixe von einem Nachbarn empfangen werden können. Standardmäßig ermöglicht diese Funktion einem Router den Ausfall eines Peers, wenn die Anzahl der von diesem Peer empfangenen Präfixe die konfigurierte maximale Präfixgrenze überschreitet. Dies wird in der Regel für externe BGP-Peers verwendet, kann jedoch auf interne BGP-Peers angewendet werden.
Die Funktion "Maximum-Prefix" ist nützlich, wenn bei einer Änderung der Richtlinie für ausgehenden Datenverkehr am Remote-Peering-Standort ein Router mehr Routen zu empfangen beginnt, als der Router-Speicher annehmen kann. Wenn der Router auch kritische Routing-Funktionen ausführt, kann eine unerwartete Zunahme der empfangenen BGP-Präfixe die Systemressourcen belasten und die interne Netzwerkverbindung beeinträchtigen. Mit dem Befehl neighbor <neighbor-ip> maximum-prefix kann ein Router vor dieser Situation geschützt werden.
Beachten Sie bei der Nutzung dieser Funktion folgende Punkte:
Informieren Sie sich darüber, wie viele Routen der BGP-Peering-Remote-Router normalerweise sendet.
Legen Sie den maximalen Präfixgrenzwert höher als die Anzahl der im Normalbetrieb erwarteten Präfixe fest. Konfigurieren Sie den Warnschwellenwert als Prozentsatz dieses Grenzwerts für das maximale Präfix.
Anmerkung: Die Option "restart" versucht automatisch, eine BGP-Sitzung wiederherzustellen, nachdem das Limit für das maximale Präfix die Sitzung beendet hat. Ausführliche Informationen zur Konfiguration finden Sie unter BGP Restart Neighbor Session After Max-Prefix Limit Reached.
In diesem Abschnitt erfahren Sie, wie Sie die in diesem Dokument beschriebenen Funktionen konfigurieren können.
Die Befehlssyntax für die Konfiguration der Funktion "BGP Maximum-Prefix" lautet:
neighbor {ip-address | peer-group-name} maximum-prefix <maximum> [threshold] [restart <restart-interval>] [warning-only]
Dabei gilt:
maximum - Stellt die maximale Anzahl von Präfixen dar, die vom Nachbarn zulässig sind.
threshold - Gibt den Prozentsatz des konfigurierten Maximal-Präfix-Grenzwerts an, bei dem der Router eine Warnmeldung generiert. Der gültige Bereich liegt zwischen 1 und 100 %.
Der Standardwert ist 75 Prozent.
Wenn der konfigurierte Maximalwert beispielsweise 20 und der Schwellenwert 60 beträgt, generiert der Router Warnmeldungen, wenn die Anzahl der vom Nachbarn bezogenen BGP-Routen 60 % von 20 (12) Routen übersteigt.
restart-interval - Gibt das Intervall in Minuten an, nach dem der Router versucht, die BGP-Sitzung wiederherzustellen. Der gültige Bereich liegt zwischen 1 und 65535 Minuten. So ist es.
warning-only (Optional): Ermöglicht dem Router, eine Protokollmeldung zu generieren, wenn das Maximum-Prefix-Limit überschritten wird, anstatt die Peering-Sitzung zu beenden.
Um die Nutzung besser zu veranschaulichen, betrachten Sie dieses Beispiel:
neighbor 10.1.1.1 maximum-prefix 3000 !--- Drops the peering to 10.1.1.1 when !--- more than 3000 prefixes are received. neighbor 10.1.1.1 maximum-prefix 3000 warning-only !--- Logs a warning message when the peer sends !--- more than 3000 prefixes. neighbor 10.1.1.1 maximum-prefix 3000 50 !--- Logs a warning message at 1500 and drops the !--- peering when over 3000 prefixes are sent. neighbor 10.1.1.1 maximum-prefix 3000 50 warning-only !--- Initially warns at 1500 and re-warns !--- (different message) at 3000 prefixes received. !--- However, the BGP Peer is not disconnected.
BGP-Topologie mit maximalem Präfix
Router_A im autonomen System 200 ist direkt mit Router_B im autonomen System 300 über die Schnittstelle TenGigabitEthernet0/0/0 verbunden. Router_A verwendet 10.0.0.1/30 und Router_B verwendet 10.0.0.2/30. Die Router stellen über diesen Link eine eBGP-Sitzung (External Border Gateway Protocol) mit einem Hop her.
In der reinen Maximum-Prefix-Warnkonfiguration ist Router_B so konfiguriert, dass nur eine Warnmeldung protokolliert wird, wenn die Anzahl der von Router_A empfangenen Präfixe den festgelegten Grenzwert überschreitet.
Die Konfiguration der beiden Router ist in dieser Tabelle dargestellt. Beachten Sie das Vorhandensein des Warn-Only-Schlüsselworts, das mit dem Befehl neighbor konfiguriert wurde:
| Router A | Router B |
|---|---|
|
|
Anmerkung: In diesem Beispiel generiert der Befehl maximum-prefix eine Warnung, wenn die Anzahl der vom Nachbarn 10.0.0.1 empfangenen BGP-Präfixe acht überschreitet.
Die Ausgabe des Befehls show and debug im Abschnitt Verify and Troubleshoot dieses Dokuments gibt an, was auf Router_B geschieht, wenn die Anzahl der von Router_A empfangenen Präfixe den festgelegten Grenzwert überschreitet.
In diesem Beispiel generiert Router_B eine Warnung, wenn die Anzahl der empfangenen Präfixe den Warnschwellenwert überschreitet. Router_B beendet die BGP-Sitzung, wenn die Anzahl der empfangenen Präfixe den Grenzwert für maximale Präfixe überschreitet. Das Schlüsselwort warning-only ist nicht konfiguriert. Der Befehl maximum-prefix beendet die BGP-Sitzung, wenn die Anzahl der vom Nachbarn empfangenen Präfixe 10 überschreitet:
| Router A | Router B |
|---|---|
|
|
Anmerkung: In diesem Beispiel erzwingt der Befehl maximum-prefix die Beendigung der Nachbarsitzung, wenn das vom BGP empfangene Routing vom Nachbarn 10 überschreitet.
Die Ausgabe des Befehls show and debug im Abschnitt Verify and Troubleshoot gibt an, was auf Router_B geschieht, wenn die Anzahl der Präfixe, die er von Router_A empfängt, den festgelegten Grenzwert überschreitet.
Diese Abschnitt enthält Informationen, mit denen Sie überprüfen können, ob Ihre Konfiguration ordnungsgemäß funktioniert. Die Befehlssyntax und Standardwerte für die in diesem Dokument verwendete Funktion finden Sie auf der BGP-Befehlsseite.
Anmerkung: Lesen Sie Wichtige Informationen zu Debug-Befehlen, bevor Sie Debug-Befehle verwenden.
show ip bgp neighbor - Zeigt den BGP-Nachbarstatus und Informationen zum Präfixlimit an
show ip bgp summary - Zeigt den Status aller BGP-Verbindungen an
debug ip bgp updates in — Zeigt Informationen zu BGP-Updates an
Achten Sie auf folgende Zahlen:
Konfigurierter Grenzwert für maximale Präfixe: 10 (zehn Präfixe)
Warnschwelle: 80 Prozent (acht Präfixe)
Anmerkung: Die für die Testpräfixe verwendete Konfiguration zur Routengenerierung und BGP-Ankündigung wird weggelassen. Router_A kann die Präfixe durch Netzwerkaussagen oder Neuverteilung generieren oder sie von anderen BGP-Nachbarn beziehen und Router_B mitteilen.
Solange die Anzahl der empfangenen Präfixe den festgelegten Grenzwert nicht überschreitet, werden keine Meldungen protokolliert. Sobald die Anzahl der vom Nachbarn 10.0.0.1 bezogenen BGP-Routen den Grenzwert von acht Präfixen überschreitet, wird diese Nachricht von Router_B protokolliert.
Diese Situation wird simuliert, wenn neun Präfixe gesendet werden:
%BGP-4-MAXPFX: No. of prefix received from 10.0.0.1 (afi 0) reaches 9, max 10
Wenn sich die Situation verschlechtert und der Maximum-Prefix-Wert von 10 überschritten wird, protokolliert der Router diese Meldung. Diese Situation wird simuliert, wenn mehr Präfixe gesendet werden:
%BGP-3-MAXPFXEXCEED: No. of prefix received from 10.0.0.1 (afi 0): 11 exceed limit 10
Router_B#show ip bgp neighbor 10.0.0.1 BGP neighbor is 10.0.0.1, remote AS 200, external link BGP version 4, remote router ID 10.0.0.1 BGP state = Established, up for 00:17:22 Last read 00:00:25, last write 00:00:22, hold time is 180, keepalive interval is 60 seconds Last update received: 00:04:04 Neighbor sessions: 1 active, is not multisession capable (disabled) Neighbor capabilities: Route refresh: advertised and received(new) Four-octets ASN Capability: advertised and received Address family IPv4 Unicast: advertised and received Enhanced Refresh Capability: advertised and received Multisession Capability: Stateful switchover support enabled: NO for session 1 Message statistics: InQ depth is 0 OutQ depth is 0 Sent Rcvd Opens: 1 1 Notifications: 0 0 Updates: 1 2 Keepalives: 20 19 Route Refresh: 0 0 Total: 22 22 Do log neighbor state changes (via global configuration) Default minimum time between advertisement runs is 30 seconds For address family: IPv4 Unicast Session: 10.0.0.1 BGP table version 12, neighbor version 12/0 Output queue size : 0 Index 1, Advertise bit 0 1 update-group member Slow-peer detection is disabled Slow-peer split-update-group dynamic is disabled Sent Rcvd Prefix activity: ---- ---- Prefixes Current: 0 11 (Consumes 1496 bytes) Prefixes Total: 0 11 Implicit Withdraw: 0 0 Explicit Withdraw: 0 0 Used as bestpath: n/a 11 Used as multipath: n/a 0 Used as secondary: n/a 0 Outbound Inbound Local Policy Denied Prefixes: -------- ------- Bestpath from this peer: 11 n/a Total: 11 0 Maximum prefixes allowed 10 (warning-only) Threshold for warning message 80% Number of NLRIs in the update sent: max 0, min 0 Current session network count peaked at 11 entries at 20:05:46 Aug 19 2026 UTC (00:04:05.075 ago) Highest network count observed at 11 entries at 20:05:46 Aug 19 2026 UTC (00:04:05.075 ago) Last detected as dynamic slow peer: never Dynamic slow peer recovered: never Refresh Epoch: 1 Last Sent Refresh Start-of-rib: never Last Sent Refresh End-of-rib: never Last Received Refresh Start-of-rib: never Last Received Refresh End-of-rib: never Sent Rcvd Refresh activity: ---- ---- Refresh Start-of-RIB 0 0 Refresh End-of-RIB 0 0 Address tracking is enabled, the RIB does have a route to 10.0.0.1 Route to peer address reachability Up: 1; Down: 0 Last notification 00:17:27 Connections established 1; dropped 0 Last reset never External BGP neighbor configured for connected checks (single-hop no-disable-connected-check) Interface associated: TenGigabitEthernet0/0/0 (peering address in same link) Transport(tcp) path-mtu-discovery is enabled Graceful-Restart is disabled SSO is disabled Connection state is ESTAB, I/O status: 1, unread input bytes: 0 Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 1 Local host: 10.0.0.2, Local port: 179 Foreign host: 10.0.0.1, Foreign port: 48663 Connection tableid (VRF): 0 Maximum output segment queue size: 50 Enqueued packets for retransmit: 0, input: 0 mis-ordered: 0 (0 bytes) Event Timers (current time is 0x386BB365): Timer Starts Wakeups Next Retrans 21 0 0x0 TimeWait 0 0 0x0 AckHold 22 21 0x0 SendWnd 0 0 0x0 KeepAlive 0 0 0x0 GiveUp 0 0 0x0 PmtuAger 0 0 0x0 DeadWait 0 0 0x0 Linger 0 0 0x0 ProcessQ 0 0 0x0 iss: 3438119007 snduna: 3438119468 sndnxt: 3438119468 irs: 2705427639 rcvnxt: 2705428185 sndwnd: 15924 scale: 0 maxrcvwnd: 16384 rcvwnd: 15839 scale: 0 delrcvwnd: 545 SRTT: 939 ms, RTTO: 1411 ms, RTV: 472 ms, KRTT: 0 ms minRTT: 0 ms, maxRTT: 1000 ms, ACK hold: 120 ms uptime: 1042758 ms, Sent idletime: 22095 ms, Receive idletime: 21895 ms Status Flags: passive open, gen tcbs Option Flags: nagle, path mtu capable IP Precedence value : 6 Window update Optimisation : Enabled ACK Optimisation : Dynamic ACK Tuning Enabled Datagrams (max data segment is 1460 bytes): Peer MSS: 1460 Rcvd: 44 (out of order: 0), with data: 22, total data bytes: 545 Sent: 45 (retransmit: 0, fastretransmit: 0, partialack: 0, Second Congestion: 0), with data: 22, total data bytes: 460 Packets received in fast path: 0, fast processed: 0, slow path: 0 fast lock acquisition failures: 0, slow path: 0 TCP Semaphore 0x746BB5E1C7B0 FREE
Router_B#show ip bgp summary BGP router identifier 10.0.0.2, local AS number 300 BGP table version is 12, main routing table version 12 11 network entries using 2728 bytes of memory 11 path entries using 1496 bytes of memory 1/1 BGP path/bestpath attribute entries using 296 bytes of memory 1 BGP AS-PATH entries using 24 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 4544 total bytes of memory BGP activity 11/0 prefixes, 11/0 paths, scan interval 60 secs 11 networks peaked at 20:05:46 Aug 19 2026 UTC (00:08:51.371 ago) Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 10.0.0.1 4 200 27 27 12 0 0 00:22:09 11
Router_A kündigt Router_B elf Präfixe an. Router_B generiert eine Warnung, wenn die Anzahl der empfangenen Präfixe neun erreicht, und generiert eine Meldung, dass die Anzahl der empfangenen Präfixe 11 erreicht hat. Da Warnungsnur konfiguriert ist, bleibt die BGP-Sitzung hergestellt.
Vorsicht: Der Befehl debug ip bgp updates in kann erhebliche Ausgaben generieren und die Geräteleistung beeinflussen. Führen Sie diesen Befehl nur während eines gesteuerten Fensters zur Fehlerbehebung aus, überwachen Sie die Systemressourcen, verwenden Sie Befehlsfilter, und deaktivieren Sie das Debuggen nach der Datenerfassung.
Router_B#debug ip bgp updates in *Aug 19 20:34:50.019: BGP(0): 10.0.0.1 rcvd UPDATE w/ attr: nexthop 10.0.0.1, origin ?, metric 0, merged path 200, AS_PATH *Aug 19 20:34:50.019: BGP(0): 10.0.0.1 rcvd 10.0.0.0/30 *Aug 19 20:34:50.019: BGP(0): 10.0.0.1 rcvd 10.10.1.0/30 *Aug 19 20:34:50.019: BGP(0): 10.0.0.1 rcvd 10.1.1.1/32 *Aug 19 20:34:50.019: BGP(0): 10.0.0.1 rcvd 10.2.2.2/32 *Aug 19 20:34:50.019: BGP(0): 10.0.0.1 rcvd 10.3.3.3/32 *Aug 19 20:34:50.019: BGP(0): 10.0.0.1 rcvd 10.4.4.4/32 *Aug 19 20:34:50.019: BGP(0): 10.0.0.1 rcvd 10.5.5.5/32 *Aug 19 20:34:50.019: BGP(0): 10.0.0.1 rcvd 10.6.6.6/32 *Aug 19 20:34:50.019: BGP(0): 10.0.0.1 rcvd 10.7.7.7/32 *Aug 19 20:34:50.019: %BGP-4-MAXPFX: Number of prefixes received from 10.0.0.1 (afi 0) reaches 9, max 10 *Aug 19 20:34:50.019: BGP(0): 10.0.0.1 rcvd 10.9.9.9/32 *Aug 19 20:34:50.019: BGP(0): 10.0.0.1 rcvd 10.8.8.8/32 *Aug 19 20:34:50.019: %BGP-3-MAXPFXEXCEED: Number of prefixes received from 10.0.0.1 (afi 0): 11 exceeds limit 10 *Aug 19 20:34:51.040: BGP(0): Revise route installing 1 of 1 routes for 10.0.0.0/30 -> 10.0.0.1(global) to main IP table *Aug 19 20:34:51.040: BGP(0): Revise route installing 1 of 1 routes for 10.1.1.1/32 -> 10.0.0.1(global) to main IP table *Aug 19 20:34:51.040: BGP(0): Revise route installing 1 of 1 routes for 10.2.2.2/32 -> 10.0.0.1(global) to main IP table *Aug 19 20:34:51.040: BGP(0): Revise route installing 1 of 1 routes for 10.3.3.3/32 -> 10.0.0.1(global) to main IP table *Aug 19 20:34:51.040: BGP(0): Revise route installing 1 of 1 routes for 10.4.4.4/32 -> 10.0.0.1(global) to main IP table *Aug 19 20:34:51.040: BGP(0): Revise route installing 1 of 1 routes for 10.5.5.5/32 -> 10.0.0.1(global) to main IP table *Aug 19 20:34:51.040: BGP(0): Revise route installing 1 of 1 routes for 10.6.6.6/32 -> 10.0.0.1(global) to main IP table *Aug 19 20:34:51.040: BGP(0): Revise route installing 1 of 1 routes for 10.7.7.7/32 -> 10.0.0.1(global) to main IP table *Aug 19 20:34:51.040: BGP(0): Revise route installing 1 of 1 routes for 10.8.8.8/32 -> 10.0.0.1(global) to main IP table *Aug 19 20:34:51.040: BGP(0): Revise route installing 1 of 1 routes for 10.9.9.9/32 -> 10.0.0.1(global) to main IP table *Aug 19 20:34:51.040: BGP(0): Revise route installing 1 of 1 routes for 10.10.1.0/30 -> 10.0.0.1(global) to main IP table
Im vorherigen Beispiel wird die BGP-Nachbarbeziehung beibehalten, selbst wenn der benachbarte Router mehr Präfixe sendet, als die Richtlinie zulässt. Router_B protokolliert Warnmeldungen und Meldungen über das Maximum-Präfix-Überschreiten, behält jedoch die BGP-Sitzung bei. Router_B akzeptiert weiterhin Präfixe vom Nachbarn, da Warning-only konfiguriert ist.
In diesem Fall ist der BGP-Nachbar unter den ersten Bedingungen einsatzbereit und wird mit sechs Präfixen von Router_A an Router_B gesendet. Wie im Beispiel gezeigt, wenn Router_A weitere Präfixe ankündigt (z. B. 9), spiegelt die Ausgabe der Befehle genau das wider, was bereits für den Fall vorhanden war, dass Router_B so konfiguriert ist, dass eine Warnmeldung protokolliert wird.
Nachdem Router_A ein elftes Präfix angekündigt hat, überschreitet die Anzahl der empfangenen Präfixe den konfigurierten Grenzwert von 10. Router_B sendet eine Benachrichtigung über die maximale Anzahl der erreichten Präfixe und beendet die BGP-Sitzung.
Router_B#debug ip bgp updates in
*Aug 19 20:45:48.779: BGP(0): 10.0.0.1 rcvd UPDATE w/ attr: nexthop 10.0.0.1, origin ?, metric 0, merged path 200, AS_PATH
*Aug 19 20:45:48.779: BGP(0): 10.0.0.1 rcvd 10.7.7.7/32
*Aug 19 20:45:48.779: %BGP-4-MAXPFX: Number of prefixes received from 10.0.0.1 (afi 0) reaches 10, max 10 *Aug 19 20:45:48.779: BGP(0): 10.0.0.1 rcvd 10.9.9.9/32
*Aug 19 20:45:48.779: %BGP-3-MAXPFXEXCEED: Number of prefixes received from 10.0.0.1 (afi 0): 11 exceeds limit 10 *Aug 19 20:45:48.780: %BGP-3-NOTIFICATION: sent to neighbor 10.0.0.1 6/1 (Maximum Number of Prefixes Reached) 7 bytes 00010100 00000A
*Aug 19 20:45:48.780: %BGP-5-NBR_RESET: Neighbor 10.0.0.1 reset (Peer over prefix limit)
*Aug 19 20:45:48.780: BGP(0): no valid path for 10.0.0.0/30
*Aug 19 20:45:48.780: BGP(0): no valid path for 10.1.1.1/32
*Aug 19 20:45:48.780: BGP(0): no valid path for 10.2.2.2/32
*Aug 19 20:45:48.780: BGP(0): no valid path for 10.3.3.3/32
*Aug 19 20:45:48.780: BGP(0): no valid path for 10.4.4.4/32
*Aug 19 20:45:48.780: BGP(0): no valid path for 10.5.5.5/32
*Aug 19 20:45:48.780: BGP(0): no valid path for 10.6.6.6/32
*Aug 19 20:45:48.780: BGP(0): no valid path for 10.7.7.7/32
*Aug 19 20:45:48.780: BGP(0): no valid path for 10.8.8.8/32
*Aug 19 20:45:48.780: BGP(0): no valid path for 10.10.1.0/30
*Aug 19 20:45:48.780: %BGP-5-ADJCHANGE: neighbor 10.0.0.1 Down Peer over prefix limit *Aug 19 20:45:48.780: %BGP_SESSION-5-ADJCHANGE: neighbor 10.0.0.1 IPv4 Unicast topology base removed from session Peer over prefix limit
*Aug 19 20:45:48.780: BGP: topo global:IPv4 Unicast:base Remove_fwdroute for 10.0.0.0/30
*Aug 19 20:45:48.780: BGP: topo global:IPv4 Unicast:base Remove_fwdroute for 10.1.1.1/32
*Aug 19 20:45:48.780: BGP: topo global:IPv4 Unicast:base Remove_fwdroute for 10.2.2.2/32
*Aug 19 20:45:48.780: BGP: topo global:IPv4 Unicast:base Remove_fwdroute for 10.3.3.3/32
*Aug 19 20:45:48.780: BGP: topo global:IPv4 Unicast:base Remove_fwdroute for 10.4.4.4/32
*Aug 19 20:45:48.780: BGP: topo global:IPv4 Unicast:base Remove_fwdroute for 10.5.5.5/32
*Aug 19 20:45:48.780: BGP: topo global:IPv4 Unicast:base Remove_fwdroute for 10.6.6.6/32
*Aug 19 20:45:48.780: BGP: topo global:IPv4 Unicast:base Remove_fwdroute for 10.7.7.7/32
*Aug 19 20:45:48.780: BGP: topo global:IPv4 Unicast:base Remove_fwdroute for 10.8.8.8/32
*Aug 19 20:45:48.780: BGP: topo global:IPv4 Unicast:base Remove_fwdroute for 10.10.1.0/30
Router_B#show ip bgp summary
BGP router identifier 10.0.0.2, local AS number 300
BGP table version is 25, main routing table version 25
17 networks peaked at 20:33:04 Aug 19 2026 UTC (00:13:00.072 ago)
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.0.0.1 4 200 0 0 1 0 0 00:00:15 Idle (PfxCt)
Anmerkung: In diesem Szenario müssen Sie den Befehl clear ip bgp <neighbor-ip> verwenden, um die Peer-Sitzung wiederherzustellen. Reduzieren Sie vor dem Zurücksetzen der Sitzung die Anzahl der vom Peer angekündigten Präfixe, oder passen Sie nach der Kapazitätsüberprüfung den konfigurierten Grenzwert für das maximale Präfix an. Mit diesem Befehl wird die BGP-Sitzung zurückgesetzt und die vom Peer empfangenen Routen vorübergehend entfernt.
Router_B#show ip bgp neighbors 10.0.0.1
BGP neighbor is 10.0.0.1, remote AS 200, external link
BGP version 4, remote router ID 10.0.0.1
BGP state = Idle, down for 00:00:39
Last update received: n/a
Neighbor sessions:
0 active, is not multisession capable (disabled)
Stateful switchover support enabled: NO for session 0
Message statistics:
InQ depth is 0
OutQ depth is 0
Sent Rcvd
Opens: 0 1
Notifications: 1 0
Updates: 0 0
Keepalives: 0 0
Route Refresh: 0 0
Total: 1 1
Do log neighbor state changes (via global configuration)
Default minimum time between advertisement runs is 30 seconds
For address family: IPv4 Unicast
BGP table version 25, neighbor version 1/25
Output queue size : 0
Index 0, Advertise bit 0
Address family not supported notification sent
Slow-peer detection is disabled
Slow-peer split-update-group dynamic is disabled
Peer had exceeded the max. no. of prefixes configured.
Maximum prefixes allowed 10
Threshold for warning message 80%
Reduce the no. of prefix and clear ip bgp 10.0.0.1 to restore peering
Number of NLRIs in the update sent: max 0, min 0
Highest network count observed at 12 entries at 20:32:03 Aug 19 2026 UTC (00:14:25.012 ago) Last detected as dynamic slow peer: never
Dynamic slow peer recovered: never
Refresh Epoch: 1
Last Sent Refresh Start-of-rib: never
Last Sent Refresh End-of-rib: never
Last Received Refresh Start-of-rib: never
Last Received Refresh End-of-rib: never
Sent Rcvd
Refresh activity: ---- ----
Refresh Start-of-RIB 0 0
Refresh End-of-RIB 0 0
Address tracking is enabled, the RIB does have a route to 10.0.0.1
Route to peer address reachability Up: 1; Down: 0
Last notification 00:54:04
Connections established 3; dropped 3
Last reset 00:00:39, due to BGP protocol initialization
External BGP neighbor configured for connected checks (single-hop no-disable-connected-check)
Interface associated: TenGigabitEthernet0/0/0 (peering address in same link)
Transport(tcp) path-mtu-discovery is enabled
Graceful-Restart is disabled
SSO is disabled
No active TCP connection
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
2.0 |
20-Aug-2026
|
Aktualisierte Titel, Rechtschreibung, Grammatik, eingefügte horizontale Linien in separate Abschnitte für die Lesbarkeit. |
1.0 |
09-Jul-2002
|
Erstveröffentlichung |