Why is EIGRP automatically redistributing a static route?

[johnnylingo]

Spotted this in my CCIE lab and am rather baffled.  Why would EIGRP redistribute a static route even though I've configured it not to?

Configuration:

ip classess

!

router eigrp 65100
network 198.19.0.0 0.0.1.255
no auto-summary
!

ip route 198.19.0.0 255.255.0.0 Null0

CORE-2#sh ip eigrp top 198.19.0.0/16
IP-EIGRP (AS 65100): Topology entry for 198.19.0.0/16
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 256
  Routing Descriptor Blocks:
  0.0.0.0, from Rstatic, Send flag is 0x0
      Composite metric is (256/0), Route is Internal
      Vector metric:
        Minimum bandwidth is 10000000 Kbit
        Total delay is 0 microseconds
        Reliability is 0/255
        Load is 0/255
        Minimum MTU is 1500
        Hop count is 0

[marikakis]

Hi Johnny,

It's really past my bedtime and we should not count on my subnetting skills right now. Can you do the following tests?

a. network 10.0.0.0/8 AND static routes with masks /7, /8, /9, /16, /24, /25 (first 2 should contain network and the rest be contained in network)

b. network 10.10.0.0/16 AND static routes with masks /15, /16, /17, /24, /25 (first 2 should contain network and the rest be contained in network)

1. At the beginning of each test put each static route alone and see what happens

2. Then try to add them all from more specific to less specific (maybe it would be interesting to make each specific contained in all the less specific ones)

3. Repeat 2 in reverse order

Kind Regards,

Maria

[Peter Paluch]

Hi Johnny,

Please repeat your experiment but any time you change the EIGRP configuration and/or the static routes in your routing table, issue the command clear ip route * on your CORE-2 router and wait up to 15-20 seconds before looking into the EIGRP topology table. I have had somewhat similar experience to yours but it turned out that the EIGRP missed to detect changes in the routing table contents. The clear ip route * should tickle the EIGRP process strong enough to notice that the contents of the routing table have changed.

Best regards,

Peter

[johnnylingo]

What I found that clearing the route table doesn't affect the routes, but sometimes changes the FD:

CORE-2#clear ip route *

CORE-2#sh ip eigrp top | inc 172\.
P 172.30.0.0/16, 1 successors, FD is 256
P 172.20.0.0/14, 1 successors, FD is 256

[marikakis]

Hi Johnny,

When doing explicit redistribution into EIGRP, for Connected and Static routes the metric information is taken from the associated interfaces. Can you check if this makes any sense in the context of your results?

You are taking your revenge now, don't you? I feel under DDoS from test results! I am trying to write down a summary of your results and I feel confused sometimes. Up to now, it is clear that you should not use next-hop information to explore this behavior. There are 3 parameters in your tests. The classful mask of the network you are using, the mask of the network statement,  and the mask of the static route. Try to keep as many parameters constant while exploring possibilities. Also, maybe you should note each time the mask of any interfaces included in the network you are exploring (when such an interface exists).

Kind Regards,

Maria

[johnnylingo]

When doing explicit redistribution into EIGRP, for Connected and Static routes the metric information is taken from the associated interfaces. Can you check if this makes any sense in the context of your results?

Absolutely correct.  If I change the static route to Serial0/0, the FD changes from 256 to 2178560.  If I add the new route before deleting the existing one, then "clear ip route *" is needed for the FD change to be picked up.

[milan.kulik]

Hi Maria,

I just met a very similar problem in another thread.

It might be interesting for you your favorite book is explaining that.

See my post I just added to

https://supportforums.cisco.com/message/3257434#3257434

BR,

Milan

[david scott]

Think of the routing process as advertising connected subnets instead of connected interfaces.

A connected Subnet (it's not via any hops):

ip route 198.19.0.0 255.255.0.0 via serial 0

Not a connected subnet (it's at least a hop away):

ip route 198.19.1.0 255.255.0.0 via 10.10.10.1

[Flanger23]

I know this is an old thread, but I found one workaround yesterday. Had exactly the same problem with two 4500-X switches. One switch would advertise summary static route pointing to Null0 as external and another one advertised it as internal route. Exactly the same behavior OP has posted. Both switches had identical IOS version and configuration (explicitly redistributing static route in eigrp configuration).

After several hours of reading same configuration lines over and over and resetting EIGRP neighbor sessions many times, I noticed one difference. Previously the switch, which was advertising static as internal, had network statment 0.0.0.0 configured (which would also include static to null0) and then it was removed from configuration. Other switch never had matching network statment for given summary network.

This led me to thinking, that network statement gets stuck somewhere in memory in IOS, and although it is removed from configuration and does not match the networks exclusively, the effect for directly connected static networks remains the same. So I've deleted whole EIGRP process, reconfigured it and the redistribution started working correctly!

D EX     10.30.0.0/16 
           [170/1734656] via 10.30.252.2, 10:32:08, GigabitEthernet0/0/1.400
D        10.30.144.0/24 
           [90/28672] via 10.30.252.2, 10:32:08, GigabitEthernet0/0/1.400

EIGRP-IPv4 Topology Entry for AS(1311)/ID(10.30.255.1) for 10.30.0.0/16
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 1709056
Descriptor Blocks:
0.0.0.0, from Rstatic, Send flag is 0x0
Composite metric is (1709056/0), route is External
Vector metric:
Minimum bandwidth is 1500 Kbit
Total delay is 100 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1
Hop count is 0
Originating router is 10.30.255.1
External data:
AS number of route is 0
External protocol is Static, external metric is 0
Administrator tag is 0 (0x00000000)