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:

Above, we have three 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 192.168.12.1 255.255.255.0
R1(config-if)#exit
R1(config)#interface loopback0
R1(config-if)#ip address 1.1.1.1 255.255.255.255
R1(config-if)#exit

ISP(config)#interface fastEthernet 0/0
R2(config-if)#ip address 192.168.12.2 255.255.255.0
R2(config-if)#exit
R2(config)#interface fastEthernet 1/0
R2(config-if)#ip address 192.168.23.2 255.255.255.0

Branch(config)#interface fastEthernet 0/0
R3(config-if)#ip address 192.168.23.3 255.255.255.0
R3(config-if)#exit
R3(config)#interface loopback 0
R3(config-if)#ip address 3.3.3.3 255.255.255.255
R3(config-if)#exit

Now let’s configure RIP on all routers:

R1(config)#router rip
R1(config-router)#version 2
R1(config-router)#no auto-summary 
R1(config-router)#network 192.168.12.0
R1(config-router)#network 1.0.0.0

R2(config)#router rip
R2(config-router)#version 2
R2(config-router)#no auto-summary 
R2(config-router)#network 192.168.12.0
R2(config-router)#network 192.168.23.0

R3(config)#router rip
R3(config-router)#version 2
R3(config-router)#no auto-summary 
R3(config-router)#network 192.168.23.0
R3(config-router)#network 3.0.0.0

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 192.168.13.1 255.255.255.0
R1(config-if)#tunnel destination 3.3.3.3

R3(config)#interface tunnel 1
R3(config-if)#tunnel source loopback0
R3(config-if)#ip address 192.168.13.3 255.255.255.0
R3(config-if)#tunnel destination 1.1.1.1

This will enable the tunnel between R1 and R3’s loopback interfaces. I configured network 192.168.13.0 /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 3.3.3.3
R       3.3.3.3 [120/2] via 192.168.12.2, 00:00:24, FastEthernet0/0

R3#show ip route rip | include 1.1.1.1
R       1.1.1.1 [120/2] via 192.168.23.2, 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 other’s loopback interface. Now we will enable RIP on the tunnel interface:

R1(config)#router rip
R1(config-router)#network 192.168.13.0

R3(config)#router rip
R3(config-router)#network 192.168.13.0

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 they could reach each other’s loopback interface through R2 with a hop count of 2.

After activating RIP on the tunnel interface, R1 and R3 learn they can reach each other’s 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 when the tunnel comes up. Here’s an example of R3:

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

Above, you can see that R3 wants to reach 1.1.1.1 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 ensure the router doesn’t reach the tunnel destination through the tunnel itself. There are some 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: