IP : Protocole EIGPR (Enhanced Interior Gateway Routing Protocol)

Message d'erreur « %TUN-5-RECURDOWN » et affolement des voisins EIGRP/OSPF/BGP sur un tunnel GRE

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


Contenu


Introduction

Le %TUN-5-RECURDOWN : Tunnel0 a temporairement désactivé en raison du message d'erreur récursif de routage signifie que le routeur de tunnel d'Encapsulation de routage générique (GRE) a découvert un problème récursif de routage. Cette condition est habituellement due à une de ces causes :

  • Une mauvaise configuration qui fait essayer le routeur de conduire à l'adresse de destination de tunnel utilisant l'interface de tunnel elle-même (le routage récursif)

  • Une instabilité provisoire provoquée par l'artère s'agitant ailleurs dans le réseau

L'état d'interface de tunnel dépend de l'accessibilité par IP à la destination de tunnel. Quand le routeur détecte une panne récursive de routage pour la destination de tunnel, elle ferme l'interface de tunnel pendant quelques minutes de sorte que la situation posant le problème puisse se résoudre pendant que les protocoles de routage convergent. Si le problème est provoqué par par mauvaise configuration, le lien peut osciller indéfiniment.

Un autre symptôme de ce problème est continuellement les voisins instables de Protocole EIGPR (Enhanced Interior Gateway Routing Protocol), de Protocole OSPF (Open Shortest Path First), ou de Protocole BGP (Border Gateway Protocol), quand les voisins sont au-dessus d'un tunnel GRE.

Ce document affiche un exemple de dépanner une interface de tunnel de oscillation qui exécute l'EIGRP.

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 ou de logiciel spécifiques.

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Conventions

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

Diagramme du réseau

Le routeur 1 (R1) et Routeur3 (R3) sont connectés au Router2 (R2). La connexion réseau est telle que R1 peut atteindre l'interface de bouclage R3 par R2 et vice versa. L'EIGRP s'exécute au-dessus de l'interface de tunnel sur R1 et R3. R2 n'est pas une partie du domaine EIGRP.

/image/gif/paws/22327/gre_flap_01.gif

Configurations

R1
hostname R1
!
interface Loopback0
 ip address 10.1.1.1 255.255.255.0
!
interface Tunnel0
 ip address 192.168.1.1 255.255.255.0
 tunnel source Loopback0
 tunnel destination 10.3.3.3
!
interface Serial0
 ip address 172.16.15.1 255.255.255.0
 encapsulation ppp
!
router eigrp 1
 network 10.1.1.0 0.0.0.255
 network 192.168.1.0
 no auto-summary
!
ip route 0.0.0.0 0.0.0.0 172.16.15.2

R3
hostname R3
!
interface Loopback0
 ip address 10.3.3.3 255.255.255.0
!
interface Tunnel0
 ip address 192.168.1.3 255.255.255.0
 tunnel source Loopback0
 tunnel destination 10.1.1.1
!
interface Serial1
 ip address 172.16.25.3 255.255.255.0
!
router eigrp 1
 network 10.3.3.0 0.0.0.255
 network 192.168.1.0
 no auto-summary
!
ip route 0.0.0.0 0.0.0.0 172.16.25.2

Observation

Observez ces messages d'erreur sur R1 et R3. L'état de l'interface de tunnel oscille continuellement entre en haut et en bas.

01:11:39: %LINEPROTO-5-UPDOWN:
          Line protocol on Interface Tunnel0, changed state to up
01:11:48: %TUN-5-RECURDOWN:
          Tunnel0 temporarily disabled due to recursive routing
01:11:49: %LINEPROTO-5-UPDOWN:
          Line protocol on Interface Tunnel0, changed state to down
01:12:49: %LINEPROTO-5-UPDOWN:
          Line protocol on Interface Tunnel0, changed state to up
01:12:58: %TUN-5-RECURDOWN:
          Tunnel0 temporarily disabled due to recursive routing
01:12:59: %LINEPROTO-5-UPDOWN:
          Line protocol on Interface Tunnel0, changed state to down

Remarque: Chaque ligne horodatée de sortie précédente d'exemple apparaît sur une ligne dans la sortie réelle.

Dépannage

C'est l'artère pour percer un tunnel la destination 10.3.3.3 sur R1 avant que l'interface de tunnel monte :

R1# 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 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is 172.16.15.2 to network 0.0.0.0

     172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C       172.16.15.2/32 is directly connected, Serial0
C       172.16.15.0/24 is directly connected, Serial0
     10.0.0.0/24 is subnetted, 1 subnets
C       10.1.1.0 is directly connected, Loopback0
S*   0.0.0.0/0 [1/0] via 172.16.15.2

La destination 10.3.3.3 de tunnel enlève le default route par 172.16.15.2 (interface série 0).

Maintenant, observez la table de routage après que l'interface de tunnel monte, affichée ici :

R1# 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 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is 172.16.15.2 to network 0.0.0.0

     172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
D       172.16.25.0/24 [90/297756416] via 192.168.1.3, 00:00:00, Tunnel0
C       172.16.15.2/32 is directly connected, Serial0
C       172.16.15.0/24 is directly connected, Serial0
     10.0.0.0/24 is subnetted, 2 subnets
