28 May
2017
28 May
'17
6:04 a.m.
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
28 May
28 May
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
9:18 a.m.
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
10:59 a.m.
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
11:23 a.m.
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(a)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))
12:12 p.m.
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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
12:30 p.m.
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
1:15 p.m.
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
2737
days inactive
2737
days old
8 comments
4 participants
participants (4)
-
Brian Kantor -
David Ranch -
Gustavo Ponza -
R P