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

[jmaxwellUSAF]

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]

Pondering about what I've been trying, I believe I've overlooked a basic requirement, a rookie mistake.

For my basic concept to work, we need primary static AD < primary redistributed AD < secondary static AD < secondary redistributed AD.  My PT configuration was not configured for that.  I believe I can configure for that.  Will try later today and post results.

[Joseph W. Doherty]

PT still not working as expected, but I think (?) what I've now configured should work.

Topology is:

R1 (primary static next hop) 192.168.10.2/24 <> 192.168.10.1/24 R0 (primary static w/redistrib) 192.168.1.1/24  <EIGRP> 192.168.1.2/24  R2 192.168.2.2/24 <EIGRP> 192.168.2.1/24 R4 (secondary static w/redistrib) 192.168.20.1/24 <> 192.168.2.2/24 R3 (secondary static next hop)

R0:
router eigrp 1
redistribute static metric 10000 100 255 1 1500
network 192.168.1.0
ip route 1.1.1.1 255.255.255.255 192.168.10.2

R2:
router eigrp 1
network 192.168.1.0
network 192.168.2.0

R4:
router eigrp 1
distance eigrp 90 180
redistribute static metric 10000 100 255 1 1500
network 192.168.2.0
ip route 1.1.1.1 255.255.255.255 192.168.20.2 175

What I see on R2:

Gateway of last resort is not set

     1.0.0.0/32 is subnetted, 1 subnets
D EX    1.1.1.1/32 [170/281856] via 192.168.1.1, 00:18:50, GigabitEthernet0/0/0
                   [170/281856] via 192.168.2.1, 00:00:23, GigabitEthernet0/0/1
     192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C       192.168.1.0/24 is directly connected, GigabitEthernet0/0/0
L       192.168.1.2/32 is directly connected, GigabitEthernet0/0/0
     192.168.2.0/24 is variably subnetted, 2 subnets, 2 masks
C       192.168.2.0/24 is directly connected, GigabitEthernet0/0/1
L       192.168.2.2/32 is directly connected, GigabitEthernet0/0/1

but what I think we should see is:

D EX 1.1.1.1/32 [170/281856] via 192.168.1.1, 00:18:50, GigabitEthernet0/0/0
                         [180/281856] via 192.168.2.1, 00:00:23, GigabitEthernet0/0/1

Again, I did once see, on R2 "180" for AD from .2.1., so I do wonder whether PT is inconsistent.

BTW, in the above R1 and R3 don't need to be routers, just cloned them to "nail up" the static routes next hop link.

@MHM Cisco World if the above makes sense, can you lab the above on a "real" emulator?

[MHM Cisco World]

Sure friend but I need just topology, I will apply the config as you list above. 
thanks 

[Joseph W. Doherty]

Ah, may have just figured out a major misunderstanding on my part.

EIGRP's "distance" isn't sent with routes exchanged within EIGRP, it appears it only changes the AD for any EIGRP routes received.

If that's correct, it impacts how this might be done.  Got to think some more on this . . .

[Joseph W. Doherty]

More testing in PT, makes me believe something isn't right; I suspect PT isn't fully working correctly.

@MHM Cisco World might you build a similar topology, as I earlier described?

If you "mirror" my topology, start with:

R0:
router eigrp 1
redistribute static
network 192.168.1.0

R2:
router eigrp 1
network 192.168.1.0
network 192.168.2.0

R4:
router eigrp 1
redistribute static
network 192.168.2.0

Verify R0 and R4 see network on the other side of R2.

Then add:

R4:
router eigrp 1
ip route 1.1.1.1 255.255.255.255 192.168.20.2 175

What you should see is static with 175 AD on R4 and EIGRP external on R0 and R2 with AD of 170.  (I get this with PT.)

Then add:

R0:
router eigrp 1
ip route 1.1.1.1 255.255.255.255 192.168.10.2

What I expect to see, is static on R0 with AD 1 and EIGRP externals on R2 and R4 with AD 170 also expect to see R2's source of 1.1.1.1 shift to 192.168.1.1.  (I don't get this with PT.  On PT I see the change on R2 but no change on R4.)

Let me know result, and depending on it, we can figure out what to try next.

[Joseph W. Doherty]

I've obtained a copy of Cisco's CML-personal, spun it up and implement, basically, the same topology I had in PT.

I'm getting the same unexpected (to me) results I saw in PT.  (BTW, I'm wondering if PT might just use a lobotomized version of CML'S virtual IOSs.)

What's unexpected?

Well, after I have EIGRP configured between 3 routers, e.g. R1 <> R2 <> R3, R1 sees R2:R3 network, and R3 sees R1:R2 network, and R1 can ping R3 and the converse.  I.e. all as expected.

If I add a redistributed static, to either R1 or R3, the other two routers see the redistributed static as a "D EX".  I.e. all as expected.

If I start with the a static on R3, with an AD of 175, then add same destination network static on R1 with AD of 1, R2 has two "D EX" and R3 retains its static, again with AD 175.  This is NOT expected!  I though R3 would see the "D EX" from R1 and withdraw its static.

If I then manually remove static from R3, R3 static route is withdrawn from both R2 and R3.  This is expected.

If I then, again, re-add R2 static with AD 175, static does not appear in R2 or R3.  This is expected.

If I remove static from R1, R3's static appears on both R1 and R2.  This is expected.

If I again, add R1 static, with AD 1, we're back to seeing R1 and R3 static as "D EX" on R2 and R3 doesn't remove its AD 175 static.

