Dépannage des routes BGP instables (échec du routage récursif)

Introduction

Ce document décrit comment effectuer le dépannage des routes instables de Border Gateway Protocol (BGP) provoquées par une panne récursive de routage. 

Conditions préalables

Exigences

Aucune exigence spécifique n'est associée à ce document.

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

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. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

Ce document décrit comment effectuer le dépannage des routes instables de Border Gateway Protocol (BGP) provoquées par une panne récursive de routage.

Les symptômes courants d'échec de routage récursif dans BGP sont :

• Suppression et réinsertion constantes des routes BGP dans la table de routage.

• Perte de connectivité vers les destinations apprises via BGP.

Référez-vous à ce diagramme de réseau lorsque vous utilisez ce document :

Diagramme du réseau

Référez-vous à ces configurations lorsque vous utilisez ce document :

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

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Problème

Symptômes

Ces deux symptômes sont observés lors d’une défaillance récursive du routage :

• Le battement continu des routes apprises par BGP dans la table de routage IP.

  Observez la table de routage en continu pendant quelques minutes afin de voir le battement.

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

Remarque : il est utile d'utiliser la commande show ip route | include, 00:00 afin d'observer les routes instables lorsque vous traitez de grandes tables de routage.

Après environ une minute d'attente, les résultats de la commande show ip route se transforment en ceci :

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

Remarque : les routes BGP sont manquantes dans la table de routage précédente.

• Lorsque les routes BGP sont présentes dans la table de routage, la connectivité à ces réseaux échoue.

  Afin d'observer ceci, quand la table de routage du Rtr-A a la route apprise par BGP 172.16.1.0/24 dans sa table de routage, une requête ping vers l'hôte valide 172.16.1.1 échoue.

  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#

Défaillance de routage récursif

Sur Rtr-A, observez la route vers l'homologue BGP 10.20.20.20. La route oscille entre les deux tronçons suivants toutes les minutes environ.

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 vers l'adresse IP de l'homologue BGP est apprise par le biais du protocole BGP lui-même ; elle crée donc une défaillance de routage récursive.

Après environ une minute, la route passe à :

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

Causes des échecs de routage récursifs

Les étapes suivantes décrivent la cause des échecs de routage récursif :

1. Reportez-vous à la configuration de Rtr-A. Dans cette configuration, une route statique 10.20.20.0/24 est configurée pour pointer vers le tronçon suivant directement connecté 192.168.16.2. Avec cette route statique, une session BGP avec l'homologue Rtr-B 10.20.20.20 est établie.

2. Rtr-B annonce les routes BGP 172.16.1.0/24 et 10.20.20.20/32 vers Rtr-A avec son adresse IP de bouclage 10.20.20.20 comme tronçon suivant.

3. Rtr-A reçoit les routes BGP annoncées par Rtr-B et tente d'installer le 10.20.20.20/32. Ceci est plus spécifique que 10.20.20.0/24, qui est déjà configuré dans Rtr-A comme route statique. Comme la route correspondante la plus longue est préférée, 10.20.20.20/32 est préférable à 10.20.20.0/24. Référez-vous à Sélection de route pour les routeurs Cisco pour plus d'informations. La route installée 10.20.20.20/32 a le tronçon suivant 10.20.20.20 (adresse IP d’appairage Rtr-B) dans la table de routage. Cela entraîne une défaillance de routage récursive, car la route vers 10.20.20.20/32 a un tronçon suivant de lui-même.

   Afin de comprendre la raison derrière l'échec du routage récursif dans cette situation particulière, vous devez comprendre comment l'algorithme de routage fonctionne. Pour toute route non connectée directement dans la table de routage dont l'adresse IP de tronçon suivant n'est pas une interface connectée directement du routeur, l'algorithme examine récursivement la table de routage jusqu'à ce qu'il trouve une interface connectée directement à laquelle il peut transférer les paquets.

   Dans cette situation particulière, Rtr-A apprend une route vers le réseau non directement connecté 10.20.20.20/32 avec un prochain saut non directement connecté de 10.20.20.20 (lui-même). L'algorithme de routage rencontre une défaillance de boucle de routage récursive, car il ne trouve aucune interface connectée directement à laquelle envoyer des paquets destinés à 10.20.20.20/32.

4. Le routeur détecte que cette route non connectée directement 10.20.20.20/32 présente un échec de routage récursif et retire 10.20.20.20/32 de la table de routage. Par conséquent, toutes les routes apprises par BGP avec l'adresse IP de tronçon suivant 10.20.20.20 sont également retirées de la table de routage.

5. L'ensemble du processus se répète à partir de l'étape 1. Vous pouvez le confirmer si vous émettez la commande debug ip routing.

   Remarque : avant d'exécuter une commande de débogage, exécutez la commande debug sur une liste de contrôle d'accès (ACL) pour un réseau spécifique afin de limiter la sortie de debug. Dans cet exemple, configurez une liste de contrôle d'accès afin de limiter la sortie de débogage.

   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. Si la récursivité de la route échoue continuellement, le message d'erreur suivant apparaît :

   %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

   Cela est dû aux retransmissions TCP qui se produisent sur le réseau compatible MPLS. Si un message de keepalive BGP a échoué une fois et est envoyé à l'homologue BGP parce que la liaison de transport est en panne, l'homologue BGP voisin n'accepte aucun autre paquet keepalive même si TCP retransmet le message en panne par le chemin de secours, et il conduit finalement à l'homologue BGP en panne avec l'expiration du délai de conservation. Ce problème se produit uniquement lorsque MPLS est configuré sur Catalyst6500 ou Cisco7600. Ces informations sont incluses dans l'ID de bogue Cisco CSCsj89544 .

   Remarque : seuls les utilisateurs Cisco enregistrés peuvent accéder aux informations de bogue internes et aux autres outils.

Solution

La ou les solutions à ce problème sont expliquées dans ces détails.

Ajoutez une route statique spécifique dans Rtr-A pour l'adresse IP de l'homologue BGP (10.20.20.20 dans ce cas).

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 configuration d'une route statique pour le préfixe 10.20.20.20/32 garantit qu'une route BGP apprise dynamiquement 10.20.20.20/32 n'est pas installée dans la table de routage et évite ainsi la situation de boucle de routage récursive. Référez-vous à Sélection de route pour les routeurs Cisco pour plus d'informations.

Remarque : lorsque des homologues EBGP sont configurés pour se joindre avec des routes par défaut, le voisinage BGP n'apparaît pas. Cela permet d’éviter les battements de route et les boucles de routage.

Une requête ping vers 172.16.1.1 confirme la solution.

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

Amortissement D'Itinéraire

L'amortissement de route est une fonctionnalité BGP conçue pour minimiser la propagation des routes instables sur un interréseau. Les valeurs recommandées par le FAI sont les valeurs par défaut sur Cisco IOS^® et il vous suffit de configurer cette commande pour l'activer.

router bgp <AS number>
 bgp dampening

La commande bgp dampening définit les valeurs par défaut des paramètres de mouillage, tels que Halftime= 15 minutes, reuse = 750, Suppress = 2000 et Max Suppress Time= 60. Ces valeurs peuvent être configurées par l'utilisateur, mais Cisco recommande de ne pas les modifier.

Informations connexes

• Que signifie le message d'erreur « #%BGP-3-INSUFCHUNKS : Pools de blocs insuffisants pour un chemin d'accès » ?
• Dépannage des problèmes de connexion de voisinage BGP
• Prise en charge du routage IP/BGP
• Assistance technique de Cisco et téléchargements