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

[thomasdzubin]

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.

[singhsaju]

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]

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]

I think there is some resursive routing loop .Just see the link below which will help u to get an idea of the issue.

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094690.shtml

If thats not helping attach the router configs with correct interface ip addresses(not WAN).

HTH

Ullas

[ullasupendran]

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]

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]

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]

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]

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]

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

[singhsaju]

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

interface Tunnel0

no keepalive 10 3

[thomasdzubin]

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]

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