EIGRP and Static (AD185) switch over problem in NEXUS

Rupesh Kashyap · ‎12-23-2009

Hi, I have two Nexus 7200, switches A & B. I am running EIGRP between them. I have configure Static Route for 172.28.22.0/24 pointing towards 172.19.33.4 in both switches, but I change the AD as 185. I have redistributed Static into EIGRP on both switches.

My problem is both switches are going through Static route, AD-185. Logic says that, one should go through Static and other should go on EIGRP having lower metric- 170. Please help why it is not happening.

SW-2# sh ip route 172.28.22.0
IP Route Table for VRF "default"
172.28.22.0/24, 1 ucast next-hops, 0 mcast next-hops
*via 172.19.33.4, Vlan333, [185/0], 00:00:10, static

DDC2-ED2# sh ip ei topology 172.28.22.0 255.255.255.0

IP-EIGRP (AS 1): Topology entry for 172.28.22.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 51200
Routing Descriptor Blocks:
0.0.0.0, from Rstatic, Send flag is 0x0
      Composite metric is (51200/0), Route is External
      Vector metric:
        Minimum bandwidth is 100000 Kbit
        Total delay is 1000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1492
        Hop count is 0
      External data:
        Originating router is 10.80.0.68 (this system)
        AS number of route is 0
        External protocol is Static, external metric is 0
        Administrator tag is 0 (0x00000000)

10.80.3.69 (port-channel3), from 10.80.3.69, Send flag is 0x0
      Composite metric is (51712/51456), Route is External
      Vector metric:
        Minimum bandwidth is 100000 Kbit
        Total delay is 1020 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1492
        Hop count is 2
      External data:
        Originating router is 10.80.0.64
        AS number of route is 0
        External protocol is Static, external metric is 0
        Administrator tag is 0 (0x00000000)

Peter Paluch · ‎12-23-2009

Hello Rupesh,

Note that you have created a potentially unstable situation in your network. You have two routers, each of them has a static route towards the same destination 172.28.22.0/24. This static route is made less preferred than the EIGRP-distributed external network. Now, you redistribute the network into EIGRP and you expect that the routing tables on both routers will contain the EIGRP-discovered network instead of the static route. However, that is not possible - the explanation follows.

Imagine that both routers actually replace the static route with the EIGRP external route. That means that the route 172.28.22.0/24 is no longer identified as static in your routing table, but instead, it is an EIGRP external route. Therefore, this network can no longer be redistributed into EIGRP as static because it is not present in the routing table as static. As a result, it will be removed from the EIGRP topology table and subsequently from the entire EIGRP routing domain. Therefore, it will disappear from the routing tables on both routers as EIGRP-discovered route, and after a while, it will be replaced by the static route from the configuration. However, as this route is static again, it will be redistributed back into EIGRP and advertised, thereby potentially repeating the entire process again. The route could be flapping between EIGRP and static source in your routing table but it is not possible for both routers to consistently hold the EIGRP-discovered route in your routing tables. The route must first be present in the routing table as a static route, only then it can be redistributed into EIGRP (assuming that you are using the redistribute static command). If it is not present as static, it cannot be redistributed into EIGRP.

This flapping is more theoretical than a practical issue. In real life, some router will ultimately be faster than the other, resulting in a situation where one router has the 172.28.22.0/24 network in its routing table as static and redistributing it into EIGRP while the other knows the network from EIGRP, thereby suppressing its own static route to the same destination. So, one router will be using its own static route while the other will be using the EIGRP-discovered route, and this will remain as the stable state of your routing tables.

This was to illustrate that what you have created and expected is not valid in general practice. However, your case seems to be slightly different, as you are implying that both routers actually know about EIGRP-discovered route to the destination from their peer while still retaining the static route in their routing tables. I can only hypothesize here that if the EIGRP ecounters a network that is both redistributed into the EIGRP locally, and is discovered by EIGRP as an external network which was redistributed from the same routing source as you are using locally (the static routes in your case), then the EIGRP decides to ignore that advertisement and instead it believes more its local source of information, despite the administrative distance is not favorable. This is just my guess but in the light of the possible complications I have highlighted earlier, this seems to me to be a sensible precaution.

Best regards,

Peter