I'm not looking to do the pinging myself. I have my own destinations I use. I also use the RIPE system on occasion. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Stephane Bortzmeyer" <bortzmeyer@nic.fr> To: "Mike Hammett" <nanog@ics-il.net> Cc: nanog@nanog.org Sent: Tuesday, February 8, 2022 12:46:54 PM Subject: Re: Authoritative Resources for Public DNS Pinging On Tue, Feb 08, 2022 at 11:56:44AM -0600, Mike Hammett <nanog@ics-il.net> wrote a message of 140 lines which said:

Are there any authoritative resources from said organizations saying you shouldn't use their servers for your persistent ping destinations?

Why not using RIPE Anchors, which are made to be pinged (reasonably)?

Orly? 64 bytes from 8.8.8.8: icmp_seq=10937 ttl=112 time=44.408 ms 64 bytes from 8.8.8.8: icmp_seq=10938 ttl=112 time=43.480 ms 64 bytes from 8.8.8.8: icmp_seq=10939 ttl=112 time=57.839 ms 64 bytes from 8.8.8.8: icmp_seq=10940 ttl=112 time=38.816 ms -LB Ms. Lady Benjamin PD Cannon of Glencoe, ASCE 6x7 Networks & 6x7 Telecom, LLC CEO ben@6by7.net <mailto:ben@6by7.net> "The only fully end-to-end encrypted global telecommunications company in the world.” ANNOUNCING: 6x7 GLOBAL MARITIME <https://alexmhoulton.wixsite.com/6x7networks> FCC License KJ6FJJ

On Feb 8, 2022, at 12:39 PM, Lukas Tribus <lukas@ltri.eu <mailto:lukas@ltri.eu>> wrote:

Hello,

On Tue, 8 Feb 2022 at 18:56, Mike Hammett <nanog@ics-il.net <mailto:nanog@ics-il.net>> wrote:

...

Yes, pinging public DNS servers is bad.

Googling didn't help me find anything.

Are there any authoritative resources from said organizations saying you shouldn't use their servers for your persistent ping destinations?

This was just posted by Matthew Walster on the outages list (since 8.8.8.8 stopped responding to ICMP somewhere):

https://peering.google.com/#/learn-more/faq <https://peering.google.com/#/learn-more/faq>

Lukas

Some people need a clue by four and I'm looking to build my collection of them. Someone on Outages was nice enough to send this about someone else's thread: https://peering.google.com/#/learn-more/faq "Google services, including Google Public DNS, are not designed as ICMP network testing services" ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Tom Beecher" <beecher@beecher.cc> To: "Mike Hammett" <nanog@ics-il.net> Cc: "NANOG" <nanog@nanog.org> Sent: Tuesday, February 8, 2022 3:01:27 PM Subject: Re: Authoritative Resources for Public DNS Pinging Are there any authoritative resources from said organizations saying you shouldn't use their servers for your persistent ping destinations? I'm not sure that an ' authoritative resource ' is really needed. It should be generally understood at this point in the internet's life that networks will block / restrict some or all ICMP traffic as they need to. On Tue, Feb 8, 2022 at 12:58 PM Mike Hammett < nanog@ics-il.net > wrote: <blockquote> Yes, pinging public DNS servers is bad. Googling didn't help me find anything. Are there any authoritative resources from said organizations saying you shouldn't use their servers for your persistent ping destinations? ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP </blockquote>

Right, someone could do that. I was more here to find ammunition to show someone that they were doing something wrong than to build anything myself. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Christopher Morrow" <morrowc.lists@gmail.com> To: "Mike Hammett" <nanog@ics-il.net> Cc: "Tom Beecher" <beecher@beecher.cc>, "NANOG" <nanog@nanog.org> Sent: Tuesday, February 8, 2022 4:35:16 PM Subject: Re: Authoritative Resources for Public DNS Pinging On Tue, Feb 8, 2022 at 4:05 PM Mike Hammett < nanog@ics-il.net > wrote: Some people need a clue by four and I'm looking to build my collection of them. Someone on Outages was nice enough to send this about someone else's thread: https://peering.google.com/#/learn-more/faq "Google services, including Google Public DNS, are not designed as ICMP network testing services" you know what you COULD do though... probe it with DNS requests, and then you know, test the service being offered, and still know that 'the internet is not on fire'. <blockquote> ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP From: "Tom Beecher" < beecher@beecher.cc > To: "Mike Hammett" < nanog@ics-il.net > Cc: "NANOG" < nanog@nanog.org > Sent: Tuesday, February 8, 2022 3:01:27 PM Subject: Re: Authoritative Resources for Public DNS Pinging <blockquote> Are there any authoritative resources from said organizations saying you shouldn't use their servers for your persistent ping destinations? </blockquote> I'm not sure that an ' authoritative resource ' is really needed. It should be generally understood at this point in the internet's life that networks will block / restrict some or all ICMP traffic as they need to. On Tue, Feb 8, 2022 at 12:58 PM Mike Hammett < nanog@ics-il.net > wrote: <blockquote> Yes, pinging public DNS servers is bad. Googling didn't help me find anything. Are there any authoritative resources from said organizations saying you shouldn't use their servers for your persistent ping destinations? ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP </blockquote> </blockquote>

On Tue, Feb 8, 2022 at 2:49 PM Mike Hammett <nanog@ics-il.net> wrote:

I was more here to find ammunition to show someone that they were doing something wrong than to build anything myself.

Someone once challenged me to find documentation showing that the Java garbage collector does not (and is not supposed to) terminate abandoned running threads. I ended up leaving that job. You can't fix willful ignorance. -- William Herrin bill@herrin.us https://bill.herrin.us/

On Tue, 8 Feb 2022, Christopher Morrow wrote:

you know what you COULD do though... probe it with DNS requests, and then you know, test the service being offered, and still know that 'the internet is not on fire'.

What?!? Use UDP to test the Internet? How would you even know if the Internet was fine but some router didn't like how your packet smelled and dropped it? ;-) Seriously though, if ICMP is becoming the problem this thread seems to believe, TCP rather than UDP is probably a better judge of the "availability of the Internet" as the remote end is going to attempt to respond. Though I cannot argue that lack of DNS also can indicate why Chicken Little is perturbed. I don't have any issues with ICMP generally, though I'm usually sending such packets to systems and servers and networks I control or have permission/access to. For people that don't have access to multiple servers dotted around the Internet, is it time for them to move away from ICMP and start using HTTP HEAD TCP requests to well-known websites to determine if a route is available and functioning? That's a lot more data when multiplied by a few million queries per second, just to check that the Internet is up... but also less likely to get filtered or throttled to the point where you get no response, even though the sky is not falling. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman@angryox.com https://www.angryox.com/ ---------------------------------------------------------------------------

