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 gets 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!
Follow my CCIE journey on Twitter!