Advertise Static Routes in EIGRP without Redistribution

Reading Time: 5 minutes

I came across a paragraph in an older book in regards to EIGRP operation. As I read it I was kind of dumfounded. To be honest I didn’t believe it at first so of course I had to lab it to see if it was true. It turns out that it is in fact the way EIGRP operates in this very specific circumstance. I had never seen it before in some of my favorite books nor through my favorite video training vendors. So my findings are this: In a very specific scenario, EIGRP will advertise static routes into EIGRP as internal routes without any redistribution statements.

So I’ll admit that sentence reads a little funny. Of course it’s internal if it isn’t redistributed. Unfortunately I can’t think of a better way to summarize this scenario of static routes showing up as EIGRP routes without somehow mentioning redistribution.

The scenario goes like this. If an interface is matched by the EIGRP network statement, and a static route whose destination also matches the EIGRP network statement, it will be advertised into EIGRP ONLY IF the static route points out the matched interface not including the next hop. In other words, the static routes destination and outgoing interface must match the EIGRP network statement, while leaving the next hop out of the static route statement.

The topology is simple for this example. There are three routers with only two being relevant for output. In this case R2 is simply there to provide and up/up interface for R1’s static routes to point out of.

EIGRP Static Advertisements

EIGRP Static Advertisements

Lets start by configuring The R1 — R2 link with a /24 subnet as

Now we will bring up EIGRP AS 42 on R1. In this case I am going to use a class full network statement. I will show a non class full output at the end of this post. The important part comes down to the network statement matching. In this case R2’s network statement and EIGRP configuration are irrelevant so long as the adjacency forms. The same goes true for R1 <--> R3’s EIGRP adjacency and subnet. For brevity I will leave those configurations out.

Now we add the magic statement. I am adding a static route which points out of an interface but not towards a next hop. This occurs on R1. The magic in this statement is that the interfaces IP address, as well as the destination of the route both are matched by the EIGRP network statement. Please note that this requires auto-summary to be turned off as we are using discontiguous class full networks.

If we go over to R3 we will now see these two routes in the routing table as internal EIGRP routes. Again this indicates that it isn’t truly redistribution however, we are logically “redistributing” the static routes into EIGRP.

If we look at this new route on R1 specifically we will see that the routing table sees it as a “connected” route to the EIGRP process. Also note that it states it is “redistributing” via our EIGRP process.

This fact is what tells R3 it is an internal EIGRP route advertised by the EIGRP 42 process. Looking at R3s output for this route confirms it as just that, an internal EIGRP route.

Now, if we modify the static route on R1 to point out towards a next hop as opposed to out an interface we will see that the route is no longer “advertised” by EIGRP as an internal route. In fact it isn’t advertised at all. Again, using “redistribution” loosely the EIGRP process doesn’t not redistribute the static route into it’s process. (The lack of advertisement occurs with a static route pointing to an interface AND a next hop, or just out a next hop).

With this change made we can look again at R1s version of the route. In this case it sees the route as Static and via a next hop as opposed to Static connected advertised and redistributed by EIGRP 42.

Jumping over to R3 we can confirm these results. In this case I only modified the .33 route on R1 which is no longer in R3’s routing table.

As you can see in this very specific scenario static routes pointed out an interface in which both the destination of the route, and the interface in which it points out are both matched by the EIGRP network statement will be advertised as internal EIGRP routes as if they are connected.

To verify this operation with non class full network statements I confirmed using the same network of subnetted into further networks. The output is below. In this case the interface address was unchanged.

Share this article:

Permanent link to this article: