Risoluzione dei problemi relativi allo scaricamento delle route BGP (errore di routing ricorsivo)

Introduzione

In questo documento viene descritto come risolvere i problemi relativi a route Border Gateway Protocol (BGP) instabili a causa di un errore di routing ricorsivo. 

Prerequisiti

Requisiti

Nessun requisito specifico previsto per questo documento.

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Premesse

In questo documento viene descritto come risolvere i problemi relativi a route Border Gateway Protocol (BGP) instabili a causa di un errore di routing ricorsivo.

I sintomi comuni di errore di routing ricorsivo in BGP sono:

• Eliminazione e reinserimento costanti delle route BGP nella tabella di routing.

• Perdita di connettività verso le destinazioni appresa tramite BGP.

Per ulteriori informazioni, fare riferimento al diagramma di rete seguente:

Esempio di rete

Durante l'uso del presente documento, consultare le seguenti configurazioni:

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
!

Convenzioni

Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.

Problema

Sintomi

Questi due sintomi vengono osservati con un errore di routing ricorsivo:

• Il flapping continuo delle route apprese da BGP nella tabella di routing IP.

  Osservare ininterrottamente la tabella di routing per alcuni minuti per verificare il 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

     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

Nota: è utile usare il comando show ip route | includere il comando 00:00 per osservare le route flapping quando si utilizzano tabelle di routing di grandi dimensioni.

Dopo circa un minuto di attesa, i risultati del comando show ip route vengono modificati nel modo seguente:

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

Nota: le route BGP non sono presenti nella tabella di routing precedente.

• Quando le route BGP sono presenti nella tabella di routing, la connettività a tali reti non riesce.

  A tal fine, quando la tabella di routing dell'router A ha la route 172.16.1.0/24 appresa da BGP nella relativa tabella di routing, il ping tra l'host valido 172.16.1.1 e l'operazione non riesce.

  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#

Errore di routing ricorsivo

Sull'Rtr-A, osservare il percorso verso il peer BGP 10.20.20.20. Il percorso esegue il flap tra i due hop successivi in modo coerente ogni minuto o giù di lì.

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

La route verso l'indirizzo IP del peer BGP viene appresa tramite BGP stesso; in questo modo, viene creato un errore di routing ricorsivo.

Dopo circa un minuto, il percorso diventa:

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

Cause degli errori di routing ricorsivo

La procedura seguente descrive la causa degli errori di routing ricorsivo:

1. Fare riferimento alla configurazione di Rtr-A. In questa configurazione, viene configurato un percorso statico 10.20.20.0/24 che punti all'hop successivo connesso direttamente 192.168.16.2. Con questa route statica, viene stabilita una sessione BGP con router-B 10.20.20.20 peer.

2. Rtr-B annuncia le route BGP 172.16.1.0/24 e 10.20.20.20/32 verso Rtr-A con l'indirizzo IP di loopback 10.20.20.20 come hop successivo.

3. Rtr-A riceve le route BGP annunciate da Rtr-B e tenta di installare 10.20.20.20/32. Questa configurazione è più specifica di 10.20.20.0/24, che è già configurata in Rtr-A come route statica. Poiché si preferisce la route corrispondente più lunga, 10.20.20.20/32 è preferibile rispetto a 10.20.20.0/24. per ulteriori informazioni, fare riferimento a Selezione router in Cisco Router. Il router 10.20.20.20/32 installato ha un hop successivo di 10.20.20.20 (indirizzo IP peer Rtr-B) nella tabella di routing. Questo porta a un errore di routing ricorsivo perché il percorso verso la 10.20.20.20/32 ha un hop successivo.

   Per comprendere la ragione per cui il routing ricorsivo fallisce in questa particolare situazione, è necessario capire come funziona l'algoritmo di routing. Per qualsiasi percorso nella tabella di routing non connesso direttamente il cui indirizzo IP dell'hop successivo non sia un'interfaccia del router connessa direttamente, l'algoritmo cerca in modo ricorsivo nella tabella di routing fino a trovare un'interfaccia connessa direttamente a cui inoltrare i pacchetti.

   In questa particolare situazione, Rtr-A apprende un percorso verso la rete non connessa direttamente 10.20.20.20/32 con un hop successivo non connesso direttamente 10.20.20.20 (stesso). L'algoritmo di routing viene eseguito in un errore di loop di routing ricorsivo perché non è in grado di trovare un'interfaccia connessa direttamente a cui inviare i pacchetti destinati alla versione 10.20.20.20/32.

