2-part EIGRP routing metrics question

[Amafsha1]

Hello everyone,  I have a 2 part question that I will try to put as much context into as I can.

Lets say I have a Core Nexus 9k multi-layer switch/router that sees a route, lets say 172.28.1.1 as distance  [170/25600512]  eigrp-1, external, tag 2000 to get there.  Now let say I connected up a router (Router1) to this 9k via a routed link they becom eigrp neighbors with eachother.  Now Router 1 is 1 hop farther away from the 172.28.1.1 network.  I'm wondering will Router1 see the metrics as the exact same as the core 9k sees it [170/25600512] ?  or will EIGRP metrics know that this route is farther away, so it will change the metrics to something higher than 25600512.  I'm pretty sure the AD won't change because it will still view this route EIGRP external routes, but I'm wondering if the metrics will change.   the  Picture attached describes the situation better.

So in a nutshell, my question is pretty much just asking does hops become a factor in changing EIGRP metrics when we're increasing hops such as my example?

Thank you

[Cisco Freak · Accepted solution]

If Router1 is learning that route from N9k, it will do a metric calculation based on the  metric values that N9k advertises to Router1. So there will be an increase in metric in Router1.

If you do a packet capture, you can see the route update like this:

[Amafsha1]

yes, that is correct, it is learning it from the n9k because that's the only path it has to get anywhere...as of now.  Thank you for answering my question.  So the metrics will increase.  The second we provision Router1, I will do a sh ip route and see if the metrics have increased indeed.  

This brings me to my final question:   Lets say that we somehow change the network and make it more redundant so that Router1 will now have 2 paths to get to the 172.28.1.1 network - and both paths will have the same AD of eigrp external 170.  Will it choose the path with lower metrics as the preferred path, then install the 2nd path with higher metrics as the Feasible successor path...so in case the first path fails, it will now instate the FS route into the routing table after the failure of path 1?  Does that make sense?

[Richard Burts · Accepted solution]

Yes it does make sense. And you are sort of/maybe correct about what EIGRP will do with the second path. Installing a second path as feasible successor is not automatic. EIGRP has some conditions that must be satisfied for an alternate path to be identified as feasible successor. The advertised metric for the alternate path must be less than the feasible distance of the active route. If this condition is satisfied then the alternate route is guaranteed to be loop free and qualifies as feasible successor. If the advertised metric of the alternate route is not less than the feasible distance then there is a possibility that the alternate path will create a routing loop and this path does not qualify as a feasible successor. 

Perhaps it will help to think of a simple example. Think of a scenario where router A has connected network 10.1.1.0/24. think of a network where router B and C are at intermediate locations in the network and where router D is further away. router D receives advertisements of routes with paths through both B and C. Assume that router D has chosen the path through router B as the best path and it has metric with 200 as the feasible distance. If router D receives an advertisement from router C with advertised metric of 180 then router D can be confident that the route from C does not come back through D and the path is loop free and will qualify as a feasible successor. But what if the advertised metric from C is 300? Is it possible that the path from C is through D to B? In that case the path through C could create a routing loop and does not qualify as a feasible successor.

