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.

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 r



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

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 655 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

546 Sign Ups in the last 30 days

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

Tags: , ,


Forum Replies

  1. Hi Rene,
    Your post is very informative bro…keep it up!!

    Would you please help me understand what you really mean by this rule #1?
    (Don’t advertise the tunnel destination IP address on the tunnel interface. Don’t advertise it or use route filtering.)

    What if you used the network connected to R2 as the destination IP? like:

    R1(config)#interface tunnel 1
    R1(config-if)#tunnel source fa0/0
    R1(config-if)#ip address 192.168.13.1 255.255.255.0
    R1(config-if)#tunnel destination 192.168.23.3
    

    -

    R3(config)#interface tunnel 1
    R3(config-if)#tunnel source Fa0/0
    R3(config-if)#
    ... Continue reading in our forum

  2. Hi Rene,
    Very interesting post and topics.

    please woul you give me more details on the 1st rule you listed to fix the issues? (Don’t advertise the tunnel destination IP address on the tunnel interface. Don’t advertise it or use route filtering)

    What if we set the tunnels this way below, would we have the same rr issue?

    R1(config)#interface tunnel 1
    R1(config-if)#tunnel source fa0/0
    R1(config-if)#ip address 192.168.13.1 255.255.255.0
    R1(config-if)#tunnel destination 192.168.23.3
    

    -

    R3(config)#interface tunnel 1
    R3(config-if)#tunnel source Fa0/0
    R3(config-if)#ip 
    ... Continue reading in our forum

  3. Hi Thom,

    In my example, R1 and R3 learn about each others tunnel destination IP address through R2 with a hop count of 2.

    Once the tunnel is established, they learn about each others destination IP address through the tunnel with a hop count of 1.

    Since 1 is a better metric than 2, they remove their entry from the routing table that points to R2 and insert an entry that points to the tunnel interface.

    The tunnel now collapses…because we are trying to reach the tunnel destination through the tunnel itself. The same problem will occur if you configure OSPF on the

    ... Continue reading in our forum

  4. Hi Rene, thank you for the excellent post.

    And if I’m running OSPF instead of RIP, how could I solve this situation since my tunnel has a lower cost than my physical interfaces?

    I tried to filter the tunnel destination address (LSA3) with distribute-list IN on the tunnel interface, but it didn’t work. Any idea?

    Thanks!

  5. I got “recursive routing” before applying the offset command.

    However ; I noted that traceroute works, before and after applying offset. It, also, displays the same result (below).

    **R1#traceroute 3.3.3.3**
    
    Type escape sequence to abort.
    Tracing the route to 3.3.3.3
    
      1 192.168.12.2 56 msec 8 msec 12 msec
      2 192.168.23.3 20 msec 20 msec 20 msec

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