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
Lets start by configuring The R1 — R2 link with a /24 subnet as 172.16.12.0/24.
R1#show ip int bri | e unassigned Interface IP-Address OK? Method Status Protocol FastEthernet1/0 172.16.12.1 YES manual up up ! ! interface FastEthernet1/0 ip address 172.16.12.1 255.255.255.0 interface FastEthernet0/0 ip address 192.168.13.1 255.255.255.0
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.
<pre class="lang:default decode:true " >R1#show run | s eigrp router eigrp 42 network 172.16.0.0 network 192.168.13.1 0.0.0.0 no auto-summary</pre>
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.
ip route 172.16.33.0 255.255.255.0 FastEthernet1/0 ip route 172.16.254.0 255.255.255.128 FastEthernet1/0
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.
<pre class="lang:default decode:true " >R3#show ip route
172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
D 172.16.254.0/25 [90/30720] via 192.168.13.1, 00:42:59, FastEthernet0/0
D 172.16.33.0/24 [90/30720] via 192.168.13.1, 00:42:59, FastEthernet0/0
D 172.16.12.0/24 [90/30720] via 192.168.13.1, 00:43:01, FastEthernet0/0
[90/30720] via 10.23.23.2, 00:43:01, FastEthernet2/0
10.0.0.0/24 is subnetted, 1 subnets
C 10.23.23.0 is directly connected, FastEthernet2/0</pre>
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.
R1#show ip route 172.16.33.0 255.255.255.0
Routing entry for 172.16.33.0/24
Known via "static", distance 1, metric 0 (connected)
Redistributing via eigrp 42
Advertised by eigrp 42
Routing Descriptor Blocks:
* directly connected, via FastEthernet1/0
Route metric is 0, traffic share count is 1
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.
R3#show ip route 172.16.33.0 255.255.255.0
Routing entry for 172.16.33.0/24
Known via "eigrp 42", distance 90, metric 30720, type internal
Redistributing via eigrp 42
Last update from 192.168.13.1 on FastEthernet0/0, 00:46:39 ago
Routing Descriptor Blocks:
* 192.168.13.1, from 192.168.13.1, 00:46:39 ago, via FastEthernet0/0
Route metric is 30720, traffic share count is 1
Total delay is 200 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
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).
R1(config)#no ip route 172.16.33.0 255.255.255.0 FastEthernet1/0 R1(config)#ip route 172.16.33.0 255.255.255.0 fa1/0 172.16.12.2
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.
R1#show ip route
C 192.168.13.0/24 is directly connected, FastEthernet0/0
D 192.168.24.0/24 [90/30720] via 172.16.12.2, 00:49:25, FastEthernet1/0
172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
S 172.16.254.0/25 is directly connected, FastEthernet1/0
S 172.16.33.0/24 [1/0] via 172.16.12.2, FastEthernet1/0
C 172.16.12.0/24 is directly connected, FastEthernet1/0
10.0.0.0/24 is subnetted, 1 subnets
D 10.23.23.0 [90/30720] via 192.168.13.3, 00:49:25, FastEthernet0/0
[90/30720] via 172.16.12.2, 00:49:26, FastEthernet1/0
R1#show ip route 172.16.33.0 255.255.255.0
Routing entry for 172.16.33.0/24
Known via "static", distance 1, metric 0
Routing Descriptor Blocks:
* 172.16.12.2, via FastEthernet1/0
Route metric is 0, traffic share count is 1
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.
R3#show ip route
C 192.168.13.0/24 is directly connected, FastEthernet0/0
D 192.168.24.0/24 [90/30720] via 10.23.23.2, 00:49:38, FastEthernet2/0
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
D 172.16.254.0/25 [90/30720] via 192.168.13.1, 00:49:38, FastEthernet0/0
D 172.16.12.0/24 [90/30720] via 192.168.13.1, 00:49:39, FastEthernet0/0
[90/30720] via 10.23.23.2, 00:49:39, FastEthernet2/0
10.0.0.0/24 is subnetted, 1 subnets
C 10.23.23.0 is directly connected, FastEthernet2/0
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 172.16.0.0/24 subnetted into further networks. The output is below. In this case the interface address was unchanged.
R1(config-router)#ip route 172.16.33.0 255.255.255.0 FastEthernet1/0
R1(config)#end
R1#show ip
*Mar 1 01:40:53.579: %SYS-5-CONFIG_I: Configured from console by console
R1#show run | s eigrp
router eigrp 42
network 172.16.0.0 0.0.127.255
network 192.168.13.1 0.0.0.0
no auto-summary
R3#show ip route
C 192.168.13.0/24 is directly connected, FastEthernet0/0
D 192.168.24.0/24 [90/33280] via 192.168.13.1, 00:00:53, FastEthernet0/0
172.16.0.0/24 is subnetted, 2 subnets
D 172.16.33.0 [90/30720] via 192.168.13.1, 00:00:03, FastEthernet0/0
