A mensagem de erro "%TUN-5-RECURDOWN" e os vizinhos EIGRP/OSPF/BGP oscilantes em um túnel GRE

Opções de download

  • PDF     (209.3 KB)
    Ver no Adobe Reader em vários dispositivos
  • ePub     (96.6 KB)
    Ver em vários aplicativos no iPhone, iPad, Android, Sony Reader ou Windows Phone
  • Mobi (Kindle)     (109.9 KB)
    Ver no dispositivo Kindle ou no aplicativo Kindle em vários dispositivos
Atualizado:11 de setembro de 2018
ID do documento:22327

Linguagem imparcial

O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.

Sobre esta tradução

A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.

Introduction

O %TUN-5-RECURDOWN: O túnel0 temporariamente desativado devido à mensagem de erro de roteamento recursivo significa que o roteador de túnel GRE (generic routing encapsulation) descobriu um problema de roteamento recursivo. Essa condição geralmente é devida a uma destas causas:

  • Um erro de configuração que faz com que o roteador tente rotear para o endereço destino do túnel usando a própria interface do túnel (roteamento recursivo)

  • Uma instabilidade temporária provocada por perda de sincronia de rotas em outro lugar na rede

O status da interface de túnel depende do alcance de IP para o destino do túnel. Quando o roteador detecta uma falha de roteamento recursiva para o destino do túnel, ele desliga a interface do túnel por alguns minutos para que a situação que está causando o problema possa se resolver enquanto os protocolos de roteamento convergem. Se o problema for causado por configuração incorreta, o link pode oscilar indefinidamente.

Outro sintoma deste problema é o Protocolo de encaminhamento de gateway interior melhorado (EIGRP) não sincronizado, Abrir caminho mais curto primeiro (OSPF) ou vizinhos de Protocolo de gateway de limite (BGP), quando os vizinhos estiverem em um túnel GRE.

Este documento mostra um exemplo de identificação e solução de problemas de uma interface de túnel oscilante que está executando o EIGRP.

Prerequisites

Requirements

Não existem requisitos específicos para este documento.

Componentes Utilizados

Este documento não é restrito a versões de software ou hardware específicas.

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. If your network is live, make sure that you understand the potential impact of any command.

Conventions

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

Diagrama de Rede

O roteador 1 (R1) e o roteador 3 (R3) estão conectados ao roteador 2 (R2). A conectividade de rede é tal que R1 pode acessar a interface de loopback de R3 por meio de R2 e vice-versa. O EIGRP está sendo executado na interface do túnel em R1 e R3. O R2 não faz parte do domínio EIGRP.

gre_flap_01.gif

Configurações

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

Observação

Observe essas mensagens de erro em R1 e R3. O estado da interface do túnel oscila continuamente entre up e down.

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

Observação: cada linha com carimbo de data e hora do exemplo de saída anterior aparece em uma linha na saída real.

Troubleshooting

Esta é a rota para o destino do túnel 10.3.3.3 em R1 antes da interface do túnel ser ativada:

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

O destino de túnel 10.3.3.3 toma a rota padrão através de 172.16.15.2 (Serial 0).

Agora, observe a tabela de roteamento após a interface do túnel subir, mostrada aqui:

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

A rota para o destino do túnel 10.3.3.3 é aprendida através do EIGRP e seu próximo salto é o túnel 0 da interface.

Nesta situação, o melhor caminho para o destino do túnel é através da interface do túnel; no entanto, isso ocorre:

  1. O pacote é colocado em fila na fila de saída da interface de túnel.

  2. A interface de túnel adiciona um cabeçalho de GRE ao pacote e enfileira o pacote para o protocolo de transporte destinado ao endereço de destino da interface de túnel.

  3. O IP procura a rota até o endereço de destino e aprende que é através da interface do túnel, que retorna o pacote para a Etapa 1 acima; então, há um circuito de roteamento recorrente.

Solução

Configure rotas estáticas para o destino do túnel em R1 e 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

Agora, observe a rota IP em R1, mostrada abaixo.

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

Para o destino de túnel, uma rota estática mais específica (10.3.3.3/32) é preferível a uma rota EIGPR conhecida menos específica (10.3.3.0/24). Esta rota estática mais específica impede o loop recursivo de roteamento, a não-sincronização da interface de túnel e, conseqüentemente, a não-sincronização dos vizinhos de 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

%Aviso: Recurso não suportado no hardware. Os pacotes de túnel serão comutados por software

A mensagem é vista quando o mesmo loopback ou endereço físico é usado como origem para dois túneis diferentes. Por causa disso, cada pacote vai para o processador, em vez de ser comutado por hardware.

Esse problema pode ser resolvido se você usar endereços secundários em uma interface de loopback ou se usar várias interfaces de loopback para os endereços origem do túnel.

O pacote hello do OSPF é enviado por um roteador sobre o túnel GRE, mas não chega na outra extremidade do túnel.

Em uma rede habilitada para OSPF, o roteador R1 envia o pacote de hello do OSPF pelo túnel GRE, mas ele não é recebido pelo roteador R3. Use o comando debug ip ospf hello para depurar os eventos de saudação. 

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.

Solução

Configure o comando tunnel key no túnel de interface 10 em ambos os roteadores. Esse comando habilita o multicast no GRE.

Informações Relacionadas

Histórico de revisões

Revisão Data de publicação Comentários
1.0
11-Sep-2018
Versão inicial

Este documento lhe foi útil?

FeedbackFeedback

Contate a Cisco