Configurar o recurso de prefixo máximo de BGP
Contents
Introdução
Este documento descreve a configuração e as informações de Troubleshooting no recurso de Prefixo Máximo do Border Gateway Protocol (BGP).
Pré-requisitos
Requisitos
A Cisco recomenda que você tenha conhecimento destes tópicos:
- Roteamento IP básico
- Configuração de BGP
Componentes Utilizados
As informações neste documento não estão restritas a versões específicas de software e hardware, no entanto, os exemplos são baseados nas plataformas Cisco Catalyst 8500 Series Edge que executam o Cisco IOS XE Software Release 17.12.x.
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Conventions
Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.
Informações de Apoio
Este documento fornece informações de configuração e Troubleshooting sobre o recurso BGP Maximum Prefix. Esse recurso permite controlar quantos prefixos podem ser recebidos de um vizinho. Por padrão, este recurso permite que um roteador derrube um peer quando o número de prefixos recebidos desse peer excede o limite de Prefixo Máximo configurado. Isso é comumente usado para peers BGP externos, mas pode ser aplicado a peers BGP internos.
O recurso Prefixo Máximo é útil quando, em uma alteração de política de saída no local de peering remoto, um roteador começa a receber mais rotas do que a memória do roteador pode suportar. Se o roteador também executar funções críticas de roteamento, um aumento inesperado nos prefixos BGP recebidos pode consumir recursos do sistema e afetar a conectividade de rede interna. Com o comando neighbor <neighbor-ip> maximum-prefix, é possível proteger um roteador contra essa situação.
Quando você planeja usar esse recurso, considere estes pontos principais:
-
Saiba quantas rotas o roteador de peering BGP remoto envia normalmente.
-
Defina o limite maximum-prefix maior que o número de prefixos esperados durante a operação normal. Configure o limite de aviso como uma porcentagem desse limite de prefixo máximo.
- Selecione a ação necessária quando a contagem de prefixos recebidos exceder o máximo configurado:
- Encerre a sessão BGP e exija uma reinicialização manual.
- Configure o restart <restart-interval> para restabelecer a sessão automaticamente.
- Configure warning-only para registrar o evento sem encerrar a sessão.
Note: A opção de reinicialização tenta automaticamente restabelecer uma sessão BGP depois que o limite de prefixo máximo termina a sessão. Para obter informações de configuração detalhadas, consulte BGP Restart Neighbor Session After Max-Prefix Limit Reached.
Configurar
Nesta seção, você encontrará informações para configurar os recursos descritos neste documento.
A sintaxe de comando usada para configurar o recurso BGP Maximum-Prefix é:
neighbor {ip-address | peer-group-name} maximum-prefix <maximum> [threshold] [restart <restart-interval>] [warning-only]
Where:
-
maximum — Representa o número máximo de prefixos permitidos do vizinho.
-
threshold — Especifica o percentual do limite máximo de prefixo configurado no qual o roteador gera uma mensagem de advertência. O intervalo válido é de 1 a 100%.
-
O padrão é 75%.
-
Por exemplo, se o valor máximo configurado for 20 e o limiar for 60, o roteador gera mensagens de aviso quando o número de rotas BGP aprendidas do vizinho excede 60% de 20 (12) rotas.
-
-
restart-interval — Especifica o intervalo, em minutos, após o roteador tentar restabelecer a sessão BGP. O intervalo válido é de 1 a 65535 minutos, é assim que funciona.
-
warning-only (Optional) — Permite que o roteador gere uma mensagem de log quando o limite de prefixo máximo é excedido, em vez de encerrar a sessão de peering.
Para ilustrar melhor o uso, considere este exemplo:
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.
Diagrama de Rede
Topologia de prefixo máximo de BGP
O Router_A no sistema autônomo 200 se conecta diretamente ao Router_B no sistema autônomo 300 através da interface TenGigabitEthernet0/0/0. O Router_A usa 10.0.0.1/30 e o Router_B usa 10.0.0.2/30. Os roteadores estabelecem uma sessão de Border Gateway Protocol (eBGP) externa de salto único sobre esse link.
Configurar o comportamento de aviso de prefixo máximo somente
Na configuração somente de advertência Maximum-Prefix, o Router_B é configurado para registrar apenas uma mensagem de advertência quando o número de prefixos recebidos do Router_A excede o conjunto de limites.
A configuração de ambos os roteadores é conforme mostrado nesta tabela. Observe a presença da palavra-chave warning-only configurada com o comando neighbor:
| roteador_A | router_B |
|---|---|
|
|
Note: Neste exemplo, o comando maximum-prefix gera um aviso quando o número de prefixos BGP recebidos do vizinho 10.0.0.1 excede oito.
As saídas dos comandos show e debug na seção Verify and Troubleshoot deste documento relatam o que acontece no Router_B quando o número de prefixos recebidos do Router_A excede o limite definido.
Configure o prefixo máximo para encerrar o comportamento da sessão BGP
Neste exemplo, Router_B gera um aviso quando a contagem de prefixo recebido excede o limite de aviso. Router_B encerra a sessão BGP quando a contagem de prefixo recebido excede o limite de prefixo máximo. A palavra-chave warning-only não está configurada. O comando maximum-prefix termina a sessão BGP quando o número de prefixos recebidos do vizinho excede 10:
| roteador_A | router_B |
|---|---|
|
|
Note: Neste exemplo, o comando maximum-prefix força a sessão vizinha a ser desfeita quando o BGP aprendeu rotas do vizinho exceder 10.
As saídas dos comandos show e debug na seção Verify and Troubleshoot relatam o que acontece no Router_B quando o número de prefixos que ele recebe do Router_A excede o limite definido.
Verificar e solucionar problemas
Esta seção fornece informações que você pode usar para confirmar se sua configuração está funcionando adequadamente. A sintaxe de comando e os padrões do recurso usado neste documento estão disponíveis na página de comando BGP.
Note: Consulte Compreender informações importantes sobre comandos de depuração antes de usar os comandos de depuração.
-
show ip bgp neighbor — Exibe o status do vizinho BGP e as informações de limite de prefixo
-
show ip bgp summary — Exibe o status de todas as conexões BGP
-
debug ip bgp updates in — Exibe informações relacionadas às atualizações BGP
Apenas aviso de prefixo máximo
Preste atenção a estes números:
-
Limite máximo de prefixo configurado: 10 (dez prefixos)
-
Limiar de advertência: 80% (oito prefixos)
Note: A geração de rota exata e a configuração de anúncio BGP usadas para os prefixos de teste são omitidas. O Router_A pode originar os prefixos por meio de instruções de rede ou redistribuição, ou aprendê-los de outros vizinhos BGP e anunciá-los ao Router_B.
Desde que o número de prefixos recebidos não exceda o limite definido, nenhuma mensagem será registrada. Assim que o número de rotas BGP aprendidas do vizinho 10.0.0.1 exceder o limite de oito prefixos, Router_B registrará esta mensagem.
Essa situação é simulada quando nove prefixos são enviados:
%BGP-4-MAXPFX: No. of prefix received from 10.0.0.1 (afi 0) reaches 9, max 10
Se a situação piorar e exceder o número de prefixo máximo definido como 10, o roteador registrará essa mensagem. Esta situação é simulada quando mais prefixos são enviados:
%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 anuncia 11 prefixos para Router_B. Router_B gera um aviso quando a contagem de prefixos recebidos atinge nove e gera uma mensagem de prefixo máximo excedido quando a contagem atinge 11. Como warning-only é configurado, a sessão BGP permanece estabelecida.
Caution: O comando debug ip bgp updates in pode gerar uma saída substancial e afetar o desempenho do dispositivo. Execute este comando somente durante uma janela de solução de problemas controlada, monitore os recursos do sistema, use filtros de comando e desabilite a depuração após a coleta de dados.
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
No exemplo anterior, a relação de vizinhança do BGP é mantida mesmo se o roteador vizinho enviar mais prefixos do que a política permite. O Router_B registra mensagens de aviso e de prefixo máximo excedido, mas mantém a sessão BGP estabelecida. Router_B continua a aceitar prefixos do vizinho porque warning-only está configurado.
Sessão BGP de Término de Prefixo Máximo
As condições iniciais necessárias para esse caso têm o vizinho BGP em funcionamento e com seis prefixos enviados pelo Router_A ao Router_B. Como visto no exemplo, quando o Router_A anuncia mais prefixos (por exemplo, 9), a saída dos comandos reflete exatamente o que já foi visto no caso em que o Router_B está configurado para registrar uma mensagem de aviso.
Depois que o Router_A anuncia um décimo primeiro prefixo, a contagem de prefixos recebidos excede o limite configurado de 10. O Router_B envia um número máximo de notificações de prefixos atingidos e encerra a sessão 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)Note: Neste cenário, você deve usar o comando clear ip bgp <neighbor-ip> para restaurar a sessão de peer. Antes de redefinir a sessão, reduza o número de prefixos anunciados pelo peer ou ajuste o limite máximo de prefixo configurado após a validação da capacidade. Esse comando redefine a sessão BGP e remove temporariamente as rotas aprendidas do 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 connectionInformações Relacionadas
Histórico de revisões
| Revisão | Data de publicação | Comentários |
|---|---|---|
2.0 |
20-Aug-2026
|
Título, ortografia, gramática e linhas horizontais inseridas atualizados para separar seções para facilitar a leitura. |
1.0 |
09-Jul-2002
|
Versão inicial |
Feedback