Hi MHM,
The situation is more complex.
R4 is placed in a position where it is looking at the same destination network through two different advertising routers, and those two advertising routers - R6 and R9 - also happen to be redistribution points for that network so they have a complete power over the metric of the network and can set it to an arbitrary value. The way the redistribution is set up, the path through R9 should be with a total cost of 28416, the path through R6 should be with a total cost of 30720. The redistribution configuration never changes, so neither R6 nor R9 should change their mind about the cost of the redistributed route. Yet, apparently, exactly that happens on R9.
Now, the path through R9 is a combination of two EIGRP processes, and in the process 200, the metric of 192.168.99.0/24 is significantly lower (thanks to an overriding metric configured in the redistribution) than in the process 100 which is the original proces that carries the information about this network. On R9, in process 100, the composite metric of the route to 192.168.99.0/24 through R10 is 25630720 while in process 200, the composite metric through R4 is merely 33280 (that is the result of R9 deciding to use the path through R4 instead of staying with the path through R10). You could say - sure, the path is shorter! - but that would be a wrong understanding.
If R9 first redistributed the route from process 100 to process 200, the network in process 100 was first in its routing table with the high metric of 25630720, and it just got reinjected into process 200 with an overriden metric of 2816 = (10+1)*256. However, this reinjected route in process 200 would itself never override the original route in RIB because that is the basic rule of redistribution: Even if the redistributed route ends in a local routing process that has a lower AD and/or a lower metric, the original route must stay in the routing table untouched because it is the source for the redistribution.
The output from R9, however, shows something quite different:
R9# show ip eigrp topology 192.168.99.0/24
IP-EIGRP (AS 200 Topology entry for 192.168.99.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 33280
Routing Descriptor Blocks:
10.160.40.137 (FastEthernet0/0), from 10.160.40.137, Send flag is 0x0
Composite metric is (33280/30720), Route is External
Vector metric:
Minimum bandwidth is 100000 Kbit
Total delay is 300 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2
External data:
Originating router is 57.213.9.110
AS number of route is 65001
External protocol is BGP, external metric is 0
Administrator tag is 65003 (0x00003637)
IP-EIGRP (AS 100 Topology entry for 192.168.99.0/24
State is Passive, Query origin flag is 1, 0 Successor(s), FD is 4294967295
Routing Descriptor Blocks:
10.160.40.146 (FastEthernet0/1), from 10.160.40.146, Send flag is 0x0
Composite metric is (25630720/25628160), Route is External
Vector metric:
Minimum bandwidth is 100 Kbit
Total delay is 1200 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2
External data:
Originating router is 10.43.13.233
AS number of route is 0
External protocol is Static, external metric is 0
Administrator tag is 0 (0x00000000)
Note that in process 200, there is no mention of the locally redistributed route, only the route learned back from R4. In process 100, FD is set to infinity due to the fact that the process 100 was unable to install its own variant of the route into the routing table (a so-called zero-successor route) and so is marked as unusable even if learned. In fact, exactly because the process 100 does not own the route to 192.168.99.0/24 in the RIB on R9 anymore, there is no redistribution from process 100 to process 200 happening, and so there is no locally redistributed route in the process 200.
But clearly, at the beginning, the process 100 on R9 did have the route to 192.168.99.0/24 installed in the RIB and redistributed into process 200. So what happened that this has changed? The redistribution alone would not have caused process 200 overturn process 100.
A possible answer is that R4 advertised the route to 192.168.99.0/24 to R9. But let's break this up into details: Just what could have R4 advertised? The relevant debugs are:
*Mar 1 01:04:44.875: RT: add 192.168.99.0/24 via 10.160.40.138, eigrp metric [170/28416]
*Mar 1 01:04:44.875: RT: NET-RED 192.168.99.0/24
*Mar 1 01:04:44.875: DUAL: RT installed 192.168.99.0/24 via 10.160.40.138
*Mar 1 01:04:44.875: DUAL: Send update about 192.168.99.0/24. Reason: metric chg
*Mar 1 01:04:44.875: DUAL: Send update about 192.168.99.0/24. Reason: new if
Here, R4 picked the route through R9 and sent updates about it. But with EIGRP, we have split horizon with poisoned reverse. Unless it was deactivated on R4 - and that's why I asked Eric if he changed its setting - R9 would have received a poisoned reverse update from R4 which it should not have cared about at all because it wasn't using the path through R4 anyway.
So either R9 unexpectedly reacted even to the poisoned reverse from R4, or the split horizon on R4 was in fact disabled and then R4 advertised the network with the metric of 28416 to R9. R9 would then realize that it had a better path to 192.168.99.0/24 with a total metric of 33280 instead of 25630720... and that would explain some thing.
But unless we have this nailed down and clarified beyond doubt, we do not really know what is happening. There are quite a few things that should not have happened here and that don't make sense, at least not intuitively. Hence, I am not accepting an arbitrary manipulation with metrics as a solution - without understanding exactly what is going on and why the manipulation would solve it, it is a blind shot which, if it works, it works only by chance and coincidence.
Best regards,
Peter
