EIGRP Redistribution – Default Metrics of Connected and Static Routes

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 to keep my options open. I went ahead and added Loopback100 on R3 with an address of and added a redistribute connected with a route-map to get the route out in the wild.  Here’s what I had.

Alright. All looks good there, so I checked the topology table on R1 and saw it in there as an external and everything.

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 to interface Null 0, added redistribute static, and took a look.  Yep.  There it is with different K values.

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.

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 through  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 network from EIGRP and checked topology again.  Since this interface included the next hop for the route to, 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*

Send any study time wasted on pointless labs questions to me.

Aaron Conaway

I shake my head around sometimes and see what falls out. That's what lands on these pages. @aconaway@mstdn.social

More Posts

1 comment for “EIGRP Redistribution – Default Metrics of Connected and Static Routes

Leave a Reply

Your email address will not be published. Required fields are marked *