Configurar o recurso de prefixo máximo de BGP

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 ter conhecimento deste tópico:

• Configurando uma rede BGP.

Componentes Utilizados

As informações neste documento não estão restritas a versões específicas de software e hardware, mas as saídas foram obtidas destas versões de software:

• Software Cisco IOS® versões 12.2(27)

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 de Troubleshooting no recurso de prefixo máximo Border Gateway Protocol (BGP).

O recurso BGP Maximum-Prefix 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. Esse recurso é comumente usado para peers BGP externos, mas também 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 site de peering remoto, um roteador começa a receber mais rotas do que a memória do roteador pode suportar. Se esse mesmo roteador estiver fazendo peering com o BGP e também executar funções críticas de roteamento dentro de uma rede, essa sobrecarga pode se tornar ruim. Um problema de BGP poderia interromper a conectividade de rede interna. Com o comando neighbor 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 um limite um pouco maior que o número de prefixos BGP esperados para serem recebidos durante operações normais.

• Conheça a ação a ser tomada caso o peer BGP remoto envie mais prefixos do que os esperados. As ações disponíveis podem ser desativar a sessão e manter a relação de vizinhança BGP inativa até que você use o comando clear ip bgp x.x.x.x ou, alternativamente, registrar apenas uma mensagem de aviso.

Observação: um aprimoramento desse recurso foi introduzido no Cisco IOS Software Release 12.0(22)S e 12.2(15)T. O aprimoramento permite que o usuário restabeleça automaticamente uma sessão de peering que foi desativada porque o limite máximo de prefixo configurado foi excedido. Nenhuma intervenção do operador de rede é necessária quando este recurso está habilitado. Para obter mais informações, consulte Sessão de reinicialização do BGP após limite de prefixo máximo.

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 — Um valor inteiro opcional que especifica em qual porcentagem maximum-value é configurado. O roteador começa a gerar uma mensagem de aviso. O intervalo é de 1 a 100 por cento, e o padrão é 75 por cento.

  Por exemplo, se o valor máximo configurado for 20 e o limiar for 60, o roteador gerará mensagens de aviso quando o número de rotas BGP aprendidas do vizinho exceder 60 por cento de 20 (12) rotas.

  restart-interval — Um intervalo de tempo opcional (em minutos) durante o qual uma sessão de troca de tráfego (peering) é restabelecida. O intervalo é de 1 a 65535 minutos.

  advertência apenas—(opcional) 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

Este documento utiliza a seguinte configuração de rede:

Configurações

Este documento utiliza as seguintes configurações:

• Prefixo máximo configurado para mensagem somente de advertência quando o limiar exceder o conjunto de limiar

• Prefixo máximo configurado para tornar inativo o relacionamento vizinho quando o limiar exceder o conjunto de limiar

Prefixo máximo configurado para mensagem somente de advertência quando o limiar exceder o conjunto de limiar

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.

hostname Router_A
! 
interface Loopback0
 ip address 10.0.0.1 255.255.255.255
!
interface Serial0 
 ip address 192.168.1.1 255.255.255.252
!
interface Serial1
 ip unnumbered Loopback0 
! 
router bgp 200
 no synchronization
 bgp router-id 10.0.0.1
 bgp log-neighbor-changes
 neighbor 192.168.1.2 local-as 100
 neighbor 10.0.0.2 remote-as 300
 neighbor 10.0.0.2 ebgp-multihop 2
 neighbor 10.0.0.2 update-source Loopback0
 neighbor 10.0.0.2 version 4
 no auto-summary
!
ip route 10.0.0.2 255.255.255.252 Serial1

hostname Router_B 
!
interface Loopback0
 ip address 10.0.0.2 255.255.255.252
!
interface Ethernet0 
 ip address 10.0.1.1 255.255.255.0 
!
interface Serial0
 ip unnumbered Loopback0
! 
router bgp 300
 no synchronization
 bgp router-id 10.0.0.2
 bgp log-neighbor-changes
 neighbor 10.0.0.1 remote-as 200
 neighbor 10.0.0.1 ebgp-multihop 2
 neighbor 10.0.0.1 update-source Loopback0
 neighbor 10.0.0.1 version 4
 neighbor 10.0.0.1 maximum-prefix 10 80 warning-only

!--- Enables warning message logging when the number 
!--- of BGP routes learned from neighbor 
!--- 10.0.0.1 exceeds eight. 

 no auto-summary
!
ip route 10.0.0.1 255.255.255.252 Serial0

As saídas dos comandos show e debug na seção Verify and Troubleshoot deste documento relatam o que realmente acontece no Router_B sempre que o número de prefixos recebidos do Router_A excede o conjunto de limites.

Prefixo máximo configurado para tornar inativo o relacionamento vizinho quando o limiar exceder o conjunto de limiar

No prefixo máximo configurado para desativar a configuração de relacionamento de vizinhança, o Router_B é configurado para gerar mensagens de aviso quando o número de prefixos recebidos do Router_A excede o limite definido. Router_B também é configurado para desativar o vizinho BGP quando o limite máximo de prefixo é excedido. A configuração de ambos os roteadores é conforme mostrado na tabela. Observe a ausência do conjunto de palavras-chave warning-only com o comando neighbor.

hostname Router_A
! 
interface Loopback0
 ip address 10.0.0.1 255.255.255.255
!
interface Serial0 
 ip address 192.168.1.1 255.255.255.252
!
interface Serial1
 ip unnumbered Loopback0 
! 
router bgp 200
 no synchronization
 bgp router-id 10.0.0.1
 bgp log-neighbor-changes
 neighbor 192.168.1.2 local-as 100
 neighbor 10.0.0.2 remote-as 300
 neighbor 10.0.0.2 ebgp-multihop 2
 neighbor 10.0.0.2 update-source Loopback0
 neighbor 10.0.0.2 version 4
 no auto-summary
!
ip route 10.0.0.2 255.255.255.252 Serial1

hostname Router_B 
!
interface Loopback0
 ip address 10.0.0.2 255.255.255.252
!
interface Ethernet0 
 ip address 10.0.1.1 255.255.255.0 
!
interface Serial0
 ip unnumbered Loopback0
! 
router bgp 300
 no synchronization
 bgp router-id 10.0.0.2
 bgp log-neighbor-changes
 neighbor 10.0.0.1 remote-as 200
 neighbor 10.0.0.1 ebgp-multihop 2
 neighbor 10.0.0.1 update-source Loopback0
 neighbor 10.0.0.1 version 4
 neighbor 10.0.0.1 maximum-prefix 10 80

!--- This forces the neighbor session to tear down 
!--- when the BGP learned routes from 
!--- the neighbor exceeds 10.

 no auto-summary
!
ip route 10.0.0.1 255.255.255.252 Serial0

As saídas dos comandos show e debug na seção Verify and Troubleshoot relatam o que realmente acontece no Router_B sempre que 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 Comando BGP.

Observação: consulte Compreender informações importantes sobre comandos debug antes de usar comandos debug.

• show ip bgp neighbor — Exibe o status do vizinho BGP.

• 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:

• Máximo de prefixos acordado: 10

• Limite de aviso: 80 por cento (oito)

Desde que o número de prefixos recebidos não seja maior que o limite definido, oito, nenhuma mensagem será registrada. Assim que o número de rotas BGP aprendidas do vizinho 10.0.0.1 exceder o limite de oito, 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 12 prefixos são enviados:

%BGP-3-MAXPFXEXCEED: No. of prefix received from 10.0.0.1 (afi 0): 11 exceed limit 10 

Quando você ativa o debug ip bgp updates no , é possível obter uma visão mais detalhada do que acontece. No entanto, não use esse comando em um ambiente ativo com vários milhares de prefixos. A situação descrita é que o Router_B já tem um emparelhamento estabelecido. Seis prefixos foram anunciados ao Roteador B pelo Roteador_A. Agora, três prefixos adicionais são anunciados pelo peer Router_A.

