cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3630
Views
36
Helpful
49
Replies

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

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.

49 Replies 49

#ip route 1.1.1.1 255.255.255.255 172.16.2.2 !! this primary route is inserted and redistributed at the router connected to the primary vendor device !!
#ip route 1.1.1.1 255.255.255.255 172.16.9.2 10 !! this secondary route is inserted and redistributed at the router connected to the secondary vendor device !!
===

Failover SLA config inserted at the router connected to the primary device...

#track 28 ip sla 1 reachability

#ip sla 1
#icmp-echo 172.16.2.2 source-ip 172.16.2.1
#ip sla schedule 1 life forever start-time now
===

Also exists...

router eigrp 1
network 172.16.2.0 0.0.0.3
===

"you need to add the tracking option to the primary static route"

Isn't that already the above config? 

"

"you need to add the tracking option to the primary static route"

Isn't that already the above config?"

From what the others have posted, believe you need:

ip route 1.1.1.1 255.255.255.255 172.16.2.2 track 28

I still would want a better understanding of this topology but assuming that the primary static route is on one device (Nexus) that the failover static is on another device then I believe that the failover static should not have AD of 10 but should be some value greater than 170.

HTH

Rick

I originally had that strategy, but it seems that it is impossible for to EIGRP redistribute a static route without the AD=170. This seems ridiculous to me.

Is it possible to create a static route, and EIGRP distribute it with an AD of 175?

"Is it possible to create a static route, and EIGRP distribute it with an AD of 175?"

Personally I don't know, as I'm beginner with EIGRP, but possibly with some combination of the EIGRP distance command and/or using a route-map.

BTW, what Rick recently suggested, may mean you don't need to modify EIGRP's ADs for the two static routes being redistributed.

". . . failover static is on another device then I believe that the failover static should not have AD of 10 but should be some value greater than 170."

Agreed, assuming it "sees" redistributed primary with AD of 170; and that might also keep secondary from being redistributed and/or used on secondary (while primary is "good").

