Chris et. al.,
You noted something possible loss along a path. Close to AMPRGW, I notice dc-tus-agg8--lax-agg8-300g.cenic.net is constantly giving me packet loss.
Also CENIC.ear1.LosAngeles1.Level3.net is somewhat dropping (also dc-lax-agg8--lax-agg6-100ge-2.cenic.net).
I'm able to see this loss running with the command 'mtr -u gw.ampr.org' (UDP seems to show more packet loss than 'mtr -T').
user@machine:~$ tracepath gw.ampr.org 1?: [LOCALHOST] pmtu 1500 1: OpenWrt.lan 0.540ms 1: OpenWrt.lan 0.824ms 2: no reply 3: B3352.WASHDC-LCR-21.verizon-gni.net 20.242ms 4: no reply 5: 0.ae1.BR1.IAD8.ALTER.NET 8.127ms 6: no reply 7: no reply 8: CENIC.ear1.LosAngeles1.Level3.net 65.995ms asymm 11 9: dc-lax-agg8--lax-agg6-100ge-2.cenic.net 71.811ms asymm 11 10: dc-tus-agg8--lax-agg8-300g.cenic.net 70.475ms asymm 11 11: dc-sdg-agg4--tus-agg8-300g.cenic.net 67.237ms 12: dc-ucsd-100ge--sdg-agg4.cenic.net 69.696ms 13: mcore-flow-bypass-mx0-p2p.ucsd.edu 68.723ms 14: sdsc-7710-7--mcore-vl2995-p2p.ucsd.edu 72.042ms 15: no reply
- Lynwood KB3VWG
Hey Guys,
I've noticed that the issue is still going on. Has there been any progress...??? Can we get an update please..???
Thanks
73's
- Albert WB7AWL
-----Original Message----- From: 44Net [mailto:44net-bounces+wb7awl=lawsonpc.com@mailman.ampr.org] On Behalf Of lleachii--- via 44Net Sent: Saturday, November 7, 2020 7:55 AM To: 44net@mailman.ampr.org Cc: lleachii@aol.com Subject: Re: [44net] Lost Packets
Chris et. al.,
You noted something possible loss along a path. Close to AMPRGW, I notice dc-tus-agg8--lax-agg8-300g.cenic.net is constantly giving me packet loss.
Also CENIC.ear1.LosAngeles1.Level3.net is somewhat dropping (also dc-lax-agg8--lax-agg6-100ge-2.cenic.net).
I'm able to see this loss running with the command 'mtr -u gw.ampr.org' (UDP seems to show more packet loss than 'mtr -T').
user@machine:~$ tracepath gw.ampr.org 1?: [LOCALHOST] pmtu 1500 1: OpenWrt.lan 0.540ms 1: OpenWrt.lan 0.824ms 2: no reply 3: B3352.WASHDC-LCR-21.verizon-gni.net 20.242ms 4: no reply 5: 0.ae1.BR1.IAD8.ALTER.NET 8.127ms 6: no reply 7: no reply 8: CENIC.ear1.LosAngeles1.Level3.net 65.995ms asymm 11 9: dc-lax-agg8--lax-agg6-100ge-2.cenic.net 71.811ms asymm 11 10: dc-tus-agg8--lax-agg8-300g.cenic.net 70.475ms asymm 11 11: dc-sdg-agg4--tus-agg8-300g.cenic.net 67.237ms 12: dc-ucsd-100ge--sdg-agg4.cenic.net 69.696ms 13: mcore-flow-bypass-mx0-p2p.ucsd.edu 68.723ms 14: sdsc-7710-7--mcore-vl2995-p2p.ucsd.edu 72.042ms 15: no reply
- Lynwood KB3VWG _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Hmm. We saw some unusually high traffic on the link late last week, which I thought might be the culprit, but that's died down, and if the packet loss is continuing, there may be some other issue. I've fired off an email to the UCSD netops guys to see if they know of any problems up at CENIC.
Dan
On 11/10/20 6:59 PM, Albert Lawson via 44Net wrote:
Hey Guys,
I've noticed that the issue is still going on. Has there been any progress...??? Can we get an update please..???
Thanks
73's
- Albert WB7AWL
-----Original Message----- From: 44Net [mailto:44net-bounces+wb7awl=lawsonpc.com@mailman.ampr.org] On Behalf Of lleachii--- via 44Net Sent: Saturday, November 7, 2020 7:55 AM To: 44net@mailman.ampr.org Cc: lleachii@aol.com Subject: Re: [44net] Lost Packets
Chris et. al.,
You noted something possible loss along a path. Close to AMPRGW, I notice dc-tus-agg8--lax-agg8-300g.cenic.net is constantly giving me packet loss.
Also CENIC.ear1.LosAngeles1.Level3.net is somewhat dropping (also dc-lax-agg8--lax-agg6-100ge-2.cenic.net).
I'm able to see this loss running with the command 'mtr -u gw.ampr.org' (UDP seems to show more packet loss than 'mtr -T').
user@machine:~$ tracepath gw.ampr.org 1?: [LOCALHOST] pmtu 1500 1: OpenWrt.lan 0.540ms 1: OpenWrt.lan 0.824ms 2: no reply 3: B3352.WASHDC-LCR-21.verizon-gni.net 20.242ms 4: no reply 5: 0.ae1.BR1.IAD8.ALTER.NET 8.127ms 6: no reply 7: no reply 8: CENIC.ear1.LosAngeles1.Level3.net 65.995ms asymm 11 9: dc-lax-agg8--lax-agg6-100ge-2.cenic.net 71.811ms asymm 11 10: dc-tus-agg8--lax-agg8-300g.cenic.net 70.475ms asymm 11 11: dc-sdg-agg4--tus-agg8-300g.cenic.net 67.237ms 12: dc-ucsd-100ge--sdg-agg4.cenic.net 69.696ms 13: mcore-flow-bypass-mx0-p2p.ucsd.edu 68.723ms 14: sdsc-7710-7--mcore-vl2995-p2p.ucsd.edu 72.042ms 15: no reply
- Lynwood
KB3VWG _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Albert,
Can you describe the service you're actually experiencing issues with?
I'm still seeing losses mainly in the Cenic routers at Los Angeles when running commands like 'mtr -u -P 12252 gw.ampr.org' - nearly up to 30%.
Oddly, I'm not having much loss e.g. with real traffic inside the tunnel. I was able to glean more information observing a video stream with Wireshark. I'm noticing the packet loss in the direction TOWARD AMPRGW. It doesn't appear that packets are being lost more so from AMPRGW towards my gateway.
I observed this by looking at the packets in the stream - I see a TCP packet labeled from the from the far end "TCP Previous Segment is not captured" and sometimes subsequent out-of-order - plus duplicate ACK errors from the local side.
I do see few "TCP ACKed unseen segment" from remote hosts - which indicated drops inbound. These came from a few hosts not related to the stream.
73,
- Lynwood KB3VWG
All,
I should also note that I did not observe the issue constantly since Friday. The loss subsided over the weekend. I also haven't tested since approximately Monday - until the emails today.
- KB3VWG
I’m running 3 MMDVM servers that are connecting to a cBridge in Kennewick, Washington. As you know, these packets use UDP, and dropped UDP packets are the “kiss of death” for these type of connections.
I also noticed the pattern of the amount of packets being dropped on Friday, versus how it seemed to decrease over the weekend and even more so into the first part of this week. That smells like a DOS attack….
73’s
-Albert WB7AWL
From: lleachii@aol.com [mailto:lleachii@aol.com] Sent: Tuesday, November 10, 2020 9:14 PM To: Albert Lawson wb7awl@LAWSONPC.COM; 44net@mailman.ampr.org Subject: Re: Lost Packets
All,
I should also note that I did not observe the issue constantly since Friday. The loss subsided over the weekend. I also haven't tested since approximately Monday - until the emails today.
- KB3VWG
From what I have seen logged into the GW machine itself, together with tests others have reported it looks like there may be some issue upstream of UCSD, possibly on the CENIC network rather than within UCSD itself.
It certainly seems to make a big difference depending on where in the world the packets are coming from (I’m still seeing no packet loss to/from my UK servers).
Hopefully the net ops guys at UCSD can shed more light on this (thanks Dan).
Chris - G1FEF
On 11 Nov 2020, at 05:38, Albert Lawson via 44Net 44net@mailman.ampr.org wrote:
I’m running 3 MMDVM servers that are connecting to a cBridge in Kennewick, Washington. As you know, these packets use UDP, and dropped UDP packets are the “kiss of death” for these type of connections.
I also noticed the pattern of the amount of packets being dropped on Friday, versus how it seemed to decrease over the weekend and even more so into the first part of this week. That smells like a DOS attack….
73’s
-Albert WB7AWL
From: lleachii@aol.com [mailto:lleachii@aol.com] Sent: Tuesday, November 10, 2020 9:14 PM To: Albert Lawson wb7awl@LAWSONPC.COM; 44net@mailman.ampr.org Subject: Re: Lost Packets
All,
I should also note that I did not observe the issue constantly since Friday. The loss subsided over the weekend. I also haven't tested since approximately Monday - until the emails today.
- KB3VWG
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Hi all For What it's worth from a 'layman' networker! re performance. I have seen a MASSIVE INCREASE of what I call ATTACK PROBING port scanning coming down the protocol 4 tunnel HAMMERING away (and being dropped by my firewall the two pairs of addreses from <169.228.34.84> <###.###.###.###> <any non 44net address-bandits> <gb7cip hosted 44net: gateway routes> Monitored realtime on my servers.
So the remote router is very very busy handling this unwanted trsffic attacks)
I do not run a BGP network, though do have some external point to point routing to BGP hosted partner. Just my observations 73 Paul g4apl
On Wed, 11 Nov 2020, G1FEF via 44Net wrote:
From what I have seen logged into the GW machine itself, ...
Hopefully the net ops guys at UCSD can ...
Fundemental problem here (for debugging network issues) is that neither ARDC/Amprnet/44Net (...nor CAIDA), have full direct control, or access, to their own network instructure.
CAIDA/UCSD is beholden to random upstream filtering as much in 2001[1] and 2009[2] as it is now. And in-turn, AmprGW is/was beholden (2019) to an ethernet switch with customised firmware[3]... a blackbox.
Graphs used to show the packet flow for Network Telescope (44net):
https://www.caida.org/data/realtime/telescope/?monitor=telescope_attack&...
but those broke (~2019-12-11), giving less insight for debugging.
---------
ARDC now has the resources to put independently hosted redundancy in place for 44net. Perhaps it would make sense to prioritise AmprGW infrastructure over distributions of funds to other organisations? [4]
-Paul
[1] Shannon (2001) https://www.caida.org/research/security/code-red/coderedv2_analysis.xml#back... "filter was put into place upstream of the monitor, we were unable to capture IP packet headers after 16:30 UTC"
[2] Polterock (2012) https://blog.caida.org/best_available_data/2012/04/04/targeted-serendipity-t... "increase in the amount of data stored after April 2009 due to the removal of an upstream rate limit filter on incoming packets"
[3] Kantor (October 2019) "I don't know the make and model of the switch that is crashing. I believe it may be running locally-modified firmware."
[4] ie. put a moratorium on the fun "grant giving" side of the business, until the primary/core mission of bringing AmprGW services under full control has been solved.
Just FYI:
I have have some 550 distinct IP addresses trying to connect from the internet via tunnel to unavailable ports via my gateway every hour.
What I do is to place them in a list and blacklist them for 1 hour :-)
Marius, YO2LOJ
On 11.11.2020 18:00, Paul Sladen via 44Net wrote:
On Wed, 11 Nov 2020, G1FEF via 44Net wrote:
From what I have seen logged into the GW machine itself, ...
Hopefully the net ops guys at UCSD can ...
Fundemental problem here (for debugging network issues) is that neither ARDC/Amprnet/44Net (...nor CAIDA), have full direct control, or access, to their own network instructure.
CAIDA/UCSD is beholden to random upstream filtering as much in 2001[1] and 2009[2] as it is now. And in-turn, AmprGW is/was beholden (2019) to an ethernet switch with customised firmware[3]... a blackbox.
Graphs used to show the packet flow for Network Telescope (44net):
https://www.caida.org/data/realtime/telescope/?monitor=telescope_attack&...
but those broke (~2019-12-11), giving less insight for debugging.
ARDC now has the resources to put independently hosted redundancy in place for 44net. Perhaps it would make sense to prioritise AmprGW infrastructure over distributions of funds to other organisations? [4]
-Paul
[1] Shannon (2001) https://www.caida.org/research/security/code-red/coderedv2_analysis.xml#back... "filter was put into place upstream of the monitor, we were unable to capture IP packet headers after 16:30 UTC"
[2] Polterock (2012) https://blog.caida.org/best_available_data/2012/04/04/targeted-serendipity-t... "increase in the amount of data stored after April 2009 due to the removal of an upstream rate limit filter on incoming packets"
[3] Kantor (October 2019) "I don't know the make and model of the switch that is crashing. I believe it may be running locally-modified firmware."
[4] ie. put a moratorium on the fun "grant giving" side of the business, until the primary/core mission of bringing AmprGW services under full control has been solved.
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
fail2ban?
________________________________________ De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Marius Petrescu via 44Net 44net@mailman.ampr.org Envoyé : 11 novembre 2020 12:59 À : 44net@mailman.ampr.org Cc : Marius Petrescu Objet : Re: [44net] Lost Packets
Just FYI:
I have have some 550 distinct IP addresses trying to connect from the internet via tunnel to unavailable ports via my gateway every hour.
What I do is to place them in a list and blacklist them for 1 hour :-)
Marius, YO2LOJ
On 11.11.2020 18:00, Paul Sladen via 44Net wrote:
On Wed, 11 Nov 2020, G1FEF via 44Net wrote:
From what I have seen logged into the GW machine itself, ...
Hopefully the net ops guys at UCSD can ...
Fundemental problem here (for debugging network issues) is that neither ARDC/Amprnet/44Net (...nor CAIDA), have full direct control, or access, to their own network instructure.
CAIDA/UCSD is beholden to random upstream filtering as much in 2001[1] and 2009[2] as it is now. And in-turn, AmprGW is/was beholden (2019) to an ethernet switch with customised firmware[3]... a blackbox.
Graphs used to show the packet flow for Network Telescope (44net):
https://www.caida.org/data/realtime/telescope/?monitor=telescope_attack&...
but those broke (~2019-12-11), giving less insight for debugging.
ARDC now has the resources to put independently hosted redundancy in place for 44net. Perhaps it would make sense to prioritise AmprGW infrastructure over distributions of funds to other organisations? [4]
-Paul[1] Shannon (2001) https://www.caida.org/research/security/code-red/coderedv2_analysis.xml#back... "filter was put into place upstream of the monitor, we were unable to capture IP packet headers after 16:30 UTC"
[2] Polterock (2012) https://blog.caida.org/best_available_data/2012/04/04/targeted-serendipity-t... "increase in the amount of data stored after April 2009 due to the removal of an upstream rate limit filter on incoming packets"
[3] Kantor (October 2019) "I don't know the make and model of the switch that is crashing. I believe it may be running locally-modified firmware."
[4] ie. put a moratorium on the fun "grant giving" side of the business, until the primary/core mission of bringing AmprGW services under full control has been solved.
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
_________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Nope, just a Mikrotik router.
On 11.11.2020 22:01, pete M via 44Net wrote:
fail2ban?
De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Marius Petrescu via 44Net 44net@mailman.ampr.org Envoyé : 11 novembre 2020 12:59 À : 44net@mailman.ampr.org Cc : Marius Petrescu Objet : Re: [44net] Lost Packets
Just FYI:
I have have some 550 distinct IP addresses trying to connect from the internet via tunnel to unavailable ports via my gateway every hour.
What I do is to place them in a list and blacklist them for 1 hour :-)
Marius, YO2LOJ
On 11.11.2020 18:00, Paul Sladen via 44Net wrote:
On Wed, 11 Nov 2020, G1FEF via 44Net wrote:
From what I have seen logged into the GW machine itself, ...
Hopefully the net ops guys at UCSD can ...
Fundemental problem here (for debugging network issues) is that neither ARDC/Amprnet/44Net (...nor CAIDA), have full direct control, or access, to their own network instructure.
CAIDA/UCSD is beholden to random upstream filtering as much in 2001[1] and 2009[2] as it is now. And in-turn, AmprGW is/was beholden (2019) to an ethernet switch with customised firmware[3]... a blackbox.
Graphs used to show the packet flow for Network Telescope (44net):
https://www.caida.org/data/realtime/telescope/?monitor=telescope_attack&row=timescales&col=sources&sources=app&graphs_sing=ts&counters_sing=bits×cales=672https://www.caida.org/data/realtime/telescope/?monitor=telescope_attack&row=timescales&col=sources&sources=app&graphs_sing=ts&counters_sing=bits×cales=672but those broke (~2019-12-11), giving less insight for debugging.
ARDC now has the resources to put independently hosted redundancy in place for 44net. Perhaps it would make sense to prioritise AmprGW infrastructure over distributions of funds to other organisations? [4]
-Paul[1] Shannon (2001) https://www.caida.org/research/security/code-red/coderedv2_analysis.xml#back... "filter was put into place upstream of the monitor, we were unable to capture IP packet headers after 16:30 UTC"
[2] Polterock (2012) https://blog.caida.org/best_available_data/2012/04/04/targeted-serendipity-t... "increase in the amount of data stored after April 2009 due to the removal of an upstream rate limit filter on incoming packets"
[3] Kantor (October 2019) "I don't know the make and model of the switch that is crashing. I believe it may be running locally-modified firmware."
[4] ie. put a moratorium on the fun "grant giving" side of the business, until the primary/core mission of bringing AmprGW services under full control has been solved.
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
You are too kind I block for three years Paul
On 11/11/2020 17:59, Marius Petrescu via 44Net wrote:
Just FYI:
I have have some 550 distinct IP addresses trying to connect from the internet via tunnel to unavailable ports via my gateway every hour.
What I do is to place them in a list and blacklist them for 1 hour :-)
Marius, YO2LOJ
On 11.11.2020 18:00, Paul Sladen via 44Net wrote:
On Wed, 11 Nov 2020, G1FEF via 44Net wrote:
From what I have seen logged into the GW machine itself, ...
Hopefully the net ops guys at UCSD can ...
Fundemental problem here (for debugging network issues) is that neither ARDC/Amprnet/44Net (...nor CAIDA), have full direct control, or access, to their own network instructure.
CAIDA/UCSD is beholden to random upstream filtering as much in 2001[1] and 2009[2] as it is now. And in-turn, AmprGW is/was beholden (2019) to an ethernet switch with customised firmware[3]... a blackbox.
Graphs used to show the packet flow for Network Telescope (44net):
https://www.caida.org/data/realtime/telescope/?monitor=telescope_attack&...
but those broke (~2019-12-11), giving less insight for debugging.
ARDC now has the resources to put independently hosted redundancy in place for 44net. Perhaps it would make sense to prioritise AmprGW infrastructure over distributions of funds to other organisations? [4]
-Paul
[1] Shannon (2001) https://www.caida.org/research/security/code-red/coderedv2_analysis.xml#back...
"filter was put into place upstream of the monitor, we were unable to capture IP packet headers after 16:30 UTC"
[2] Polterock (2012) https://blog.caida.org/best_available_data/2012/04/04/targeted-serendipity-t...
"increase in the amount of data stored after April 2009 due to the removal of an upstream rate limit filter on incoming packets"
[3] Kantor (October 2019) "I don't know the make and model of the switch that is crashing. I believe it may be running locally-modified firmware."
[4] ie. put a moratorium on the fun "grant giving" side of the business, until the primary/core mission of bringing AmprGW services under full control has been solved.
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
______________________________________________ This email has been scanned by Netintelligence http://www.netintelligence.com/email
Hehe.
It actually gives some kind of hourly statistics by itself.
Anyway, a full port scan would take 7.5 years :-)
On 11.11.2020 22:07, Paul via 44Net wrote:
You are too kind I block for three years Paul
On 11/11/2020 17:59, Marius Petrescu via 44Net wrote:
Just FYI:
I have have some 550 distinct IP addresses trying to connect from the internet via tunnel to unavailable ports via my gateway every hour.
What I do is to place them in a list and blacklist them for 1 hour :-)
Marius, YO2LOJ
On 11.11.2020 18:00, Paul Sladen via 44Net wrote:
On Wed, 11 Nov 2020, G1FEF via 44Net wrote:
From what I have seen logged into the GW machine itself, ...
Hopefully the net ops guys at UCSD can ...
Fundemental problem here (for debugging network issues) is that neither ARDC/Amprnet/44Net (...nor CAIDA), have full direct control, or access, to their own network instructure.
CAIDA/UCSD is beholden to random upstream filtering as much in 2001[1] and 2009[2] as it is now. And in-turn, AmprGW is/was beholden (2019) to an ethernet switch with customised firmware[3]... a blackbox.
Graphs used to show the packet flow for Network Telescope (44net):
https://www.caida.org/data/realtime/telescope/?monitor=telescope_attack&...
but those broke (~2019-12-11), giving less insight for debugging.
ARDC now has the resources to put independently hosted redundancy in place for 44net. Perhaps it would make sense to prioritise AmprGW infrastructure over distributions of funds to other organisations? [4]
-Paul
[1] Shannon (2001) https://www.caida.org/research/security/code-red/coderedv2_analysis.xml#back...
"filter was put into place upstream of the monitor, we were unable to capture IP packet headers after 16:30 UTC"
[2] Polterock (2012) https://blog.caida.org/best_available_data/2012/04/04/targeted-serendipity-t...
"increase in the amount of data stored after April 2009 due to the removal of an upstream rate limit filter on incoming packets"
[3] Kantor (October 2019) "I don't know the make and model of the switch that is crashing. I believe it may be running locally-modified firmware."
[4] ie. put a moratorium on the fun "grant giving" side of the business, until the primary/core mission of bringing AmprGW services under full control has been solved.
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
______________________________________________ This email has been scanned by Netintelligence http://www.netintelligence.com/email
On 11/11/20 8:00 AM, Paul Sladen via 44Net wrote:
CAIDA/UCSD is beholden to random upstream filtering as much in 2001[1] and 2009[2] as it is now. And in-turn, AmprGW is/was beholden (2019) to an ethernet switch with customised firmware[3]... a blackbox.
I can answer this part, at least. The make and model is a juniper ex3300-48t. It is not running any customized firmware. Rather, the link drops down into a small vlan grouping with the link from UCSD, a link to the ampr gw box, and a port replicator. For whatever reason, when the ampr gw box reboots, there is a chance it takes the switch with it. usually, the switch just reboots, but sometimes it full on crashes and needs a power cycle.
It has been pretty stable recently, however.
Last flapped : 2019-10-18 01:34:48 PDT (55w5d 08:34 ago) ( on all three ports )
In other news, I'm still waiting to hear back from UCSD. Keep in mind it is a holiday here, so it may be tomorrow.
Dan
Dan,
Please keep us posted on USCD's response. I'm experiencing a 30% packet loss to the gateway tonight and that's not acceptable. I don't want to make waves or cause trouble....but this is not sustainable. The packet loss started again tonight around 5PM (PST) and has so far made a complete mess of two of our DMR nets.
73's
-Albert WB7AWL
-----Original Message----- From: 44Net [mailto:44net-bounces+wb7awl=lawsonpc.com@mailman.ampr.org] On Behalf Of Daniel E Andersen via 44Net Sent: Wednesday, November 11, 2020 9:06 PM To: 44net@mailman.ampr.org Cc: Daniel E Andersen dea@caida.org Subject: Re: [44net] Lost Packets
On 11/11/20 8:00 AM, Paul Sladen via 44Net wrote:
CAIDA/UCSD is beholden to random upstream filtering as much in 2001[1] and 2009[2] as it is now. And in-turn, AmprGW is/was beholden (2019) to an ethernet switch with customised firmware[3]... a blackbox.
I can answer this part, at least. The make and model is a juniper ex3300-48t. It is not running any customized firmware. Rather, the link drops down into a small vlan grouping with the link from UCSD, a link to the ampr gw box, and a port replicator. For whatever reason, when the ampr gw box reboots, there is a chance it takes the switch with it. usually, the switch just reboots, but sometimes it full on crashes and needs a power cycle.
It has been pretty stable recently, however.
Last flapped : 2019-10-18 01:34:48 PDT (55w5d 08:34 ago) ( on all three ports )
In other news, I'm still waiting to hear back from UCSD. Keep in mind it is a holiday here, so it may be tomorrow.
Dan _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
This may sound blunt, but why do you need to run DMR traffic from/to the internet via 44net if you don't have a BGP announced subnet? Using your public IP for it (since you have a gateway, otherwise you would not need ampr-gw) would actually circumvent all those problems related to the gateway. Also, your partners would experience a round trip time cut in half by connecting directly to you or you connecting to them via public IP instead of the client<->ampr-gw<->client option. And if they also use 44net, then again the gateway should not matter, since all tunnels are full mesh.
The AMPR tunneling system is for interlinking isolated subnets and the gateway itself to provide management and occasional internet access, not for providing high speed high performance routing, like those needed for DV traffic.
Talking of sustainability, you use the gateway for something it was not meant to support, not mentioning the contribution to clogging the ampr-gw router itself.
Marius, YO2LOJ
On 12.11.2020 07:15, Albert Lawson via 44Net wrote:
Dan,
Please keep us posted on USCD's response. I'm experiencing a 30% packet loss to the gateway tonight and that's not acceptable. I don't want to make waves or cause trouble....but this is not sustainable. The packet loss started again tonight around 5PM (PST) and has so far made a complete mess of two of our DMR nets.
73's
-Albert WB7AWL
-----Original Message----- From: 44Net [mailto:44net-bounces+wb7awl=lawsonpc.com@mailman.ampr.org] On Behalf Of Daniel E Andersen via 44Net Sent: Wednesday, November 11, 2020 9:06 PM To: 44net@mailman.ampr.org Cc: Daniel E Andersen dea@caida.org Subject: Re: [44net] Lost Packets
On 11/11/20 8:00 AM, Paul Sladen via 44Net wrote:
CAIDA/UCSD is beholden to random upstream filtering as much in 2001[1] and 2009[2] as it is now. And in-turn, AmprGW is/was beholden (2019) to an ethernet switch with customised firmware[3]... a blackbox.
I can answer this part, at least. The make and model is a juniper ex3300-48t. It is not running any customized firmware. Rather, the link drops down into a small vlan grouping with the link from UCSD, a link to the ampr gw box, and a port replicator. For whatever reason, when the ampr gw box reboots, there is a chance it takes the switch with it. usually, the switch just reboots, but sometimes it full on crashes and needs a power cycle.
It has been pretty stable recently, however.
Last flapped : 2019-10-18 01:34:48 PDT (55w5d 08:34 ago) ( on all three ports )
In other news, I'm still waiting to hear back from UCSD. Keep in mind it is a holiday here, so it may be tomorrow.
Dan _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
I am with Marius on this. Using a single point to route all the 44 net traffic by tunnel is good for small communication that wont suffer from resend or such. But for a voice communication that need to have a steady stream you are looking for trouble. Of course it will work most of the time, But nope it wont work all the time.
Pierre VE2PF
________________________________________ De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Marius Petrescu via 44Net 44net@mailman.ampr.org Envoyé : 12 novembre 2020 14:13 À : 44net@mailman.ampr.org Cc : Marius Petrescu Objet : Re: [44net] Lost Packets
This may sound blunt, but why do you need to run DMR traffic from/to the internet via 44net if you don't have a BGP announced subnet? Using your public IP for it (since you have a gateway, otherwise you would not need ampr-gw) would actually circumvent all those problems related to the gateway. Also, your partners would experience a round trip time cut in half by connecting directly to you or you connecting to them via public IP instead of the client<->ampr-gw<->client option. And if they also use 44net, then again the gateway should not matter, since all tunnels are full mesh.
The AMPR tunneling system is for interlinking isolated subnets and the gateway itself to provide management and occasional internet access, not for providing high speed high performance routing, like those needed for DV traffic.
Talking of sustainability, you use the gateway for something it was not meant to support, not mentioning the contribution to clogging the ampr-gw router itself.
Marius, YO2LOJ
On 12.11.2020 07:15, Albert Lawson via 44Net wrote:
Dan,
Please keep us posted on USCD's response. I'm experiencing a 30% packet loss to the gateway tonight and that's not acceptable. I don't want to make waves or cause trouble....but this is not sustainable. The packet loss started again tonight around 5PM (PST) and has so far made a complete mess of two of our DMR nets.
73's
-Albert WB7AWL
-----Original Message----- From: 44Net [mailto:44net-bounces+wb7awl=lawsonpc.com@mailman.ampr.org] On Behalf Of Daniel E Andersen via 44Net Sent: Wednesday, November 11, 2020 9:06 PM To: 44net@mailman.ampr.org Cc: Daniel E Andersen dea@caida.org Subject: Re: [44net] Lost Packets
On 11/11/20 8:00 AM, Paul Sladen via 44Net wrote:
CAIDA/UCSD is beholden to random upstream filtering as much in 2001[1] and 2009[2] as it is now. And in-turn, AmprGW is/was beholden (2019) to an ethernet switch with customised firmware[3]... a blackbox.
I can answer this part, at least. The make and model is a juniper ex3300-48t. It is not running any customized firmware. Rather, the link drops down into a small vlan grouping with the link from UCSD, a link to the ampr gw box, and a port replicator. For whatever reason, when the ampr gw box reboots, there is a chance it takes the switch with it. usually, the switch just reboots, but sometimes it full on crashes and needs a power cycle.
It has been pretty stable recently, however.
Last flapped : 2019-10-18 01:34:48 PDT (55w5d 08:34 ago) ( on all three ports )
In other news, I'm still waiting to hear back from UCSD. Keep in mind it is a holiday here, so it may be tomorrow.
Dan _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
_________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Not wanting to pile on here... but I do recommend for this use case to stand up a lightweight VPS that will do BGP announcements on your behalf and then use that as your own IPIP or GRE tunnel back to your onsite location(s). We have three points of connectivity into a single VPS that are routing our 44Net space to a multisite system that supports a strong mix of DMR, D-STAR, YSF, and Allstar/IAX2 as well as logging, telemetry, etc. Works great and is much more robust than the IPIP mesh. It also allows us to do the IPIP/GRE over IPv6 addressing so we can avoid NATing connections over standard cable modem connections.
There are a few providers that will do BGP announcements for you with a cheap VPS, but we have had very good success with FreeRangeCloud.com.
Jason N8EI
-----Original Message----- From: 44Net 44net-bounces+jason=mfamily.org@mailman.ampr.org On Behalf Of pete M via 44Net Sent: Thursday, November 12, 2020 2:40 PM To: AMPRNet working group 44net@mailman.ampr.org Cc: pete M petem001@hotmail.com Subject: Re: [44net] Lost Packets
I am with Marius on this. Using a single point to route all the 44 net traffic by tunnel is good for small communication that wont suffer from resend or such. But for a voice communication that need to have a steady stream you are looking for trouble. Of course it will work most of the time, But nope it wont work all the time.
Pierre VE2PF
________________________________________ De : 44Net 44net-bounces+petem001=hotmail.com@mailman.ampr.org de la part de Marius Petrescu via 44Net 44net@mailman.ampr.org Envoyé : 12 novembre 2020 14:13 À : 44net@mailman.ampr.org Cc : Marius Petrescu Objet : Re: [44net] Lost Packets
This may sound blunt, but why do you need to run DMR traffic from/to the internet via 44net if you don't have a BGP announced subnet? Using your public IP for it (since you have a gateway, otherwise you would not need ampr-gw) would actually circumvent all those problems related to the gateway. Also, your partners would experience a round trip time cut in half by connecting directly to you or you connecting to them via public IP instead of the client<->ampr-gw<->client option. And if they also use 44net, then again the gateway should not matter, since all tunnels are full mesh.
The AMPR tunneling system is for interlinking isolated subnets and the gateway itself to provide management and occasional internet access, not for providing high speed high performance routing, like those needed for DV traffic.
Talking of sustainability, you use the gateway for something it was not meant to support, not mentioning the contribution to clogging the ampr-gw router itself.
Marius, YO2LOJ
On 12.11.2020 07:15, Albert Lawson via 44Net wrote:
Dan,
Please keep us posted on USCD's response. I'm experiencing a 30% packet loss to the gateway tonight and that's not acceptable. I don't want to make waves or cause trouble....but this is not sustainable. The packet loss started again tonight around 5PM (PST) and has so far made a complete mess of two of our DMR nets.
73's
-Albert WB7AWL
-----Original Message----- From: 44Net [mailto:44net-bounces+wb7awl=lawsonpc.com@mailman.ampr.org] On Behalf Of Daniel E Andersen via 44Net Sent: Wednesday, November 11, 2020 9:06 PM To: 44net@mailman.ampr.org Cc: Daniel E Andersen dea@caida.org Subject: Re: [44net] Lost Packets
On 11/11/20 8:00 AM, Paul Sladen via 44Net wrote:
CAIDA/UCSD is beholden to random upstream filtering as much in 2001[1] and 2009[2] as it is now. And in-turn, AmprGW is/was beholden (2019) to an ethernet switch with customised firmware[3]... a blackbox.
I can answer this part, at least. The make and model is a juniper ex3300-48t. It is not running any customized firmware. Rather, the link drops down into a small vlan grouping with the link from UCSD, a link to the ampr gw box, and a port replicator. For whatever reason, when the ampr gw box reboots, there is a chance it takes the switch with it. usually, the switch just reboots, but sometimes it full on crashes and needs a power cycle.
It has been pretty stable recently, however.
Last flapped : 2019-10-18 01:34:48 PDT (55w5d 08:34 ago) ( on all three ports )
In other news, I'm still waiting to hear back from UCSD. Keep in mind it is a holiday here, so it may be tomorrow.
Dan _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
_________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
_________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
If you haven't reviewed https://www.youtube.com/watch?v=OxsmGaFZ2MM it might be a good time to do so. There is also a group at https://groups.io/g/net-44-vpn -- I am using Spartan and they have a $2.50/mon. VPS and will advertise your 44.x.x.x address space /24 or larger.
On Thu, Nov 12, 2020 at 1:13 PM Jason McCormick via 44Net < 44net@mailman.ampr.org> wrote:
Not wanting to pile on here... but I do recommend for this use case to stand up a lightweight VPS that will do BGP announcements on your behalf and then use that as your own IPIP or GRE tunnel back to your onsite location(s). We have three points of connectivity into a single VPS that are routing our 44Net space to a multisite system that supports a strong mix of DMR, D-STAR, YSF, and Allstar/IAX2 as well as logging, telemetry, etc. Works great and is much more robust than the IPIP mesh. It also allows us to do the IPIP/GRE over IPv6 addressing so we can avoid NATing connections over standard cable modem connections.
There are a few providers that will do BGP announcements for you with a cheap VPS, but we have had very good success with FreeRangeCloud.com.
Jason N8EI
A reminder to those using icmp echo/reply (ping & traceroute) to measure network performance.
Due to DOS attacks many ISPs rate limit ICMP echo/reply traffic because it is usually kicked over to router’s CPU instead of being handled in hardware.
I’ve been bitten by this a couple of times trying to diagnose network issues.
Neil N0SFH
On Thu, Nov 12, 2020 at 6:21 PM K7VE - John via 44Net < 44net@mailman.ampr.org> wrote:
If you haven't reviewed https://www.youtube.com/watch?v=OxsmGaFZ2MM it might be a good time to do so. There is also a group at https://groups.io/g/net-44-vpn -- I am using Spartan and they have a $2.50/mon. VPS and will advertise your 44.x.x.x address space /24 or larger.
On Thu, Nov 12, 2020 at 1:13 PM Jason McCormick via 44Net < 44net@mailman.ampr.org> wrote:
Not wanting to pile on here... but I do recommend for this use case to stand up a lightweight VPS that will do BGP announcements on your behalf and then use that as your own IPIP or GRE tunnel back to your onsite location(s). We have three points of connectivity into a single VPS that are routing our 44Net space to a multisite system that supports a strong mix of DMR, D-STAR, YSF, and Allstar/IAX2 as well as logging, telemetry, etc. Works great and is much more robust than the IPIP mesh. It also
allows
us to do the IPIP/GRE over IPv6 addressing so we can avoid NATing connections over standard cable modem connections.
There are a few providers that will do BGP announcements for you with a cheap VPS, but we have had very good success with FreeRangeCloud.com.
Jason N8EI
--
John D. Hays - K7VE Kingston, WA http://k7ve.org/blog http://twitter.com/#!/john_hays http://www.facebook.com/john.d.hays _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
--
Sent from Gmail Mobile
Thank You John. That was a very good presentation. On a personal note: It brought a tear to my eye when you introduced Brian. We have exchanged many emails over the years, but I never got the chance to meet him in person.
73's
-Albert
-----Original Message----- From: 44Net [mailto:44net-bounces+wb7awl=lawsonpc.com@mailman.ampr.org] On Behalf Of K7VE - John via 44Net Sent: Thursday, November 12, 2020 4:21 PM To: AMPRNet working group 44net@mailman.ampr.org Cc: K7VE - John k7ve@k7ve.org Subject: Re: [44net] Lost Packets
If you haven't reviewed https://www.youtube.com/watch?v=OxsmGaFZ2MM it might be a good time to do so. There is also a group at https://groups.io/g/net-44-vpn -- I am using Spartan and they have a $2.50/mon. VPS and will advertise your 44.x.x.x address space /24 or larger.
On Thu, Nov 12, 2020 at 1:13 PM Jason McCormick via 44Net < 44net@mailman.ampr.org> wrote:
Not wanting to pile on here... but I do recommend for this use case to stand up a lightweight VPS that will do BGP announcements on your behalf and then use that as your own IPIP or GRE tunnel back to your onsite location(s). We have three points of connectivity into a single VPS that are routing our 44Net space to a multisite system that supports a strong mix of DMR, D-STAR, YSF, and Allstar/IAX2 as well as logging, telemetry, etc. Works great and is much more robust than the IPIP mesh. It also allows us to do the IPIP/GRE over IPv6 addressing so we can avoid NATing connections over standard cable modem connections.
There are a few providers that will do BGP announcements for you with a cheap VPS, but we have had very good success with FreeRangeCloud.com.
Jason N8EI
Marius,
Bluntness is fine. Coming from the old days of packet, I find that my skin is still pretty thick.
Understand that I've been out of this for a while. And I'm seeing that what you say makes sense. I have a BGP provider that will advertise my route, but the standard for advertising a subnet via BGP is no less than /24. I'm waiting to hear back from Chris on expanding my allocation from /27 to /24.
Thanks,
73's
-Albert WB7AWL
-----Original Message----- From: 44Net [mailto:44net-bounces+wb7awl=lawsonpc.com@mailman.ampr.org] On Behalf Of Marius Petrescu via 44Net Sent: Thursday, November 12, 2020 11:13 AM To: 44net@mailman.ampr.org Cc: Marius Petrescu marius@yo2loj.ro Subject: Re: [44net] Lost Packets
This may sound blunt, but why do you need to run DMR traffic from/to the internet via 44net if you don't have a BGP announced subnet? Using your public IP for it (since you have a gateway, otherwise you would not need ampr-gw) would actually circumvent all those problems related to the gateway. Also, your partners would experience a round trip time cut in half by connecting directly to you or you connecting to them via public IP instead of the client<->ampr-gw<->client option. And if they also use 44net, then again the gateway should not matter, since all tunnels are full mesh.
The AMPR tunneling system is for interlinking isolated subnets and the gateway itself to provide management and occasional internet access, not for providing high speed high performance routing, like those needed for DV traffic.
Talking of sustainability, you use the gateway for something it was not meant to support, not mentioning the contribution to clogging the ampr-gw router itself.
Marius, YO2LOJ
On 12.11.2020 07:15, Albert Lawson via 44Net wrote:
Dan,
Please keep us posted on USCD's response. I'm experiencing a 30% packet loss to the gateway tonight and that's not acceptable. I don't want to make waves or cause trouble....but this is not sustainable. The packet loss started again tonight around 5PM (PST) and has so far made a complete mess of two of our DMR nets.
73's
-Albert WB7AWL
-----Original Message----- From: 44Net [mailto:44net-bounces+wb7awl=lawsonpc.com@mailman.ampr.org] On Behalf Of Daniel E Andersen via 44Net Sent: Wednesday, November 11, 2020 9:06 PM To: 44net@mailman.ampr.org Cc: Daniel E Andersen dea@caida.org Subject: Re: [44net] Lost Packets
On 11/11/20 8:00 AM, Paul Sladen via 44Net wrote:
CAIDA/UCSD is beholden to random upstream filtering as much in 2001[1] and 2009[2] as it is now. And in-turn, AmprGW is/was beholden (2019) to an ethernet switch with customised firmware[3]... a blackbox.
I can answer this part, at least. The make and model is a juniper ex3300-48t. It is not running any customized firmware. Rather, the link drops down into a small vlan grouping with the link from UCSD, a link to the ampr gw box, and a port replicator. For whatever reason, when the ampr gw box reboots, there is a chance it takes the switch with it. usually, the switch just reboots, but sometimes it full on crashes and needs a power cycle.
It has been pretty stable recently, however.
Last flapped : 2019-10-18 01:34:48 PDT (55w5d 08:34 ago) ( on all three ports )
In other news, I'm still waiting to hear back from UCSD. Keep in mind it is a holiday here, so it may be tomorrow.
Dan _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
_________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
So, I've been told by the UCSD folks that CENIC completed some maintenance involving the LA and Pomona routes this morning. It's perhaps wishful thinking on my part, but are folks still seeing packet loss? I have not been able to replicate the issue, so for now must rely on this list for debugging information.
Another possible data point that may be of use. SDSC's website www.sdsc.edu (132.249.21.111 ) should be topologically identical ( or near enough that it shouldn't matter ). If packet loss to this machine is significantly different than to 44.0.0.1, that points us to possible routing issues over a more physical issue.
Dan
On 11/11/20 9:15 PM, Albert Lawson wrote:
Dan,
Please keep us posted on USCD's response. I'm experiencing a 30% packet loss to the gateway tonight and that's not acceptable. I don't want to make waves or cause trouble....but this is not sustainable. The packet loss started again tonight around 5PM (PST) and has so far made a complete mess of two of our DMR nets.
73's
-Albert WB7AWL
-----Original Message----- From: 44Net [mailto:44net-bounces+wb7awl=lawsonpc.com@mailman.ampr.org] On Behalf Of Daniel E Andersen via 44Net Sent: Wednesday, November 11, 2020 9:06 PM To: 44net@mailman.ampr.org Cc: Daniel E Andersen dea@caida.org Subject: Re: [44net] Lost Packets
On 11/11/20 8:00 AM, Paul Sladen via 44Net wrote:
CAIDA/UCSD is beholden to random upstream filtering as much in 2001[1] and 2009[2] as it is now. And in-turn, AmprGW is/was beholden (2019) to an ethernet switch with customised firmware[3]... a blackbox.
I can answer this part, at least. The make and model is a juniper ex3300-48t. It is not running any customized firmware. Rather, the link drops down into a small vlan grouping with the link from UCSD, a link to the ampr gw box, and a port replicator. For whatever reason, when the ampr gw box reboots, there is a chance it takes the switch with it. usually, the switch just reboots, but sometimes it full on crashes and needs a power cycle.
It has been pretty stable recently, however.
Last flapped : 2019-10-18 01:34:48 PDT (55w5d 08:34 ago) ( on all three ports )
In other news, I'm still waiting to hear back from UCSD. Keep in mind it is a holiday here, so it may be tomorrow.
Dan _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Dan,
Tried both from the office and at home....this is pretty representative of what I see from both locations..
--- ampr.org ping statistics --- 100 packets transmitted, 67 received, 33% packet loss, time 99798ms rtt min/avg/max/mdev = 32.771/37.410/62.854/5.015 ms
--- 132.249.21.111 ping statistics --- 100 packets transmitted, 71 received, 29% packet loss, time 99697ms rtt min/avg/max/mdev = 33.062/36.580/50.200/3.406 ms
Thanks
-Albert
-----Original Message----- From: Daniel E Andersen [mailto:dea@caida.org] Sent: Thursday, November 12, 2020 11:59 AM To: Albert Lawson wb7awl@LAWSONPC.COM; AMPRNet working group 44net@mailman.ampr.org Subject: Re: [44net] Lost Packets
So, I've been told by the UCSD folks that CENIC completed some maintenance involving the LA and Pomona routes this morning. It's perhaps wishful thinking on my part, but are folks still seeing packet loss? I have not been able to replicate the issue, so for now must rely on this list for debugging information.
Another possible data point that may be of use. SDSC's website www.sdsc.edu (132.249.21.111 ) should be topologically identical ( or near enough that it shouldn't matter ). If packet loss to this machine is significantly different than to 44.0.0.1, that points us to possible routing issues over a more physical issue.
Dan
On 11/11/20 9:15 PM, Albert Lawson wrote:
Dan,
Please keep us posted on USCD's response. I'm experiencing a 30% packet loss to the gateway tonight and that's not acceptable. I don't want to make waves or cause trouble....but this is not sustainable. The packet loss started again tonight around 5PM (PST) and has so far made a complete mess of two of our DMR nets.
73's
-Albert WB7AWL
-----Original Message----- From: 44Net [mailto:44net-bounces+wb7awl=lawsonpc.com@mailman.ampr.org] On Behalf Of Daniel E Andersen via 44Net Sent: Wednesday, November 11, 2020 9:06 PM To: 44net@mailman.ampr.org Cc: Daniel E Andersen dea@caida.org Subject: Re: [44net] Lost Packets
On 11/11/20 8:00 AM, Paul Sladen via 44Net wrote:
CAIDA/UCSD is beholden to random upstream filtering as much in 2001[1] and 2009[2] as it is now. And in-turn, AmprGW is/was beholden (2019) to an ethernet switch with customised firmware[3]... a blackbox.
I can answer this part, at least. The make and model is a juniper ex3300-48t. It is not running any customized firmware. Rather, the link drops down into a small vlan grouping with the link from UCSD, a link to the ampr gw box, and a port replicator. For whatever reason, when the ampr gw box reboots, there is a chance it takes the switch with it. usually, the switch just reboots, but sometimes it full on crashes and needs a power cycle.
It has been pretty stable recently, however.
Last flapped : 2019-10-18 01:34:48 PDT (55w5d 08:34 ago) ( on all three ports )
In other news, I'm still waiting to hear back from UCSD. Keep in mind it is a holiday here, so it may be tomorrow.
Dan _________________________________________ 44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
Paul,
Wait...are you saying that you're receiving IPENCAP packets from a registered gateway - that contains malicious or invalid traffic?
Or that you see malicious traffic with an internal source IP matching the subnet registered to GB7CIP??? (AMPRGW doesn't send 44 packets unless they's BGP, as I recall...)
Or that you're receiving routes from a source other than AMPRGW???
In networking context, it's not completely clear what you mean by "pairs of addresses". I don't understand the need to obfuscate the IPs.
<gb7cip hosted 44net: gateway routes>
- KB3VWG
Hi This is the standard output coming on from the amprgw gateway over protocol 4 tcpdump -ni eth# proto 4 on your linux server in/out interface to gatewaay (firewalled) address entry for the 44net subnets that my system serves to mine and my downstream UK link partners over amprnet IP over UDP tunnels)
Address 3 and Address 4 would (idealy) normally be axpected to be from 44net. Those that are non 44net, are mostly from attacking scanning system. I am not going to mention countries for too many.
How do you determing a valid non amprnet address as being trusted you can not.
(I have other security filtering devices (Firewalls) infront of my gb7cip system including it's own denigh all firewall in/out unless a valid rule is in place) So I only see BANDITs scanning attacking via the protocol 4 (tunl0) all get blocked as rule state address3 and address must be from 44net /9 and /10 (restricted valid range as of July 2019)
Someone else can do the trace themselves on their server Internet facing interfaces dmz. and output interfaces to their system running their services. This issue is not new. Just getting worse de Paul g4apl
On 11/11/2020 12:27 lleachii--- via 44Net 44net@mailman.ampr.org wrote:
Paul,
Wait...are you saying that you're receiving IPENCAP packets from a registered gateway - that contains malicious or invalid traffic?
Or that you see malicious traffic with an internal source IP matching the subnet registered to GB7CIP??? (AMPRGW doesn't send 44 packets unless they's BGP, as I recall...)
Or that you're receiving routes from a source other than AMPRGW???
In networking context, it's not completely clear what you mean by "pairs of addresses". I don't understand the need to obfuscate the IPs.
<gb7cip hosted 44net: gateway routes>
- KB3VWG
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net
This email has been scanned by Netintelligence http://www.netintelligence.com/email
Paul et. al.,
Thanks for your clarifications. I believe I understand what you mean now.
- Your AMPR firewall/gateway blocks ALL non-AMPRNet traffic by default (Good! I didn't understand, because I drop ALL traffic by default, lol) - You only see increased hits at the IPENCAP tunnel's WAN-facing side because you block the traffic prior to forwarding - and this traffic is coming from AMPRGW's Public IP (i.e. Internet traffic)
I don't need a list of IPs particularly; but your information helped me find a search target. I have Netflow and SNMP records of my WAN and AMPR interfaces. I can see if any of my 44 IPs have been hit identically.
Looking at Neflow traffic by total flows: Traffic increased at about 01:00 UTC on Wednesday, 4 November. It subsided approximately 05:00 UTC on Sunday, 8 November. The increased traffic is primarily TCP. I can send a screenshot to you and Albert. Obviously, I can search the IPs in the block if anyone is curious - or needs to confirm anything.
- KB3VWG
I think he is trying to say he receives: Outer (IPIP) pair: from 169.228.34.84 to his gateway (<###.###.###.###>) -> Inner pair (encapsulated): from <any non 44net address-bandits> to <gb7cip hosted 44net: gateway routes> This is how any internet originated traffic looks like, and everything comes over ampr-gw (44.0.0.1/169.228.34.84).
There is not much one can do about it, except unregistering the hosts in the DNS, which will prevent forwarding by the ampr gateway.
Marius, YO2LOJ
On 11.11.2020 14:27, lleachii--- via 44Net wrote:
Paul,
Wait...are you saying that you're receiving IPENCAP packets from a registered gateway - that contains malicious or invalid traffic?
Or that you see malicious traffic with an internal source IP matching the subnet registered to GB7CIP??? (AMPRGW doesn't send 44 packets unless they's BGP, as I recall...)
Or that you're receiving routes from a source other than AMPRGW???
In networking context, it's not completely clear what you mean by "pairs of addresses". I don't understand the need to obfuscate the IPs.
<gb7cip hosted 44net: gateway routes>
- KB3VWG
44Net mailing list 44Net@mailman.ampr.org https://mailman.ampr.org/mailman/listinfo/44net