Solucionar problemas básicos do Border Gateway Protocol
Contents
Introdução
Este documento descreve como solucionar os problemas mais comuns com o Border Gateway Protocol (BGP) e fornece soluções e diretrizes básicas.
Pré-requisitos
Requisitos
Não existem requisitos específicos para este documento. O conhecimento básico do protocolo BGP é útil; você pode consultar o Guia de Configuração BGP para obter mais informações.
Componentes Utilizados
Este documento não está restrito a versões específicas de software e hardware, mas os comandos são aplicáveis para o Cisco IOS® e o Cisco IOS® XE.
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.
Informações de Apoio
Este documento descreve um guia básico para solucionar os problemas mais comuns no BGP (Border Gateway Protocol), fornece ações corretivas, comandos/depurações úteis para detectar a causa raiz dos problemas e práticas recomendadas para evitar possíveis problemas. Lembre-se de que todas as variáveis e cenários possíveis não podem ser considerados e que uma análise mais profunda pode ser exigida pelo TAC da Cisco.
Topologia
Use este diagrama de topologia como referência para as saídas fornecidas neste documento.
Cenários e problemas
Adjacência para Baixo
Se uma sessão BGP estiver off-line, execute o comando show ip bgp all summary command.. Isso fornece o status atual da sessão:
- Se a sessão não estiver no estado ativo, ela pode variar entre IDLE e ATIVE (isso depende do processo da máquina de estado finito.)
- Se a sessão estiver on-line, você poderá ver o número de prefixos recebidos.
R2#show ip bgp all summary For address family: IPv4 Unicast BGP router identifier 198.51.100.2, local AS number 65537 BGP table version is 19, main routing table version 19 18 network entries using 4464 bytes of memory 18 path entries using 2448 bytes of memory 1/1 BGP path/bestpath attribute entries using 296 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 7208 total bytes of memory BGP activity 18/0 prefixes, 18/0 paths, scan interval 60 secs 18 networks peaked at 11:21:00 Jun 30 2022 CST (00:01:35.450 ago) Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 10.0.23.3 4 65537 6 5 19 0 0 00:01:34 18 198.51.100.1 4 65536 0 0 1 0 0 never Idle
Sem conectividade
O primeiro requisito é a conectividade entre os dois peers, portanto, a sessão TCP na porta 179 é estabelecida. Eles estão diretamente conectados ou não) e você pode usar um ping. Se o peering for estabelecido entre interfaces de loopback, um loopback para o ping de loopback deverá ser concluído. Se um teste de ping for executado sem um loopback específico como a interface de origem, o endereço IP da interface física de saída será usado como o endereço IP de origem do pacote em vez do endereço IP de loopback do roteador.
Se o ping não tiver êxito, considere estes motivos:
- Nenhum par de rota conectado ou nenhuma rota; execute o comando show ip route peer_IP_address.
- Questão da camada 1: interface física, SFP (conector), cabo ou problema externo (transporte e provedor, se aplicável) devem ser considerados.
- Verifique qualquer firewall ou lista de acesso que possa bloquear sua conexão.
Se o ping tiver êxito:
Problemas de configuração
- Endereço IP errado ou AS configurado: Para o endereço IP errado, essa mensagem não é exibida; no entanto, verifique se a configuração apropriada foi concluída. Para um AS errado, você deve ver uma mensagem semelhante ao comando show logging.
%BGP-3-NOTIFICATION: sent to neighbor 198.51.100.1 passive 2/2 (peer in wrong AS) 2 bytes 1B39
Verifique a configuração do BGP em ambas as extremidades para corrigir os números AS ou o endereço IP do peer.
- ID do roteador duplicada:
%BGP-3-NOTIFICATION: sent to neighbor 198.51.100.1 passive 2/3 (BGP identifier wrong) 4 bytes 0A0A0A0A
Verifique o identificador de BGP em ambas as extremidades executando o comando show ip bgp all summary e corrija o problema de duplicação. Isso pode ser feito manualmente com o comando global bgp router-id X.X.X.X na configuração do roteador bgp. Como prática recomendada, verifique se o ID do roteador está definido manualmente para um número exclusivo.
- Origem e TTL do BGP:
A maioria das sessões de iBGP são configuradas em interfaces de loopback, que podem ser alcançadas através de um IGP. Essa interface de loopback deve ser explicitamente definida como a origem. Você pode concluir isso executando o comando neighbor ip-address update-source interface-id.
Para interfaces diretamente conectadas de peer eBGP, a maioria é usada para peering. Há uma verificação do Cisco IOS/Cisco IOS XE para atender a essa finalidade, ou ele não tenta estabelecer uma sessão. Se o eBGP é tentado de loopback para loopback em roteadores conectados diretamente, esta verificação pode ser desabilitada para um vizinho específico em ambas as extremidades executando o comando neighbor ip-address disable-connected-check.
No entanto, se houver vários saltos entre os peers do eBGP, uma contagem de saltos apropriada será necessária, certifique-se de que o vizinho ip-address ebgp-multihop [hop-count] esteja configurado com a contagem de saltos correta para que cada sessão possa ser estabelecida. Se a contagem de saltos não for especificada, o valor TTL padrão para sessões iBGP é 255, enquanto o valor TTL padrão para sessões eBGP é 1.
Problemas de sessão TCP
Uma ação útil para testar a porta 179 é um telnet manual de um peer para o outro:
R1#telnet 198.51.100.2 179 Trying 198.51.100.2, 179 ... Open [Connection to 198.51.100.2 closed by foreign host]
Abertura/conexão fechada ou conexão recusada pelo host remoto indica que os pacotes chegaram ao fim remoto. Em seguida, verifique se não há problemas com o plano de controle na extremidade oposta. Caso contrário, se houver uma mensagem de Destino Inalcançável, verifique qualquer firewall ou lista de acesso que possa bloquear a porta TCP 179, pacotes BGP ou se houver alguma perda de pacote no caminho.
Se a autenticação for o problema, as mensagens que você pode ver são:
%TCP-6-BADAUTH: Invalid MD5 digest from 198.51.100.1(179) to 198.51.100.2(20062) tableid - 0 %TCP-6-BADAUTH: No MD5 digest from 198.51.100.1(179) to 198.51.100.2(20062) tableid - 0
Verifique os métodos de autenticação, a senha e as configurações relacionadas e, para obter troubleshooting adicional, consulte o guia MD5 Authentication Between BGP Peers Configuration Example.
Se a sessão TCP não estiver on-line, use os próximos comandos para isolamento:
show tcp brief all
show control-plane host open-ports
debug ip tcp transactions
Devoluções de adjacências
Se a sessão for intermitente, procure o show log e você poderá encontrar alguns cenários.
Flap de Interface
%BGP-5-ADJCHANGE: neighbor 198.51.100.2 Down Interface flap
A razão para essa falha é devido ao "Oscilador de Interface Inativo". Procure problemas físicos na porta/SFP, no cabo ou nas desconexões.
Temporizador em Espera Expirado
%BGP-3-NOTIFICATION: sent to neighbor 198.51.100.2 4/0 (hold time expired) 0 bytes
Isso é comum e o roteador não recebeu/processou uma mensagem de keepalive ou não atualizou a mensagem antes que o temporizador de espera expire. O dispositivo envia uma mensagem de notificação e fecha a sessão. As razões mais comuns para este problema são:
- Problemas de interface: Procure erros de entrada, quedas de fila de entrada ou problemas físicos em ambas as interfaces conectadas por pares; a execução do comando show interface pode ser usada para essa finalidade.
- Perda de pacotes em trânsito: Às vezes, os pacotes Hello podem ser descartados durante o trânsito, para garantir que esta seja uma captura de pacote no nível da interface:
- Use a Captura de pacotes incorporada nos dispositivos Cisco IOS e Cisco IOS XE.
- Se os pacotes forem vistos no nível da interface, certifique-se de que acessem o plano de controle, o EPC no plano de controle ou execute o comando debug bgp [vrf name] ipv4 unicast keepalives.
- CPU de alto desempenho: uma condição de CPU de alto desempenho pode causar quedas no plano de controle. O comando show processes cpu [sorted|history] pode ajudar a identificar esses problemas. Com base na plataforma, você pode encontrar as próximas etapas para solucionar problemas consultando o guia CPU Reference.
- Problemas de política de CoPP: A metodologia de identificação e solução de problemas varia para cada plataforma e está fora do escopo deste documento.
- Incompatibilidade de MTU: Se houver discrepâncias de MTU no caminho e se as mensagens ICMP forem bloqueadas no caminho da origem para o destino, o PMTUD não funcionará corretamente e poderá resultar em uma oscilação de sessão. As atualizações são enviadas com o valor MSS negociado e um bit DF definido. Se um dispositivo no caminho ou no destino não puder aceitar os pacotes com uma MTU mais alta, ele enviará uma mensagem de erro ICMP de volta ao alto-falante BGP. O roteador de destino espera pela manutenção de atividade do BGP ou o BGP atualiza o pacote para seu temporizador de retenção.
Você pode verificar o MSS negociado executando o comando show ip bgp neighbors ip_address.
Um teste de ping para um vizinho específico com o conjunto df pode mostrar se o MTU é válido ao longo do caminho:
ping 198.51.100.2 size max_seg_size df
Se forem encontrados problemas de MTU, uma revisão precisa da configuração deverá ser concluída para garantir que os valores de MTU sejam consistentes em toda a rede.
Problemas AFI/SAFI
%BGP-5-ADJCHANGE: neighbor 198.51.100.2 passive Down AFI/SAFI not supported
%BGP-3-NOTIFICATION: received from neighbor 198.51.100.2 active 2/8 (no supported AFI/SAFI) 3 bytes 000000
O Identificador de Família de Endereços (AFI - Address-Family Identifier) é uma extensão de capacidade adicionada pelo BGP Multiprotocolo (MP-BGP). Ele se correlaciona a um protocolo de rede específico, como IPv4, IPv6 e similares. Granularidade adicional por meio de um Identificador de família de endereços (SAFI) subsequente, como unicast e multicast. O MBGP obtém essa separação com os atributos de caminho (PAs) do BGP MP_REACH_NLRI e MP_UNREACH_NLRI. Esses atributos são transportados dentro das mensagens de atualização do BGP e são usados para transportar informações de alcançabilidade de rede para diferentes famílias de endereços.
A mensagem fornece os números do AFI/SAFI registrado pela IANA:
- Números da família de endereços IANA
- Parâmetros dos Identificadores da Família de Endereços Subsequentes (SAFI)
- Verifique a configuração do BGP para as famílias de endereços planejadas em ambos os lados para corrigir quaisquer famílias de endereços indesejadas.
- Execute o comando neighbor ip-address dont-capability-negotiation em ambas as extremidades. Para obter mais informações, consulte o guia Unsupported Capabilities Cause BGP Peer Malfunction.
Instalação e seleção de caminho
Para obter informações adicionais sobre o BGP e a seleção do melhor caminho, consulte Algoritmo de seleção do melhor caminho BGP.
Próximo Salto
Para que uma rota seja instalada na tabela de roteamento, o próximo salto deve estar acessível, caso contrário, mesmo que o prefixo esteja na tabela BGP Loc-RIB, ele não se move para o RIB. Como regra de prevenção de loop, no Cisco IOS/Cisco IOS XE, o iBGP não altera o atributo do próximo salto, pois deixa o AS_PATH sozinho, enquanto o eBGP regrava o próximo salto e antecede seu AS_PATH.
Você pode revisar o próximo salto executando o comando show ip bgp [prefix] pois ele fornece o próximo salto e a palavra inacessível. Neste exemplo, este é um prefixo anunciado por R1 via eBGP para R2 e aprendido por R3 via conexão iBGP de R2:
R3#show ip bgp 192.0.2.1
BGP routing table entry for 192.0.2.1/32, version 0
Paths: (1 available, no best path)
Not advertised to any peer
Refresh Epoch 1
65536
198.51.100.1 (inaccessible) from 10.0.23.2 (10.2.2.2)
Origin incomplete, metric 0, localpref 100, valid, internal
rx pathid: 0, tx pathid: 0
Updated on Jul 1 2022 13:44:19 CST
Na saída, o próximo salto é a interface de saída de R1, que não é conhecida por R3. Para corrigir essa situação, você pode anunciar o próximo salto via IGP, rota estática ou executar o comando neighbor ip-address next-hop-self no peer do iBGP para modificar o IP do próximo salto (que está conectado diretamente). No exemplo do diagrama, essa configuração deve estar em R2; o vizinho em direção a R3 (neighbor 10.0.23.3 next-hop-self.)
Como resultado, o próximo salto muda (após um clear ip bgp 10.0.23.2 soft) para a interface diretamente conectada (alcançável) e o prefixo é instalado:
R3#show ip bgp 192.0.2.1
BGP routing table entry for 192.0.2.1/32, version 24
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
65536
10.0.23.2 from 10.0.23.2 (10.2.2.2)
Origin incomplete, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0
Updated on Jul 1 2022 13:46:53 CST
Falha de RIB
Isso acontece quando uma rota não pode ser instalada na RIB global, o que resulta em uma falha da RIB. Os motivos comuns são quando o mesmo prefixo já está no RIB para outro protocolo de roteamento com distância administrativa mais baixa, mas o motivo exato de uma falha no RIB é visto com o comando show ip bgp rib-failure.
Condição de corrida
O problema mais comum visto é quando o IGP é preferido sobre o eBGP em um cenário de redistribuição mútua. Quando uma rota IGP é redistribuída no BGP, ela é considerada gerada localmente pelo BGP e recebe um peso de 32.768 por padrão. Todos os prefixos recebidos de um par BGP recebem um peso local de 0 por padrão. Portanto, se o mesmo prefixo precisar ser comparado, o prefixo com maior peso será instalado na tabela de roteamento com base no processo de seleção do melhor caminho BGP, razão pela qual a rota IGP é instalada no RIB.
A solução para esse problema é definir um peso maior para todas as rotas recebidas do peer BGP na configuração de BGP do roteador:
neighbor ip-address weight 40000
Outros problemas
BGP Slow Peer
É um peer que não consegue acompanhar a taxa em que um remetente gera mensagens de atualização. Há muitas razões para que um colega exiba esse problema; alta utilização de CPU em um dos peers, excesso de tráfego, perda de tráfego em um link, recurso de largura de banda, entre outros.
Problemas com memória
O BGP usa a memória atribuída ao processo do Cisco IOS para manter prefixos de rede, melhores caminhos, políticas e todas as configurações relacionadas para operar corretamente. Os processos gerais são vistos com a execução do comando show processes memory sorted:
R1#show processes memory sorted
Processor Pool Total: 2121414332 Used: 255911152 Free: 1865503180 reserve P Pool Total: 102404 Used: 88 Free: 102316 lsmpi_io Pool Total: 3149400 Used: 3148568 Free: 832 PID TTY Allocated Freed Holding Getbufs Retbufs Process 0 0 266231616 81418808 160053760 0 0 *Init* 662 0 34427640 51720 34751920 0 0 SBC main process 85 0 9463568 0 8982224 0 0 IOSD ipc task 0 0 34864888 25213216 8513400 8616279 0 *Dead* 504 0 696632 0 738576 0 0 QOS_MODULE_MAIN 518 0 940000 8616 613760 0 0 BGP Router 228 0 856064 345488 510080 0 0 mDNS 82 0 547096 118360 417520 0 0 SAMsgThread 0 0 0 0 395408 0 0 *MallocLite*
O conjunto de processadores é a memória utilizada; cerca de 2,1 GB no exemplo. Em seguida, você deve examinar a coluna Em Espera para identificar o subprocesso que contém a maior parte dele. Em seguida, você precisa verificar as sessões BGP que tem, quantas rotas são recebidas e a configuração usada.
Etapas comuns para reduzir a retenção de memória pelo BGP:
- Filtragem de BGP: se não for necessário receber uma tabela de BGP completa, use políticas para filtrar rotas e instalar apenas os prefixos necessários.
- Reconfiguração suave: Procure neighbor ip_address soft-reconfiguration inbound na configuração BGP; esse comando permite ver todos os prefixos recebidos antes de qualquer política de entrada (Adj-RIB-in). No entanto, essa tabela precisa de cerca de metade da tabela RIB local do BGP atual para armazenar essas informações para que você possa evitar essa configuração, a menos que seja obrigatório ou seus prefixos atuais sejam poucos.
Alta utilização da CPU
Os roteadores usam processos diferentes para que o BGP opere. Para verificar se o processo BGP é a causa da alta utilização da CPU, execute o comando show process cpu sorted.
R3#show processes cpu sorted CPU utilization for five seconds: 0%/0%; one minute: 0%; five minutes: 0% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 163 36 1463 24 0.07% 0.00% 0.00% 0 ADJ background 62 28 132 212 0.07% 0.00% 0.00% 0 Exec 2 39 294 132 0.00% 0.00% 0.00% 0 Load Meter 1 0 4 0 0.00% 0.00% 0.00% 0 Chunk Manager 3 27 1429 18 0.00% 0.00% 0.00% 0 BGP Scheduler 4 0 1 0 0.00% 0.00% 0.00% 0 RO Notify Timers 63 4 61 65 0.00% 0.00% 0.00% 0 BGP I/O 83 924 26 35538 0.00% 0.03% 0.04% 0 BGP Scanner 96 142 11651 12 0.00% 0.00% 0.00% 0 Tunnel BGP 7 0 1 0 0.00% 0.00% 0.00% 0 DiscardQ Backgro
Estes são os processos comuns, as causas e as etapas gerais para superar a alta utilização da CPU devido ao BGP:
- Roteador BGP: É executado uma vez por segundo para proteger uma convergência mais rápida (esse é um segmento importante). Lê as mensagens de atualização do bgp, valida os prefixos/redes e atributos, atualiza a tabela de rede/prefixo por AFI/SAFI e a tabela de atributos, realiza o cálculo do melhor caminho, entre outras tarefas.
Uma rotatividade enorme é um cenário muito comum que leva a essa situação. - Scanner BGP: Processo de baixa prioridade que é executado a cada 60 segundos por padrão. Esse processo verifica a tabela de BGP inteira para verificar a acessibilidade do próximo salto e atualiza a tabela de BGP de acordo. Ele é executado através da RIB (Routing Information Base, base de informações de roteamento) para fins de redistribuição. Verifique a escala da plataforma, à medida que mais prefixos e rotas instalados e TCAM usado, mais recursos são necessários.
- BGP I/O: É executado quando os pacotes de controle BGP são recebidos e gerencia o enfileiramento e o processamento de pacotes BGP. Se houver pacotes excessivos recebidos na fila de BGP por um longo período, ou se houver um problema com o TCP, o roteador mostra sintomas de alta utilização da CPU devido ao processo de BGP I/O. Geralmente, o Roteador BGP também é alto nessa situação. Examine as contagens de mensagens para identificar os pacotes correspondentes e de captura para identificar a origem dessas mensagens.
- BGP aberto: Processo usado no estabelecimento da sessão; não é um problema comum de alta utilização da CPU, a menos que uma sessão esteja presa em um estado Aberto.
- Evento BGP: é responsável pelo processamento do próximo salto. Procure oscilações de próximos saltos nos prefixos recebidos.
Informações Relacionadas
- Suporte Técnico e Documentação - Cisco Systems
- Manual de configuração de BGP
- Exemplo de Configuração de Autenticação MD5 Entre Pares BGP
- Captura de pacotes incorporada
- Flaps de vizinhos BGP com Troubleshooting de MTU
-
Parâmetros dos Identificadores da Família de Endereços Subsequentes (SAFI)
- Recursos não suportados causam mau funcionamento do correspondente BGP
- Algoritmo de seleção de melhor caminho BGP
- Entender a falha RIB do BGP e o comando bgp suppress-inative
- Entender a importância do atributo de caminho de peso BGP em cenários de failover de rede
- Usar o recurso "Slow Peer" do BGP para resolver problemas de peer lento
- Configurar roteadores BGP para desempenho ideal e consumo de memória reduzido
- Solucionar problemas de alta utilização da CPU causados pelo scanner BGP ou pelo processo do roteador
Histórico de revisões
| Revisão | Data de publicação | Comentários |
|---|---|---|
5.0 |
02-Sep-2026
|
A recertificação atualizou a ortografia/gramática, inseriu linhas horizontais em seções separadas para facilitar a leitura e corrigiu erros do CCW. |
4.0 |
19-Feb-2025
|
Recertificação |
3.0 |
25-Sep-2023
|
IOS XE atualizado (traço removido) e marca registrada adicionada, SEO e formatação. |
2.0 |
21-Feb-2023
|
Recertificação. |
1.0 |
04-Aug-2022
|
Versão inicial |
Feedback