Doing that, alone, might solve issue (this all assuming primary and secondary are redistributed on different devices.

"". . . failover static is on another device then I believe that the failover static should not have AD of 10 but should be some value greater than 170."

Agreed, assuming it "sees" redistributed primary with AD of 170; and that might also keep secondary from being redistributed and/or used on secondary (while primary is "good").

Doing that, alone, might solve issue (this all assuming primary and secondary are redistributed on different devices."

--

I originally had this strategy, but it seems that it is impossible for to EIGRP redistribute a static route without the AD=170. This seems ridiculous to me.

Is it possible to create a static route, and EIGRP distribute it with an AD of 175?

"Is it possible to create a static route, and EIGRP distribute it with an AD of 175?"

Answered, in my prior posting, likely I was composing it concurrently with yours.

"Doing that, alone, might solve issue (this all assuming primary and secondary are redistributed on different devices.""

Let me describe, what I'm thinking.

On primary routing device you have static route with AD of 1, redistributed into EIGRP.  However, you're also tracking reachability to vendor device, if no reachability, static route withdrawn, and with it, the redistributed "copy".

On secondary routing device you have static route with AD greater than EIGRP.  If primary device's static is being redistributed, its AD will suppress secondary static route, and if secondary static route is suppressed, it will not be redistributed.  However, if primary device's static isn't in EIGRP, secondary device will use its static and redistribute it.

So, if things work as described above, you only need to "track" primary and insure secondary's static AD is higher than EIGRP AD for primary (which should be the EIGRP default).

If things don't work as above, then we would need to adjust at least one (shouldn't need to adjust both, just need primary route AD > secondary route AD; either one could be default AD) of the static route AD cost when in EIGRP.

BTW, without taking advantage of ADs, either implicitly or explicitly, if both statics are being redistributed, on different routers, regardless of their static ADs, both routes should have "equal" ADs in EIGRP, although internal EIGRP costs for the two could make them "unequal" to other EIGRP routers.

PS:

My "lab" is just Packet Tracer, and since PT usually doesn't support "advanced" features, I doubt I could try this and so could not provide you an explicit working example.

"However, if primary device's static isn't in EIGRP, secondary device will use its static and redistribute it.

So, if things work as described above, you only need to "track" primary and ensure secondary's static AD is higher than EIGRP AD for primary (which should be the EIGRP default)."

When is secondary route redistributed? It seems that it is redistributed immediately upon config execution, which means it will have AD=170 always, just like primary EIGRP redistributed route. So this won't work. 

What are your thoughts?

I'm not 100% certain, which is why I would like to "lab" it, but consider:

if we start with primary, static route with AD 1, before being installed in route table, looks for matching prefix and its AD cost.  If same prefix with lower AD already in route table (e.g. a connected route, AD = 0), static route prefix NOT installed in route table, and if not in route table, it's NOT, I believe, redistributed.  If prefix not in route table, or if static route's AD cost lower (or possible the same), it will be installed in route table.  Once in route table, then it can be redistributed.  (BTW, one route prefix preempting another, which has a higher AD, is not unusual, e.g. RIP vs. OSPF vs. EIGRP vs BGP routes.  Also this is what allows "floating" statics to work.)

On secondary, much like primary, static route will only be installed in route table if same prefix is not present or static route's AD is lower AD cost.  Since the only matching prefix that would otherwise be in secondary's route table, is the primary static that has been redistributed, but now in EIGRP, its default AD will be 170.  So, if secondary's static has a higher AD cost, it will not preempt the existing EIGRP (redistributed) route.  And if not installed in route table, it too shouldn't be redistributed.

Although I only have Packet Tracer to "lab" with, others do have "better" lab environments.  I'm pretty sure @MHM Cisco World has such an environment, and he very often will lab something up.  Perhaps he will try this.(?)

I'm going to try this in PT too, just to see whether it support this or not.

Just setup a PT test - didn't get the results desired (i.e. static with AD of 254 replaces EIGRP external with AD cost of 170), but with PT, very much might be a PT issue.

sorry Friend  @Joseph W. Doherty  what topology I run in lab 
can you provide more info. 
Thanks a lot 

"what topology I run in lab"

Similar to what's in my zipped PT attachment.

If you don't have PT that can open the attachment, let me know and I'll describe the topology and critical configuration statements (which there's not much of either).

Sorry I dont have pkt' can share it as photo 

Thanks

I believe I can, but before doing that (assuming I need to . . . ), I'm going to post some additional information, in another reply to OP.

Joseph W. Doherty
Hall of Fame
Hall of Fame

Earlier I noted I consider myself only a "beginner" with EIGRP.  This mostly because I've never had to deal with it in a production environment.

The last several hours, I've been trying to get PT to work, while also reviewing these Cisco documents (TechNotes):

https://www.cisco.com/c/en/us/support/docs/ip/ip-routed-protocols/113153-adjust-ad-00.html
https://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/8651-21.html
https://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/8606-redist.html#anc14

Those TechNotes appear, to me, to confirm my understanding.  (Of course, perhaps I'm misunderstanding something.)

Anyway, I still could not get PT to work as I expected it should.  Doing more research about adjusting EIGRP ADs (again, which I still think should not be needed, but if it's needed), I found a couple of Cisco Learning Network posts about adjusting EIGRP ADs for EIGRP externals:

https://learningnetwork.cisco.com/s/question/0D53i00000KsxzLCAR/eigrp-distance-command

https://learningnetwork.cisco.com/s/question/0D53i00000KszQ7CAJ/distance-for-external-routes-specific-source

Which indicates adjusting ADs for specific EIGRP routes cannot be done.(?!)

However, those postings mention alternative approaches include using an EIGRP summary route, rather than an EIGRP external; or using "ordinary" EIGRP metrics; or changing default AD EIGRP metrics.  The latter, I was about to try, because I had "independently confirmed" I could not use the distance variant to adjust EIGRP external ADs.  (The latter, though, again, might be PT issues.  My PT doesn't appear to support appending an ACL reference to distance variant that should allow it [also, unclear what the "source IP" should be for static routes same device.])

The changing the EIGRP default ADs values (per device), did work for me in PT, but just once.  (Again, I don't trust PT's fidelity.)

More information I found interesting to read:

https://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/13673-14.html

https://community.cisco.com/t5/routing/how-to-change-the-administrative-distance-for-external-eigrp/td-p/465543

Tomorrow, I'll provide greater details on what I was trying in PT so @MHM Cisco World can try it in his lab.

Review Cisco Networking for a $25 gift card