I.e. behavior of R2 appears to be, when adding static, with higher AD then 170, it doesn't replace an existing prefix, but if static gets into redistribution "first" it doesn't remove itself when a redistributed static then appears.

I'm now also tempted to spin up a copy of GNS3, to see if "real" emulated Cisco IOS versions show the same behavior.

At the moment, though, I cannot explain why initial redistribution of a higher AD static behaves as expected when it conflict with another same prefix redistributed route, but not doesn't when another same prefix redistribute route, with a lower AD doesn't force it to withdraw itself.

Perhaps this is the way EIGRP just works, which might explain why I was different posting complaining about EIGRP's externals and ADs.

[MHM Cisco World]

Dont worry I will check it tonight.

Update you soon.

[jmaxwellUSAF]

Hi folks. My rarely-available senior engineer (CCIE 20 years) just answered this for me. And I (the OP) am satisfied.

He stated that the essence of this successful config is to insert the original backup route with an AD of 175 before redistribution.

I didn't think this would work because I thought this route, when redistributed, would have an AD of 170. THIS IS NOT EXACTLY LOGICALLY CORRECT because, although I execute the "#redistribute static" command, that route actually never enters the routing table until the primary redistributed route with AD 170 fails. 

In other words, in the healthy situation the routing table has a primary route with AD 170, and a secondary route NOT in the routing table, but only in the routing database with an AD of 175. Even though that 175 route was configured with "redistribute static", it never enteres the routing table. It just sits un-redistributed at 175 in the database.

When the primary route fails, that triggers the AD 175 route into the database, AND AT THAT MOMENT it gets actively redistributed with an AD of 170.

Hope that helps!

[Joseph W. Doherty]

Yes that's the behavior I'm seeing, but . . .

When original/primary is restored, the secondary doesn't automatically get withdrawn!!!

If the original/primary comes back on-line, you'll have two paths for the same route!

Assuming both paths being active is an issue, you need to insure original/primary doesn't come back on-line, remove secondary static insertion, bring original/primary back on-line and finally restore the secondary static insertion.

Of course, while making all these changes, you'll lose both primary and secondary routes.  Also, of course, unsure how you preclude the original/primary from coming back on-line before you want it (much would depend on nature of failure).

Actually, (and again if duplicate paths would be an issue) you really might need, for a failure, manually insure the primary cannot come back on-line until you're ready for it, and then manually bring the secondary on-line.

Personally, though, I would much prefer to see the primary, when it comes back on-line to also automatically push aside the secondary.  Also, personally, what I'm seeing may be expected behavior for EIGRP (?), but if so, it's "ugly".

BTW, AD isn't redistributed, it's local to the router.  I.e. each router decides what AD to assign to received prefixes.

Also BTW, as it appears ADs, even with EIGRP, might be assigned per prefix based on its source, we could always make the secondary redistributed prefix have a higher AD than the primary (on each router).  Which may work well for all routers except the actual secondary redistribution router, but I was looking for an approach that, ideally, might only need to be applied to one router, or two (primary, secondary).  EGRIP metrics, though, can be done at the source router(s).  The secondary redistribution router, would still be problematic. 

Possibly, an EEM script could examine the route table and only configure static redistribution when prefix is not in route table.  That might be a one router approach that would work correctly, without any manual intervention.

[MHM Cisco World]

No EEM no prefix save in routing table (with respect to all CCIE)
I have limit so limit time these days so sorry for delay.
this my second time in one week I win against multi CCIE LOL...

solution 
the issue in IOU3 which dont see the static up/down and dont see static AD high/low since both advertise the same prefix with same metric 
solution is config different metric when redistribute static into EIGRP 
this force IOU3 select the path to static primary and when down/up it can detect it and inform other router include IOU2

interface to IOU4 is down 
the traffic immediate go through back IOU2

the interface to IOU4 is up again 
the EIGRP redistribute the static without any issue 

[Joseph W. Doherty]

Could you please post the configs?

[MHM Cisco World]

Same as except in primary 

Redistribute static metric 100 100 255 1 1500

In backup 

Redistrubte static metric 100 1000 255 1 1500

[Joseph W. Doherty]

In PT, doing that primary static pushes static out of secondary router - which is great!

Unfortunately, after doing that and they pulling primary static, also in PT, static shows reinstalled on secondary, but transit router no longer had "D EX" - which is bad!!!  (NB: if I first start with secondary, it pushes its external to both other routers.)

I'm going to try that in CML, but I hadn't saved router configs, so I need to config all the routers again.

[Joseph W. Doherty]

@MHM Cisco World it appears to work fine in CML!!!  Nicely done.  (BTW, I'm not a CCIE, so you'll have to decrement me off your multi CCIE win list - laugh.  [Actually, I don't have any Cisco certs.])

I suspect why adjusting the metric works is for exactly for the reason you described, i.e. if redistribution sees what "appears" to be its redistributed prefix, with all the same metrics, it assumes its from its own redistribution, so it sees no need to withdraw itself.

Although I would think it very unlikely, in theory, a received "foreign" external metric might also match what the router's redistribution metric (causing the issue again).  Rather than adjusting the metric, I wondered if tagging the route would work too, as you can uniquely set your tags, but just tried that in CML, it doesn't work.

To @jmaxwellUSAF, with the addition of a simple metric adjustment; you may have exactly what you wanted.

PS:

Today is first time I've use CML. In the past, I've used GNS3, but cannot compare the two.  Can say, it's nice to once again have something that provides all the optional features that PT doesn't.

[MHM Cisco World]

Yes welcome to gns3 and cml world.

Have a nice day friend. 

MHM