Router_B# debug ip bgp updates in
*Mar 12 07:31:18.944: BGP(0): 10.0.0.1 rcvd UPDATE w/ attr: nexthop 10.0.0.1, origin i, metric 0, path 200
*Mar 12 07:31:18.948: BGP(0): 10.0.0.1 rcvd 10.0.1.0/24...duplicate ignored
*Mar 12 07:31:18.952: BGP(0): 10.0.0.1 rcvd 10.0.2.0/24...duplicate ignored
*Mar 12 07:31:18.960: BGP(0): 10.0.0.1 rcvd 10.0.3.0/24...duplicate ignored
*Mar 12 07:32:20.224: BGP(0): 10.0.0.1 rcvd 10.0.4.0/24...duplicate ignored
*Mar 12 07:32:20.228: BGP(0): 10.0.0.1 rcvd 10.0.5.0/24...duplicate ignored
*Mar 12 07:32:20.232: BGP(0): 10.0.0.1 rcvd 10.0.6.0/24...duplicate ignored
*Mar 12 07:34:19.768: BGP(0): 10.0.0.1 rcvd 10.0.7.0/24
*Mar 12 07:34:19.772: BGP(0): 10.0.0.1 rcvd 10.0.8.0/24
*Mar 12 07:34:19.780: BGP(0): 10.0.0.1 rcvd 10.0.9.0/24
*Mar 12 07:34:19.780: 
%BGP-4-MAXPFX: No. of prefix received from 10.0.0.1 (afi 0 ) reaches 9, max 10

*Mar 12 07:34:19.792: BGP(0): Revise route installing 1 of 1 route for 10.0.7.0/24 -> 10.0.0.1 to main IP table
*Mar 12 07:34:19.796: BGP(0): Revise route installing 1 of 1 route for 10.0.8.0/24 -> 10.0.0.1 to main IP table
*Mar 12 07:34:19.804: BGP(0): Revise route installing 1 of 1 route for 10.0.9.0/24 -> 10.0.0.1 to main IP table

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:13:22
  Last read 00:00:21, hold time is 180, keepalive interval is 60 seconds
  Neighbor capabilities:
    Route refresh: advertised and received(old & new)
    Address family IPv4 Unicast: advertised and received
    IPv4 MPLS Label capability:
  Received 930 messages, 0 notifications, 0 in queue
  Sent 919 messages, 1 notifications, 0 in queue
  Default minimum time between advertisement runs is 30 seconds

 For address family: IPv4 Unicast
  BGP table version 30, neighbor version 30
  Index 1, Offset 0, Mask 0x2
  Route refresh request: received 0, sent 0
  9 accepted prefixes consume 432 bytes
  Prefix advertised 0, suppressed 0, withdrawn 0, maximum limit 10 (warning-only)
  Threshold for warning message 80%

  Connections established 2; dropped 1
  Last reset 00:29:13, due to BGP Notification sent, update malformed
  Message received that caused BGP to send a Notification:
    FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
    003C0200 00001940 01010040 02040201
    00C84003 040A0000 01800404 00000000
    180A000A 180A000B 180A000C
  External BGP neighbor can be up to 2 hops away.
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Local host: 10.0.0.2, Local port: 15668
Foreign host: 10.0.0.1, Foreign port: 179

Enqueued packets for retransmit: 0, input: 0  mis-ordered: 0 (0 bytes)

Event Timers (current time is 0x3A46EB54):
Timer          Starts    Wakeups            Next
Retrans            18          0             0x0
TimeWait            0          0             0x0
AckHold            22          9             0x0
SendWnd             0          0             0x0
KeepAlive           0          0             0x0
GiveUp              0          0             0x0
PmtuAger            0          0             0x0
DeadWait            0          0             0x0

iss: 2047376434  snduna: 2047376784  sndnxt: 2047376784     sndwnd:  16035
irs:  821061364  rcvnxt:  821062116  rcvwnd:      16188  delrcvwnd:    196

SRTT: 279 ms, RTTO: 500 ms, RTV: 221 ms, KRTT: 0 ms
minRTT: 24 ms, maxRTT: 384 ms, ACK hold: 200 ms
Flags: higher precedence, nagle

Datagrams (max data segment is 536 bytes):
Rcvd: 33 (out of order: 0), with data: 22, total data bytes: 751
Sent: 29 (retransmit: 0, fastretransmit: 0), with data: 17, total data bytes: 349

