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.

[Richard Burts · Accepted solution]

I am not sure that I understand your issue but think that using track on the static route might accomplish your intention. track can monitor reachability of a remote address sending periodic probe packets. If track detects that the remote is not responding the static route is removed. Perhaps this link will provide helpful information.

https://www.cisco.com/c/en/us/support/docs/ip/ip-routing/200785-ISP-Failover-with-default-routes-using-I.html 

[jmaxwellUSAF]

ISP Failover with Default Routes Using IP SLA Tracking - Cisco

This solution is what I was looking for, yet there still exists an issue with its implementation....

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.

--

In the above link, an essential element is the administrative distance (AD) of 10 added to the backup route. This allows the route to float below the primary route.

In my present strategy, I cannot directly advertise 1.1.1.1 as a simple network attached to the router (is this correct?). I must create a static route, then redistribute it via EIGRP, which will immutably force its AD to be 170.

Thus, my understanding is that it is impossible to implement a solution that manipulates the Administrative Distance, because all my routes will always be AD 170.

Logic declares that if my understanding of the above is not correct, such a solution is still possible. I expect my understanding is not complete. I expect that Cisco has ways around this architectural issue.

Questions:

1. Is this the solution?-- Because the static route will be created on the same relevant adjacent device to the vendor box, the routes will actually not live in the local routing table with an AD of 170, but actually an AD of 1 (static route), and the redistribution happens as a second resulting separate task, so the original solution will work fine?

2. Is there a solution that resolves my less than perfect understanding above?

3. If the above SLA solution is indeed impossible, then what is my solution?

Thank you!

[Joseph W. Doherty]

Thus, my understanding is that it is impossible to implement a solution that manipulates the Administrative Distance, because all my routes will always be AD 170.

I have no expertise in EIGRP (although I believe @Richard Burts does), but if adjusting the AD of individual routes is required, I would hope EIGRP would allow that wherever you're doing the redistribution.  (The whole point being, allowing "floating" routes within dynamic routing too, I believe.)

That said, using floating routes will work?  From OP thought you wanted to withdraw route, so unclear which might be a tad different then using another route.(?)

[Richard Burts]

As I said there is much about your environment/issue that I do not understand. And perhaps we are encountering some of that in the proposed solution. Let me address one part of that and if there are still questions then you can provide clarification. You focus on " an essential element". The essential element is not necessarily the value of 10 but is that the AD be greater than the default value of a static route (which is one). So the eigrp AD of 170 would not be an issue if I am understanding your environment correctly.

[Joseph W. Doherty]

Unless you can find some feature, such as what Rick describes, your other alternative might be via scripting monitoring pings to the vendor box, either on the neighboring Cisco device or using a dedicated computer which will externally reconfigure the neighboring Cisco device.

BTW, if pinging is done other than from a device connected to the vendor box network, you have the problem of discovering when vendor device comes back online.

[paul driver]

Hello

---

@jmaxwellUSAF wrote:

If the above SLA solution is indeed impossible, then what is my solution?

---

Ipsla/object tracking will work only if the destination monitoring address isn't reliant on the static route you are advertising, otherwise if /when the host fails the monitoring will never re-enable

1.  create IPSLA probe to monitor the reachability of say the next hop ip address specified in the static route sourced from interface/ip that can reach that next hop address.
2. create a track object to relate to the ipsla probe
3. Apply the track to the static route

Example:

ip sla 1
icmp-echo 10.10.10.10 source-ip 10.1.12.1
ip sla schedule 1 life forever start-time now

track 1 ip sla 1 reachability

ip route 3.3.3.3 255.255.255.255 10.10.10.10 track 1

classic eigrp
router eigrp 10
no auto-summary
redistribute static

Named eigrp
router eigrp stan
address-family ipv4 unicast autonomous-system 10
topology base
no auto-summary
redistribute static

[MHM Cisco World]

friend let start from bottom to up 
bottom the static route, 
static route will in RIB and redistribute if 
1- the egress interface is UP
2- the next-hop is reachable, HERE you need track (ip sla) to check the availability of next-hop of static route 

when above is egress interface is down and track is down then the static route will automatic remove from RIB and it never redistribute via any other IGP protocol 

hope this what you looking for 

[Joseph W. Doherty]

Although both Paul and Rick have implicitly conveyed the same information, MHM's posting explicitly reminds us that a tracked static route is withdrawn when it fails, and if so, AD priorities shouldn't matter.

Is that not what you wanted in your OP?

[jmaxwellUSAF]

The original primary static route has a default AD of 1
The original secondary static route has an AD of 10
Both redistributed routes will have a default AD of 170...

#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
===

So then...

Is it true that with this config implementation, if primary vendor device fails, then the first route will be removed from the routing table, and the second route will be inserted?

Thank you.

[MHM Cisco World]

Yes but how router know this static route is not available anymore?

Here the Q

You need to add egress interface to ststic route when it down the static route auto remove

You need track if the next-hop is not direct connect for example in case of

R1-SW-R2

HERE even if R1-Sw interface is up there is chance that Sw-R2 interfaces is down and your traffic is blackhole drop. 

[jmaxwellUSAF]

The primary device is directly connected to a L3 switch (Nexus-9300). The SLA, and the routing table is in this Nexus.

So it seems your concern is not an issue. Correct?

[MHM Cisco World]

I prefer use egress interface.

NOTE:- nsk or any other l3sw  not support egress interface you can use vlan x instead of egress interface. 

[Richard Burts]

I am confused about the topology here. I had been assuming that we were talking about static routes, route redistribution on a single device. Now we are told about "router connected to the primary vendor device" and about "router connected to the secondary vendor device". How many routers, how many vendor devices, how are they connected? What is the topology of this part of the network?

[Joseph W. Doherty]

Well, just as your secondary is already "suppressed" because the primary has a better AD, withdrawal of the primary route should allow the secondary to take over (on the same router [these two statics are on the same router?]).  Believe this will also "flow though" to your redistribution.

BTW, don't forget, as shown by others, you need to add the tracking option to the primary static route.