[Outages-discussion] [outages] Ping to Google 8.8.8.8

Grant Taylor gtaylor at tnetconsulting.net
Wed Feb 9 16:13:27 EST 2022


On 2/9/22 12:10 PM, Jeff Shultz wrote:
> This is sort of silly, and thank you Grant for pointing that out.

Happy accident on my part.  I'll do my best to not do it again.  ;-)

> Each ISP ought to have, within their network/ASN/segment of network 
> that does not involve traversing the internet, at least one reliably 
> pingable box, whether it be a gateway router or an odd jobs server 
> sitting on your backbone.

I like the subtext of this.

What if network operators / ISPs were to come up with a (standardized) 
IP address that is meant /explicitly/ for testing ISP reach ability? 
Something beyond the default gateway on the other end of the link.

What if we extend this further to have another IP address that is meant 
/explicitly/ for testing ISP's ability to reach the upstream Internet?

E.g.

  - All ISPs, T3, T2, and T1, have 198.18.0.<something>/24.
  - All ISP's ISPs, T2 and T1, have 192.18.1.<something>/24.
  - All ISP's ISP's ISPs, T1, have 192.18.2.<something>/24.

The intention being that end users / monitoring systems ping things in 
this order:

1)  Default gateway / far side of the link-net.
2)  198.18.0.<something>/24 located at your ISP.
3)  192.18.1.<something>/24 located at your ISP's ISP.
4)  192.18.2.<something>/24 located at your ISP's ISP's ISP.
...
n)  <something>.<something>.<something>.<something>/32 located somewhere 
on the Big Bad Internet.

IM(ns)HO you should only progress to larger numbers if you can 
successfully ping the lower numbers.

I know that one of the reasons that I've manually tested Google, my VPS, 
my friend's Co-Lo, what have you, is because #1 and maybe #2 work, but 
#3 fails because my ISP is having an uplink issue.

With this in mind, simply trying to ping the default gateway (#1) is an 
insufficient test.

I prefer to test by IP as opposed to name if at all possible in order to 
eliminate the DNS variable from the equation.  Basic algebra suggests 
tells us to only work with one variable at a time.

> Not until you can demonstrate that the customer's connection to your 
> network is up and running do you have any business thinking about 
> pinging some box out on the internet somewhere. And I'm going to guess 
> that if your network's connection to the wider internet goes down, 
> you're going to know about it very soon, and you won't have to try and 
> ping 8.8.8.8 to demonstrate it.

Agreed.

> And after you prove that your customer can ping your internal box by IP, 
> then you can have them try it by DNS name. Then, and only then, do you 
> need to try and test connectivity to the wider internet. I personally 
> like news sites like CNN or Fox News, since they change all the time and 
> are unlikely to be cached by the customer's web browser. They're also 
> likely to be CDN'd to somewhere nearby.

Even news sites, et al., aren't as reliable as we might like to believe. 
  Look at how outages of big players; AWS, Google, etc., negatively 
effect large swaths of the Internet in one way or another, usually via 
unmet dependencies.

> This is reminding me of my early days in tech support where if a 
> customer couldn't access their #emailprovider for some reason, "the 
> internet was down."

Yes.

We -- subscribers to this list and the likes -- need to come up with a 
standardized way to support the levels of testing, embrace it, and 
promote it to the larger community -- the Internet at large.  We can't 
get others to change until we change and get our ducks in a row.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4017 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://puck.nether.net/pipermail/outages-discussion/attachments/20220209/bb2a6033/attachment.p7s>


More information about the Outages-discussion mailing list