Send Outages-discussion mailing list submissions to
outages-discussion@outages.org
To subscribe or unsubscribe via the World Wide Web, visit
https://puck.nether.net/mailman/listinfo/outages-discussion
or, via email, send a message with subject or body 'help' to
outages-discussion-requ...@outages.org
You can reach the person managing the list at
outages-discussion-ow...@outages.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Outages-discussion digest..."
Today's Topics:
1. Re: [outages] Ping to Google 8.8.8.8 (Jay Hennigan)
2. Re: [outages] Ping to Google 8.8.8.8 (Jay R. Ashworth)
3. Re: [outages] Ping to Google 8.8.8.8 (Mark Tinka)
4. Re: [outages] Ping to Google 8.8.8.8 (Matthew Walster)
5. Re: [outages] Ping to Google 8.8.8.8 (Jay R. Ashworth)
6. Re: [outages] Ping to Google 8.8.8.8 (Mark Tinka)
7. Re: [outages] Ping to Google 8.8.8.8 (Matthew Walster)
----------------------------------------------------------------------
Message: 1
Date: Tue, 8 Feb 2022 21:33:14 -0800
From: Jay Hennigan <j...@west.net>
To: Mark Tinka <mark@tinka.africa>, "outages-discussion@outages.org"
<outages-discussion@outages.org>
Subject: Re: [Outages-discussion] [outages] Ping to Google 8.8.8.8
Message-ID: <550f3096-3581-c1cf-cb07-bf888b29a...@west.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
[Moved to -discussion.]
On 2/8/22 20:45, Mark Tinka via Outages wrote:
> That ship long sailed.
>
> If we want to stop this behaviour, we'll have to do something about it,
> specifically, offering an alternative to Internet users that is regarded
> as official, e.g., like we do with other public services such as NTP.
So, "ping pool.ntp.org", then? Hey, it works! Problem solved.
Seriously, that would just be repeating the problem of (ab)using a
public resource for something other than its intended purpose.
To be universal, it would need to be anycast from multiple dispersed
locations. Maybe Cloudflare would be willing, like the 1.1.1.1 resolver.
There's probably some interesting data for the operator of such a
service to analyze and monetize. If popular, the operator would have
real-time observation of outages by location, ASN, etc. to a very
granular level.
--
Jay Hennigan - j...@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV
------------------------------
Message: 2
Date: Wed, 9 Feb 2022 06:17:25 +0000 (UTC)
From: "Jay R. Ashworth" <j...@baylink.com>
To: Jay Hennigan <j...@west.net>
Cc: Mark Tinka <mark@tinka.africa>, outages-discussion@outages.org
Subject: Re: [Outages-discussion] [outages] Ping to Google 8.8.8.8
Message-ID:
<1875767289.206318.1644387445834.javamail.zim...@baylink.com>
Content-Type: text/plain; charset=utf-8
----- Original Message -----
> From: "Jay Hennigan" <j...@west.net>
> [Moved to -discussion.]
>
> On 2/8/22 20:45, Mark Tinka via Outages wrote:
>
>> That ship long sailed.
>>
>> If we want to stop this behaviour, we'll have to do something about it,
>> specifically, offering an alternative to Internet users that is regarded
>> as official, e.g., like we do with other public services such as NTP.
>
> So, "ping pool.ntp.org", then? Hey, it works! Problem solved.
>
> Seriously, that would just be repeating the problem of (ab)using a
> public resource for something other than its intended purpose.
Well, what's the actual problem here?
Is there a measurable problem from the actual 64 bytes per second of ICMP?
Or is the problem untrained 'engineers' getting all up in their bootstraps
about "it not working" when they try to do it?
We ping and trace because *we know what machine we're trying to diagnose*,
usually, though I'll admit to occasionally using it to diagnose the network
as well. I just *understand the limits on that*, and usually try to have
3 or 4 pieces of evidence something's broke before I ask...
Cheers,
-- jra
--
Jay R. Ashworth Baylink j...@baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII
St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
------------------------------
Message: 3
Date: Wed, 9 Feb 2022 08:41:18 +0200
From: Mark Tinka <mark@tinka.africa>
To: Jay Hennigan <j...@west.net>, "outages-discussion@outages.org"
<outages-discussion@outages.org>
Subject: Re: [Outages-discussion] [outages] Ping to Google 8.8.8.8
Message-ID: <321f29ee-27a4-3ebd-fa0e-ccb1b62c7734@tinka.africa>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 2/9/22 07:33, Jay Hennigan wrote:
> So, "ping pool.ntp.org", then? Hey, it works! Problem solved.
>
> Seriously, that would just be repeating the problem of (ab)using a
> public resource for something other than its intended purpose.
You are putting words in my mouth...
To be clear, I mean that we develop ping-specific infrastructure that is
public and well-known by all and sundry, in the same way we developed
NTP for time-specific infrastructure, that is public and well-known by
all and sundry.
Why would I recommend that anyone ping NTP servers for testing :-\?
The fact that you misinterpreted what I was saying (and perhaps, I could
have been clearer as well) shows just how hard it will be to get regular
folk away from pinging yahoo.com, google.com or 8.8.8.8, until we give
them something else that is built for purpose.
>
> To be universal, it would need to be anycast from multiple dispersed
> locations. Maybe Cloudflare would be willing, like the 1.1.1.1
> resolver. There's probably some interesting data for the operator of
> such a service to analyze and monetize. If popular, the operator would
> have real-time observation of outages by location, ASN, etc. to a very
> granular level.
Agree.
My point is we have to be deliberate about it, because the general
public don't care.
Mark.
------------------------------
Message: 4
Date: Wed, 9 Feb 2022 06:55:40 +0000
From: Matthew Walster <matt...@walster.org>
To: "Jay R. Ashworth" <j...@baylink.com>
Cc: Jay Hennigan <j...@west.net>, Mark Tinka <mark@tinka.africa>,
outages-discussion@outages.org
Subject: Re: [Outages-discussion] [outages] Ping to Google 8.8.8.8
Message-ID:
<CADLW2vzqW-yUs1Xztd-6qAwTJ4watm2bKG30ny4Fibv7YQ=t...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Wed, 9 Feb 2022, 06:17 Jay R. Ashworth, <j...@baylink.com> wrote:
> Is there a measurable problem from the actual 64 bytes per second of ICMP?
>
> Or is the problem untrained 'engineers' getting all up in their bootstraps
> about "it not working" when they try to do it?
>
As I've recently been informed, certain shipping hardware from a big name
manufacturer does liveness checks every second to 8.8.8.8 via ICMP. It's
gone past diagnostics during a fault, it's now being treated as a public
facility.
What's more, it's being treated as a canonical source of information
despite protests by the people operating the service that happens to give
that side effect, and complaints being raised when it is rate limited due
to abuse.
It doesn't matter what is invented to replace it, "ping 8.8.8.8" is very
fast to type, easy to remember, and is probably going to take the same
amount of time to disappear as people setting 4.2.2.2 as their nameserver
did.
M
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/outages-discussion/attachments/20220209/d2a94c9d/attachment-0001.htm>
------------------------------
Message: 5
Date: Wed, 9 Feb 2022 06:58:51 +0000 (UTC)
From: "Jay R. Ashworth" <j...@baylink.com>
To: Matthew Walster <matt...@walster.org>
Cc: Jay Hennigan <j...@west.net>, Mark Tinka <mark@tinka.africa>,
outages-discussion@outages.org
Subject: Re: [Outages-discussion] [outages] Ping to Google 8.8.8.8
Message-ID:
<1572972602.206396.1644389931063.javamail.zim...@baylink.com>
Content-Type: text/plain; charset=utf-8
----- Original Message -----
> From: "Matthew Walster" <matt...@walster.org>
> On Wed, 9 Feb 2022, 06:17 Jay R. Ashworth, <j...@baylink.com> wrote:
>
>> Is there a measurable problem from the actual 64 bytes per second of ICMP?
>>
>> Or is the problem untrained 'engineers' getting all up in their bootstraps
>> about "it not working" when they try to do it?
>
> As I've recently been informed, certain shipping hardware from a big name
> manufacturer does liveness checks every second to 8.8.8.8 via ICMP. It's
> gone past diagnostics during a fault, it's now being treated as a public
> facility.
No shit?
Well, that's a big enough problem to fix at the source, like the notorious
NTP screwup some years back.
> What's more, it's being treated as a canonical source of information
> despite protests by the people operating the service that happens to give
> that side effect, and complaints being raised when it is rate limited due
> to abuse.
Well the latter point speaks to my question: it's not the *pinging*, it's
the *bitching*.
> It doesn't matter what is invented to replace it, "ping 8.8.8.8" is very
> fast to type, easy to remember, and is probably going to take the same
> amount of time to disappear as people setting 4.2.2.2 as their nameserver
> did.
Yup, that's a lot of it.
But as I suggest, if that's 1 Mb/s of traffic aggregate, then the *pinging*
is likely not the problem... QUICK! How many simultaneous pings is that?
Cheers,
-- jra
--
Jay R. Ashworth Baylink j...@baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII
St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
------------------------------
Message: 6
Date: Wed, 9 Feb 2022 09:10:33 +0200
From: Mark Tinka <mark@tinka.africa>
To: Matthew Walster <matt...@walster.org>, "Jay R. Ashworth"
<j...@baylink.com>
Cc: Jay Hennigan <j...@west.net>, outages-discussion@outages.org
Subject: Re: [Outages-discussion] [outages] Ping to Google 8.8.8.8
Message-ID: <882e671c-0e77-b94f-bdef-2165b3ca989c@tinka.africa>
Content-Type: text/plain; charset=UTF-8; format=flowed
On 2/9/22 08:55, Matthew Walster wrote:
>
> As I've recently been informed, certain shipping hardware from a big
> name manufacturer does liveness checks every second to 8.8.8.8 via
> ICMP. It's gone past diagnostics during a fault, it's now being
> treated as a public facility.
Lost of vendors (even the unknown ones) do this.
When I look at default DNS and liveliness settings in many CPE, 8.8.8.8
is just about always there.
>
> What's more, it's being treated as a canonical source of information
> despite protests by the people operating the service that happens to
> give that side effect, and complaints being raised when it is rate
> limited due to abuse.
Most folk don't read the FAQ's of Google et al, about not using their
network for liveliness detection. They just assume it's the magic of the
Internet, and will last forever.
>
> It doesn't matter what is invented to replace it, "ping 8.8.8.8" is
> very fast to type, easy to remember, and is probably going to take the
> same amount of time to disappear as people setting 4.2.2.2 as their
> nameserver did.
If Google significantly rate-limit or block 8.8.8.8 in a way that causes
hardship, whatever is invented to replace it will catch on pretty quick.
Mark.
------------------------------
Message: 7
Date: Wed, 9 Feb 2022 07:36:00 +0000
From: Matthew Walster <matt...@walster.org>
To: "Jay R. Ashworth" <j...@baylink.com>
Cc: Jay Hennigan <j...@west.net>, Mark Tinka <mark@tinka.africa>,
outages-discussion@outages.org
Subject: Re: [Outages-discussion] [outages] Ping to Google 8.8.8.8
Message-ID:
<CADLW2vybSasqdw6m=h3bdslvhz-ixfedfnx9vw+k+k+khpf...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On Wed, 9 Feb 2022, 06:58 Jay R. Ashworth, <j...@baylink.com> wrote:
>
> But as I suggest, if that's 1 Mb/s of traffic aggregate, then the *pinging*
> is likely not the problem... QUICK! How many simultaneous pings is that?
>
It's not the bandwidth that's the problem, it's that the service wasn't
designed for that, so all of a sudden you are likely making custom
forwarding rules to push ICMP Echo Requests somewhere else, and having
sufficient infrastructure for it at all the same PoPs that you have the DNS
service.
It wouldn't surprise me (full disclosure: former Googler, but completely
unaware of anything to do with this) if it caused real issues -- I can't
remember off-hand how ICMP is treated when it comes to ECMP etc, due to
only having a two-way tuple involved.
M
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/outages-discussion/attachments/20220209/9a81f2e3/attachment.htm>
------------------------------
Subject: Digest Footer
_______________________________________________
Outages-discussion mailing list
Outages-discussion@outages.org
https://puck.nether.net/mailman/listinfo/outages-discussion
------------------------------
End of Outages-discussion Digest, Vol 144, Issue 2
**************************************************