D       10.3.3.0 [90/297372416] via 192.168.1.3, 00:00:00, Tunnel0
C       10.1.1.0 is directly connected, Loopback0
C    192.168.1.0/24 is directly connected, Tunnel0
S*   0.0.0.0/0 [1/0] via 172.16.15.2

L'artère pour percer un tunnel la destination 10.3.3.3 est apprise par l'EIGRP, et son prochain saut est l'interface tunnel 0.

Dans cette situation, le meilleur chemin à la destination de tunnel est par l'interface de tunnel ; cependant, ceci se produit :

  1. Le paquet est aligné dans la file d'attente de sortie de l'interface de tunnel.

  2. L'interface de tunnel ajoute une en-tête GRE au paquet et aligne le paquet au protocole de transport destiné à l'adresse de destination de l'interface de tunnel.

  3. Les consultations IP l'artère à l'adresse de destination et apprend qu'elle est par l'interface de tunnel, qui renvoie le paquet à l'étape 1 ci-dessus ; par conséquent, il y a une boucle de routage récursive.

Solution

Configurez les artères statiques pour la destination de tunnel sur R1 et R3.

R1(config)# ip route 10.3.3.3 255.255.255.255  serial 0
R3(config)# ip route 10.1.1.1 255.255.255.255 serial 1

Maintenant, observez l'artère IP sur R1, affiché ci-dessous.

R1# 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 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is 172.16.15.2 to network 0.0.0.0

     172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
D       172.16.25.0/24 [90/297756416] via 192.168.1.3, 00:01:08, Tunnel0
C       172.16.15.2/32 is directly connected, Serial0
C       172.16.15.0/24 is directly connected, Serial0
     10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
S       10.3.3.3/32 is directly connected, Serial0
D       10.3.3.0/24 [90/297372416] via 192.168.1.3, 00:01:08, Tunnel0
C       10.1.1.0/24 is directly connected, Loopback0
C    192.168.1.0/24 is directly connected, Tunnel0
S*   0.0.0.0/0 [1/0] via 172.16.15.2

Plus d'artère statique spécifique (10.3.3.3/32) est préférable à moins de route apprise de la particularité EIGRP (10.3.3.0/24) pour la destination de tunnel. Cette plus d'artère statique spécifique évite la boucle de routage récursive, l'interface de tunnel instable, et, par conséquent, le lien instable des voisins EIGRP.

R1# show interfaces tunnel 0
Tunnel0 is up, line protocol is up
  Hardware is Tunnel
  Internet address is 192.168.1.1/24
  MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive set (10 sec)
  Tunnel source 10.1.1.1 (Loopback0), destination 10.3.3.3

%Warning : Caractéristique non prise en charge dans le matériel. Les paquets de tunnel seront logiciel commuté

Le message est vu quand le même bouclage ou adresse physique est utilisé comme source pour deux tunnels différents. En raison de ceci, chaque paquet va au processeur, au lieu d'être matériel commuté.

Ce problème peut être résolu si vous utilisez des adresses secondaires sur une interface de bouclage ou si vous utilisez de plusieurs interfaces de bouclage pour les adresses de source du tunnel.

Le paquet HELLO OSPF est envoyé par un routeur au-dessus de tunnel GRE mais il ne fait pas arrive sur l'autre extrémité du tunnel.

Dans un OSPF activé le réseau, le routeur R1 envoie le paquet HELLO OSPF au-dessus du tunnel GRE mais il n'est pas reçu par le routeur R3. Employez la commande OSPF d'IP de débogage bonjour afin de mettre au point bonjour les événements.

R1#debug ip ospf hello
May 31 13:58:29.675 EDT: OSPF: Send hello to 224.0.0.5 area 0.0.0.12 on Tunnel0 from 192.168.1.1
May 31 13:58:39.675 EDT: OSPF: Send hello to 224.0.0.5 area 0.0.0.12 on Tunnel0 from 192.168.1.1
May 31 13:58:49.675 EDT: OSPF: Send hello to 224.0.0.5 area 0.0.0.12 on Tunnel0 from 192.168.1.1


R3#debug ip ospf hello
May 31 15:02:07 ADT: OSPF: Send hello to 224.0.0.5 area 0.0.0.12 on Tunnel0 from 192.168.1.3
May 31 15:02:09 ADT: OSPF: Rcv hello from 172.16.15.1 area 0.0.0.12 from Tunnel0 192.168.1.1
May 31 15:02:09 ADT: OSPF: Send immediate hello to nbr 172.16.15.3, src address 192.168.1.3, on Tunnel0
May 31 15:02:09 ADT: OSPF: Send hello to 224.0.0.5 area 0.0.0.12 on Tunnel0 from 192.168.1.3

!--- The previous output shows that the hello packets
!--- re sent by R1 but not received by R3.

Solution

Configurez la commande de tunnel key sur l'interface tunnel 10 sur les les deux les Routeurs. Cette Multidiffusion de commandes enables sur GRE.

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: 22327