Like This Blog 2

Added by Mark Jacob January 8, 2014

Have you ever wanted to make your router dance on the head of a pin? Neither have I. But that doesn’t mean I don’t want to modify its default behavior from time to time either. Since routers already have a default route selection process, we do well to understand it so we can manipulate it to the betterment of our networking scenario.

The specific issue addressed in this blog is the disheartening message:

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

I have built the scenario shown here:

As shown, R1 and R3 are running both EIGRP and OSPF. R2 sees both R1 and R3 as OSPF neighbors. Loopback 11 on R1 represents user networks behind R1 of which R3 needs to be aware. Likewise the loopback interface on R3 represents a user network of which R1 needs to be aware. Let’s say that network requirements are as follows: You are not permitted to run EIGRP on R2. You must have a tunnel interface between R1 and R3 so that R1 and R3 can be EIGRP neighbors. You would like to avoid the error shown above.

Let’s take a look at the relevant information before we configure the EIGRP portion of the objective.

R1 knows about the destination of 3.3.3.3 via OSPF, and R3 knows about the destination of 1.1.1.1 also via OSPF. I can also ping back and forth from R1 to R3 using source IP of their respective loopbacks.

So all is well so far. Now let’s introduce the EIGRP routing protocol and include both the loopback networks and the tunnel networks on R1 and R3 and watch what happens. Here is a screenshot from R3 (the same output appeared on R1):

What happened? If you type quickly (on R1 for example) when the message appears that an EIGRP adjacency has occurred, you can see something interesting appear as output from the show ip route command. Moments later, the tunnel interface goes away and the recursive message appears. Issue the show ip route again and observe the difference. Here is a screenshot:

So the EIGRP route appeared briefly, but then was replaced by an OSPF route. The Administrative Distance shown in the output for the EIGRP route is 90, which is the default value. The Administrative Distance (AD is a believability or reliability rating and the lower the number, the more believable the information) for the OPSF route is 110, which is also its default value. So why did a higher (less believable) number replace a lower (more believable) number? In order for a tunnel interface to be active, the other side of the tunnel must be a reachable address. In this case, EIGRP was seeing the destination address at the other end of the tunnel, but the best path to get there was THROUGH THE TUNNEL itself. The router sees this as recursive routing, and Voila! the tunnel interface dies.

We can now address the question: How can I keep my OSPF adjacencies, my tunnel interfaces, and EIGRP routing all humming along without any errors? This then brings us full circle to our original reason for this blog – the DISTANCE command. I want R1 and R3 to prefer the OSPF route to the destination loopback of the far side router. This desired result breaks as soon as the routers see an EIGRP route. So I want these two routers to believe OSPF over EIGRP. Let’s make it happen.

I will need an access-list on each router which permits the remote loopback network and denies everything else. We’ll do that first.

On R1, it looks like this:
access-list 1 permit 3.0.0.0 0.255.255.255

On R3, it looks like this:
access-list 1 permit 1.0.0.0 0.255.255.255

The distance command is executed within the routing process of the protocol you are modifying. The value needs to be set lower than 90. Let’s use 85 in our example. Here is the command:
distance 85 0.0.0.0 255.255.255.255 1

Explanation: 85 is the number we selected to apply to routing information so that it would look better to the router than the EIGRP route. 0.0.0.0 255.255.255.255 is specifying which routers will have their incoming routing information impacted by this distance command – in this case, the given syntax means that any source of routing information will be affected. The number 1 is the access-list ID number. For R1, this affects the routing updates from any router that provides information about networks that have a 3 in the first octet (see the access-list above). To simplify, any incoming route on R1 with 3 in the first octet will have an AD of 85 assigned to it. This means the router will prefer this newly modified route over the EIGRP route, since the EIGRP route now has a worse AD of 90. The same logic holds for R3. Let’s see this entire config in action. With the distance command executed on both routers and stability ensuing, let’s look at the show ip route on R1:

Aha! There is the OSPF route in the routing table. I also see the modified AD which has been applied. If it is working correctly, R1 and R3 should now be stable EIGRP neighbors. Let’s check:

A stable EIGRP relationship does exist as expected.  Goals have been met, high-fives have been given, the roar of approval has been heard…ok, maybe not, but didn’t it feel good to meet the objectives?

A little side note on interpreting the distance command (as it has been demonstrated in this blog). The portion that follows the newly assigned AD, the part that looks like ACL syntax (0.0.0.0 255.255.255.255) serves to identify the SOURCE (router) of the incoming routing information. If the distance command is not associated with an ACL, then the new AD is applied to any incoming routing information heard from that source. That’s why it is helpful to be more granular and select, with the use of an ACL, which specific routes are supposed to be affected by the distance command.

If you have any questions or comments, please feel free to comment on my blog. If you have suggestions for improvement, I am all ears for that also. I used GNS3 to create this scenario and my routers were 3725 devices running IOS 12.4. I have made the config files available as I have done with blogs in the past, and the link to access them can be found here: Download Cisco Distance Command

Last note: A major upgrade to GNS3 is in the offing, and if you wish to donate at their website (this is not required) you get advance screenings of the new product before the general public. One cool thing that is on the way is full switch support. For those of you studying for your CCNP Switch exam, this is happy news indeed.

Until next time, keep your distance!
Mark Jacob
Cisco Instructor – Interface Technical Training
Phoenix, AZ