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:
- Take the smaller value from the bandwidth metric component in the received update and from the bandwidth setting on the interface that received the update. Store this minimum in variable B.
- Take the delay metric component value from the received update, and add it to the delay setting on the interface that received the update. Store this sum of delays in variable D.
- The the smaller value from the reliability metric component in the received update and from the reliability value on the interface that received the update. Store this minimum in variable R.
- Take the higher value from the load metric component in the received update and from the load value on the interface that received the update. Store this maximum in variable L.
- Now, using the value B, D, R, L as determined above, do the usual EIGRP metric computation.
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
