Hello Noe,
Feasible distance is the best metric along the Path
Not entirely. The Feasible Distance, or FD in short, is the historical minimum of the best metric towards that particular destination (with the history starting from scratch when the route neds to enter the Active state and then returns back to Passive state). This means that the FD may be equal to or lower than the current total best metric towards the destination, including the link to the next hop (or successor in EIGRP parlance).
Also, there is only a single FD for a given destination. Some authors sometime make gross mistakes when they talk about "FD through neighbor A, and FD through neighbor B". What they really have in mind is simply the total distance via the neighbor A or neighbor B, including the cost of the link to these neighbors. However, the FD is not associated with a particular neighbor, only with a particular route.
Also, FD is never sent out or advertised to anyone. It is always kept inside a router and used for internal EIGRP needs (in particular, the feasible condition check) but it it never being shared with any other router.
This is one of the most commonly appearing misconceptions about EIGRP and seems to persist for some reason.
Reported Distance is the metric/value between the destination and the first hop next to the source
Yes, or in other words, the Reported Distance, or RD, as advertised by a particular neighbor, is its current total distance to a particular destination. It is simply the neighbor's own distance to the destination. Our total distance via a particular neighbor is that neighbor's RD plus the metric of the link between us and that neighbor.
10,000000/56+2000x256 = 46226285 ( the metric between the source and the upstream neighbor) plus the reported distance 307200 the total metric will be 46533485 instead of 46277376.
This is not correct. You have to remember that EIGRP uses a composite metric that, as a whole, behaves in a non-linear and non-additive way - in particular, the bandwidth is not added to but rather the bandwidth is taken as the minimum of the reported bandwidth and the interface bandwidth. Only the delay is additive.
What EIGRP really does is always advertise the individual metric components (bandwidth, delay, reliability, load) but never the resulting metric itself. Advertising the resulting metric would make it impossible to select the minimal bandwidth and increase the delay. Instead, you always have to look at the metric components and compute the resulting metric yourself (that's why it is absolutely necessary to have the K-values on all EIGRP routers within your AS identical).
So for the route via router 3, the total metric would be:
Bandwidth: min(10000, 128) = 128
Delay: 1000+200 = 1200
Total metric via router 3: (10000000/128 + 1200) * 256 = 20307200
For the route via router 4, the total metric would be:
Bandwidth: min(10000, 56) = 56
Delay: 2000 + 200 = 2200
Total metric via router 4: (10000000/56 + 2200) * 256 = 46277376
These values align with the Cisco document you referenced perfectly.
If the metric in EIGRP was a simple constant assigned to an interface, then your original idea of taking the RD from the neighbor and increasing it by the metric of the link to that neighbor would work perfectly. But EIGRP in particular uses a metric that cannot be simply added to, mostly because of the min() function used for bandwidth. Instead, your perform the necessary operations on the metric components first, and only then you compute the resulting metric.
Does this make sense? Please feel welcome to ask further!
Best regards,
Peter
