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