Router_B#show ip bgp summary
BGP router identifier 10.0.0.2, local AS number 300
BGP table version is 30, main routing table version 30
9 network entries and 9 paths using 1341 bytes of memory
1 BGP path attribute entries using 60 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 activity 36/101 prefixes, 36/27 paths, scan interval 60 secs

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.0.0.1        4   200     932     921       30    0    0 00:15:08        9

Suponha que a situação piore e que o Router_A envie três prefixos adicionais, o que aumenta o número total para até 12.

Router_B# debug ip bgp updates in
*Mar 12 07:39:21.192: BGP(0): 10.0.0.1 rcvd UPDATE w/ attr: nexthop 10.0.0.1, origin i, metric 0, path 200
*Mar 12 07:39:21.196: BGP(0): 10.0.0.1 rcvd 10.0.10.0/24
*Mar 12 07:39:21.200: %BGP-4-MAXPFX: No. of prefix received from 10.0.0.1 (afi 0) reaches 10, max 10
*Mar 12 07:39:21.208: BGP(0): 10.0.0.1 rcvd 10.0.11.0/24
*Mar 12 07:39:21.212: %BGP-3-MAXPFXEXCEED: No. of prefix received from 10.0.0.1 (afi 0): 11 exceed limit 10
*Mar 12 07:39:21.216: BGP(0): 10.0.0.1 rcvd 10.0.12.0/24
*Mar 12 07:39:21.228: BGP(0): Revise route installing 1 of 1 route for 10.0.10.0/24 -> 10.0.0.1 to main IP table
*Mar 12 07:39:21.236: BGP(0): Revise route installing 1 of 1 route for 10.0.11.0/24 -> 10.0.0.1 to main IP table
*Mar 12 07:39:21.240: BGP(0): Revise route installing 1 of 1 route for 10.0.12.0/24 -> 10.0.0.1 to main IP table

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 = Established, up for 00:19:56
  Last read 00:00:56, hold time is 180, keepalive interval is 60 seconds
  Neighbor capabilities:
    Route refresh: advertised and received(old & new)
    Address family IPv4 Unicast: advertised and received
    IPv4 MPLS Label capability:
  Received 937 messages, 0 notifications, 0 in queue
  Sent 925 messages, 1 notifications, 0 in queue
  Default minimum time between advertisement runs is 30 seconds

 For address family: IPv4 Unicast
  BGP table version 33, neighbor version 33
  Index 1, Offset 0, Mask 0x2
  Route refresh request: received 0, sent 0
  12 accepted prefixes consume 576 bytes
  Prefix advertised 0, suppressed 0, withdrawn 0, maximum limit 10 (warning-only)
  Threshold for warning message 80%

  Connections established 2; dropped 1
  Last reset 00:35:47, due to BGP Notification sent, update malformed
  Message received that caused BGP to send a Notification:
    FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
    003C0200 00001940 01010040 02040201
    00C84003 040A0000 01800404 00000000
    180A000A 180A000B 180A000C
  External BGP neighbor can be up to 2 hops away.
Connection state is ESTAB, I/O status: 1, unread input bytes: 0
Local host: 10.0.0.2, Local port: 15668
Foreign host: 10.0.0.1, Foreign port: 179

Enqueued packets for retransmit: 0, input: 0  mis-ordered: 0 (0 bytes)

Event Timers (current time is 0x3A4CEA98):
Timer          Starts    Wakeups            Next
Retrans            24          0             0x0
TimeWait            0          0             0x0
AckHold            29         16             0x0
SendWnd             0          0             0x0
KeepAlive           0          0             0x0
GiveUp              0          0             0x0
PmtuAger            0          0             0x0
DeadWait            0          0             0x0

iss: 2047376434  snduna: 2047376898  sndnxt: 2047376898     sndwnd:  15921
irs:  821061364  rcvnxt:  821062290  rcvwnd:      16014  delrcvwnd:    370

SRTT: 290 ms, RTTO: 376 ms, RTV: 86 ms, KRTT: 0 ms
minRTT: 24 ms, maxRTT: 384 ms, ACK hold: 200 ms
Flags: higher precedence, nagle

