I wanted to do some analysis of the EIGRP topology table last night, so I fired up a small lab. I was especially interested in how external routes appear there and compare to internal entries. Like all good scientific endeavors, the whole thing got derailed when I made a realization.
Here’s the lab I set up. You can ignore the IPv6 info for this exercise.
It’s a simple little thing. All the networks you see are included in EIGRP 100 for simplicity. I limited the network statements to 192.0.2.0/24 to keep my options open. I went ahead and added Loopback100 on R3 with an address of 220.127.116.11/32 and added a redistribute connected with a route-map to get the route out in the wild. Here’s what I had.
12345678 R3#show run | section eigrprouter eigrp 100redistribute connected route-map RM-REDIST-CONNnetwork 192.0.2.0no auto-summary!route-map RM-REDIST-CONN permit 100match interface Loopback100
Alright. All looks good there, so I checked the topology table on R1 and saw it in there as an external and everything.
123456789101112131415161718 R1#sh ip eigrp topology 18.104.22.168/32IP-EIGRP (AS 100): Topology entry for 22.214.171.124/32State is Passive, Query origin flag is 1, 1 Successor(s), FD is 409600Routing Descriptor Blocks:192.0.2.66 (FastEthernet0/1), from 192.0.2.66, Send flag is 0x0Composite metric is (409600/128256), <span style="color: #ff0000;">Route is External</span>Vector metric:Minimum bandwidth is 10000 KbitTotal delay is 6000 microsecondsReliability is 255/255Load is 1/255Minimum MTU is 1500Hop count is 1External data:Originating router is 126.96.36.199AS number of route is 0External protocol is Connected, external metric is 0Administrator tag is 0 (0x00000000)
I got to thinking, though, that it probably shouldn’t exist in the topology table on R1. One of the things we all learn about redistribution is that there is no mapping of metrics between protocols and that EIGRP is the pickiest of them all. At least that’s how it echoes in my head. So, where did these K values come from for this calculation? Usually you set them with a default-metric or a route-map, but I’m not setting them anywhere. I ventured further into the rabbit hole.
How about a static route? How does a redistributed static show up in the topology table? I added a static for 188.8.131.52/32 to interface Null 0, added redistribute static, and took a look. Yep. There it is with different K values.
123456789101112131415161718 R1#sh ip eigrp topology 184.108.40.206/32IP-EIGRP (AS 100): Topology entry for 220.127.116.11/32State is Passive, Query origin flag is 1, 1 Successor(s), FD is 281600Routing Descriptor Blocks:192.0.2.66 (FastEthernet0/1), from 192.0.2.66, Send flag is 0x0Composite metric is (281600/256), Route is ExternalVector metric:<span style="color: rgb(255, 0, 0);"> Minimum bandwidth is 10000 KbitTotal delay is 1000 microsecondsReliability is 0/255Load is 1/255Minimum MTU is 1500</span>Hop count is 1External data:Originating router is 18.104.22.168AS number of route is 0External protocol is Static, external metric is 0Administrator tag is 0 (0x00000000)
Where were they coming from!??!??!?! I had some suspicions, and the leading candidate had to do with the fact that each route deals with an interface. I posted a discussion on Twitter and the Cisco Learning Network to get some ideas, and Lonnie showed that the values in the topology table come from the route’s outgoing interface details. That’s exactly what was happening! The connected was taking the characteristics of the loopback interface, and the static was taking the characteristics of the Null 0 interface. Those were passed on to R1, who did the standard EIGRP thing of incrementing delay and comparing minimum bandwidths.
123456789101112131415161718192021222324252627282930313233343536373839 R3#sh ip eigrp topology 22.214.171.124/32IP-EIGRP (AS 100): Topology entry for 126.96.36.199/32State is Passive, Query origin flag is 1, 1 Successor(s), FD is 128256Routing Descriptor Blocks:0.0.0.0, from Rconnected, Send flag is 0x0Composite metric is (128256/0), Route is ExternalVector metric:Minimum bandwidth is 10000000 KbitTotal delay is 5000 microsecondsReliability is 255/255Load is 1/255Minimum MTU is 1514...R3#sh int lo100Loopback100 is up, line protocol is upHardware is LoopbackInternet address is 188.8.131.52/32MTU 1514 bytes, BW 8000000 Kbit/sec, DLY 5000 usec,reliability 255/255, txload 1/255, rxload 1/255...R3#sh ip eigrp topology 184.108.40.206/32IP-EIGRP (AS 100): Topology entry for 220.127.116.11/32State is Passive, Query origin flag is 1, 1 Successor(s), FD is 256Routing Descriptor Blocks:0.0.0.0, from Rstatic, Send flag is 0x0Composite metric is (256/0), Route is ExternalVector metric:Minimum bandwidth is 10000000 KbitTotal delay is 0 microsecondsReliability is 0/255Load is 0/255Minimum MTU is 1500Hop count is 0...R3#sh int null0Null0 is up, line protocol is upHardware is UnknownMTU 1500 bytes, BW 10000000 Kbit/sec, DLY 0 usec,reliability 0/255, txload 0/255, rxload 0/255
Note : There’s a difference in BW between the Lo100 characteristics and the EIGRP topology table. I really can’t find a reason for this discrepancy. Input welcome as always.
Let’s go deeper still! Pete Lumbis had a similar suggestion on Twitter. He said that static routes pointing to an interface that’s included in EIGRP (i.e., covered by a network statement) will have the K values for that interface automatically applied. I added a route on R3 pointing to 18.104.22.168/32 through 192.0.2.200. The next hop didn’t exist in the network, but it did resolve to an interface participating in EIGRP. Sure enough, it popped right into the topology table on R1. Looks like Pete was right, too. Going deeper still, I removed the 192.0.2.192/26 network from EIGRP and checked topology again. Since this interface included the next hop for the route to 22.214.171.124/32, I expected it to not be redistributed. Wrong! It’s in there with the same metrics as before.
“Too many words, Aaron. What’s the juicy details we need to remember?” I guess it’s that EIGRP will try to apply K values when it can, and the outgoing interface is one way to get it. If you redistribute OSPF without a default metric, will it work? Probably not, but, if the next hop is out of an interface that EIGRP already knows about, it probably will. *insert “lab it out yourself” and “I can’t do it all” comments*
study time wasted on pointless labs questions to me.