GRE Recursive Routing

In this lesson we’re going to take a look at recursive routing within GRE and the problems it causes.

If you haven’t already, I highly suggest you check out the previous lesson on GRE tunnelling before continuing.

2.0 Virtualization
  2.2 Configure and verify data path virtualization technologies
    2.2.a GRE tunneling

Recursive routing is a common issue that can occur when using overlay networks and tunnel protocols – like GRE.

To help understand recursive routing better, lets take a look at an example topology.

In the topology, we’ve got a GRE tunnel connecting SITE_A and SITE_B. Our GRE tunnel is using 172.16.0.0/24 in order to communicate.

Across the tunnel, we’re running EIGRP process 10 in order to advertise our tunnel interface and local subnets, allowing the sites to route between each other.


Although traffic looks to route directly across our GRE tunnel, it instead routes via our ISP – encapsulated within a GRE packet.

If we take a look at our routing table on SITE_A, we’re routing to SITE_B via our ISP.

SITE_A#show ip route | include 0.0.0.0
Gateway of last resort is 32.113.43.2 to network 0.0.0.0
S* 0.0.0.0/0 [1/0] via 32.113.43.2

But what happens if we accidentally advertise our public interface (82.122.36.0/29) across our GRE tunnel via EIGRP?

SITE_B will now advertise its public interface across the GRE tunnel via EIGRP.

Why is this a problem?

SITE_A#show ip route | include 82.122.36.0
D 82.122.36.0 [90/297756416] via 172.16.0.2, 00:00:02, Tunnel1

You can see now on SITE_A that we’ve learned a more specific route for SITE_B’s public IP.

Because of this, our router will now try and send our GRE encapsulated packets across the tunnel – instead of across the internet.

The problem with this is that we can’t actually route traffic directly across the tunnel – the traffic needs to route via the ISP.

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

Because of this, our GRE tunnel drops – as indicated by the syslog message displayed on the console.

As our GRE tunnel has dropped, it means we’ve also lost our EIGRP neighbour relationship – therefore removing the corrupt route from our routing table.

But remember, the corrupt route that broke our tunnel has now been removed from SITE_A’s routing table. Due to this, SITE_A now has the ability to route to SITE_B to bring the GRE tunnel back up.

After a few our GRE tunnel re-establishes.

%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: Neighbor 172.16.0.2 (Tunnel1) is up: new adjacency

What happens when our GRE tunnel is formed again?

Once again, we’ll learn the public IP address of SITE_B via our tunnel interface.

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

We’re now stuck in a situation where our GRE tunnel will continuously become active and drop again.

This is known as Recursive Routing, when our router tries to route to SITE_B via our tunnel interface.

We can fix this by removing the network advertisement from SITE_B – restoring connectivity.