Datagrams (max data segment is 536 bytes):
Rcvd: 40 (out of order: 0), with data: 29, total data bytes: 925
Sent: 42 (retransmit: 0, fastretransmit: 0), with data: 23, total data bytes: 463

Router_B#show ip bgp summary
BGP router identifier 10.0.0.2, local AS number 300
BGP table version is 33, main routing table version 33
12 network entries and 12 paths using 1788 bytes of memory
1 BGP path attribute entries using 60 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 activity 39/101 prefixes, 39/27 paths, scan interval 60 secs

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.0.0.1        4   200     939     927       33    0    0 00:21:28       12

Como você pode ver no exemplo mostrado, a relação de vizinhança do BGP é mantida mesmo se o roteador vizinho enviar mais prefixos do que a política permite. O resultado é que somente uma mensagem de aviso é registrada pelo Router_B. Nenhuma outra ação é tomada pelo Roteador B.

Prefixo máximo configurado para encerrar a sessão quando o limiar definido for excedido

As condições iniciais necessárias para esse caso são ter o vizinho BGP ativo e em execução 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 apenas registrar uma mensagem de aviso. Se você aumentar o número de prefixos enviados e fizer com que o Router_A anuncie 12, o Router_B fechará o relacionamento de vizinhança com o Router_A.

Router_B#debug ip bgp updates in
*Mar 12 08:03:27.864: BGP(0): 10.0.0.1 rcvd UPDATE w/ attr: nexthop 10.0.0.1, origin i, metric 0, path 200
*Mar 12 08:03:27.868: BGP(0): 10.0.0.1 rcvd 10.0.1.0/24...duplicate ignored
*Mar 12 08:03:27.876: BGP(0): 10.0.0.1 rcvd 10.0.2.0/24...duplicate ignored
*Mar 12 08:03:27.880: BGP(0): 10.0.0.1 rcvd 10.0.3.0/24...duplicate ignored
*Mar 12 08:03:27.884: BGP(0): 10.0.0.1 rcvd 10.0.4.0/24...duplicate ignored
*Mar 12 08:03:27.892: BGP(0): 10.0.0.1 rcvd 10.0.5.0/24...duplicate ignored
*Mar 12 08:03:27.896: BGP(0): 10.0.0.1 rcvd 10.0.6.0/24...duplicate ignored
*Mar 12 08:03:27.900: BGP(0): 10.0.0.1 rcvd 10.0.7.0/24
*Mar 12 08:03:27.908: BGP(0): 10.0.0.1 rcvd 10.0.8.0/24
*Mar 12 08:03:27.912: BGP(0): 10.0.0.1 rcvd 10.0.9.0/24
*Mar 12 08:03:27.916: %BGP-4-MAXPFX: No. of prefix received from 10.0.0.1 (afi 0) reaches 9, max 10
*Mar 12 08:03:27.924: BGP(0): 10.0.0.1 rcvd 10.0.10.0/24
*Mar 12 08:03:27.932: BGP(0): 10.0.0.1 rcvd 10.0.11.0/24
*Mar 12 08:03:27.932: %BGP-3-MAXPFXEXCEED: No. of prefix received from 10.0.0.1 (afi 0): 11 exceed limit 10
*Mar 12 08:03:27.940: %BGP-5-ADJCHANGE: neighbor 10.0.0.1 Down BGP Notification sent
*Mar 12 08:03:27.940: %BGP-3-NOTIFICATION: sent to neighbor 10.0.0.1 3/1 (update
 malformed) 0 bytes  FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0060 0200 0000 1940
 0101 0040 0204 0201 00C8 4003 040A 0000 0180 0404 0000 0000 180A 0001 180A 0002
 180A 0003 180A 0004 180A 0005 180A 0006 180A 0007 180A 0008 180A 0009 180A 000A
 180A 000B 180A 000C