Anyone swinging a clue-by-four it going to hit Meraki real hard. https://community.meraki.com/t5/Switching/Switch-Constantly-Pings-8-8-8-8/m-...

On a related note, I just discovered a NID that has 1.1.1.1 assigned to the outband interface by default, and it is apparently not user modifiable. So, not only can these devices never use 1.1.1.1 for name resolution, but attempts to determine "is the circuit up" by pinging it will always return bad information. To really pour salt on the wound, this device has no physical outbound interface (likely why the UI doesn't allow changing it). Bug report filed. I don't really want to use it for either purpose, but hopefully a fix saves someone else the headache. And it really chaps my .... when public addresses get used this way.

On 2/11/22 22:43, Mike Lewinski via NANOG wrote:

On a related note, I just discovered a NID that has 1.1.1.1 assigned to the outband interface by default, and it is apparently not user modifiable. So, not only can these devices never use 1.1.1.1 for name resolution, but attempts to determine "is the circuit up" by pinging it will always return bad information. To really pour salt on the wound, this device has no physical outbound interface (likely why the UI doesn't allow changing it).

Bug report filed. I don't really want to use it for either purpose, but hopefully a fix saves someone else the headache. And it really chaps my .... when public addresses get used this way.

Do you know if this was codified prior to 1.1.1.1 being taken over by Cloudflare? Mark.

On 2/12/22 16:43, Mike Lewinski via NANOG wrote:

Yes, I'm sure it was.

Then probably rhymes with the days of "admin/admin". If they have been pushing out security and OS updates since then, and still keep 1.1.1.1 coded, that is purely their fault. Mark.

Anyone willing to write a icmp(8/0) concatenation/concentration/proxy tool ? That can be deployed at the provider edge ? Catch all the packets !!! -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.

On Feb 8, 2022, at 21:18, Mike Hammett <nanog@ics-il.net> wrote:

 What irked me today was an equipment manufacturer. I found out because Google had some issues handling ICMP to their DNS resolvers today and some of my devices started spazzing out.

There's no reason this manufacturer doesn't just setup a variety their own servers to handle this, other than being lazy.

----- Mike Hammett Intelligent Computing Solutions

Midwest Internet Exchange

The Brothers WISP

From: "Mark Delany" <k3f@november.emu.st> To: "NANOG" <nanog@nanog.org> Sent: Tuesday, February 8, 2022 5:13:30 PM Subject: Re: Authoritative Resources for Public DNS Pinging

On 08Feb22, Mike Hammett allegedly wrote:

...

Some people need a clue by four and I'm looking to build my collection of them.

...

"Google services, including Google Public DNS, are not designed as ICMP network testing services"

Hard to disagree with "their network, their rules", but we're talking about an entrenched, pervasive, Internet-wide behaviorial issue.

My guess is that making ping/ICMP less reliable to the extent that it becomes unusable wont change fundamental behavior. Rather, it'll make said "pingers" reach for another tool that does more or less the same thing with more or less as little extra effort as possible on their part.

And what might such an alternate tool do? My guess is one which SYN/ACKs various popular TCP ports (say 22, 25, 80, 443) and maybe sends a well-formed UDP packet to a few popular DNS ports (say 53 and 119). Let's call this command "nmap -sn" with a few tweaks, shall we?

After all, it's no big deal to the pinger if their reachability command now exchanges 10-12 packets with resource intensive destination ports instead of a couple of packets to lightweight destinations. I'll bet most pingers will neither know nor care, especially if their next-gen ping works more consistently than the old one.

So. Question. Will making ping/ICMP mostly useless for home-gamers and lazy network admins change internet behaviour for the better? Or will it have unintended consequences such as an evolutionary adaptation by the tools resulting in yet more unwanted traffic which is even harder to eliminate?

Mark.

(as posted to outages) On Wed, 9 Feb 2022, 04:53 Mark Tinka, <mark@tinka.africa> wrote:

It is clear that a number of Internet users find pinging "reliable" IP addresses useful, regardless of whether it actually is or isn't, or whether it's ethical or not.

Like we have done with other public services such as NTP, perhaps it's time we developed some infrastructure for this, so that folk can have something reliable to ping that was built for purpose, and also release the Google's and Yahoo's of the world from having to bear the brunt of such.

Certainly, trying to get people to stop pinging is not going to work. Time to go with the tide, than against it.

Do a DNS query. You don't even have to randomise the id number, just query for something that will have a small set of results (so, not the root) and ensure checking is disabled. For 8.8.8.8, I'm guessing "dns.google" is probably an excellent target. If you wanted something generic, what about a PTR query for something in 10/8, directed at the AS112 project? That's pretty much the sinkhole that expects that kind of unwanted traffic... I bet that within a gnat's crotchet you'll find systemd has adopted that as a special "liveness" command or something. </snark> M

On 2/8/22 4:13 PM, Mark Delany wrote:

Hard to disagree with "their network, their rules", but we're talking about an entrenched, pervasive, Internet-wide behaviorial issue.

The entrenched, pervasive, Internet-wide behavior used to be to use any convenient SMTP server to relay mail too. The entrenched, pervasive, <something?>-wide behavior used to be to smoke on planes too. Things change with the times.

My guess is that making ping/ICMP less reliable to the extent that it becomes unusable wont change fundamental behavior. Rather, it'll make said "pingers" reach for another tool that does more or less the same thing with more or less as little extra effort as possible on their part.

I'm curious what sort of resources Google, et al., expend responding to these types of tests.

And what might such an alternate tool do? My guess is one which SYN/ACKs various popular TCP ports (say 22, 25, 80, 443) and maybe sends a well-formed UDP packet to a few popular DNS ports (say 53 and 119). Let's call this command "nmap -sn" with a few tweaks, shall we?

If ~> when that happens, we'll probably start to see responses for those tests too.

After all, it's no big deal to the pinger if their reachability command now exchanges 10-12 packets with resource intensive destination ports instead of a couple of packets to lightweight destinations. I'll bet most pingers will neither know nor care, especially if their next-gen ping works more consistently than the old one.

Though I wouldn't be surprised to learn that it might be easier for Google to respond to a full / fat / heavy weight HTTP GET / POST that includes an actual search than it is to respond to an ICMP ping. As if their network magic is a LOT more efficient / better scaled for HTTP than it is for ICMP. <ASCII shruggie>

So. Question. Will making ping/ICMP mostly useless for home-gamers and lazy network admins change internet behaviour for the better? Or will it have unintended consequences such as an evolutionary adaptation by the tools resulting in yet more unwanted traffic which is even harder to eliminate?

Time will tell. -- Grant. . . . unix || die

On 2/9/22 07:24, Grant Taylor via NANOG wrote:

The entrenched, pervasive, Internet-wide behavior used to be to use any convenient SMTP server to relay mail too.

The entrenched, pervasive, <something?>-wide behavior used to be to smoke on planes too.

Things change with the times.

Yep. And we would do well to change, as well. We can't keep fighting reality, and reality is that CPE vendors (including the big ones like the Meraki's of the world) hard-code 8.8.8.8 as a test target in their software. It's terrible behaviour, but unless we offer a more "official" alternative, it won't end. Google may stop it, but the public will simply turn to something else, and that target will not have been expecting it. Mark.

On 2/9/22 09:30, Stephane Bortzmeyer wrote:

Let me repeat that there is a service which is officially intended to be pinged/queried/etc, the RIPE Anchors.

Yeah, but how do we get out there in a manner that Jane can easily find and use, like she does 8.8.8.8? RIPE's probes are great, but only if you know about them, and how to use them. Jane doesn't know what she doesn't know, and I'm not certain she would know how to use them, even if she did. Mark.

On 2/9/22 09:42, Stephane Bortzmeyer wrote:

I don't think that John (who is probably no more clueful than Jane) knows about Google Public DNS either.

It's less about Jane and John than it is about a number of techs and IT folk who are not interested in global Internet operations. Those folk will ask Jane and John to "ping 8.8.8.8". Do it enough times, and Jane and John will be able to do it themselves, next time, as they hold on the phone for the tech to get to their spot in the queue. Same goes for CPE vendors... they don't necessarily care about global Internet operations... they just follow the trend, and that's how Jane and John become part of the problem.

The only problem is the less friendly IP address (although this will be less and less a problem with IPv6, since 2001:4860:4860::8888 is not really friendly). This can be partially mitigated with nice domain names, that an access or service provider can set up.

This. Mark.

On 2/9/22 10:12, Matthew Walster wrote:

But yes, that would be the easiest way around it. If only ping.network didn't look as though it was squatting on the name for it's resale value...

As is ping.net. Mark.

ok that’s amazing. RFC1149 amazing. Side note, am I missing something obvious where I can’t just have hardware routers strip ICMP, pipe it separately, put 500 VMs behind 4 vLBs and let the world ping the brains out of it? Who owns 69.69.69.69 - collab? How naff is this? -LB Ms. Lady Benjamin PD Cannon of Glencoe, ASCE 6x7 Networks & 6x7 Telecom, LLC CEO ben@6by7.net <mailto:ben@6by7.net> "The only fully end-to-end encrypted global telecommunications company in the world.” ANNOUNCING: 6x7 GLOBAL MARITIME <https://alexmhoulton.wixsite.com/6x7networks> FCC License KJ6FJJ

On Feb 9, 2022, at 9:38 AM, Jay Hennigan <jay@west.net <mailto:jay@west.net>> wrote:

On 2/8/22 23:42, Stephane Bortzmeyer wrote:

...

The only problem is the less friendly IP address (although this will be less and less a problem with IPv6, since 2001:4860:4860::8888 is not really friendly).

Fun fact: Someone at Sprint had the same hobby as I did in the early 1970s. Their website resolves to 2600:: which I think is rather friendly. :-)

