GRE - %TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive routing

[burkj]

I am trying to build a GRE tunnel betwen two routers, I keep getting this error message -

%TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive routing

I am running EIGRP, Config is below

========Router A==============

interface Loopback0
ip address 10.104.0.130 255.255.255.255
!
interface Tunnel0
description == GRE Tunnel ==
ip address 10.104.254.53 255.255.255.252
mpls ip
tunnel source Vlan3
tunnel destination 10.104.254.78

interface Vlan3
description == CEM IP Interface to carry Emulated TDM T1 ===
ip address 10.104.254.74 255.255.255.252
no ptp enable
mpls ip
!
router eigrp 1205
network 10.104.0.0 0.0.255.255
no auto-summary
eigrp stub connected
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 10.104.254.73 181
ip route 10.104.0.131 255.255.255.255 Tunnel0

======================================

============Router B===================

interface Loopback0
ip address 10.104.0.131 255.255.255.255
!
interface Tunnel0
description == GRE Tunnel ==
ip address 10.104.254.54 255.255.255.252
mpls ip
tunnel source Vlan3
tunnel destination 10.104.254.74
!

interface Vlan3
description == CEM IP Interface to carry Emulated TDM T1 ===
ip address 10.104.254.78 255.255.255.252
no ptp enable
mpls ip
!
router eigrp 1205
network 10.104.0.0 0.0.255.255
no auto-summary
eigrp stub connected
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 10.104.254.77 181
ip route 10.104.0.130 255.255.255.255 Tunnel0

==================================

I have found that if I address the tunnels in different subnets, that the tunnel stays up - I get this error in that case -

IP-EIGRP(Default-IP-Routing-Table:1205): Neighbor 10.104.254.53 not on common subnet for Tunnel0

I am thinking maybe I need to block EIGRP on that tunnel interface, but not sure - can anyone offer advice?

[Peter Paluch]

John,

You are making a mistake seen quite often: using EIGRP, you are advertising the tunnel's destination network over the tunnel itself. This in turn creates a recursive entry in the routing table. The solution is quite simple, frankly: make sure that the EIGRP running over the tunnel never advertises the real networks in which the endpoints are located, so in your case:

Router A:

router eigrp 1205
 network 10.104.254.53 0.0.0.0
 ! AVOID ENTRY MATCHING OR COVERING THE NETWORK 10.104.254.72/30

Router B:

router eigrp 1205
 network 10.104.254.54 0.0.0.0
 ! AVOID ENTRY MATCHING OR COVERING THE NETWORK 10.104.254.76/30

The reachability of the individual tunnel endpoints should be done either by a different EIGRP process or by static routes.

Another solution often employed by experienced configurators is to statically create a host route towards the opposite tunnel endpoint. This way, even if the network is accidentally advertised over tunnel itself, the host route will be more specific and being static, it will remain in the routing table. The downside is, obviously, the static nature of this workaround.

Best regards,

Peter

[burkj]

Peter,

thank you for the response - I like the static route idea better - to keep the network engineering guys happy that I am not putting stuff in their AS that they may not understand (even though these routers are stubs)

so on Router A I would put

ip route 10.104.254.53 255.255.255.255 tunnel0

and Router B

ip route 10.104.254.54 255.255.255.255 tunnel0

is this right?

or could I do this on both

router eigrp 1205

passive-interface tunnel0

[Peter Paluch · Accepted solution]

John,

is this right?

Unfortunately, it isn't Correctly, it should be as follows:

Router A:

ip route 10.104.254.78 255.255.255.255 10.104.254.73

Router B:

ip route 10.104.254.74 255.255.255.255 10.104.254.77

Under all circumstances, avoid running the same EIGRP process both over the GRE tunnel and towards your provider. This would result in leaking your tunelled addressing into "real world" which is certainly not what you want. Note that running a different process over GRE tunnel (not including real interfaces) and a different process over real interface (not including the GRE tunnel) also provides the necessary prevention against recursive routing loops, as these two processes will not leak one to another, causing the real endpoint of a tunnel to be discovered through the tunnel itself.

Best regards,

Peter

EDIT: Corrected typos in the static route next hops. I apologize!

[burkj]

Problem solved, thanks for the quick response and the help resolving this issue - it definitely makes more sense now

[Peter Paluch]

Hi John,

You are heartily welcome. I have made an error in my last post with the next hop IP addresses - I have corrected it afterwards. Please double check my suggested configuration once - I need proofreading as well

Best regards,

Peter