*Mar 12 08:03:28.024: BGP(0): Revise route installing 1 of 1 route for 10.0.7.0/24 -> 10.0.0.1 to main IP table
*Mar 12 08:03:28.032: BGP(0): Revise route installing 1 of 1 route for 10.0.8.0/24 -> 10.0.0.1 to main IP table
*Mar 12 08:03:28.036: BGP(0): Revise route installing 1 of 1 route for 10.0.9.0/24 -> 10.0.0.1 to main IP table
*Mar 12 08:03:28.044: BGP(0): Revise route installing 1 of 1 route for 10.0.10.0/24 -> 10.0.0.1 to main IP table
*Mar 12 08:03:28.148: BGP(0): no valid path for 10.0.1.0/24
*Mar 12 08:03:28.152: BGP(0): no valid path for 10.0.2.0/24
*Mar 12 08:03:28.156: BGP(0): no valid path for 10.0.3.0/24
*Mar 12 08:03:28.156: BGP(0): no valid path for 10.0.4.0/24
*Mar 12 08:03:28.160: BGP(0): no valid path for 10.0.5.0/24
*Mar 12 08:03:28.164: BGP(0): no valid path for 10.0.6.0/24
*Mar 12 08:03:28.168: BGP(0): no valid path for 10.0.7.0/24
*Mar 12 08:03:28.168: BGP(0): no valid path for 10.0.8.0/24
*Mar 12 08:03:28.172: BGP(0): no valid path for 10.0.9.0/24
*Mar 12 08:03:28.176: BGP(0): no valid path for 10.0.10.0/24
*Mar 12 08:03:28.184: BGP(0): nettable_walker 10.0.1.0/24 no best path
*Mar 12 08:03:28.188: BGP(0): nettable_walker 10.0.2.0/24 no best path
*Mar 12 08:03:28.192: BGP(0): nettable_walker 10.0.3.0/24 no best path
*Mar 12 08:03:28.196: BGP(0): nettable_walker 10.0.4.0/24 no best path
*Mar 12 08:03:28.200: BGP(0): nettable_walker 10.0.5.0/24 no best path
*Mar 12 08:03:28.204: BGP(0): nettable_walker 10.0.6.0/24 no best path
*Mar 12 08:03:28.208: BGP(0): nettable_walker 10.0.7.0/24 no best path
*Mar 12 08:03:28.212: BGP(0): nettable_walker 10.0.8.0/24 no best path
*Mar 12 08:03:28.212: BGP(0): nettable_walker 10.0.9.0/24 no best path
*Mar 12 08:03:28.216: BGP(0): nettable_walker 10.0.10.0/24 no best path

Router_B# show ip bgp summary
BGP router identifier 10.0.0.2, local AS number 300
BGP table version is 87, main routing table version 87

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.0.0.1        4   200     965     948        0    0    0 00:02:24 Idle (PfxCt)

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 0.0.0.0
  BGP state = Idle
  Last read 00:02:43, hold time is 180, keepalive interval is 60 seconds
  Received 965 messages, 0 notifications, 0 in queue
  Sent 948 messages, 2 notifications, 0 in queue
  Default minimum time between advertisement runs is 30 seconds

 For address family: IPv4 Unicast
  BGP table version 87, neighbor version 0
  Index 1, Offset 0, Mask 0x2
  Route refresh request: received 0, sent 0, maximum limit 10
  Threshold for warning message 80%

  Connections established 2; dropped 2
  Last reset 00:02:43, due to BGP Notification sent, update malformed
  Message received that caused BGP to send a Notification:
    FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
    00600200 00001940 01010040 02040201
    00C84003 040A0000 01800404 00000000
    180A0001 180A0002 180A0003 180A0004
    180A0005 180A0006 180A0007 180A0008
    180A0009 180A000A 180A000B 180A000C

  Peer had exceeded the max. no. of prefixes configured.
  Reduce the no. of prefix and clear ip bgp 10.0.0.1 to restore peering
  External BGP neighbor can be up to 2 hops away.
  No active TCP connection

Observação: use este comando para restaurar a capacidade do peer:

Router_B#clear ip bgp 10.0.0.1

Informações Relacionadas

• Sessão de reinício de BGP depois do limite de prefixo máximo
• Troubleshooting de BGP
• Estudos de caso de BGP
• Suporte técnico e downloads da Cisco