03-16-2015 05:03 PM - edited 03-05-2019 01:01 AM
Team,
I somehow find the doc above for EIGRP UCLB a little bit misleading because it shows that the cost to reach network X is additive to demonstrate EIGRP variance. The only time that the cost will be additive is if only delay is used along the path to network X. However, there is no mention about delay solely being used as the metric in the doc which might lead one to think that the metric for a certain route is FD = cost to neighbor + neighbor's RD.
Thoughts please. Thanks.
Solved! Go to Solution.
03-17-2015 01:12 AM
Hi Carlos,
I think you have posted this topic twice in two separate threads. You should probably delete the other one so that it does not confuse other readers seeking for the same answers.
I am going to provide my own view on this matter. It may - or may not, depending on what you find here - answer your question so please more than welcome to ask further.
Metrics in EIGRP are, in general, counterintuitive. In general, EIGRP metric as a whole cannot be considered cumulative - only the delay component is. Even if no variance is in effect and you are simply looking at the basic computation of a path metric in EIGRP, this is what you do in reality when you receive an update about a network X:
So in general, the metric is truly not cumulative because that would assume that you take the computed metric as known by your neighbor, and increase it by summing it with the metric of the interface toward that neighbor. Obviously, no such thing take place, as you have correctly commented yourself.
In addition, and this is where I would also like to correct you, it is not true that "FD = cost to neighbor + neighbor's RD". People misunderstand what Feasible Distance, or FD stands for. FD is not the current best distance to a destination, nor is it the computed distance to the destination over a particular neighbor. Feasible Distance is the record of the lowest known distance to the destination since the last time the destination transitioned from Active to Passive state; in other words, FD is a historical minimum of the distance to the destination since the path was last computed. There is exactly one FD per destination, and it is not bound to any particular neighbor, nor is it necessarily equal to the current best distance (obviously over the current sucessor). FD is not used as the path's metric, is not installed into the routing table, and is not advertised to neighbors. FD can only be seen in the show ip eigrp topology output and is only used for testing the Feasibility Condition conformance, nothing more - thus, it is an internal variable of a specific prefix known to EIGRP.
The metric of a path through a particular neighbor is commonly called the Computed Distance. Interestingly enough, this name is not typically used in official document about EIGRP but it does appear in SNMP MIBs for EIGRP managed objects. Nonetheless, the computation in the steps outlined above in fact computes a CD to the destination X over a particular neighbor. Obviously, the neighbor satisfying the Feasibility Condition (that is, RD<FD) and providing the least CD is the successor. All other neighbors satisfying the Feasibility Condition but providing higher-than-lowest CD are feasible successors.
Following this, implementing the unequal cost load balancing to a particular destination X is trivial. For each neighbor satisfying the Feasibility Condition (that is, all sucessors and feasible successors) and whose CD falls into the interval <best CD, variance x best CD>, use this neighbor as the next hop and install it into the routing table. That is all what is to the UCLB in EIGRP.
The document you have referenced simplifies the EIGRP metric to be constant, non-composite numbers. This is to aid readability and perhaps ease the understanding but it is not how EIGRP metrics work.
Best regards,
Peter
03-17-2015 01:12 AM
Hi Carlos,
I think you have posted this topic twice in two separate threads. You should probably delete the other one so that it does not confuse other readers seeking for the same answers.
I am going to provide my own view on this matter. It may - or may not, depending on what you find here - answer your question so please more than welcome to ask further.
Metrics in EIGRP are, in general, counterintuitive. In general, EIGRP metric as a whole cannot be considered cumulative - only the delay component is. Even if no variance is in effect and you are simply looking at the basic computation of a path metric in EIGRP, this is what you do in reality when you receive an update about a network X:
So in general, the metric is truly not cumulative because that would assume that you take the computed metric as known by your neighbor, and increase it by summing it with the metric of the interface toward that neighbor. Obviously, no such thing take place, as you have correctly commented yourself.
In addition, and this is where I would also like to correct you, it is not true that "FD = cost to neighbor + neighbor's RD". People misunderstand what Feasible Distance, or FD stands for. FD is not the current best distance to a destination, nor is it the computed distance to the destination over a particular neighbor. Feasible Distance is the record of the lowest known distance to the destination since the last time the destination transitioned from Active to Passive state; in other words, FD is a historical minimum of the distance to the destination since the path was last computed. There is exactly one FD per destination, and it is not bound to any particular neighbor, nor is it necessarily equal to the current best distance (obviously over the current sucessor). FD is not used as the path's metric, is not installed into the routing table, and is not advertised to neighbors. FD can only be seen in the show ip eigrp topology output and is only used for testing the Feasibility Condition conformance, nothing more - thus, it is an internal variable of a specific prefix known to EIGRP.
The metric of a path through a particular neighbor is commonly called the Computed Distance. Interestingly enough, this name is not typically used in official document about EIGRP but it does appear in SNMP MIBs for EIGRP managed objects. Nonetheless, the computation in the steps outlined above in fact computes a CD to the destination X over a particular neighbor. Obviously, the neighbor satisfying the Feasibility Condition (that is, RD<FD) and providing the least CD is the successor. All other neighbors satisfying the Feasibility Condition but providing higher-than-lowest CD are feasible successors.
Following this, implementing the unequal cost load balancing to a particular destination X is trivial. For each neighbor satisfying the Feasibility Condition (that is, all sucessors and feasible successors) and whose CD falls into the interval <best CD, variance x best CD>, use this neighbor as the next hop and install it into the routing table. That is all what is to the UCLB in EIGRP.
The document you have referenced simplifies the EIGRP metric to be constant, non-composite numbers. This is to aid readability and perhaps ease the understanding but it is not how EIGRP metrics work.
Best regards,
Peter
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: