O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento descreve como solucionar problemas de rotas de Border Gateway Protocol (BGP) não sincronizadas causadas por falha de roteamento recursivo.
Não existem requisitos específicos para este documento.
Este documento não se restringe a versões de software e hardware específicas.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Este documento descreve como solucionar problemas de rotas de Border Gateway Protocol (BGP) não sincronizadas causadas por falha de roteamento recursivo.
Sintomas comuns de falha de roteamento recursivo no BGP são:
Exclusão e reinserção constantes de rotas BGP na tabela de roteamento.
Perda de conectividade para destinos aprendidos através do BGP.
Consulte este diagrama de rede enquanto você utiliza este documento.
Diagrama de Rede
Consulte estas configurações ao usar este documento:
Rtr-A |
---|
hostname RTR-A ! interface Loopback0 ip address 10.10.10.10 255.255.255.255 ! interface Serial8/0 ip address 192.168.16.1 255.255.255.252 ! router bgp 1 bgp log-neighbor-changes neighbor 10.20.20.20 remote-as 2 neighbor 10.20.20.20 ebgp-multihop 2 neighbor 10.20.20.20 update-source Loopback0 ! ip route 10.20.20.0 255.255.255.0 192.168.16.2 |
Rtr-B |
---|
hostname RTR-B ! interface Loopback0 ip address 10.20.20.20 255.255.255.255 ! interface Ethernet0/0 ip address 172.16.1.1 255.255.255.0 ! interface Serial8/0 ip address 192.168.16.2 255.255.255.252 ! router bgp 2 no synchronization bgp log-neighbor-changes network 10.20.20.20 mask 255.255.255.255 network 172.16.1.0 mask 255.255.255.0 neighbor 10.10.10.10 remote-as 1 neighbor 10.10.10.10 ebgp-multihop 2 neighbor 10.10.10.10 update-source Loopback0 no auto-summary ! ip route 10.10.10.0 255.255.255.0 192.168.16.1 ! |
Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.
Esses dois sintomas são observados com falha de roteamento recursivo:
A não sincronização contínua das rotas BGP aprendidas na tabela de IP Routing.
Observe a tabela de roteamento continuamente por alguns minutos para ver a oscilação.
RTR-A#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - ISIS level-1, L2 - ISIS level-2, ia - ISIS inter are * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks B 10.20.20.20/32 [20/0] via 10.20.20.20, 00:00:35 S 10.20.20.0/24 [1/0] via 192.168.16.2 172.16.0.0/24 is subnetted, 1 subnets B 172.16.1.0 [20/0] via 10.20.20.20, 00:00:35 10.0.0.0/32 is subnetted, 1 subnets C 10.10.10.10 is directly connected, Loopback0 192.168.16.0/30 is subnetted, 1 subnets C 192.168.16.0 is directly connected, Serial8/0
Observação: é útil usar o comando show ip route | include , 00:00 para observar rotas não sincronizadas quando você lida com tabelas de roteamento grandes.
Depois de esperar aproximadamente um minuto, os resultados do comando show ip route mudam para:
RTR-A#show ip route [..] Gateway of last resort is not set 10.0.0.0/24 is subnetted, 1 subnets S 10.20.20.0 [1/0] via 192.168.16.2 10.0.0.0/32 is subnetted, 1 subnets C 10.10.10.10 is directly connected, Loopback0 192.168.16.0/30 is subnetted, 1 subnets C 192.168.16.0 is directly connected, Serial8/0
Observação: as rotas BGP estão ausentes na tabela de roteamento anterior.
Quando as rotas BGP estão presentes na tabela de roteamento, a conectividade com essas redes falha.
Para observar isso, quando a tabela de roteamento do Rtr-A tem a rota 172.16.1.0/24 aprendida pelo BGP em sua tabela de roteamento, um ping para o host válido 172.16.1.1 falha.
RTR-A#show ip route 172.16.1.0 Routing entry for 172.16.1.0/24 Known via "bgp 1", distance 20, metric 0 Tag 2, type external Last update from 10.20.20.20 00:00:16 ago Routing Descriptor Blocks: * 10.20.20.20, from 10.20.20.20, 00:00:16 ago Route metric is 0, traffic share count is 1 AS Hops 1 RTR-A#ping 172.16.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) RTR-A#
No Rtr-A, observe a rota em direção ao peer de BGP 10.20.20.20. A rota oscila entre os dois próximos saltos consistentemente a cada minuto aproximadamente.
RTR-A#show ip route 10.20.20.20 Routing entry for 10.20.20.20/32 Known via "bgp 1", distance 20, metric 0 Tag 2, type external Last update from 10.20.20.20 00:00:35 ago Routing Descriptor Blocks: * 10.20.20.20, from 10.20.20.20, 00:00:35 ago Route metric is 0, traffic share count is 1 AS Hops 1
A rota em direção ao endereço IP do peer do BGP é aprendida pelo próprio BGP; portanto, cria uma falha de roteamento recursiva.
Após aproximadamente um minuto, a rota muda para:
RTR-A#show ip route 10.20.20.20 Routing entry for 10.20.20.0/24 Known via "static", distance 1, metric 0 Routing Descriptor Blocks: * 192.168.16.2 Route metric is 0, traffic share count is 1
Estes passos descrevem a causa de recorrentes falhas de roteamento:
Consulte a configuração de Rtr-A. Nessa configuração, uma rota estática 10.20.20.0/24 é configurada para apontar para o próximo salto diretamente conectado 192.168.16.2. Com essa rota estática, uma sessão BGP com peer Rtr-B 10.20.20.20 é estabelecida.
Rtr-B anuncia rotas BGP 172.16.1.0/24 e 10.20.20.20/32 para Rtr-A com seu endereço IP de loopback 10.20.20.20 como o próximo salto.
O Rtr-A recebe rotas BGP anunciadas pelo Rtr-B e tenta instalar o 10.20.20.20/32. Isso é mais específico do que 10.20.20.0/24, que já está configurado no Rtr-A como uma rota estática. Como a rota de correspondência mais longa é preferencial, 10.20.20.20/32 é preferível a 10.20.20.0/24. Consulte Seleção de rota em roteadores Cisco para obter mais informações. A rota instalada 10.20.20.20/32 tem o próximo salto de 10.20.20.20 (endereço IP de peering Rtr-B) na tabela de roteamento. Isso leva a uma falha de roteamento recursiva, já que a rota em direção a 10.20.20.20/32 possui um próximo salto dela mesma.
Para entender o motivo por trás do qual o roteamento recursivo falha nessa situação específica, você precisa entender como o algoritmo de roteamento funciona. Para qualquer rota conectada não diretamente na tabela de roteamento cujo endereço IP do próximo salto não seja uma interface diretamente conectada do roteador, o algoritmo procura recursivamente na tabela de roteamento até encontrar uma interface diretamente conectada para a qual possa encaminhar os pacotes.
Nessa situação específica, o Rtr-A aprende uma rota para a rede 10.20.20.20/32 conectada indiretamente com um próximo salto de 10.20.20.20 conectado indiretamente (ele mesmo). O algoritmo de roteamento é executado em uma falha de loop de roteamento recursivo porque não consegue encontrar nenhuma interface diretamente conectada para a qual enviar pacotes destinados a 10.20.20.20/32.
O roteador detecta que essa rota 10.20.20.20/32 conectada indiretamente tem uma falha de roteamento recursiva e retira 10.20.20.20/32 da tabela de roteamento. Consequentemente, todas as rotas aprendidas por BGP com o endereço IP do próximo salto 10.20.20.20 também são retiradas da tabela de roteamento.
O processo inteiro se repete a partir do Passo 1. Você pode confirmar isso ao executar o comando debug ip routing.
Nota:Antes de executar qualquer comando debug, execute o comando debug em uma lista de controle de acesso (ACL) de uma rede específica para limitar a saída da depuração. Neste exemplo, configure uma ACL para limitar a saída de depuração.
RTR-A(config)#access-list 1 permit 10.20.20.20 RTR-A(config)#access-list 1 permit 172.16.1.0 RTR-A(config)#end RTR-A#debug ip routing 1 IP routing debugging is on for access list 1 00:29:50: RT: add 10.20.20.20/32 via 10.20.20.20, bgp metric [20/0] 00:29:50: RT: add 172.16.1.0/24 via 10.20.20.20, bgp metric [20/0] 00:30:45: RT: recursion error routing 10.20.20.20 - probable routing loop 00:30:45: RT: recursion error routing 10.20.20.20 - probable routing loop 00:30:45: RT: recursion error routing 10.20.20.20 - probable routing loop 00:30:46: RT: recursion error routing 10.20.20.20 - probable routing loop 00:30:46: RT: recursion error routing 10.20.20.20 - probable routing loop 00:30:48: RT: recursion error routing 10.20.20.20 - probable routing loop 00:30:48: RT: recursion error routing 10.20.20.20 - probable routing loop 00:30:50: RT: del 10.20.20.20/32 via 10.20.20.20, bgp metric [20/0] 00:30:50: RT: delete subnet route to 10.20.20.20/32 00:30:50: RT: del 172.16.1.0/24 via 10.20.20.20, bgp metric [20/0] 00:30:50: RT: delete subnet route to 172.16.1.0/24
Se a recursão da rota falhar continuamente, esta mensagem de erro será exibida:
%COMMON_FIB-SP-6-FIB_RECURSION: 10.71.124.25/32 has too many (8) levels of recursion during setting up switching info %COMMON_FIB-SP-STDBY-6-FIB_RECURSION: 10.71.124.25/32 has too many (8) levels of recursion during setting up switching info
Isso ocorre porque as retransmissões de TCP ocorrem na rede habilitada para MPLS. Se uma mensagem de keepalive BGP falhar uma vez em ser enviada ao BGP Peer porque o link de transporte está inoperante, o BGP Peer vizinho não aceita nenhum pacote de keepalive adicional mesmo que o TCP retransmita a mensagem com falha através do caminho de backup e, eventualmente, leva ao BGP Peer inoperante com expiração de holdtime. Esse problema é visto apenas quando o MPLS é configurado no Catalyst 6500 ou no Cisco 7600. Essas informações estão incluídas no bug da Cisco ID CSCsj89544 .
Observação: somente usuários registrados da Cisco podem acessar informações de bugs internos e outras ferramentas.
As soluções para esse problema são explicadas com esses detalhes.
Adicione uma rota estática específica em Rtr-A para o endereço IP do par BGP (10.20.20.20 neste caso).
RTR-A#configure terminal Enter configuration commands, one per line. End with CNTL/Z. RTR-A(config)#ip route 10.20.20.20 255.255.255.255 192.168.16.2
A configuração de uma rota estática para o prefixo 10.20.20.20/32 garante que uma rota BGP dinamicamente aprendida 10.20.20.20/32 não seja instalada na tabela de roteamento e, portanto, evita a situação de loop de roteamento recursivo. Consulte Seleção de rota em roteadores Cisco para obter mais informações.
Observação: quando os peers EBGP são configurados para alcançar um ao outro com rotas padrão, a vizinhança BGP não aparece. Isso é feito para evitar a oscilação e os loops de roteamento.
Um ping para 172.16.1.1 confirma a solução.
RTR-A#ping 172.16.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 20/24/40 ms
O retardamento de rota é um recurso de BGP projetado para minimizar a propagação de rotas não sincronizadas através de uma rede interconectada. Os valores recomendados pelo ISP são os padrões no Cisco IOS® e você só precisa configurar esse comando para ativá-lo.
router bgp <AS number> bgp dampening
O comando bgp dampeningdefine valores padrão para os parâmetros de redução, como Meio-período= 15 minutos, reutilização = 750, Suprimir = 2000 e Tempo Máximo de Supressão = 60. Esses valores são configuráveis pelo usuário, mas a Cisco recomenda que permaneçam inalterados.
Revisão | Data de publicação | Comentários |
---|---|---|
1.0 |
07-Feb-2002 |
Versão inicial |