Please don't use it for an IPv6 ping target, thanks.

-- Jay Hennigan - jay@west.net <mailto:jay@west.net> Network Engineering - CCIE #7880 503 897-8550 - WB6RDV

Perhaps owning a (small but global) cloud computing & telecom company has spoiled me, but it seems like a trivial amount of resources to me for any moderately sized company let alone a large tech/telecom like anything you’d have heard of. -LB Ms. Lady Benjamin PD Cannon of Glencoe, ASCE 6x7 Networks & 6x7 Telecom, LLC CEO ben@6by7.net "The only fully end-to-end encrypted global telecommunications company in the world.” ANNOUNCING: 6x7 GLOBAL MARITIME <https://alexmhoulton.wixsite.com/6x7networks> FCC License KJ6FJJ

On Feb 9, 2022, at 12:15 PM, Tom Beecher <beecher@beecher.cc> wrote:

Side note, am I missing something obvious where I can’t just have hardware routers strip ICMP, pipe it separately, put 500 VMs behind 4 vLBs and let the world ping the brains out of it?

Seems like a lot of overhead for zero benefit.

On Wed, Feb 9, 2022 at 2:11 PM Lady Benjamin Cannon of Glencoe <lb@6by7.net <mailto:lb@6by7.net>> wrote: ok that’s amazing.

RFC1149 amazing.

Side note, am I missing something obvious where I can’t just have hardware routers strip ICMP, pipe it separately, put 500 VMs behind 4 vLBs and let the world ping the brains out of it?

Who owns 69.69.69.69 - collab?

How naff is this?

-LB

Ms. Lady Benjamin PD Cannon of Glencoe, ASCE 6x7 Networks & 6x7 Telecom, LLC CEO ben@6by7.net <mailto:ben@6by7.net> "The only fully end-to-end encrypted global telecommunications company in the world.” ANNOUNCING: 6x7 GLOBAL MARITIME <https://alexmhoulton.wixsite.com/6x7networks>

FCC License KJ6FJJ

...

On Feb 9, 2022, at 9:38 AM, Jay Hennigan <jay@west.net <mailto:jay@west.net>> wrote:

On 2/8/22 23:42, Stephane Bortzmeyer wrote:

...

The only problem is the less friendly IP address (although this will be less and less a problem with IPv6, since 2001:4860:4860::8888 is not really friendly).

Fun fact: Someone at Sprint had the same hobby as I did in the early 1970s. Their website resolves to 2600:: which I think is rather friendly. :-)

Please don't use it for an IPv6 ping target, thanks.

-- Jay Hennigan - jay@west.net <mailto:jay@west.net> Network Engineering - CCIE #7880 503 897-8550 - WB6RDV

I'd just like to mention that PornHub is always up. (Pun intended)  Ping it. Aaron On 2/9/2022 2:43 PM, Tom Beecher wrote:

I mean if you own it, it's your money. But I think I anyone else would have a difficult time making a business or technical case to justify setting up and maintaining a large scale echo-reply endpoint for... what exactly?

On Wed, Feb 9, 2022 at 3:32 PM Lady Benjamin Cannon of Glencoe <lb@6by7.net> wrote:

Perhaps owning a (small but global) cloud computing & telecom company has spoiled me, but it seems like a trivial amount of resources to me for any moderately sized company let alone a large tech/telecom like anything you’d have heard of.

-LB

Ms. Lady Benjamin PD Cannon of Glencoe, ASCE 6x7 Networks & 6x7 Telecom, LLC CEO ben@6by7.net "The only fully end-to-end encrypted global telecommunications company in the world.” ANNOUNCING: 6x7 GLOBAL MARITIME <https://alexmhoulton.wixsite.com/6x7networks>

FCC License KJ6FJJ

...

On Feb 9, 2022, at 12:15 PM, Tom Beecher <beecher@beecher.cc> wrote:

Side note, am I missing something obvious where I can’t just have hardware routers strip ICMP, pipe it separately, put 500 VMs behind 4 vLBs and let the world ping the brains out of it?

Seems like a lot of overhead for zero benefit.

On Wed, Feb 9, 2022 at 2:11 PM Lady Benjamin Cannon of Glencoe <lb@6by7.net> wrote:

ok that’s amazing.

RFC1149 amazing.

Side note, am I missing something obvious where I can’t just have hardware routers strip ICMP, pipe it separately, put 500 VMs behind 4 vLBs and let the world ping the brains out of it?

Who owns 69.69.69.69 - collab?

How naff is this?

-LB

Ms. Lady Benjamin PD Cannon of Glencoe, ASCE 6x7 Networks & 6x7 Telecom, LLC CEO ben@6by7.net "The only fully end-to-end encrypted global telecommunications company in the world.” ANNOUNCING: 6x7 GLOBAL MARITIME <https://alexmhoulton.wixsite.com/6x7networks>

FCC License KJ6FJJ

...

On Feb 9, 2022, at 9:38 AM, Jay Hennigan <jay@west.net> wrote:

On 2/8/22 23:42, Stephane Bortzmeyer wrote:

...

The only problem is the less friendly IP address (although this will be less and less a problem with IPv6, since 2001:4860:4860::8888 is not really friendly).

Fun fact: Someone at Sprint had the same hobby as I did in the early 1970s. Their website resolves to 2600:: which I think is rather friendly. :-)

Please don't use it for an IPv6 ping target, thanks.

-- Jay Hennigan - jay@west.net Network Engineering - CCIE #7880 503 897-8550 - WB6RDV

-- ================================================================ Aaron Wendel Chief Technical Officer Wholesale Internet, Inc. (AS 32097) (816)550-9030 http://www.wholesaleinternet.com ================================================================

On Wed, 9 Feb 2022 at 22:19, Tom Beecher <beecher@beecher.cc> wrote:

...

Side note, am I missing something obvious where I can’t just have hardware routers strip ICMP, pipe it separately, put 500 VMs behind 4 vLBs and let the world ping the brains out of it?

Seems like a lot of overhead for zero benefit.

I'm not going to opinion on the quantity of benefits, but this thought could lend a razor from Occam. NPU based boxes, like JNPR Trio, NOK FP, Huawei Solar, CSCO Lightspeed et.al. could easily respond to ICMP echo and TTL exceeded in NPU for microseconds of delay and nanoseconds of jitter at higher performance and lower cost compared to transing it, i.e. ping responder would become negative cost. Only reason they don't is because customers are not asking for it. Further, we could have a global anycast address, like we already have for 6to4 relays, where a well-known ping responder exists. And anyone who welcomes responding to pings, configures this address to all the device loopbacks which they want to include, advertise those loopbacks in IGP or iBGP and advertise the /24 aggregate in eBGP. -- ++ytti

Seems way easier than literally everything else being proposed to me, am I missing something? -LB Ms. Lady Benjamin PD Cannon of Glencoe, ASCE 6x7 Networks & 6x7 Telecom, LLC CEO ben@6by7.net "The only fully end-to-end encrypted global telecommunications company in the world.” ANNOUNCING: 6x7 GLOBAL MARITIME <https://alexmhoulton.wixsite.com/6x7networks> FCC License KJ6FJJ

On Feb 9, 2022, at 12:15 PM, Tom Beecher <beecher@beecher.cc> wrote:

Side note, am I missing something obvious where I can’t just have hardware routers strip ICMP, pipe it separately, put 500 VMs behind 4 vLBs and let the world ping the brains out of it?

Seems like a lot of overhead for zero benefit.

On Wed, Feb 9, 2022 at 2:11 PM Lady Benjamin Cannon of Glencoe <lb@6by7.net <mailto:lb@6by7.net>> wrote: ok that’s amazing.

RFC1149 amazing.

Side note, am I missing something obvious where I can’t just have hardware routers strip ICMP, pipe it separately, put 500 VMs behind 4 vLBs and let the world ping the brains out of it?

Who owns 69.69.69.69 - collab?

How naff is this?

-LB

Ms. Lady Benjamin PD Cannon of Glencoe, ASCE 6x7 Networks & 6x7 Telecom, LLC CEO ben@6by7.net <mailto:ben@6by7.net> "The only fully end-to-end encrypted global telecommunications company in the world.” ANNOUNCING: 6x7 GLOBAL MARITIME <https://alexmhoulton.wixsite.com/6x7networks>

FCC License KJ6FJJ

...

On Feb 9, 2022, at 9:38 AM, Jay Hennigan <jay@west.net <mailto:jay@west.net>> wrote:

On 2/8/22 23:42, Stephane Bortzmeyer wrote:

...

The only problem is the less friendly IP address (although this will be less and less a problem with IPv6, since 2001:4860:4860::8888 is not really friendly).

Fun fact: Someone at Sprint had the same hobby as I did in the early 1970s. Their website resolves to 2600:: which I think is rather friendly. :-)

Please don't use it for an IPv6 ping target, thanks.

-- Jay Hennigan - jay@west.net <mailto:jay@west.net> Network Engineering - CCIE #7880 503 897-8550 - WB6RDV

On 2/10/22 20:27, Tom Beecher wrote:

I guess it depends on what the actual problem trying to be solved is.

If I understand it correctly, the OG issue was someone (who was not Google) building some monitoring around the assumption of the idea that ICMP echo-request/reply to 8.8.8.8 would always be available. Google decided to make a change so that assumption was now false.

