Why? %TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive routin

Unanswered Question
Sep 12th, 2008
User Badges:


I have a pretty normal two-site GRE tunnel that I want to set up


site1: (10.1.0.0/24 LAN)

interface Tunnel0

ip address 192.168.199.1 255.255.255.252

keepalive 10 3

tunnel source FastEthernet0

tunnel destination x.x.x.x


site2: (10.4.0.0/24 LAN)

interface Tunnel0

ip address 192.168.199.2 255.255.255.252

keepalive 10 3

tunnel source FastEthernet0

tunnel destination y.y.y.y


The tunnel is up and I can PING either side's 192.168.199.x address from the other side.

So far, so good.


I have NO dynamic routing protocols running

But when I put in the static "ip route" statements, to get traffic from one LAN to another...


site1: (10.1.0.0/24 LAN)

ip route 10.4.0.0 255.255.255.0 192.168.199.2


site2: (10.4.0.0/24 LAN)

ip route 10.1.0.0 255.255.255.0 192.168.199.1


I get the dreaded "%TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive routing"

error and the tunnel shuts down.


Any ideas on what I'm doing wrong?


Here's the "show ip route" output from site1:

Gateway of last resort is x.x.x.x to network 0.0.0.0


x.x.x.0/30 is subnetted, 1 subnets

C x.x.x.x is directly connected, FastEthernet0

192.168.199.0/30 is subnetted, 1 subnets

C 192.168.199.0 is directly connected, Tunnel0

10.0.0.0/24 is subnetted, 2 subnets

C 10.1.0.0 is directly connected, Vlan1

S 10.4.0.0 [1/0] via 192.168.199.2

S* 0.0.0.0/0 [1/0] via x.x.x.x

CalgaryRTR#


site2 "show ip route" is similar.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
singhsaju Fri, 09/12/2008 - 10:49
User Badges:
  • Silver, 250 points or more

Your tunnel is probably learning the tunnel destination through the tunnel .


site1: (10.1.0.0/24 LAN)

ip route 10.4.0.0 255.255.255.0 192.168.199.2


site2: (10.4.0.0/24 LAN)

ip route 10.1.0.0 255.255.255.0 192.168.199.1


Does the tunnel destination addresses x.x.x.x part of 10.4.0.0 address ? or y.y.y.y part of

10.1.0.0?




thomasdzubin Fri, 09/12/2008 - 11:06
User Badges:

Nope, x.x.x.x and y.y.y.y are regular public Internet addresses (one begins with 209 and the other with 64...so they aren't even on the same class-A subnet)


ullasupendran Fri, 09/12/2008 - 11:01
User Badges:

one more thing you keep in mind is, if the Fa0 is having the 10.4.0.0/24 IP then thats the issue.If thats the case change the tunnel source to the WAN interface.

thomasdzubin Fri, 09/12/2008 - 11:07
User Badges:

Nope, The FastEthernet0 IP addresses x.x.x.x and y.y.y.y are regular public Internet addresses (one begins with 209 and the other with 64...so they aren't even on the same class-A subnet)

ullasupendran Fri, 09/12/2008 - 11:16
User Badges:

Try this option and let me know


site1: (10.1.0.0/24 LAN)

ip route 10.4.0.0 255.255.255.0 Tunnel0


site2: (10.4.0.0/24 LAN)

ip route 10.1.0.0 255.255.255.0 Tunnel0

Richard Burts Fri, 09/12/2008 - 11:12
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Thomas


It might be interesting to know what routing you had in place (that worked ok and the tunnels came up) before you added the static routes. But I believe that we can identify the issue without knowing that.


I believe that a couple of statements in the original post give us insight into what the problem is:

site1: (10.1.0.0/24 LAN)

tunnel source FastEthernet0

So the subnet 10.1.0.0/24 is probably on the interface FastEther0, and the FastEther0 address is the tunnel destination from the other router. When you add the static route with 192.168.199.1 as the next hop, then you create a situation where the tunnel destination address is seen as reachable through the tunel (and that is the definition of recursive routing which takes the tunnel down).


You can fix this by configuring a host specific static route with its next hop being a hop outside the physical interface. Since you have been so thorough in obscuring addresses it is a bit difficult to give really good examples, but it might be something like this:

ip route y.y.y.y 255.255.255.255


HTH


Rick


thomasdzubin Fri, 09/12/2008 - 11:23
User Badges:

No, my tunnel source on both routers, FastEthernet0 is my public WAN Internet address. One of them has a 64.x.x.x address and the other has a 209.x.x.x address

My LAN with the private 10.x.0.0/24 addresses is on Vlan1 which includes Fa2-Fa7

(the routers are Cisco 1811s)


But actually, that gives me an idea...I'll try saying "tunnel source" with the IP address of FastEthernet0 instead of the actual interface name...maybe that'll work.

?

thomasdzubin Fri, 09/12/2008 - 11:35
User Badges:

Grrr... no... changing the tunnel source from interface to an IP address didn't make any difference.

singhsaju Fri, 09/12/2008 - 11:38
User Badges:
  • Silver, 250 points or more


Can you remove keepalives from the tunnel and then add routes?


interface Tunnel0

no keepalive 10 3

thomasdzubin Fri, 09/12/2008 - 13:03
User Badges:

I'm an idiot! Yes, there was something else in the config that caused it to fail.

I turned on "debug ip routing" and "debug tunnel" and saw a message with an IP that shouldn't have been there and I found an "ip nat outside source static" statement from a previous trial config. I removed it and VOILA it works!

Sorry about that.


Richard Burts Fri, 09/12/2008 - 13:27
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Thomas


With address translation the symptoms make a bit more sense. Given the parts that we were seeing it only made sense if the tunnel source and destination were the FastEther interfaces. The address translation could change that. Thanks for posting back to the thread and indicating that you have solved it and what the issue was. It makes the forum more useful when people can read about a problema and can read the resolution of the problem.


HTH


Rick

Actions

This Discussion