Let us review briefly what happens with EIGRP when there is a feasible successor and when there is not a feasible successor. In the example I have described let us focus on what happens with router D. Assuming that D has qualified the path through C as a feasible successor, router D will have a single path in its routing table to 10.1.1.0 and that path is through B. Now something happens and the path through B is not available. router D removes the path through B and immediately installs the path through C (as the feasible successor. There is no query and no further calculation. Replacement of the route is immediate and convergence is very fast. Now consider what happens if the path through C does not qualify as feasible successor. Now the table at D has a single active route through B and no feasible successor. Now the path through B is not available. router D removes the path through B, there is no feasible successor so router D enters the active state for a path to 10.1.1.1. It sends queries to its neighbors. router C responds. It turns out that router C has a path to 10.1.1.0 that is not through D (perhaps its metric is higher because one of its links in the path to 10.1.1.0 is on a much slower link) so now router D discovers that it has a path to 10.1.1.0 and installs the path through router C in its routing table. So we can see that feasible successor is a way to enhance the choice of an alternate path, but only if EIGRP can guarantee that the alternate path is loop free.

HTH

Rick

[Joseph W. Doherty]

Just to add a note to Rick's excellent post, know that EIGRP also supports unequal cost routing. If this feature is enabled, you could see multiple routes to the same destination although the cost metrics vary.

Also as Rick notes, the FS provides a new path to the destination, very quickly, if the current active path fails. This is different from other routing protocols which generally would need to recompute a new path unless it's an equal cost path. (In the latter, it would already be active.)

[Amafsha1]

Thank you for mentioning that.  We have variance at 1 I believe, the way we want to set this up I don't think Load balancing would work...  Essentially, we have a loop so I'm pretty sure that second route will not become FS...and will have to wait for EIGRP to go to active state and re-calculate to get to use the second path.  I'm pretty sure this isn't good design anyways because if there is route flapping, we would see some serious issues.

[Amafsha1]

Thank you Richard for the comprehensive answer, I really appreciate that!  I understand it much better now.

So going back to your example, lets say if we have a situation where we have a loop(Router C wouldn't become FS), but the primary path through Router B fails and EIGRP enters the active state....could we guarantee that path through Router C would become the primary path now?  I'm thinking that as long its advertised and Router D sees no other way of going...it would most likely take that path through C...even if the metrics might be pretty bad..

[Richard Burts]

I am a little puzzled with your follow up question. You ask about a situation where you have a loop. Is that really what you mean? Perhaps you could explain a bit more about your environment?

But you asked a follow up question and let me try to answer the question that you asked. If the path from router D through router C really produces a loop then C would not become FS. And when the path through router B is not available the router D goes into the active state and sends queries to its neighbors. router C will respond. If the path through C is still a loop then C will not become the primary path. If the path through C is no longer a loop then C will become the primary path. So the essential question here is what produced the loop and does the loop still exist when router B is no longer active?

HTH

Rick

[Richard Burts]

I just read through the discussion again and see a question in the original post that we have not really addressed. The question was "So in a nutshell, my question is pretty much just asking does hops become a factor in changing EIGRP metrics when we're increasing hops such as my example?" The question becomes more interesting in the context of the response which has capture information about an EIGRP advertisement. That output clearly shows that hop count is included in the advertisement. So it would be easy to assume that hop count is used to calculate the metric.

But that is not correct. Hop count is not used in the calculation of the metric. EIGRP does track the hop count. And EIGRP does have a limitation on the maximum number of hop allowed (which is why it is in the advertisement). But EIGRP does not use hop count in calculation of the metric. 

But hops does indirectly become a factor in the calculation of the EIGRP metric. One part of the calculation is delay. And we should remember that delay is accumulated over the entire path. So every time we go another hop we add a bit more delay in the metric, and the metric does increase every time we go another hop.

HTH

Rick

[Amafsha1]

yes correct! I re-read more until I figured out how that works.  Not hope count, but the delay will make the metrics heavier and since it has to do more hops, means more delay will be added.  so if I had been more knowledgable of delay before posting this question, I would've rephrased it...or maybe never asked it. :)

[Richard Burts]

Yes delay is not the same as hop count but it has an effect that is quite similar (especially as long as bandwidth remains consistent in the advertisement). You did ask the question, and it led to an interesting discussion, and you learned something good. That is one of the very good things about these forums. I hope to see you continue to be active in the forums.

HTH

Rick

[Amafsha1]

yep that answered it.  What I was asking was the latter part of your statement: so there is a loop now, but once the primary path fails, there will no longer be a loop in the network for that secondary path...so it will become primary.  Thank you for clarifying.  

environment in a nutshell:

2 datacenters geographically separated.  Both have a WAN router that does eBGP with ISP MPLS router (1 gig circuits) which in turn connects to all our branches.  These WAN routers also do EIGRP with its corresponding core n9k.  Mutual redistribution happens on the 2 these WAN routers with no filtering - meaning that BGP and EIGRP will share everything fully from one to another.  Picture attached will make it very clear.   Datacenter 1 has default information originate on the BGP confis so the branches use this is at the primary gateway for getting out to internet for example since all routes have to come back to datacenter anyways to leave.  The cores see the branch routes as AD 170 eigrp external routes learnt from redistribution.  We are now thinking of connecting up a 10gig metro-e circuit directly from core to core between these 2 datacenters which in turn makes the network into 1 big loop.  The questions I asked were related to this topology.  so what I'm presuming now is that once we connect up this metro circuit, the cores will see 2 ways of getting to the branches now, 1 through the normal route directly through the WAN router and 1 through the other core.  So I'm just thinking of how EIGRP will react to something like this.