The actual problem here has nothing to do with how Google handles (or doesn't handle) ICMP towards their servers. The issue is that people have made poor assumptions about how they structured monitoring, and learned some lessons about that. Suggesting that Party B should do something because Party A made poor decisions is questionable, even if it is 75% of what we do in this world.

100% - and this is the crux of the issue. As a community, it is clear that there is a need for this, and if 8.8.8.8 stops being an anchor for liveliness detection, users will find something else to replace it with. And we can bet all our Kwacha that it won't have been designed for that purpose, either. Mark.

On Feb 11, 2022, at 8:33 AM, Tom Beecher <beecher@beecher.cc> wrote:

The prediciate assumption that "pinging one destination is a valid check that my internet works' is INCORRECT. There is no magical unicorn that could be built that could make that true, and 'they're gonna do it anyways' is a poor excuse to even consider it.

The predicate assumption that unsuccessful pinging one destination is a valid check that my internet DOES NOT work' is ALSO INCORRECT. Still no magical unicorn. I am disappointed but not surprised to see this discussion on NANOG. Encouraging Users to use a tool (that is often ignored by the hardware targeted) by providing a non-revenue-creating special target does not make business sense. An allied issue is educating ‘Users’ about traceroute AKA sequential ping with TTL progression: Seeing missing or excessively long traceroute results from intermediate nodes does NOT indicate a real problem, especially when the target node is reachable with acceptable delay. I’ve lost count of my replies on user forums explaining this issue, even to otherwise well educated users. To be blunt, browsing to amazon.com, apple.com or another vendor site is a simple and easy to teach Internet aliveness check and, at least, offers the chance for the targeted vendor site to receive revenue from sales. I have no crisis of conscience from clicking an vendor shortcut for a basic end-to-end Internet functional test. Or for teaching a User to do the same. This meets the business purpose locally and requires no $pecial effort from Users, network providers, or target systems. This precludes memorization of IP addresses by end Users thus reducing the offered load from the likes of excessive ping 8.8.8.8. I would expect NANOG members to have favorite ping target addresses based on their environment, e.g., default router and a few designated targets. These are useful for manual debugging but, as mentioned previously, are not suitable as singular input to network monitoring.

Huh -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.

On Feb 11, 2022, at 09:10, Tom Beecher <beecher@beecher.cc> wrote:

I am disappointed but not surprised to see this discussion on NANOG. Encouraging Users to use a tool (that is often ignored by the hardware targeted) by providing a non-revenue-creating special target does not make business sense.

To be fair, I don't think this is unique to this community. Plenty of conversations on the IETF lists that are fundamentally the same. ( Proposals to change X or implement standard Y to solve something that is already solvable with current tech and standards. ) Really it's just the complexity of the existing solution that's different. :)

On Fri, Feb 11, 2022 at 9:51 AM james.cutler@consultant.com <james.cutler@consultant.com> wrote: On Feb 11, 2022, at 8:33 AM, Tom Beecher <beecher@beecher.cc> wrote:

...

The prediciate assumption that "pinging one destination is a valid check that my internet works' is INCORRECT. There is no magical unicorn that could be built that could make that true, and 'they're gonna do it anyways' is a poor excuse to even consider it.

The predicate assumption that unsuccessful pinging one destination is a valid check that my internet DOES NOT work' is ALSO INCORRECT. Still no magical unicorn.

I am disappointed but not surprised to see this discussion on NANOG. Encouraging Users to use a tool (that is often ignored by the hardware targeted) by providing a non-revenue-creating special target does not make business sense.

An allied issue is educating ‘Users’ about traceroute AKA sequential ping with TTL progression:

• Seeing missing or excessively long traceroute results from intermediate nodes does NOT indicate a real problem, especially when the target node is reachable with acceptable delay.

I’ve lost count of my replies on user forums explaining this issue, even to otherwise well educated users.

To be blunt, browsing to amazon.com, apple.com or another vendor site is a simple and easy to teach Internet aliveness check and, at least, offers the chance for the targeted vendor site to receive revenue from sales. I have no crisis of conscience from clicking an vendor shortcut for a basic end-to-end Internet functional test. Or for teaching a User to do the same. This meets the business purpose locally and requires no $pecial effort from Users, network providers, or target systems. This precludes memorization of IP addresses by end Users thus reducing the offered load from the likes of excessive ping 8.8.8.8.

I would expect NANOG members to have favorite ping target addresses based on their environment, e.g., default router and a few designated targets. These are useful for manual debugging but, as mentioned previously, are not suitable as singular input to network monitoring.

On Fri, 11 Feb 2022, Mark Tinka wrote:

100% - and this is the crux of the issue.

As a community, it is clear that there is a need for this, and if 8.8.8.8 stops being an anchor for liveliness detection, users will find something else to replace it with. And we can bet all our Kwacha that it won't have been designed for that purpose, either.

I have to admit, I haven't read most of this thread, but I am well aware of the issues with both end users and "routers" / firewalls pinging 8.8.8.8 as a means of verifying "that path to the Internet is working". I know GOOG doesn't appreciate the amount of ICMP echo requests their 8.8.8.8 instances receive, and that at various times/places, that ICMP traffic is/has been policed by GOOG. So...here's a pair of "what if"s: What if instead of pinging 8.8.8.8, all these things using it to "test the Internet" sent it DNS requests instead? i.e. GOOG=$(dig +short @8.8.8.8 google.com) if [ -z "$GOOG" ] ; then echo FAIL fi Would that make things better or worse for GOOG (Trading lots more DNS requests for the ICMP echo requests)? 8.8.8.8 is already anycasted. What if each large ISP (for whatever definition of large floats your boat) setup their own internal instance(s) of 8.8.8.8 with a caching DNS server listening, and handled the traffic without bothering GOOG? For users using 8.8.8.8 as a lighthouse, this would change the meaning of their test...i.e. a response means their connection to their ISP is up, and the ISP's network works at least enough to reach an internal 8.8.8.8, but the question of their connectivity to the rest of the Internet would be unanswered. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route StackPath, Sr. Neteng | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

On 2/11/22 7:58 AM, Jon Lewis wrote:

8.8.8.8 is already anycasted.  What if each large ISP (for whatever definition of large floats your boat) setup their own internal instance(s) of 8.8.8.8 with a caching DNS server listening, and handled the traffic without bothering GOOG?

I've pontificated doing this. On one hand I think it's a neat technical solution. On the other hand I think how ... displeased I would be if someone were to anycast one of my services without my knowledge, much less consent for them to do so. Thus I've never done it where I had a choice. I believe that anycasting resources from another organization /without/ their consent is a hard fail and non-starter. Independent of how pure the intentions are.

For users using 8.8.8.8 as a lighthouse, this would change the meaning of their test...i.e. a response means their connection to their ISP is up, and the ISP's network works at least enough to reach an internal 8.8.8.8, but the question of their connectivity to the rest of the Internet would be unanswered.

I say "where I had a choice" because I have anycasted 8.8.8.8 (for ICMP and DNS) in an offline lab ~> D.R. exercise environment /explicitly/ because other systems therein had been configured to test reach ability to 8.8.8.8 et al. Thus my hand was forced /inside/ the D.R. environment. -- Grant. . . . unix || die

The device that caused this whole conversation has failover functionality. Both interfaces ping an FQDN (that resolves to 8.8.8.8 and 1.1.1.1, with the device only latching on to one of those). If any of those meet the failure threshold, that interface is taken out of the traffic flow. So because someone else built a device (without a meaningful configuration to set otherwise), 8.8.8.8 went down for ICMP, and thus Internet ports began flapping, despite the Internet as a whole working just fine. ----- Mike Hammett Intelligent Computing Solutions Midwest Internet Exchange The Brothers WISP ----- Original Message ----- From: "Tom Beecher" <beecher@beecher.cc> To: "Lady Benjamin Cannon of Glencoe" <lb@6by7.net> Cc: "NANOG Operators' Group" <nanog@nanog.org> Sent: Thursday, February 10, 2022 12:27:03 PM Subject: Re: Authoritative Resources for Public DNS Pinging Seems way easier than literally everything else being proposed to me, am I missing something? I guess it depends on what the actual problem trying to be solved is. If I understand it correctly, the OG issue was someone (who was not Google) building some monitoring around the assumption of the idea that ICMP echo-request/reply to 8.8.8.8 would always be available. Google decided to make a change so that assumption was now false. The actual problem here has nothing to do with how Google handles (or doesn't handle) ICMP towards their servers. The issue is that people have made poor assumptions about how they structured monitoring, and learned some lessons about that. Suggesting that Party B should do something because Party A made poor decisions is questionable, even if it is 75% of what we do in this world. On Thu, Feb 10, 2022 at 12:52 PM Lady Benjamin Cannon of Glencoe < lb@6by7.net > wrote: <blockquote> Seems way easier than literally everything else being proposed to me, am I missing something? -LB Ms. Lady Benjamin PD Cannon of Glencoe, ASCE 6x7 Networks & 6x7 Telecom, LLC CEO ben@6by7.net "The only fully end-to-end encrypted global telecommunications company in the world.” ANNOUNCING: 6x7 GLOBAL MARITIME FCC License KJ6FJJ <blockquote> On Feb 9, 2022, at 12:15 PM, Tom Beecher < beecher@beecher.cc > wrote: <blockquote> Side note, am I missing something obvious where I can’t just have hardware routers strip ICMP, pipe it separately, put 500 VMs behind 4 vLBs and let the world ping the brains out of it? </blockquote> Seems like a lot of overhead for zero benefit. On Wed, Feb 9, 2022 at 2:11 PM Lady Benjamin Cannon of Glencoe < lb@6by7.net > wrote: <blockquote> ok that’s amazing. RFC1149 amazing. Side note, am I missing something obvious where I can’t just have hardware routers strip ICMP, pipe it separately, put 500 VMs behind 4 vLBs and let the world ping the brains out of it? Who owns 69.69.69.69 - collab? How naff is this? -LB Ms. Lady Benjamin PD Cannon of Glencoe, ASCE 6x7 Networks & 6x7 Telecom, LLC CEO ben@6by7.net "The only fully end-to-end encrypted global telecommunications company in the world.” ANNOUNCING: 6x7 GLOBAL MARITIME FCC License KJ6FJJ <blockquote> On Feb 9, 2022, at 9:38 AM, Jay Hennigan < jay@west.net > wrote: On 2/8/22 23:42, Stephane Bortzmeyer wrote: <blockquote> The only problem is the less friendly IP address (although this will be less and less a problem with IPv6, since 2001:4860:4860::8888 is not really friendly). </blockquote> Fun fact: Someone at Sprint had the same hobby as I did in the early 1970s. Their website resolves to 2600:: which I think is rather friendly. :-) Please don't use it for an IPv6 ping target, thanks. -- Jay Hennigan - jay@west.net Network Engineering - CCIE #7880 503 897-8550 - WB6RDV </blockquote> </blockquote> </blockquote> </blockquote>

On Wed, Feb 9, 2022 at 2:10 PM Lady Benjamin Cannon of Glencoe <lb@6by7.net> wrote:

ok that’s amazing.

RFC1149 amazing.

Side note, am I missing something obvious where I can’t just have hardware routers strip ICMP, pipe it separately, put 500 VMs behind 4 vLBs and let the world ping the brains out of it?

I suspect that half the reason: "ping 8.8.8.8" (do not do this!) is used is: "easy to remember 8.8.8.8" and half is: "Well, that IP is well connected enough that you are reasonably assured that: 'enough of the internet is up ....'" if it replies. (maybe it's 75/25? or 80/20 not 5050... but you get my point)

On 2/9/22 1:29 PM, Lady Benjamin Cannon of Glencoe wrote:

Exactly.  8.8.8.8 isn’t going down anytime soon, also is geographically redundant; even if half the internet is dead, it’ll still be there.  It’s somewhat hard to duplicate that cheap.

And yet here we are having a thread where part of the motivation was systems having problems /because/ 8.8.8.8 had problems in some capacity. Evil idea: What if an ISP anycasts 8.8.8.8 (et al.) to their own bog standard recursive DNS server? Then pings to it won't test greater Internet reach ability. (I'm assuming that it's only available to their clients and not anycasted out to the Internet at large.)

What else is like that and easy to remember and isn’t 1.1.1.1 ?

I wonder how much of the problem is /human/ /interactive/ pings as opposed to automation / monitoring / probe pings. I think the former greatly benefits from having something easy to remember. I also think the latter doesn't actually care if it's easy for the human to remember or not. -- Grant. . . . unix || die

4.2.2.2 is definitely anycast, I've used that one since I think before Google was founded... On Wed, Feb 9, 2022 at 5:01 PM Mike Lewinski via NANOG <nanog@nanog.org> wrote:

...

What else is like that and easy to remember and isn’t 1.1.1.1 ?

4.2.2.1, which IIRC predates both 8.8.8.8 and 1.1.1.1.

Muscle memory still favors it. I think 4.2.2.2 might be anycast the same but never really looked hard at it.

Lady Benjamin Cannon of Glencoe <lb@6by7.net> writes:

What else is like that and easy to remember and isn’t 1.1.1.1 ?

1.1 :) -tih -- Most people who graduate with CS degrees don't understand the significance of Lisp. Lisp is the most important idea in computer science. --Alan Kay

On 2/9/22 11:32, Brian Turnbow wrote:

It wouldn't be too hard for ripe to setup a dns record for ping.ripe.net and point it towards a local anchor for each request. I think it could generate some interesting data for the atlas project as well. Once it becomes popular the anchor hosters may not be so happy about the traffic they receive , but that is another story.

I suppose my point is as long as we have a deliberate solution that solves specifically for this, we shall be in a better place than we currently are. Mark.

Yup. And Google folks accounted for the world pinging them all day long. I wouldn't call using DNS resolvers as best "am I connected to internet over this interface" tool though. A day, year or 5 years from now the same team may decide to drop/filter and then thousands of hardcoded "handmade automation solutions" will break. And I believe that's closer to what Masataka was trying to convey. — Łukasz Bromirski

On 9 Feb 2022, at 14:23, Mark Tinka <mark@tinka.africa> wrote:

...

On 2/9/22 15:00, Masataka Ohta wrote:

Wrong. It is not bad, at least not so bad, pinging properly anycast DNS servers.

The point of anycast is resistance to DDoS.

But, relying on hard coded 8.8.8.8 is not a good idea because DNS service of the address may be terminated.

Instead, properly anycast root name servers are authoritative resources provided for public DNS queries which can be used for pinging, though pinging so with ICMP should be less painful for the servers.

That's like saying you won't have an egg for dinner because it's typically had for breakfast.

Users don't care what infrastructure has been designated for. If they can find another use for it other than designed, which serves their interests, they will use it.

We need to allow, and account, for that.

Mark.

On Wed, Feb 09, 2022 at 05:02:01PM +0200, Mark Tinka wrote:

On 2/9/22 16:53, ??ukasz Bromirski wrote:

...

Yup. And Google folks accounted for the world pinging them all day long.

I wouldn't call using DNS resolvers as best "am I connected to internet over this interface" tool though. A day, year or 5 years from now the same team may decide to drop/filter and then thousands of hardcoded "handmade automation solutions" will break. And I believe that's closer to what Masataka was trying to convey.

I get that, but what I'm saying is that users tend to expect things to remain the same. In reality, they don't, because as abstract as the Internet seems to most users, it is run by actual people, who have to apply mind and muscle to not only stand things up, but keep them standing. The movement of those people has an impact on that, even in very well established institutions.

So unless there is some specific accommodation from Google et al, that the servers they run for one service can be used for liveliness detection, expect breakage when that changes, at their whim. Until then, do not expect users to honour the original intent of the service. If it can serve some other purpose (like liveliness detection), they will use it for that purpose in the hopes that it will always be there, for that purpose.

So what people really want is to be able to "ping internet" and so far the easiest thing people have been able to find is "ping 8.8.8.8" or some other easily remembered thing. Does this mean that perhaps we should seriously consider having some TLD being named "internet", with maybe a global DNS redirector that lets service providers register appropriate upstream targets for their customers, and then maybe also allow for some form of registration such that if I wanted to provide a remote ping target for AS14536, I could somehow register "as14536.internet" or "solnet.internet"? Fundamentally, this is a valid issue. As the maintainer of several BGP networks, I can't really rely on an upstream consumer ISP to be the connectivity helpdesk when something is awry. It would really be nice to have a list of officially sanctioned testing points so that one could just do "ping google.internet" or "ping level3.internet" or "ping comcast.internet" or "ping aws.internet" and get a response. The problem with this is that someone will try to make what could be a relatively simple thing complicated, and we'll end up needing a special non-ping client and some trainwreck of names and other hard-to-grok garbage, and then we're perilously close to coming back to the current situation where people are using arbitrary targets out on the Internet for connectivity testing. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "The strain of anti-intellectualism has been a constant thread winding its way through our political and cultural life, nurtured by the false notion that democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov

On Wed, Feb 09, 2022 at 11:21:26PM +0000, Mark Delany wrote:

On 09Feb22, Joe Greco allegedly wrote:

...

So what people really want is to be able to "ping internet" and so far the easiest thing people have been able to find is "ping 8.8.8.8" or some other easily remembered thing.

Yes, I think "ping internet" is the most accurate description thus far. Or perhaps "reach internet".

...

Does this mean that perhaps we should seriously consider having some TLD being named "internet"

Meaning you need to have a functioning DNS resolver first? I'm sure you see the problem with that clouding the results of a diagnostic test.

Perhaps. As I noted, The problem with this is that someone will try to make what could be a relatively simple thing complicated and you're already implying the first step down that road, which is trying to do something more than a simple pass/fail test.

...

service providers register appropriate upstream targets for their customers, and then maybe also allow for some form of registration such that if I wanted to provide a remote ping target for AS14536, I could somehow register "as14536.internet" or "solnet.internet"?

Possibly. You'd want to be crystal clear on the use cases. As a starting point, maybe:

1. Do packets leave my network? 2. Do packets leave my ISP's network? 3. Mainly for IOT - is the internet reachable?

Because of 2 and 3. I don't think creative solutions such as ISPs any-casting some memorable IP or name will do the trick. And because of 1. anything relying on DNS resolution is probably a non-starter. Much as I like "ping ping.ripe.net" it alone is too intertwined with DNS resolution to be a reliable alternative.

I dunno. I think I'd find that being unable to resolve a hostname or being unable to exchange packets result in a similar level of Internet brokenness. It is going to be hard to quantify all the things you might want to test for. You already enumerated several. But if it has to be a comprehensive "Internet is fully working" test, what do you do to be able to detect that your local coffee shop isn't implementing a net nanny filter? Just to take it too far down the road. ;-)

...

Fundamentally, this is a valid issue.

Yup. There are far more home-gamers and tiny network admins (the networks are tiny, not the admins) who just want to run a reachability test or add a command to a cheap network monitor cron job. Those on this list who can - or should - do something more sophisticated are numerically in the minority of people who care about reachability and are not really the target audience for a better "ping 8.8.8.8".

Well, that's sorta true.

...

and we'll end up needing a special non-ping client and some trainwreck of names and other hard-to-grok

I'm not sure the two are fundamentally intertwined tho it could easily be an unintended consequence. However, being constrained to creating a new ping target does severely limit the choices. And including ipv6 just makes that more complicated.

The other matter is that the alternative probably has to present a compelling case to cause change in behavior. I can see an industry standard ping target being of possible use to tests built into devices. But again it'd have to be compelling for most manufacturers to even notice.

Change happens. Look at pool.ntp.org.

But for humans, I'd be surprised if you can create a compelling alternative ping target. For them, I'd be going down the path of a "ping-internet" command which answers use-cases 1. & 2. while carefully avoiding the second-system syndrome - he says with a laugh.

Well, I've lamented many times over the years about how we (as a network operations community) have failed to address issues in a meaningful way. End users are using "ping 8.8.8.8" to test basic connectivity. I'm happy to see the development of resources such as the RIPE Atlas monitor, because for too many years I've had to guess at strategic points to monitor. However, tools for the average end user that could also be used by the more experienced folks would be nice. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "The strain of anti-intellectualism has been a constant thread winding its way through our political and cultural life, nurtured by the false notion that democracy means that 'my ignorance is just as good as your knowledge.'"-Asimov

No doubt there would be a very long tail, but... 1) Create alternative. 2) Get Google, Cloudflare, PCH, etc. to say that per whatever new standard, this is the new way to do this, leave my stuff alone. 3) Lots of peer pressure. 4) ??? 5) Profit ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: Mark Delany <k3f@november.emu.st> To: nanog@nanog.org Sent: Wed, 09 Feb 2022 17:21:26 -0600 (CST) Subject: Re: Authoritative Resources for Public DNS Pinging On 09Feb22, Joe Greco allegedly wrote:

So what people really want is to be able to "ping internet" and so far the easiest thing people have been able to find is "ping 8.8.8.8" or some other easily remembered thing.

Yes, I think "ping internet" is the most accurate description thus far. Or perhaps "reach internet".

Does this mean that perhaps we should seriously consider having some TLD being named "internet"

Meaning you need to have a functioning DNS resolver first? I'm sure you see the problem with that clouding the results of a diagnostic test.

service providers register appropriate upstream targets for their customers, and then maybe also allow for some form of registration such that if I wanted to provide a remote ping target for AS14536, I could somehow register "as14536.internet" or "solnet.internet"?

Possibly. You'd want to be crystal clear on the use cases. As a starting point, maybe: 1. Do packets leave my network? 2. Do packets leave my ISP's network? 3. Mainly for IOT - is the internet reachable? Because of 2 and 3. I don't think creative solutions such as ISPs any-casting some memorable IP or name will do the trick. And because of 1. anything relying on DNS resolution is probably a non-starter. Much as I like "ping ping.ripe.net" it alone is too intertwined with DNS resolution to be a reliable alternative.

Fundamentally, this is a valid issue.

Yup. There are far more home-gamers and tiny network admins (the networks are tiny, not the admins) who just want to run a reachability test or add a command to a cheap network monitor cron job. Those on this list who can - or should - do something more sophisticated are numerically in the minority of people who care about reachability and are not really the target audience for a better "ping 8.8.8.8".

