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" <beec...@beecher.cc> To: "Lady Benjamin Cannon of Glencoe" <l...@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 < l...@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 b...@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 < beec...@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 < l...@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 b...@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 < j...@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 - j...@west.net Network Engineering - CCIE #7880 503 897-8550 - WB6RDV </blockquote> </blockquote> </blockquote> </blockquote>
