Configurare la funzionalità BGP Maximum Prefix
Sommario
Introduzione
In questo documento vengono descritte la configurazione e le informazioni per la risoluzione dei problemi della funzionalità BGP (Border Gateway Protocol) Maximum-Prefix.
Prerequisiti
Requisiti
Cisco raccomanda la conoscenza dei seguenti argomenti:
- Routing IP di base
- Configurazione BGP
Componenti usati
Le informazioni di questo documento non si limitano a versioni software e hardware specifiche, ma gli esempi sono basati sulle piattaforme Cisco Catalyst serie 8500 Edge con software Cisco IOS XE versione 17.12.x.
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Convenzioni
Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.
Premesse
In questo documento vengono fornite informazioni sulla configurazione e sulla risoluzione dei problemi della funzionalità BGP Maximum Prefix. Questa funzionalità consente di controllare il numero di prefissi che possono essere ricevuti da un router adiacente. Per impostazione predefinita, questa funzionalità consente a un router di disattivare un peer quando il numero di prefissi ricevuti da tale peer supera il limite di prefissi massimi configurato. Questa condizione viene in genere utilizzata per i peer BGP esterni, ma può essere applicata ai peer BGP interni.
La funzionalità Maximum-Prefix è utile quando, in seguito a una modifica dei criteri in uscita nel sito di peering remoto, un router inizia a ricevere un numero di route superiore a quello che può accettare la memoria del router. Se il router svolge anche funzioni critiche di routing, un aumento imprevisto dei prefissi BGP ricevuti può consumare le risorse del sistema e influire sulla connettività della rete interna. Con il comando neighbors <neighbor-ip> maximum-prefix è possibile proteggere un router da questa situazione.
Quando prevedete di utilizzare questa funzione, tenete presente quanto segue:
-
Conoscere il numero di route che il router di peering BGP remoto invia normalmente.
-
Impostare il limite del prefisso massimo su un valore superiore al numero di prefissi previsti durante il normale funzionamento. Configurare la soglia di avviso come percentuale del limite del prefisso massimo.
- Selezionare l'azione richiesta quando il conteggio dei prefissi ricevuti supera il massimo configurato:
- Terminare la sessione BGP e richiedere un reset manuale.
- Configurare il riavvio <restart-interval> per ristabilire automaticamente la sessione.
- Configurare l'opzione warning-only per registrare l'evento senza terminare la sessione.
Nota: L'opzione di riavvio tenta automaticamente di ristabilire una sessione BGP dopo che il limite del prefisso massimo ha terminato la sessione. Per informazioni dettagliate sulla configurazione, vedere Riavviare la sessione adiacente di BGP dopo il raggiungimento del limite del prefisso massimo.
Configurazione
In questa sezione vengono presentate le informazioni necessarie per configurare le funzionalità descritte più avanti nel documento.
La sintassi del comando utilizzata per configurare la funzionalità BGP Maximum-Prefix è:
neighbor {ip-address | peer-group-name} maximum-prefix <maximum> [threshold] [restart <restart-interval>] [warning-only]
Dove:
-
maximum: rappresenta il numero massimo di prefissi consentiti dal router adiacente.
-
threshold: specifica la percentuale del limite di prefisso massimo configurato in corrispondenza della quale il router genera un messaggio di avviso. L'intervallo valido è compreso tra 1 e 100%.
-
L'impostazione predefinita è 75%.
-
Ad esempio, se il valore massimo configurato è 20 e la soglia è 60, il router genera messaggi di avviso quando il numero di route apprese BGP dal vicino supera il 60% di 20 (12) route.
-
-
restart-interval: specifica l'intervallo, in minuti, trascorso il quale il router tenta di ristabilire la sessione BGP. L'intervallo valido è compreso tra 1 e 65535 minuti.
-
warning-only (facoltativo): consente al router di generare un messaggio di log quando viene superato il limite di Maximum-Prefix, anziché terminare la sessione di peering.
Per illustrare meglio l'utilizzo, considerare questo esempio:
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.
Esempio di rete
Topologia BGP Maximum-Prefix
Router_A nel sistema autonomo 200 si connette direttamente al router_B nel sistema autonomo 300 tramite l'interfaccia TenGigabit Ethernet0/0/0. Router_A utilizza 10.0.0.1/30, mentre Router_B utilizza 10.0.0.2/30. I router stabiliscono una sessione eBGP (Border Gateway Protocol) esterna a hop singolo su questo collegamento.
Configura comportamento di tipo Solo avviso con prefisso massimo
Nella configurazione di solo avviso Maximum-Prefix, Router_B è configurato in modo da registrare solo un messaggio di avviso quando il numero di prefissi ricevuti da Router_A supera la soglia impostata.
La configurazione di entrambi i router è come mostrato nella tabella. Si noti la presenza della parola chiave warning-only configurata con il comando neighbors:
| Router_A | Router_B |
|---|---|
|
|
Nota: In questo esempio, il comando maximum-prefix genera un avviso quando il numero di prefissi BGP ricevuti dal router adiacente 10.0.0.1 supera gli otto.
Gli output del comando show e debug nella sezione Verifica e risoluzione dei problemi di questo documento indicano cosa succede sul router_B quando il numero di prefissi ricevuti dal router_A supera la soglia impostata.
Configurazione di Maximum-Prefix per terminare il comportamento della sessione BGP
In questo esempio, Router_B genera un avviso quando il conteggio dei prefissi ricevuti supera la soglia di avviso. Router_B termina la sessione BGP quando il numero di prefissi ricevuti supera il limite massimo. La parola chiave warning-only non è configurata. Il comando maximum-prefix termina la sessione BGP quando il numero di prefissi ricevuti dal router adiacente supera 10:
| Router_A | Router_B |
|---|---|
|
|
Nota: Nell'esempio, il comando maximum-prefix forza l'interruzione della sessione adiacente quando il numero di route apprese dal BGP dal router adiacente supera 10.
Gli output del comando show e debug nella sezione Verifica e risoluzione dei problemi segnalano cosa succede sul router_B quando il numero di prefissi che riceve dal router_A supera la soglia impostata.
Verifica e risoluzione dei problemi
Le informazioni contenute in questa sezione permettono di verificare che la configurazione funzioni correttamente. La sintassi dei comandi e i valori predefiniti della funzione utilizzata in questo documento sono disponibili nella pagina dei comandi BGP.
Nota: consultare le informazioni importanti sui comandi di debug prima di usare i comandi di debug.
-
show ip bgp neighbors: visualizza lo stato dei router BGP adiacenti e le informazioni sul limite di prefisso
-
show ip bgp summary: visualizza lo stato di tutte le connessioni BGP
-
debug ip bgp updates in: visualizza le informazioni correlate agli aggiornamenti BGP
Maximum-Prefix Warning-Only
Prestare attenzione a questi numeri:
-
Limite massimo prefisso configurato: 10 (dieci prefissi)
-
Soglia di avvertenza: 80% (otto prefissi)
Nota: La configurazione esatta della generazione route e dell'annuncio BGP utilizzata per i prefissi di test è omessa. Router_A può creare i prefissi tramite istruzioni di rete o ridistribuzione oppure apprendere la creazione dei prefissi da altri router BGP adiacenti e pubblicizzarli su Router_B.
Finché il numero di prefissi ricevuti non supera la soglia impostata, non vengono registrati messaggi. Non appena il numero di route BGP apprese dal router adiacente 10.0.0.1 supera il limite di soglia di otto prefissi, Router_B registra questo messaggio.
Questa situazione viene simulata quando vengono inviati nove prefissi:
%BGP-4-MAXPFX: No. of prefix received from 10.0.0.1 (afi 0) reaches 9, max 10
Se la situazione peggiora e supera il numero di prefisso massimo impostato su 10, il router registra questo messaggio. Questa situazione viene simulata quando vengono inviati più prefissi:
%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 annuncia 11 prefissi al router_B. Router_B genera un avviso quando il conteggio dei prefissi ricevuti raggiunge nove e genera un messaggio di superamento del prefisso massimo quando il conteggio raggiunge 11. Poiché è configurata la sola avvertenza, la sessione BGP rimane stabilita.
Attenzione: Il comando debug ip bgp updates in può generare un output sostanziale e influire sulle prestazioni del dispositivo. Eseguire questo comando solo durante una finestra di risoluzione dei problemi controllata, monitorare le risorse di sistema, utilizzare i filtri dei comandi e disattivare il debug dopo la raccolta dei dati.
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
Nell'esempio precedente, la relazione tra router adiacenti BGP viene mantenuta anche se il router adiacente invia un numero di prefissi superiore a quello consentito dalla policy. Router_B registra i messaggi di avviso e di superamento del prefisso massimo ma mantiene stabilita la sessione BGP. Router_B continua ad accettare prefissi dal router adiacente perché è configurato solo avviso.
Maximum-Prefix Terminate la sessione BGP
Nelle condizioni iniziali richieste in questo caso, il router BGP adiacente è attivo e in esecuzione e con sei prefissi inviati da Router_A a Router_B. Come mostrato nell'esempio, quando il router_A annuncia più prefissi (ad esempio, 9), l'output dei comandi riflette esattamente quello che era già stato visto nel caso in cui il router_B è configurato per registrare un messaggio di avviso.
Dopo che il router_A ha annunciato un undicesimo prefisso, il conteggio dei prefissi ricevuti supera il limite configurato di 10. Il router_B invia un numero massimo di prefissi raggiunto per la notifica e termina la sessione BGP.
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/30Router_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)Nota: In questo scenario è necessario utilizzare il comando clear ip bgp <neighbor-ip> per ripristinare la sessione peer. Prima di ripristinare la sessione, ridurre il numero di prefissi annunciati dal peer o modificare il limite massimo di prefissi configurato dopo la convalida della capacità. Questo comando reimposta la sessione BGP e rimuove temporaneamente le route apprese dal peer.
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 connectionInformazioni correlate
Cronologia delle revisioni
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
2.0 |
20-Aug-2026
|
È stato aggiornato il titolo, l'ortografia, la grammatica e le righe orizzontali inserite per separare le sezioni ai fini della leggibilità. |
1.0 |
09-Jul-2002
|
Versione iniziale |
Feedback