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.