Eigrp Static Redistribution Behavior

[legerity1_2]

Ok, so here's the scenario I'd like to share with the group.

I have an EIGRP enabled router attached to an ASA, which is an EIGRP neighbor.  Often, I'll redistribute static routes that are for vpn users and remote sites on the next to last hop before a firewall, allowing all traffic inside the routing doamin to flow towards the firewall and then through appropriate IPSEC configs.  One can use reverse route injection, but for small, non complex environments, I generally don't bother.  I do this all day long with OSPF.

I did this in EIGRP and noticed a strange (strange to me, being a mostly OSPF guy) behavior.  When I redistribute a route, let's say 10.20.0.0/24 using the redistribute static route map command:

int x

ip address 10.10.0.1 255.255.255.224

!

router eigrp x

network 10.10.0.0 0.0.255.255

redistribute static route-map dist

no auto-summary

!

ip route 10.20.0.0 255.255.255.0 10.10.0.10 (asa)

!

route-map dist permit 10

  match ip address 10

!

In this scenario, the asa firewall (10.10.0.10) installs an external route [D EX] BACK to the router (10.10.0.1), as if it's ignoring that the next hop for the route is itself, resulting in a routing loop, ttl expired packets, etc. instead of the packets flowing through ipsec tunnels.  I've labbed this up, and the behavior is consistent with routers running EIGRP.  This doesn't happen in OSPF.

I can guess at all kinds of reasons why this might be (not a link state protocol, so isn't able to discern that the next hop is itself - assumes that the redistributed route is connected to the router that redistributes it, so sends the packet back towards the redirection source).  Doyle and CCIE Exam guide doesn't go deep enough into the redist. logic to give me a clear explanation.

Any thoughts?

Regards,

Geoff

[Richard Burts]

Geoff

This is a very interesting situation. There is a small detail which you do not give us which might shed some light on the issue. Your route map uses access list 10 to control distribution. But you do not tell us what is in  access list 10. So we are not sure whether the redistributed route is via a permit in the access list/route map or something else.

It is a well established behavior of EIGRP (but sometimes not so well known) that if the next hop of a static route matches a network statement in EIGRP that EIGRP will advertise the static route as if it were a connected route. It is not clear but I suspect that this may be what is happening in your situation. It might be helpful if you could post the output of show ip eigrp topology for this route and it might help us to understand how it is treated by EIGRP.

I am surprised that the advertised route causes the problems that you describe since EIGRP usually has a very strict observation of the split horizon principle. It it is advertising a route toward the next hop of the route that would seem to violate the split horizon principle. Have you tried this on other versions of code? It sounds to me as if it were buggy behavior.

HTH

Rick

[legerity1_2]

rick - thanks for jumping in, much appreciated.  I share your surprise =)

this scenario has presented on 15 line of code peered to an ASA running 8.3 as well as 2 routers in GNS running 12.4 (25)

Here's the down stream router I've configured in GNS:

!

int fa0/0

  ip address 10.10.0.98 255.255.255.252

!

int fa1/0

ip address 10.10.0.1 255.255.255.224

!

router eigrp 100

  redistribute static route-map dist

  network 10.10.0.0 0.0.255.255

  no auto-summary

!

ip route 10.50.1.0 255.255.255.0 10.10.0.10

!

access-list 10 permit 10.50.1.0

!

route-map dist permit 10

  match ip address 10

Here's upstream, in this case standing in for asa, sloppy lab code, lol:

!

int fa0/0

  ip address 10.10.0.10 255.255.255.224

!

int fa1/0

ip address 72.100.100.66 255.255.255.240

!

router eigrp 100

  redistribute static

  network 10.10.0.0 0.0.255.255

  no auto-summary

!

ip route 0.0.0.0 0.0.0.0 72.100.100.65

!

Attached is the sh ip eigrp topo for each of above.

So there are a few ways around this, including more specific routes on asa, reverse route injection on ASA, etc. but, like you mentioned, why isn't split horizon keeping this route from being installed....

route on asa stand-in is listed as:

D  EX   10.50.1.0/24 [170/30720] via 10.10.0.1, 14:38:21, FastEthernet0/0

route on penultimate router is:

S   10.50.1.0/24 [1/0] via 10.10.0.10

So in essence, a good, old fashioned routing loop.  It's almost as if EIGRP on the ASA stand-in is ignoring that the next hop in the redistributed route is itself, and is therefore unable to determine that the route would fail split horizon...  Whereas OSPF, because it has visibility to link database is able, via SPT, to come to that conclusion?

OR, this is a simple configuration oversight. =)

Warm regards and thanks for any assistance,

Geoff

[Richard Burts]

Geoff

I do not have an explanation for this. I will continue to look at it and try to come up with something. But I hope that someone else in the forum may also have something to contribute on this.

HTH

Rick