Reboot after ping timeout[SOLVED]

Question

Hi All:

I have this strange problem happening that I have only ever seen in India.
I thought it was related to IKEV1 so I switched all my field units to IKEV2 (after teaching myself how to do that) but I'm still seeing this issue.
The Digi's are the field units connected to Cisco ISR4431. What happens, from time to time, is that the field units negotiate phase 1 fine, phase 2 appears to complete and unit the tunnel gets dropped. This will go on and on.
The only recourse we have is to send a reboot via SMS. Occasionally it may require 2 reboots but usually after a single reboot the tunnel comes up and all is well.
This does not happen often but it does happen.

I am already using the SIM fail over but that is using google's 8.8.8.8 as a ping response and it doesn't fail because the GPRS is up, its just the IPSec that won't come up.
So, I would like to ping the internal gateway of my VPN network inside the cisco. If the Digi does not get a response in say 300 seconds, I want the Digi to reboot.

Is there a menu setting where I can set that up of do I need to use a python script to do it?

Cheers,
John

Answer 1

Setup Eth1 on the VPN routers network then use the same ping timeout reboot with the routers network.

Comments

Good suggestion but, the reboot appears to only be available  on the ppp interfaces, not the Eth interfaces.
Unless I'm reading that wrong.

Cheers,
john

---

I see there is a setting "Use the ETH 0 IP address as the source IP address"

Make Eth1 you Internet to FE WAN on router
then use Eth0 after setting up on router network.

Not able to test this right now though, just a thought.

Answer 2

looks like advertising spam to me.

cheers,
john

Answer 3

IF the "Use the ETH 0 IP address as the source IP address" didn't work then you could always add an external device such as a "Webrelay" which would connect to the VPN router and ping a address within your network, once ping is lost the webrelay can be configured to reboot the Digi.

https://www.controlbyweb.com/webrelay/

Answer 4

An update to this....
We updated the IOS on the ISR4431 as we are using WR41 units for a different project using an ASR1000 and those work fine using IKEv1.
I also have in my office in Singapore a 1921 running 15.4 IOS and we've had all sorts of Digis connected to it for year (over 10, since IOS 12.4) and they work perfectly.
Since upgrading the IOS to Cisco IOS XE Software, Version 16.12.04 the behavior has changed:
1. We get only duplicate SAs if they are IKEv1, the IKEv2 SAs are only duplicated for a minute or two before they are due to expire and the the old one disappears....as the RFC says it should,
2. The circular tunnel negotiation has changed to the following:
A. The Cisco receives the initial IKEv2 request and accepts the proposals and sends back the message to the Digi to start the authentication......
B. The next message from the Digi is another init message.... meaning, it did not receive the reply from the Cisco to start authentication. This behavior goes round and round with the initial request timing out on the Cisco as the Digi never replies.

So far, the only solution is to reboot the Digi via SMS which usually fixes it. If the behavior continues after the reboot we reboot again unit it comes up works. This happens at certain sites more than others. It "appears" to be something odd with the NAT the telco is doing on their GPRS cloud.

I need a function whereby after the router is up for 60-90 seconds I can ping the internal GW of the Cisco which can only happen if IPSec is up. If I fail with that for 1-2 minutes, reboot the unit.

Unfortunately it looks like I'll have to write something in python to do this as its slightly too complex for the built in functions in the router.

Short of writing the python script, does anyone have any ideas?

Cheers,
john

Answer 5

Hi All;

What I did was write a python script that does this:
1. Create a thread with a socket that when connected to will return the value of the Rebootcount variable,(this is used to check that the script is running)
2. Sleep for 120 seconds to allow the system to get up and bring up IPSec on one of the interfaces,
3. Ping the inside interface of the Cisco (inside the vpn) twice, if at least one ping is successful, call that complete and reset rebootcounter to zero,
4. If the ping fails, increment reboot counter by 1,
5. IS reboot counter 4 or more, Yes reboot, no continue,
6. Sleep for 30 seconds,
7. Go back step 3.

This has solved the circular negotiation issue that sometimes happens as the routers will reboot themselves without us having to SMS the reboot command.

Cheers,
john