4. Il router rileva che la route 10.20.20.20/32 non connessa direttamente ha un errore di routing ricorsivo e ritira il file 10.20.20.20/32 dalla tabella di routing. Di conseguenza, anche tutte le route apprese dal protocollo BGP con indirizzo IP 10.20.20.20 dell'hop successivo vengono ritirate dalla tabella di routing.

5. L'intero processo si ripete dal Passaggio 1. Per verificare questa condizione, usare il comando debug ip routing.

   Nota:prima di eseguire un comando di debug, eseguire il comando debug su un elenco di controllo di accesso (ACL) per una rete specifica per limitare l'output del comando di debug. In questo esempio, configurare un ACL per limitare l'output del debug.

   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 la ricorsione della route non riesce in modo continuo, viene visualizzato questo messaggio di errore:

   %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

   Ciò è dovuto alle ritrasmissioni TCP che si verificano sulla rete abilitata per MPLS. Se un messaggio keepalive BGP ha avuto esito negativo una volta e viene inviato al peer BGP perché il collegamento di trasporto non è attivo, il peer BGP adiacente non accetta altri pacchetti keepalive anche se il protocollo TCP trasmette nuovamente il messaggio con errore tramite il percorso di backup e infine porta il peer BGP in stato di inattività con scadenza del tempo di attesa. Questo problema si verifica solo quando MPLS è configurato su Catalyst 6500 o Cisco 7600. Queste informazioni sono contenute nell'ID bug Cisco CSCsj89544.

   Nota: solo gli utenti Cisco registrati possono accedere alle informazioni interne sui bug e ad altri strumenti.

Soluzione

Le soluzioni a questo problema sono spiegate in questi dettagli.

Aggiungere una route statica specifica in Rtr-A per l'indirizzo IP del peer BGP (in questo caso 10.20.20.20).

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

La configurazione di una route statica per il prefisso 10.20.20.20/32 assicura che una route BGP 10.20.20.20/32 appresa in modo dinamico non venga installata nella tabella di routing, evitando così la situazione di loop di routing ricorsivo. per ulteriori informazioni, fare riferimento a Selezione router in Cisco Router.

Nota: quando i peer EBGP sono configurati per comunicare tra loro con le route predefinite, il protocollo BGP adiacente non viene visualizzato. Questa operazione viene eseguita per evitare il flapping della route e i loop di routing.

Un ping su 172.16.1.1 conferma la soluzione.

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

Attenuazione route

L'attenuazione dell'impatto dei cambi di percorso è una funzione BGP progettata per ridurre al minimo la propagazione dei cambi di percorso su una rete Internet. I valori consigliati dall'ISP sono quelli predefiniti su Cisco IOS^® e per abilitarlo è necessario configurare solo questo comando.

router bgp <AS number>
 bgp dampening

Il comando di smorzamento gbp imposta i valori predefiniti per i parametri di smorzamento, ad esempio Halftime= 15 minuti, reuse = 750, Suppress = 2000 e Max Suppress Time= 60. Questi valori sono configurabili dall'utente, ma Cisco consiglia di mantenerli invariati.

Informazioni correlate

• Qual è il significato del messaggio di errore "#%BGP-3-INSUFCHUNKS: Insufficient chunk pools for aspath" (Pool di blocchi insufficienti per aspath)?
• Risoluzione dei problemi di connessione delle risorse BGP
• Routing IP/supporto BGP
• Supporto tecnico Cisco e download