GRE Tunnel Recursive Routing Error and How to Solve It

type

status

date

slug

Recursive Routing Error Explanation.

Here is what happens when a Recursive Routing Error happens in GRE Tunnel:

When the router learns the destination IP address for the tunnel interface through the tunnel itself, it removes the previous entry for the tunnel destination IP address from the routing table.

Now the tunnel destination is no longer reachable, and it collapses.

The route rebuilds the previous route and then repeats step 1.

The route flaps.

Let’s see this example and how to solve it.

Basic Configuration

Firstly, We configure basic interface information and RIP to build the connection between R1 and R3.

Set Up GRE Tunnel

Secondly, we set up the GRE tunnel between R1 and R3, and we use the 192.168.13.0/24 subnet for the tunnel interface.

Take a good look at the output above. R1 and R3 each have a hop count of 2 to reach each other’s loopback interface.

Enable Recursive Route

Now we will enable RIP on the tunnel interface:

As soon as we enable RIP on the tunnel interface, you’ll see this message on R1 and R3:

So what is going on here? Before I enabled RIP on the tunnel interface, R1 and R3 learned they could reach each other’s loopback interface through R2 with a hop count of 2.

After activating RIP on the tunnel interface, R1 and R3 learn they can reach each other’s loopback interface with a hop count of 1. As a result, they will install this new information in the routing table and remove the old information. If you are quick, you can catch it in the routing table when the tunnel comes up. Here’s an example of R3:

Above, you can see that R3 wants to reach 1.1.1.1 through the tunnel interface with a hop count of 1. Trying to reach the tunnel destination through the tunnel is a little problematic…it’s a classic chicken and egg problem.

Solve the Recursive Route

How do we solve this? You need to ensure the router doesn’t reach the tunnel destination through the tunnel itself. There are some options to do this:

Don’t advertise the tunnel destination IP address on the tunnel interface. Don’t advertise it or use route filtering.

Make sure the administrative distance of the tunnel destination IP address through the tunnel is higher (worse) than what you have in the routing table now.

Make sure the metric to the tunnel destination IP address through the tunnel is worse than what you have in the routing table now.

I will use one of the techniques to solve the problem in our setup:

An offset-list can be used to change the metric. In the example above, I’m configuring RIP so that all networks it advertises through the tunnel interface will have a hop count of 3.

Since a hop count of 3 through the tunnel is higher (worse) than a hop count of 2 through R2, our routers R1 and R3 will now use the FastEthernet links to reach the tunnel destination IP addresses.