GRE Tunnel Recursive Routing Error

If you configured GRE tunneling before you might have encountered the following error:

%TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive routing

What happened is that your router has learned the destination IP address for the tunnel interface through the tunnel itself. As a result it removed the previous entry for the tunnel destination IP address from the routing table. Now the tunnel destination is no longer reachable and it collapses.

Let me demonstrate this to you because it will make a lot more sense…this is the topology that we will use:

recursive routing gre topology

Above we have 3 routers and the idea is to have a GRE tunnel between R1 and R3. I will first configure the IP addresses on the interfaces and use RIP so that R1 and R3 can reach each other:

R1(config)#interface fastEthernet 0/0           
R1(config-if)#ip address
R1(config)#interface loopback0
R1(config-if)#ip address
ISP(config)#interface fastEthernet 0/0
R2(config-if)#ip address
R2(config)#interface fastEthernet 1/0
R2(config-if)#ip address
Branch(config)#interface fastEthernet 0/0
R3(config-if)#ip address
R3(config)#interface loopback 0
R3(config-if)#ip address

Now let’s configure RIP on all routers:

R1(config)#router rip
R1(config-router)#version 2
R1(config-router)#no auto-summary 
R2(config)#router rip
R2(config-router)#version 2
R2(config-router)#no auto-summary 
R3(config)#router rip
R3(config-router)#version 2
R3(config-router)#no auto-summary 

The network commands above will ensure that R1 and R3 can reach each other. Now let’s create a tunnel interface between the loopback interfaces of R1 and R3:

R1(config)#interface tunnel 1
R1(config-if)#tunnel source loopback0
R1(config-if)#ip address
R1(config-if)#tunnel destination
R3(config)#interface tunnel 1
R3(config-if)#tunnel source loopback0
R3(config-if)#ip address
R3(config-if)#tunnel destination

This will enable the tunnel between R1 and R3’s loopback interfaces. I configured network /24 on the tunnel interface. Before we continue, let me show you the routing tables of R1 and R3:

R1#show ip route rip | include
R [120/2] via, 00:00:24, FastEthernet0/0
R3#show ip route rip | include
R [120/2] via, 00:00:17, FastEthernet0/0

Take a good look at the output above. R1 and R3 each have a hop count of 2 to reach each others loopback interface. Now we will enable RIP on the tunnel interface:

R1(config)#router rip
R3(config)#router rip

As soon as we enable RIP on the tunnel interface you’ll see this message on R1 and R3:

%TUN-5-RECURDOWN: Tunnel1 temporarily disabled due to recursive routing
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down

So what is going on here? Before I enabled RIP on the tunnel interface, R1 and R3 learned that they could reach each others loopback interface through R2 with a hop count of 2.

After activating RIP on the tunnel interface, R1 and R3 learn that they can reach each others loopback interface with a hop count of 1. As a result they will install this new information in the routing table and remove the old information. If you are quick you can catch it in the routing table just when the tunnel comes up. Here’s an example of R3:

R3#show ip route rip | include
R [120/1] via, 00:00:02, Tunnel1

Above you can see that R3 wants to reach through the tunnel interface with a hop count of 1. Trying to reach the tunnel destination through the tunnel is a little problematic…it’s a classic chicken and egg problem.

How do we solve this? You need to make sure that the router doesn’t reach the tunnel destination through the tunnel itself. There are a number of options to do this:

  • Don’t advertise the tunnel destination IP address on the tunnel interface. Don’t advertise it or use route filtering.
  • Make sure the administrative distance of the tunnel destination IP address through the tunnel is higher (worse) than what you have in the routing table now.
  • Make sure the metric to the tunnel destination IP address through the tunnel is worse than what you have in the routing table now.

I will use one of the techniques to solve the problem in our setup:

Digiprove sealCopyright protected by Digiprove © 2013-2018 Rene Molenaar

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You’ve Ever Spent on Your Cisco Career!
  • Full Access to our 745 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

553 Sign Ups in the last 30 days

100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags: , ,

Forum Replies

  1. Hi Rene

    Really liking you new website.
    I’m confused about this scenario though. Although I do understand the tunnel is being disabled but when you solve it using offset list to make the route through the tunnel seem worse than through the Fastethernet link, what is the point of being able to reach via the fast ethernet link. Does this defeat the object of a tunnel because you are reaching tunnel destination via the fast ethernet link?

    i hope i making sense.

  2. Hi Prash,

    This scenario is only to demonstrate why recursive routing errors occur. It happens when people advertise the IP addresses that are used for the tunnel interfaces through the tunnel itself. Normally this is just a configuration error that people might make. On the other hand you might encounter it on the CCIE lab exam :slight_smile:

  3. please check this ip entries (

47 more replies! Ask a question or join the discussion by visiting our Community Forum