Dead Peer Detection for simple (non VPN) adjacent devices?

[MicJameson1]

Hello.

INTENT: Implement a solution that, when a pre-configured vendor box fails inside the LAN, the adjacent device will identify this failure, and then will remove an EIGRP distributed static route to a public IP-address that recursively points to this private IP-address of this dead box.

I understand this can be done with IPsec tunnel technology-- "dead peer detection". My research does not reveal that this DPD technology exists for simple links, especially for my situation where I have no config access to the vendor box. 

QUESTION: What is the best solution to accomplish above intent?

Thank you.

[Joseph W. Doherty]

Not being happy with the different distance approach (still kudos to @MHM Cisco World), as it can possibly fail due to an inadvertently matching metric (again, very, very unlikely), I continued to ponder on this problem and I found another way to accomplish this, w/o using different distances.

On primary router, if you change static to not have a next-hop, but with just an egress interface, you can have it injected into EIGRP using a EIGRP network statement (much like you would do for other interfaces).  What this does is treat the static route as another "internal" EIGRP route.  Then, as long as secondary has an AD higher then EIGRP internal route AD cost (default 90), it injects, or not, its external.

I've also thought using "mutual redistribution" techniques might work too.  Likely more complicated, but might try a couple of experiments.

[Richard Burts]

Joseph

I admire your creative thinking, but I am not convinced that this is a good solution. In the first place I am not convinced that it would work. I agree that a static route that specifies an egress interface without a next hop does indicate to IOS that the destination address/subnet/network is locally connected. But I am not sure that this extends to being selected by a network statement. My understanding is that the network statement looks for interface addresses in configuration statements and uses any matching interfaces as active in the protocol. I wonder if the static/locally connected satisfies the condition. Have you tested this? (I currently do not have the ability to test it so wonder if you have).

Even if it works I believe that this is a flawed suggestion. It seems that I respond with some frequency to suggestions about a static route specifying only the egress interface. My concerns include these aspects:

- specifying egress interface without a next hop only works if the next hop device supports proxy arp. And a number of organizations/ISPs are disabling proxy arp because of the security implications.

- if the next hop does support proxy arp this configuration requires that the router arp for EVERY remote destination address. That leads to these results:

--much larger arp table requiring more memory for the table

--refreshing every entry in the arp table every 4 hours which results in increased cpu to generate arp request and process arp response, and increased bandwidth used for arp request and response.

- and my biggest concern is that a static route like this will only be withdrawn from the routing table if the interface changes to protocol down. If there is a problem with the next hop device (which was part of the criteria in the original post) the static route remains in the routing table. Where is the failover in your suggestion?

[Joseph W. Doherty]

Rick, before I posted my prior reply, indeed I did test this within CML; from my testing, it appears to work fine.

BTW, it was reading Cisco documentation that I learned about EIGRP's network statement supporting this; I was previously unaware of this capability.  Also, BTW, Cisco made it clear the next hop could not be present, within the static route statement, which I confirmed in my testing.

The default behavior for RIP, IGRP and EIGRP is to advertise directly connected routes when a network statement under the routing protocol includes the connected interface subnet. There are two methods to get a connected route:

• An interface is configured with an IP address and mask, this corresponding subnet is considered a connected route.
• A static route is configured with only an outgoing interface, and not an IP next-hop, this is also considered a connected route.

What I didn't test was the original static being withdrawn via interface going down, as earlier in this thread the suggestion was made to use tracking.  (I also didn't test tracking.)

Yes, I too thought about the issues involved with using a static route statement without a next hop, but I don't think this instance is as "flawed" as in almost all the other cases you comment on, because this is not a case of using a default route without a next hop.

In fact, the destination "network" is a host address (or so is my understanding from the OP's information).

So, unless I'm mistaken, the impact of ARPing for the destination /32 "network" would be about the same as ARPing for the next hop (i.e. the same IP, same frequency, etc.)

It's unclear whether the targeted host would be on a directly connected network, or not (I too presume the latter).  If not, your concern about proxy ARP being supported on the next hop interface is valid!

Rick, if you still see an issue using a /32 network static, without a next hop, other than the proxy issue, please post what I've missed.

BTW, the two approaches boil down to:

primary:
router eigrp #
redistribute static metric 100 100 255 1 1500
ip route <pri-host-IP> 255.255.255.255 #.#.#.# track #

secondary:
router eigrp #
redistribute static metric 100 1000 255 1 1500
ip route <sec-host-IP> 255.255.255.255 #.#.#.# 175

=== versus ===

primary:
router eigrp #
network <pri-host-IP>
ip route <pri-host-IP> 255.255.255.255 <interface> track #

secondary:
router eigrp #
redistribute static
ip route <sec-host-IP> 255.255.255.255 #.#.#.# 175

In my prior posting, I mentioned I was going to experiment more, and I did. What I additionally tried, did not work, for reasons I won't list, but it still might have been possible to work around those reasons, but I look for simplicity, not additional complexity, i.e. what else I had in mind was getting to be Rube Goldberg like.

However, another somewhat simple approach, which I have not tested, would be to advertise the static through egress EIGRP summarization.  That, I believe, would require a summarization statement on every EIGRP interface.

[Richard Burts]

Joseph

Well done, and a well deserved helpful vote! Glad that you tested and verified that the egress interface without a next hop does satisfy the eigrp network statement. I have learned something new. Thank you!

Yes my concerns about a static route with egress interface but no next hop are especially oriented to default route or route to large network. When the static route is for a host address there is not much impact. And including track does address the failover. So I now agree that your suggestion of a static route with egress interface but no next hop is a viable solution. 

[Joseph W. Doherty]

Rick, a return helpful vote, not for your kind compliment, nor for your helpful vote, but for your "peer review" which I much appreciate.

Glad to read you've learned something new (I've learn much pursuing this issue), but, BTW, I've learned much from your posts over the years.  So, thank you.

In general, the routing behavior I've seen pursing this issue, personally, I consider either a bug in the software, or a design defect.  The problem issue is, the "secondary" static route injection doesn't withdraw when the "primary" static route appears.  This I suspect because when the router looks at the "route" it's the same prefix, same route type, same metric, as what it injected.  So, it ignores withdrawing itself for a route, in deference to a route with a lower AD.  When we change the distance or route type, then it "works".  Why I consider this a bug or design defect, I believe the secondary router could/should take note of source of the route, i.e. same as itself (don't withdraw), or different (withdraw).

To, @MicJameson1 it looks like you have at least two (possible 3), approaches that might serve your need.

Which is better?  Personally, I think they are, more-or-less, a toss up.  Each offers some subtle pros and cons, and the relative importance of those would depend on your environment and what you feel is easier to support.  For example, a con of using a network statement to insure the "primary" static, it's likely to be unusual.  Laugh, though, that's also a pro, as by being unusual, sort of indicates, you better understand why this is this way before you touch it.  Another con, as Rick correctly pointed out, the network statement approach will require next hop to support proxy ARP.

For the "distance" approach, it, using just the one distance statement, can impact much more than the one static we want it to.  However, you can get down to specific routes, but then complexity goes up.  And, so it goes, etc.

Please post a follow-up, whatever you eventually do, and how well it works.