Unfortunately, there's no simple way to automate this; it's a rather complex manual process now, mostly involving gathering tcpdump output and editing and sorting it. Not easy to script because of the varying messages that come back.
I found this interesting: it seems that some tcp/ip implementations don't deal with protocol 4 very well; they're returning port unreachable errors for a protocol that doesn't have any ports. - Brian
On Thu, May 11, 2017 at 07:04:11PM +0200, Rob Janssen wrote:
I think it would be a good idea to somehow keep track of this information and remove or at least mark inactive those gateways for which this condition persists for some amount of time. Especially when protocol 4 is rejected. Host unreachable could be because the internet is down or the power is out, but an explicit protocol 4 rejected indicates nonexistent configuration, that could temporarily exist because e.g. new system has just been installed that has not been configured yet, but should not persist for longer than say 2 weeks. The operator can alwayes re-enable or re-add the gateway when he has found the opportunity to re-install it. Rob