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