IP : Protocole BGP (Border Gateway Protocol)

Dépannage de routes BGP alternantes (échec de routage récursif)

17 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


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.

Les symptômes communs de la panne récursive de routage dans le BGP sont :

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

  • Perte de connectivité vers des destinations apprises par le BGP.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Composants utilisés

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

Théorie générale

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

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

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

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

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

On observe ces deux symptômes avec la panne récursive de routage :

  • Le lien instable continu des artères BGP-instruites dans la table de Routage IP.

    Observez la table de routage continuellement pour des couples des minutes afin de voir le lien instable.

    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

    Remarque: Il est utile d'utiliser le show ip route | incluez, commande de 00:00 afin d'observer des routes instables quand vous traitez de grandes tables de routage.

    Après que vous attendiez approximativement une minute, les résultats de commande de show ip route changent à ceci :

    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

    Remarque: Les routes BGP manquent dans la table précédente de routage.

  • Quand 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-Un a l'artère BGP-instruite 172.16.1.0/24 dans sa table de routage, un ping à 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 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#

Panne récursive de routage

Sur le rtr-Un, observez l'artère vers le pair 20.20.20.20 BGP. L'artère s'agite entre les deux prochains sauts uniformément chaque minute ou ainsi.

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

L'artère vers l'adresse IP de pair BGP est apprise par BGP lui-même ; ainsi il crée une panne récursive de routage.

Après approximativement une minute, l'artère change à :

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

Qu'entraîne la panne récursive de routage ?

Ces étapes décrivent la cause des pannes récursives de routage :

  1. Référez-vous à la configuration du rtr-Un. Dans cette configuration, une artère statique 20.20.20.0/24 est indication configurée le prochain-saut directement connecté 192.168.16.2. Avec cette artère statique, une session BGP avec le rtr-b 20.20.20.20 de pair est établie.

  2. Le rtr-b annonce les routes BGP 172.16.1.0/24 et 20.20.20.20/32 au rtr-Un avec son adresse IP de bouclage 20.20.20.20 comme prochain-saut.

  3. Le rtr-Un reçoit des routes BGP annoncées par rtr-b et essais pour installer les 20.20.20.20/32. C'est plus spécifique que 20.20.20.0/24 qui est déjà configuré dans le rtr-Un comme artère statique. Puisque la plus longue artère assortie est préférée, 20.20.20.20/32 est préférés plus de 20.20.20.0/24. Référez-vous à Sélection de route pour les routeurs Cisco pour plus d'informations. L'artère installée 20.20.20.20/32 a le prochain-saut de 20.20.20.20 (l'adresse IP scrutante du Rtr-b) dans la table de routage. Ceci mène à la panne récursive de routage puisque l'artère vers 20.20.20.20/32 a un prochain-saut de elle-même.

    Afin de comprendre la raison derrière pourquoi le routage récursif échoue dans cette situation particulière, vous devez comprendre comment l'algorithme de routage fonctionne. Pour n'importe quelle artère nondirectly-connectée dans la table de routage dont la prochaine adresse IP de saut n'est pas une interface directement connectée du routeur, l'algorithme regarde périodiquement dans la table de routage jusqu'à ce qu'il trouve une interface directement connectée à laquelle il peut expédier les paquets.

    Dans cette situation particulière, le rtr-Un apprend une artère au réseau nondirectly-connecté 20.20.20.20/32 avec un prochain saut nondirectly-connecté de 20.20.20.20 (lui-même). L'algorithme de routage fonctionne dans une panne récursive de boucle de routage parce qu'il ne peut pas trouver n'importe quelle interface directement connectée à laquelle pour envoyer des paquets a destiné pour 20.20.20.20/32.

  4. Le routeur détecte que cette artère nondirectly-connectée 20.20.20.20/32 a une panne récursive de routage et retire 20.20.20.20/32 de la table de routage. En conséquence, toutes les artères BGP-instruites avec la prochaine adresse IP 20.20.20.20 de saut sont également retirées de la table de routage.

  5. Les répétitions entières de processus de l'étape 1. Vous pouvez confirmer ceci si vous émettez la commande de Routage IP de débogage.

    Remarque: Avant que vous exécutiez n'importe quelle commande de débogage, exécutez la commande de débogage contre une liste de contrôle d'accès (ACL) pour un réseau spécifique afin de limiter la sortie de mettent au point. Dans cet exemple, configurez un ACL afin de limiter la sortie de débogage.

    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. Si la récursion d'artère échoue continuellement, alors ce message d'erreur 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

    C'est dû aux retransmissions de TCP se produisent sur le réseau activé par MPLS. Si un message de keepalive BGP une fois n'est pas envoyé au pair BGP parce que la relation de transport est en baisse, le pair BGP de voisin ne reçoit pas tout autre paquet keepalive quoique le TCP retransmette le message défectueux par le chemin de sauvegarde, et il mène par la suite au pair BGP vers le bas avec l'expiration de holdtime. Cette question est vue seulement quand le MPLS est configuré sur Catalyst6500 ou Cisco7600. Ceci est discuté dans l'ID de bogue Cisco CSCsj89544 (clients enregistrés seulement).

Solution

La solution au problème sont expliquées dans ces derniers détail.

Ajoutez une artère statique spécifique dans le rtr-Un pour l'adresse IP de pair BGP (20.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 20.20.20.20 255.255.255.255 192.168.16.2

La configuration d'une artère statique pour le préfixe 20.20.20.20/32 s'assure qu'une route BGP dynamique-instruite 20.20.20.20/32 n'obtient pas installé dans la table de routage et évite ainsi la situation récursive de boucle de routage. Référez-vous à Sélection de route pour les routeurs Cisco pour plus d'informations.

Remarque: Quand des pairs EBGP sont configurés pour s'atteindre avec des default route, la proximité BGP n'apparaît pas. Ceci est fait afin d'éviter le lien instable et les boucles de routage d'artère.

Un ping à 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

Atténuation de la route

L'atténuation de la route est une fonctionnalité conçue BGP pour réduire la propagation des routes instables à travers un interréseau. Les valeurs l'ISP recommandé sont les par défaut sur le Ý de Cisco IOS et vous devez seulement configurer cette commande afin de l'activer.

router bgp <AS number>
 bgp dampening

Les valeurs par défaut de commandsets de bgp dampening pour les paramètres d'atténuation tels que Halftime= 15 minutes, réutilisation = 750, suppriment = 2000 et maximum supprimez Time= 60. Ces valeurs sont utilisateur configurable mais Cisco recommande qu'il reste sans changement.

Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 19167