Solucionar problemas de rotas BGP não sincronizadas (falha de roteamento recursivo)

Introduction

Este documento descreve como solucionar problemas de rotas de Border Gateway Protocol (BGP) não sincronizadas causadas por falha de roteamento recursivo. 

Prerequisites

Requirements

Não existem requisitos específicos para este documento.

Componentes Utilizados

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.

Informações de Apoio

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:

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

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
!

Conventions

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Problema

Sintomas

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#

Falha de Roteamento Recursivo

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

Causas de falha de roteamento recursivo

Estes passos descrevem a causa de recorrentes falhas de roteamento:

1. 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.

2. 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.

3. 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.

4. 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.

5. 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

6. 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.

Solução

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

Redução de Rota

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.

Informações Relacionadas

• O que significa a mensagem de erro "#%BGP-3-INSUFCHUNKS: pools de partes insuficientes para aspath"?
• Por que os vizinhos de BGP variam entre os estados Idle (Inativo), Connect (Conectado) e Active (Ativo)?
• Suporte a IP Routing/BGP
• Suporte técnico e downloads da Cisco