"Troubleshooting EIGRP"

I ran into an odd problem recently...

I had recently migrated my core network from OSPF to EIGRP (OSPF was crashing on one of my BGP speakers due to what I presume to be an IOS bug). After migrating, everything was working fine, but one day I noticed something strange:

   /-------iBGP-----\
  /                  \
loop0               loop0
  |                   |
  R2 ------EIGRP----- R1 ------eBGP------ TRANSIT_PROVIDER ------ INTERNET

Network structure is as above.

What I noticed was that in addition to the /29 (used for the EIGRP link between R2 and R1), the entire /24 which (contains this /29) was also being advertised to R2 by EIGRP on R1. Here's the view from R2:

    R2#show ip route | include 192.168.1.0
          192.168.1.0/24 is variably subnetted, 4 subnets, 4 masks
    D        192.168.1.0/24 [90/28160] via 192.168.1.1, 00:00:23, FastEthernet1/0
    C        192.168.1.0/29 is directly connected, FastEthernet1/0

This was despite:

  1. Using "no auto-summary"
  2. Using "no redistribute-static"
  3. Configuring eigrp with:
    router eigrp ASN
        network 192.168.1.0 255.255.255.248

So why would EIGRP simply decide that I'd like to advertise the entire /24 to my neighbour? The culprit turned out to be this static route:

    ip route 192.168.1.0 255.255.255.0 Null0 200

I'd added this route to "pin" the entire /24 so that BGP would advertise it. Without this, I'd either need to aggregate the range, or apply the whole range to an interface. The first option I dislike; the second didn't suit my topology.

Once I removed this static route, EIGRP ceased advertising the /24 to its peer (excellent) but BGP would obviously break (BGP will only advertise a prefix if it knows how to reach all IPs within it). Some google-fu turned up an interesting page ( http://www.ciscopress.com/articles/article.asp?p=27839&seqNum=3 ) which explained that EIGRP was considering my static route as directly connected, as the route directs traffic to a directly connected interface (even if it is just Null0).

I conceded that there was no nice way to change EIGRP's behaviour (OSPF never performed this "trick"), so what was the solution? In the end, I went with prefix-filtering using EIGRP's "distribute-list" feature:

    ip prefix-list EIGRP_OUT seq 5 deny 192.168.1.0/24
    ip prefix-list EIGRP_OUT seq 10 permit 0.0.0.0/0 le 32

    router eigrp ASN
        distribute-list prefix EIGRP_OUT out

Here's a snippet of the debug output on R1 after making these changes:

    *Dec 18 16:53:42.126: EIGRP-IPv4(1): table(default): 192.168.1.0/29 - do advertise out FastEthernet1/0
    *Dec 18 16:53:42.130: EIGRP-IPv4(1): table(default): 192.168.1.0/24 - denied by distribute list

And the updated view from R2:

R2#show ip route | in 192.168.1
          192.168.1.0/24 is variably subnetted, 4 subnets, 4 masks
    B        192.168.1.0/24 [200/0] via 10.1.1.1, 00:01:02
    C        192.168.1.0/29 is directly connected, FastEthernet1/0

Happy days!

Richard