Troubleshooting de Rotas BGP Flapping (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.

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 com os destinos aprendidos através do BGP.

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.

Material de Suporte

Consulte este diagrama de rede enquanto você utiliza este documento.

Consulte estas configurações enquanto você usa 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 20.20.20.20 remote-as 2
 neighbor 20.20.20.20 ebgp-multihop 2
 neighbor 20.20.20.20 update-source Loopback0
!
ip route 20.20.20.0 255.255.255.0 192.168.16.2

hostname RTR-B

!
interface Loopback0
 ip address 20.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 20.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
  
       20.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
  B       20.20.20.20/32 [20/0] via 20.20.20.20, 00:00:35
  S       20.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 20.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 | inclua o comando 00:00 para observar rotas oscilantes quando você lida com grandes tabelas de roteamento.

  Depois de esperar aproximadamente um minuto, os resultados do comando show ip route mudam para este:

  RTR-A#show ip route
  [..]
  
  Gateway of last resort is not set
  
       20.0.0.0/24 is subnetted, 1 subnets
  S       20.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 20.20.20.20 00:00:16 ago
    Routing Descriptor Blocks:
    * 20.20.20.20, from 20.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 BGP 20.20.20.20. A rota oscila entre os dois próximos saltos consistentemente a cada minuto aproximadamente.

RTR-A#show ip route 20.20.20.20
Routing entry for 20.20.20.20/32
  Known via "bgp 1", distance 20, metric 0
  Tag 2, type external
  Last update from 20.20.20.20 00:00:35 ago
  Routing Descriptor Blocks:
  * 20.20.20.20, from 20.20.20.20, 00:00:35 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1

A rota para o endereço IP do peer BGP é aprendida através do próprio BGP; portanto, cria uma falha de roteamento recursiva.

Após aproximadamente um minuto, a rota muda para:

RTR-A#show ip route 20.20.20.20
Routing entry for 20.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

Qual é a Causa de uma Falha de Roteamento Recursivo?

Estes passos descrevem a causa de recorrentes falhas de roteamento:

1. Consulte a configuração do Rtr-A. Nesta configuração, uma rota estática 20.20.20.0/24 é configurada apontando para o salto seguinte diretamente conectado 192.168.16.2. Com essa rota estática, uma sessão BGP com o peer Rtr-B 20.20.20.20 é estabelecida.

2. Rtr-B anuncia rotas BGP 172.16.1.0/24 e 20.20.20.20/32 para Rtr-A com seu endereço IP de loopback 20.20.20.20 como o próximo salto.

3. Rtr-A recebe rotas BGP anunciadas pelo Rtr-B e tenta instalar o 20.20.20.20/32. Isso é mais específico que 20.20.20.0/24, que já está configurado no Rtr-A como uma rota estática. Como a rota correspondente mais longa é a preferida, 20.20.20.20/32 é a preferida em relação a 20.20.20.0/24. Consulte Seleção de rota em roteadores Cisco para obter mais informações. A rota instalada 20.20.20.20/32 tem o próximo salto de 20.20.20.20 (endereço IP de peering do Rtr-B) na tabela de roteamento. Isso leva a uma falha de roteamento recursiva, já que a rota em direção a 20.20.20.20/32 possui um próximo salto dela mesma.

   Para entender o motivo por que o roteamento recursivo falha nessa situação específica, você precisa entender como o algoritmo de roteamento funciona. Para qualquer rota não diretamente conectada 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 20.20.20.20/32 não conectada diretamente com um próximo salto 20.20.20.20 (ele mesmo) não conectado diretamente. O algoritmo de roteamento é executado em uma falha de loop de roteamento recursivo porque ele não consegue encontrar nenhuma interface diretamente conectada para a qual enviar pacotes destinados a 20.20.20.20/32.

4. O roteador detecta que esta rota 20.20.20.20/32 conectada indiretamente tem uma falha de roteamento recursiva e retira 20.20.20.20/32 da tabela de roteamento. Consequentemente, todas as rotas aprendidas com BGP com o endereço IP do próximo salto 20.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 se emitir o comando debug ip routing.

   Observação: antes de executar qualquer comando debug, execute o comando debug em uma lista de controle de acesso (ACL) para 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 20.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 20.20.20.20/32 via 20.20.20.20, bgp metric [20/0]
   00:29:50: RT: add 172.16.1.0/24 via 20.20.20.20, bgp metric [20/0]
   00:30:45: RT: recursion error routing 20.20.20.20 - probable routing loop
   00:30:45: RT: recursion error routing 20.20.20.20 - probable routing loop
   00:30:45: RT: recursion error routing 20.20.20.20 - probable routing loop
   00:30:46: RT: recursion error routing 20.20.20.20 - probable routing loop
   00:30:46: RT: recursion error routing 20.20.20.20 - probable routing loop
   00:30:48: RT: recursion error routing 20.20.20.20 - probable routing loop
   00:30:48: RT: recursion error routing 20.20.20.20 - probable routing loop
   00:30:50: RT: del 20.20.20.20/32 via 20.20.20.20, bgp metric [20/0]
   00:30:50: RT: delete subnet route to 20.20.20.20/32
   00:30:50: RT: del 172.16.1.0/24 via 20.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 se deve à ocorrência de retransmissões TCP na rede habilitada para MPLS. Se uma mensagem de keepalive de BGP falhou uma vez ao ser enviada para o Peer de BGP porque o link de transporte está inativo, o Peer de BGP vizinho não aceita mais pacotes de keepalive mesmo que o TCP retransmita a mensagem com falha através do caminho de backup e, eventualmente, leva ao peer de BGP inativo com expiração de tempo de espera. Esse problema é observado somente quando o MPLS é configurado no Catalyst 6500 ou no Cisco 7600. Isso é discutido na ID de bug da Cisco CSCsj89544 (somente clientes registrados) .

Solução

As soluções para esse problema são explicadas nesses detalhes.

Adicione uma rota estática específica no Rtr-A para o endereço IP do peer BGP (20.20.20.20 neste caso).

RTR-A#configure terminal        
Enter configuration commands, one per line.  End with CNTL/Z.
RTR-A(config)#ip route 20.20.20.20 255.255.255.255 192.168.16.2

A configuração de uma rota estática para o prefixo 20.20.20.20/32 garante que uma rota BGP aprendida dinamicamente 20.20.20.20/32 não seja instalada na tabela de roteamento e, assim, 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 do EBGP são configurados para alcançar um ao outro com rotas padrão, a vizinhança do BGP não aparece. Isso é feito para evitar oscilações de rota e 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

Apagar rota

A atenuação de rota é um recurso BGP projetado para minimizar a propagação de rotas oscilantes através de uma internetwork. 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

Os comandos bgp dampening definem valores padrão para os parâmetros de atenuação como Meia hora= 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: Insufficient chunk pools for aspath"?
• Por que os vizinhos de BGP variam entre os estados Idle (Inativo), Connect (Conectado) e Active (Ativo)?
• Página de suporte de BGP
• Suporte Técnico e Documentação - Cisco Systems

Revision History