• Skip to main content
  • Skip to footer

NetworkJutsu

Networking & Security Services | San Francisco Bay Area

  • Blog
  • Services
  • Testimonials
  • About
    • About Us
    • Terms of Use
    • Privacy Policy
  • Contact Us

GRE Tunnel Recursive Routing

01/15/2012 By Andrew Roderos Leave a Comment

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Ever seen this error message %TUN-5-RECURDOWN: Tunnel1 temporarily disabled due to recursive routing? The most common reason for this error is that the router is trying to route to the tunnel destination address using the tunnel interface itself. This error message will keep flooding your router until someone fixes the misconfiguration of the router. This will also mean that your tunnel interface will keep flapping until fixed.

Let’s take a look at a scenario in which recursive routing is being experienced. In this particular environment, there are several remote branches that will need to establish a GRE tunnel to the headend. For simplicity, the diagram only shows two remote branches and the configuration only shows the headend and a remote branch. Please ignore the IP addressing as I just picked random numbers. The 172.18.0.0/16 address, however, has been assigned to be the serial interfaces of the remote branch routers.

Here are the configuration of the enterprise routers:

GRE-HEADEND

interface Loopback0
 ip address 172.17.254.254 255.255.255.255
!
interface Loopback1
 ip address 172.17.1.254 255.255.255.0
!
interface Tunnel1
 ip unnumbered Loopback0
 tunnel source Serial0/0
 tunnel destination 172.18.1.254 
!
interface Serial0/0
 ip address 172.19.0.254 255.255.255.0 
!
router eigrp 1
 network 172.0.0.0 0.255.255.255
 no auto-summary 
! 
ip route 172.18.0.0 255.255.0.0 Serial0/0
!

REMOTE-R1

interface Loopback0
 ip address 172.17.2.254 255.255.255.255
!
interface Tunnel1
 ip unnumbered Loopback0
 tunnel source Serial0/0
 tunnel destination 172.19.0.254
!
interface FastEthernet0/0
 ip address 172.24.1.254 255.255.255.0
 duplex auto
 speed auto
!
interface Serial0/0
 ip address 172.18.1.254 255.255.255.0
!
router eigrp 1
 network 172.0.0.0 0.255.255.255
 no auto-summary
!
ip route 172.19.0.0 255.255.255.0 Serial0/0
!

Once the routers able to reach their tunnel destination IP address and when the tunnel interfaces comes up/up on both routers, then they’ve established the GRE tunnel. However, once they start exchanging EIGRP the tunnel will go down due to recursive routing. The router will automatically reestablish GRE tunnel and establish EIGRP neighborship but will eventually go down again, as shown below. This is a cycle and will never be fixed unless a human intervention.

GRE-HEADEND#
*Mar  1 03:08:46.087: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up
*Mar  1 03:08:50.435: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.17.2.254 (Tunnel1) is up: new adjacency
GRE-HEADEND#show ip eigrp neigh
IP-EIGRP neighbors for process 1
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   172.17.2.254            Tu1               14 00:00:05   32  5000  2  40
GRE-HEADEND#
*Mar  1 03:08:55.087: %TUN-5-RECURDOWN: Tunnel1 temporarily disabled due to recursive routing
*Mar  1 03:08:56.087: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down
*Mar  1 03:08:56.127: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.17.2.254 (Tunnel1) is down: interface down

So what’s the problem here? Well, it is quite simple really. The GRE-HEADEND router has a static route that is shorter prefix to reach the tunnel destination address of the remote routers – ip route 172.18.0.0 255.255.0.0 s0/0. Since this is a shorter prefix, the GRE-HEADEND router will eventually learn a better route via EIGRP and will try to use that to reach the tunnel destination address. Unfortunately, that’s not going to work since the router learned it via EIGRP which has a next hop interface of Tunnel1, as shown below.

GRE-HEADEND#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
     172.17.0.0/16 is variably subnetted, 3 subnets, 2 masks
D       172.17.2.254/32 [90/297372416] via 172.17.2.254, 00:00:01, Tunnel1
C       172.17.1.0/24 is directly connected, Loopback1
C       172.17.254.254/32 is directly connected, Loopback0
     172.19.0.0/24 is subnetted, 1 subnets
C       172.19.0.0 is directly connected, Serial0/0
     172.18.0.0/16 is variably subnetted, 2 subnets, 2 masks
S       172.18.0.0/16 is directly connected, Serial0/0
D       172.18.1.0/24 [90/297756416] via 172.17.2.254, 00:00:03, Tunnel1
     172.24.0.0/24 is subnetted, 1 subnets
D       172.24.1.0 [90/297270016] via 172.17.2.254, 00:00:03, Tunnel1

The solution for this recursive routing issue is to remove the static route with a shorter prefix and add a static route with a longer prefix, so the router won’t use the route learned via the IGP, in this case EIGRP. Remember the rules of how the router places routes in the routing table: the more specific route gets placed, if it’s a tie then the route with the best AD (Administrative Distance) value, and if the AD value is a tie then the route with the best metric will be placed.

GRE-HEADEND(config)#ip route 172.18.1.0 255.255.255.0 s0/0
GRE-HEADEND#
*Mar  1 03:19:17.611: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up
GRE-HEADEND#
*Mar  1 03:19:21.171: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.17.2.254 (Tunnel1) is up: new adjacency
GRE-HEADEND#sh ip eigrp neigh
IP-EIGRP neighbors for process 1
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   172.17.2.254            Tu1               14 00:18:20   79  5000  0  81

As you can see above, the EIGRP has been stable for more than 15 minutes compared to the show ip eigrp neighbor output shown above.

I hope this has been helpful and I thank you for reading!

Disclosure

NetworkJutsu.com is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to Amazon.com.

  • Share on Twitter Share on Twitter
  • Share on Facebook Share on Facebook
  • Share on LinkedIn Share on LinkedIn
  • Share on Reddit Share on Reddit
  • Share via Email Share via Email

Filed Under: Routing Tagged With: Cisco, IOS, Router

About Andrew Roderos

I am a network security engineer with a passion for networking and security. Follow me on Twitter, LinkedIn, and Instagram.

Footer

WORK WITH US

Schedule a free consultation now!

LET’S TALK

Copyright © 2011–2023 · NetworkJutsu · All Rights Reserved · Privacy Policy · Terms of Use