28 May
2017
28 May
'17
9:08 a.m.
Hi Brian,
all correct for almost any foreseen situations but, as per my example
setup, since my hostname(s) are reported to DNS server by cron job
every 5 minutes, the maximum theoretical lost/gap to propagate the
*new real IP* on the internet is near maximum about 7 minutes.
So, since RIP broadcast from AMPRGW succeeded every 5 minutes,
then at maximum *only 2* broadcast cycles will be lost/ineffective.
I don't know if a near true situation as above may also happen when
a fixed IP gateway is simply rebooting during the AMPRGW check.
So, for what I can understand, the economy could be fully applied,
in some way, when the checked gateway is found (temporarily or
definitively) switch off, or poorly configured, or don't want packets
from AMPRGW...
just a thinking about :)
73, gus i0ojj
--------------
I'm experimenting with a new technique in the routing daemon on amprgw:
if during a send to a gateway, the router gets certain ICMP UNREACHABLE
packets from the gateway it's sending to, it drops the host or gateway
from the routing table for a time.
This has the effect that if a gateway tells us that they don't want
packets from us by means of sending us a HOST or NET unreachable ICMP
response, we'll stop sending to them for a while.
Specifically, PORT UNREACHABLE is ignored. We don't route based on ports.
Any of the various HOST UNREACHABLE packets will defer just the one
destination host that was being sent to from the routing table; any of the
NET UNREACHABLE or PROTOCOL UNREACHABLE packets will defer the subnet from
the routing table. The deferral period is currently set to 15 minutes.
Watching this happen, one can observe that every 15 minutes, there are a
number of hosts and a subnet or two deferred out of the table as packets
are sent to them and rejected by the gateways. The number added to the
deferral list drops in rate as time goes on.
When a gateway changes its address, it is immediately removed from the
deferral list.
As with the ICMP response suppressing sending RIP transmissions, the
purpose of this is to not bombard gateways with packets they don't want
and aren't going to deliver anywhere. This is especially important with
the number of dynamic gateways we have, where a change in the gateway
address may wind up sending IPIP packets to an innocent host that has
inherited the gateway's old address.
Packets to unreachable destinations are dropped; we don't send
UNREACHABLES ourselves. (With all the backscatter and probes, we'd be
sending a LOT of them.)
We're trying to be good net neighbors.
- Brian
This is what the log entries look like:
May 28 03:54:33 <local0.info> amprgw ipipd[59063]: ICMP rec'd from
188.230.236.122: host 44.150.1.104 deferred
May 28 03:54:33 <local0.info> amprgw ipipd[59063]: ICMP rec'd from
188.230.236.122: host 44.150.1.236 deferred
May 28 03:54:33 <local0.info> amprgw ipipd[59063]: ICMP rec'd from
188.230.236.122: host 44.150.1.4 deferred
May 28 03:54:37 <local0.info> amprgw ipipd[59063]: ICMP rec'd from 97.84.0.85:
subnet 44.102.132.0/24 deferred
May 28 03:54:38 <local0.info> amprgw ipipd[59063]: ICMP rec'd from
188.230.236.122: host 44.150.1.153 deferred
May 28 03:54:38 <local0.info> amprgw ipipd[59063]: ICMP rec'd from
188.230.236.122: host 44.150.1.210 deferred
May 28 03:54:38 <local0.info> amprgw ipipd[59063]: ICMP rec'd from
188.230.236.122: host 44.150.1.210 deferred
May 28 03:54:42 <local0.info> amprgw ipipd[59063]: ICMP rec'd from
40.143.112.188: subnet 44.88.8.32/28 deferred
May 28 03:54:43 <local0.info> amprgw ipipd[59063]: ICMP rec'd from
216.161.250.190: host 44.22.128.10 deferred
May 28 03:54:44 <local0.info> amprgw ipipd[59063]: ICMP rec'd from
188.230.236.122: host 44.150.1.102 deferred
May 28 03:54:45 <local0.info> amprgw ipipd[59063]: ICMP rec'd from
78.226.112.146: host 44.151.67.67 deferred