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:
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 1.1.1.1/24 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.
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
please check this ip entries (3.3.3.3)
What about it?
Thank you boss