and we'll end up needing a special non-ping client and some trainwreck of names and other hard-to-grok

I'm not sure the two are fundamentally intertwined tho it could easily be an unintended consequence. However, being constrained to creating a new ping target does severely limit the choices. And including ipv6 just makes that more complicated. The other matter is that the alternative probably has to present a compelling case to cause change in behavior. I can see an industry standard ping target being of possible use to tests built into devices. But again it'd have to be compelling for most manufacturers to even notice. But for humans, I'd be surprised if you can create a compelling alternative ping target. For them, I'd be going down the path of a "ping-internet" command which answers use-cases 1. & 2. while carefully avoiding the second-system syndrome - he says with a laugh. Mark.

Mark,

On 9 Feb 2022, at 16:02, Mark Tinka <mark@tinka.africa> wrote: On 2/9/22 16:53, Łukasz Bromirski wrote:

...

Yup. And Google folks accounted for the world pinging them all day long.

I wouldn't call using DNS resolvers as best "am I connected to internet over this interface" tool though. A day, year or 5 years from now the same team may decide to drop/filter and then thousands of hardcoded "handmade automation solutions" will break. And I believe that's closer to what Masataka was trying to convey. I get that, but what I'm saying is that users tend to expect things to remain the same. […] If it can serve some other purpose (like liveliness detection), they will use it for that purpose in the hopes that it will always be there, for that purpose.

…aaaaaaand I absolutely agree with you on all of the points. -- ./

On 2022-02-10 11:42, John Todd wrote:

"The Prudent Mariner never relies solely on any single aid to navigation"

It's best to ping multiple targets, and take action only if all targets do not return replies. For route tracking a la $VENDOR_C's IP SLA, if possible, we'll ping next-hop IP, one target on our network, and one off our network. Withdraw the default route only if all three targets fail to return replies.

John Todd - jtodd@quad9.net General Manager - Quad9 Recursive Resolver

./btk

On 2/10/22 19:42, John Todd wrote:

I think it would be fair to say that ICMP echo to easy-to-remember internet resources is tolerated, but not encouraged, and is probably not a good idea unless one knows and very well understands the implications of failure (or success!) modes that don’t match the conditions that are expected. Terrible monitoring is easy; good monitoring is quite difficult.

It is reasonable to expect operators of systems designed for one type of service to quickly rate-limit or entirely filter non-critical alternate capabilities in the event of resource exhaustion or other type of risk to the primary service - this applies to web severs, DNS servers, NTP servers, etc. Also, choosing as an indicator a response from a protocol such as ICMP echo/reply which has had a historical risk of flooding attacks and which may have rapid clamping of traffic seems to be also a large check mark in the “do not use” column. ICMP echo stands real risks of not providing expected results for reasons that are known only to the target operator, and which do not take your non-obvious intentions into consideration.

More central to the issue: “The Prudent Mariner never relies solely on any single aid to navigation” (hi, Ken!) is an applicable quote here. Nothing is immune from interruption of service, especially as it becomes more distant from your administrative control. I see all too often people using ICMP to a nameserver, or a query to a nameserver, or a socket request to port 80 of some well-known name as the only method utilized for determining if a larger set of systems are available. This is not typically a good idea. I shudder to think what would happen if certain well-known domains were to be unavailable due to one of a dozen different potential failure cases. There are far too many poorly-written stacks that assume some singular conditions are “impossible” unless as a result of local failure, and that always ends in sadness and late nights spent writing root-cause analysis reports.

Further adding to this complexity is the benefit or detraction of anycast for many of these larger public services. What is “up” and what is “down”? What is the signal generated or inferred by presence or absence of this monitoring sample? The question typically generates lively debate within a network or monitoring team. I am pretty sure that “But I could ping x.x.x.x” is not typically a statement that has much weight when considering overall reachability. I do admit it is a hint, but not the answer, for many network conditions, but probably not by itself should any system consider that result canonical for anything other than that exact result.

If one is going to use responses of exterior (not within the same organizational control) services as an indicator of reachability, then a broad spectrum of tests are probably the only way to have anything approaching certainty or knowledge upon which action could be based, and even that will always have a shadow of a doubt. In that mix, ICMP echo/reply to public nameservers is probably not the best indicator to add in a monitoring suite, though it may appear to be perfectly OK… until it isn’t. DNS queries to DNS servers seems to be the most reasonable thing to use as test material, rather than ICMP, if one were building a rickety monitoring house out of the resources at-hand.

Additionally: The suggestions of building some new ICMP-responding service may end up being counter to the goals of the people using external tests, so careful what is wished for. Witness everyone installing various “speed testing” servers in their own networks, which may not truly provide accurate measurements of anything other than local loop speeds, which now sort of defeats the purpose of the speed test for anything other than the most local set of results.

Well, the issue is being able to test at the lowest level possible, and with the lowest common denominator. While I agree that testing an application (like DNS) makes sense, it is not simple, and is a lot higher up in the layers, where a lot more things need to work reasonably well for that test to be successful. Ping, on the other hand, is so basic, that barring rate-limiting or outright blocking, is a decent indicator of liveliness between source and destination. I'm all for pulling together as many tools as we can to detect liveliness, for I don't see Ping going anywhere, anytime soon. Heck, e-mail has been "dying" for decades, and yet it's still here. Mark.

On 2022-02-11 10:11 a.m., Mike Hammett wrote:

A system always checking to see if "Internet" is up is different than "I think something is wrong, let me check".

Yeah. I've had ping tests fail in false-positive and false-negative scenarios and the take away isn't that there IS a problem, but rather an investigation should probably take place. I don't think anybody here is trying to argue that pings (or DNS lookups) are an infallible reachability index for "the internet". When it comes to customers, ping tests are a non-issue because the complaint is normally that YouTube, Facebook, or whatever service isn't available and therefore the "internet is down". At some point you have to weight the cost/benefit of explaining to customers that the internet is a large collection of interconnected networks and not some "cloud" that we tap into. It is a series of tubes after all. K