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
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
Gus, I think you overlook one small item, and that is that amprgw only learns new routes every 15 minutes, because the encap file is only fetched every 15 minutes from the portal. And there is the question of how soon the portal changes the encap file when a dynamic address changes. I think that's every 15 minutes as well, so I believe the delay in using the new address of a dynamic gateway is more like 30 minutes.
Typically gateways that are rebooting don't return any kind of packet, especially not ICMP, so that shouldn't be an important consideration. - Brian
On Sun, May 28, 2017 at 04:08:31PM +0200, Gustavo Ponza wrote:
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
With all the respect ....
no one get exited those days from few pings to his router (i mean routers that connected to the internet via DSL or fiber optic or cable(not via 1200 baud link))
it is just enough to see that amprgw is hit by constant 25mb/s garbage so what is it more few pings every 5 seconds
I understand you want to be a good network neighbor but believe me the ping we make to a single location is not something you have to bother too much to make so much effort in changing the software
you are doing a great job and continue to do so but really no need to take care and consider too much for the other network neighbors
I would like to see all the other neighbors reducing their traffic to amprgw from 25 mb/s to say 100 kb/s then i would act the same ....
Ronen - 4Z4ZQ
________________________________
We're trying to be good net neighbors. - Brian
It's not the pings, it's the constant unending streams of connects to TCP ports and probes of UDP ports that we're encapsulating and relaying through that I want to avoid burdening 'innocent' people with.
Despite all our filtering, I do get complaints from people whose firewalls are too sensitive and too verbose. They typically don't really know what they're complaining about, they just know that their firewall told them something bad was happening. Worse, one of those products thinks it's being helpful and looks up and displays the 'abuse@ucsd.edu' address, and those people then file complaints with our campus network security people, which I then have to answer. Even if we had our own ASN, I'd still have to answer the complaints. This I don't need.
And besides, it's fun to write new code. Creeping featurism? Perhaps. - Brian
On Sun, May 28, 2017 at 03:59:51PM +0000, R P wrote:
no one get exited those days from few pings to his router (i mean routers that connected to the internet via DSL or fiber optic or cable(not via 1200 baud link))
Why dont we complain back on all the 25 mb/s garbage we get to amprgw ? is it something realistic ? or am i dreaming ?
Here are my Traffic graphs I get the peaks (in blue ) is the Network camera I have when i look on it from work or out of the house
even me for small network get too much noise in as 12 KB/s (i dont have filters beside SIP and specific address that flood me with ssh connection tries)
http://44.138.1.1/graphs/iface/bridge-local/
________________________________
Despite all our filtering, I do get complaints from people whose firewalls are too sensitive and too verbose.
And besides, it's fun to write new code. Creeping featurism? Perhaps. - Brian
On Sun, May 28, 2017 at 03:59:51PM +0000, R P wrote:
no one get exited those days from few pings to his router (i mean routers that connected to the internet via DSL or fiber optic or cable(not via 1200 baud link))
_________________________________________ 44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Hey Brian,
Man.. don't you sleep? 4:04AM?!
Anyway, I like your idea but I think this will be critical to record and let endusers review if their gateway is seemingly refusing RIP44 updates. These "intermittent" refusals could be coming from their malfunctioning gateway but more likely due to upstream equipment getting reconfigured and breaking the end to end Protocol 4 transport for a period of time. I've seen very similar things happening like this for DNS, SMTP, etc. but those systems all have some level of caching, retries, etc.
--David KI6ZHD
On Sun, May 28, 2017 at 10:30:19AM -0700, David Ranch wrote:
Man.. don't you sleep? 4:04AM?!
No, not much. Never needed much.
Anyway, I like your idea but I think this will be critical to record and let endusers review if their gateway is seemingly refusing RIP44 updates. These "intermittent" refusals could be coming from their malfunctioning gateway but more likely due to upstream equipment getting reconfigured and breaking the end to end Protocol 4 transport for a period of time. I've seen very similar things happening like this for DNS, SMTP, etc. but those systems all have some level of caching, retries, etc.
In the private web directory there is a file 'deferrals' which contains the most recent 500 of the day's 'deferred' messages extracted from the router log every 15 minutes. Gateway operators who are curious can download it and grep the relevant addresses out of it.
There's also a file 'gwlog.txt' containing raw data which records the day's ICMP exceptions that the RIP sender experienced. The last two columns are the ICMP type and code. It's really designed to be input to a presentation program of some sort, which I haven't written yet.
Both files contain a lot of the same message over and over with just a different timestamp. I haven't figured out a cool graphical way to present the data. - Brian
-
Brian Kantor -
David Ranch -
Gustavo Ponza -
R P