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:
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 184.108.40.206 0.255.255.255 no auto-summary ! ip route 172.18.0.0 255.255.0.0 Serial0/0 !
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 220.127.116.11 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!