IP : Border Gateway Protocol (BGP)

Pesquisar defeitos rotas de BGP do flapping (falha de roteamento recursivo)

15 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


Introdução

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

Os sintomas comuns da falha de roteamento recursivo no BGP são:

  • Exclusão constante e reinserção das rotas de BGP na tabela de roteamento.

  • Perda de conectividade para os destinos aprendidos com o BGP.

Pré-requisitos

Requisitos

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.

/image/gif/paws/19167/bgp-rec-routing-a.gif

Refira estas configurações como você usa 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 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

Rtr-b
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
!

Convenções

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

Problema

Sintomas

Estes 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 para pares de minutos a fim ver o flapping.

    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

    Nota: É útil usar a rota da mostra IP | inclua, comando 00:00 a fim observar rotas não sincronizadas quando você trata as grandes tabelas de roteamento.

    Depois que você espera aproximadamente um minuto, os resultados do comando show ip route mudam a 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

    Nota: As rotas de BGP faltam na tabela de roteamento precedente.

  • Quando as rotas BGP estão presentes na tabela de roteamento, a conectividade com essas redes falha.

    A fim observar isto, quando a tabela de roteamento do Rtr-a tem a rota aprendido a rota de BGP 172.16.1.0/24 em sua tabela de roteamento, um sibilo ao 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 para o bgp peer 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 de Um ou Mais Servidores Cisco ICM NT do bgp peer é instruída com BGP próprio; assim cria uma falha de roteamento recursivo.

Após aproximadamente um minuto, as alterações de rota a:

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. Refira a configuração do Rtr-a. Nesta configuração, uma rota estática 20.20.20.0/24 é apontar configurado ao salto seguinte diretamente conectado 192.168.16.2. Com esta rota estática, uma sessão de BGP com Rtr-b 20.20.20.20 do par é 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. O Rtr-a recebe as rotas de BGP anunciadas pelo Rtr-b e tenta-as instalar os 20.20.20.20/32. Isto é mais específico de 20.20.20.0/24 que é configurado já no Rtr-a como uma rota estática. Porque a rota de harmonização a mais longa é preferida, 20.20.20.20/32 são preferidos sobre 20.20.20.0/24. Refira a seleção de rota nos roteadores Cisco para mais informação. A rota instalada 20.20.20.20/32 tem o salto seguinte de 20.20.20.20 (o endereço IP de Um ou Mais Servidores Cisco ICM NT espreitando 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.

    A fim compreender a razão atrás de porque o roteamento recursivo falha nesta situação particular, você precisa de compreender como o algoritmo de roteamento trabalha. Para toda a rota não conectada diretamente na tabela de roteamento cujo o endereço IP de Um ou Mais Servidores Cisco ICM NT do salto seguinte não é uma interface conectada diretamente do roteador, o algoritmo olha recursively na tabela de roteamento até que encontre uma interface conectada diretamente a que pode enviar os pacotes.

    Nesta situação particular, o Rtr-a aprende uma rota à rede nondirectly-conectada 20.20.20.20/32 com um salto seguinte nondirectly-conectado de 20.20.20.20 (próprio). O algoritmo de roteamento é executado em uma falha do loop de roteamento recursivo porque é incapaz de encontrar toda a interface conectada diretamente a que para enviar pacotes destine para 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 aprendidos a rota de BGP com o endereço IP 20.20.20.20 do salto seguinte são retiradas igualmente da tabela de roteamento.

  5. As repetições do processo inteiro de etapa 1. Você pode confirmar este se você emite o comando debug ip routing.

    Nota: Antes que você execute todo o comando debug, execute o comando debug contra um Access Control List (ACL) para uma rede específica a fim limitar a saída de debugam. Neste exemplo, configurar um ACL a fim limitar o resultado do debug.

    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 falha continuamente, a seguir este Mensagem de Erro aparece:

    %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

    Isto é devido às retransmissões de TCP ocorre na rede permitida MPLS. Se um mensagem de keepalive BGP uma vez não é enviado ao bgp peer porque o link de transporte está para baixo, o bgp peer vizinho não aceita nenhuns pacotes keepalive mais adicionais mesmo que o TCP retransmita a falha de mensagem através do caminho backup, e conduz eventualmente ao bgp peer para baixo com expiração do holdtime. Esta edição é considerada somente quando o MPLS é configurado em Catalyst6500 ou em Cisco7600. Isto é discutido na identificação de bug Cisco CSCsj89544 (clientes registrados somente).

Solução

As soluções a este problema são explicadas nestes detalhe.

Adicionar uma rota estática específica no Rtr-a para o endereço IP de Um ou Mais Servidores Cisco ICM NT do bgp peer (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 assegura-se de que uma rota de BGP dinâmico-instruída 20.20.20.20/32 não obtenha instalada na tabela de roteamento e evite assim a situação do loop de roteamento recursivo. Refira a seleção de rota nos roteadores Cisco para mais informação.

Nota: Quando os pares EBGP são configurados para se alcançar com rotas padrão, a vizinhança de BGP não aparece. Isto é feito a fim evitar a não sincronismo de rota e os loop de roteamento.

Um sibilo a 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

Retardar da rota

O retardar da rota é uma característica BGP projetada minimizar a propagação das rotas não sincronizadas através de uma rede interna. Os valores o ISP recomendado são os padrões no½ do¿Â do Cisco IOSï e você precisa somente de configurar este comando a fim permiti-lo.

router bgp <AS number>
 bgp dampening

Os valores padrão de umedecimento dos commandsets BGP para os parâmetros de umedecimento tais como Halftime= 15 minutos, reutilização = 750, suprimem = 2000 e máximo suprima Time= 60. Estes valores são usuário configurável mas Cisco recomenda que permanece inalterado.


Informações Relacionadas


Document ID: 19167