What to do when a public IP address can't be reached

berndbausch · 09-15-2016, 08:48 PM

While I am aware that this is not strictly a Linux Networking questions, I hope somebody can help with advice how to troubleshoot my problem.

I am unable to access a certain IP address, 173.205.188.47. In principle it is reachable, as evidenced by the use of tools like https://www.dotcom-tools.com/ping-test.aspx, but access from home fails. My ISP is Yahoo Broadband, one of the largest if not the largest provider in Japan. I need to call their support but want to gather as much information as possible before I do so (admittedly the prospect of a Japanese support call makes me shrink away a little).

ping 173.205.188.47 just times out.
Traceroute (see below) seems to indicate that the packet makes good progress into the servers of NTT, the former telephony monopolist and now probably largest infrastructure provider in these parts, then seems to get stuck in inforelay.net.

How should I interpret this? Are there other tools I could use, local or web-based?

Code:

$ traceroute 173.205.188.47
traceroute to 173.205.188.47 (173.205.188.47), 30 hops max, 60 byte packets
 1  router.home (192.168.1.1)  0.593 ms  0.711 ms  0.400 ms
 2  softbank<redacted>.bbtec.net (<redacted>)  15.615 ms  15.806 ms  16.493 ms
 3  10.206.5.78 (10.206.5.78)  18.016 ms  18.466 ms  19.476 ms
 4  10.206.2.174 (10.206.2.174)  19.601 ms  20.343 ms  21.066 ms
 5  10.0.131.105 (10.0.131.105)  21.757 ms  21.727 ms  22.451 ms
 6  10.0.61.69 (10.0.61.69)  32.099 ms  19.590 ms  19.749 ms
 7  10.0.207.49 (10.0.207.49)  20.403 ms  16.602 ms  19.932 ms
 8  10.9.195.2 (10.9.195.2)  22.322 ms  18.786 ms  21.961 ms
 9  ae-12.r00.tokyjp01.jp.bb.gin.ntt.net (203.105.72.81)  18.919 ms  19.627 ms  19.820 ms
10  ae-8.r31.tokyjp05.jp.bb.gin.ntt.net (129.250.3.190)  21.278 ms  21.948 ms  22.652 ms
11  ae-4.r23.lsanca07.us.bb.gin.ntt.net (129.250.3.193)  130.221 ms  125.016 ms  125.525 ms
12  ae-2.r01.lsanca07.us.bb.gin.ntt.net (129.250.4.107)  127.281 ms  128.845 ms  128.561 ms
13  ae-0.inforelay-online-systems.lsanca07.us.bb.gin.ntt.net (128.242.180.166)  128.782 ms  129.433 ms  124.512 ms
14  er1.lax2.inforelay.net (67.208.82.78)  127.080 ms 67.208.82.6 (67.208.82.6)  126.141 ms  129.317 ms
15  67.208.84.214 (67.208.84.214)  127.506 ms 67.208.84.210 (67.208.84.210)  129.916 ms  131.955 ms
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

frankbell · 09-15-2016, 09:21 PM

I just pinged the site successfully. My traceroute was similar to yours.

The site resolves in my browser with the page header "Welcome to HPE Helion Documentation," and seems fully functional.

Sites do go down. They hiccough. They get DDoSed. Servers fail. Stuff happens.

Grab your towel (per The Hitchhiker's Guide), don't panic, and try again later.

Emerson · 09-15-2016, 09:33 PM

TCP gets thru where UDP gets blocked.

Code:

traceroute -T 173.205.188.47
traceroute to 173.205.188.47 (173.205.188.47), 30 hops max, 60 byte packets
 1  172.20.0.1 (172.20.0.1)  11.127 ms  11.112 ms  11.107 ms
 2  10.131.128.1 (10.131.128.1)  20.008 ms  20.011 ms  20.008 ms
 3  24.248.104.84 (24.248.104.84)  32.934 ms  32.949 ms  32.950 ms
 4  70.169.88.34 (70.169.88.34)  32.936 ms  32.935 ms  37.070 ms
 5  dalsbprj01-ae1.0.rd.dl.cox.net (68.1.2.109)  55.771 ms  55.765 ms  55.733 ms
 6  ae-12.r08.dllstx09.us.bb.gin.ntt.net (129.250.194.173)  64.776 ms  48.916 ms  52.212 ms
 7  ae-8.r22.dllstx09.us.bb.gin.ntt.net (129.250.3.167)  52.180 ms  21.486 ms  30.675 ms
 8  ae-5.r22.lsanca07.us.bb.gin.ntt.net (129.250.7.69)  62.828 ms  62.794 ms  62.807 ms
 9  ae-1.r01.lsanca07.us.bb.gin.ntt.net (129.250.3.123)  58.023 ms  73.664 ms  67.030 ms
10  ae-0.inforelay-online-systems.lsanca07.us.bb.gin.ntt.net (128.242.180.166)  82.458 ms  82.455 ms  84.612 ms
11  er1.lax2.inforelay.net (67.208.82.78)  84.607 ms 67.208.82.6 (67.208.82.6)  82.386 ms  64.700 ms
12  67.208.84.210 (67.208.84.210)  60.077 ms 67.208.84.214 (67.208.84.214)  60.069 ms  69.997 ms
13  173.205.188.47 (173.205.188.47)  69.982 ms  54.604 ms  50.833 ms
14  173.205.188.47 (173.205.188.47)  57.314 ms  61.312 ms  54.829 ms

berndbausch · 09-16-2016, 01:35 AM

Quote:

Originally Posted by frankbell

seems fully functional.

It is. The site contains the documentation of HPE's Helion products and had better be up at all times. I forgot to mention that I can access it via a proxy (but I haven't found a free proxy that makes that process painless enough).

It's just not reachable from here, and my baby-level networking skills are insufficient to understand what's wrong. How can I find out?

berndbausch · 09-16-2016, 01:39 AM

Quote:

Originally Posted by Emerson

TCP gets thru where UDP gets blocked.

Code:

traceroute -T 173.205.188.47
traceroute to 173.205.188.47 (173.205.188.47), 30 hops max, 60 byte packets
(...)
10  ae-0.inforelay-online-systems.lsanca07.us.bb.gin.ntt.net (128.242.180.166)  82.458 ms  82.455 ms  84.612 ms
11  er1.lax2.inforelay.net (67.208.82.78)  84.607 ms 67.208.82.6 (67.208.82.6)  82.386 ms  64.700 ms
12  67.208.84.210 (67.208.84.210)  60.077 ms 67.208.84.214 (67.208.84.214)  60.069 ms  69.997 ms
13  173.205.188.47 (173.205.188.47)  69.982 ms  54.604 ms  50.833 ms
14  173.205.188.47 (173.205.188.47)  57.314 ms  61.312 ms  54.829 ms

Funny, my packets goes through the exact same routers number 10,11 and 12 as your packets. After that, it seems to disappear.

Code:

13  ae-0.inforelay-online-systems.lsanca07.us.bb.gin.ntt.net (128.242.180.166)  123.771 ms  123.149 ms  124.482 ms
14  er1.lax2.inforelay.net (67.208.82.78)  119.528 ms 67.208.82.6 (67.208.82.6)  127.826 ms  128.371 ms
15  67.208.84.210 (67.208.84.210)  125.177 ms 67.208.84.214 (67.208.84.214)  127.028 ms  125.993 ms
16  * * *
17  * * *
etc.

What does that mean?

Habitual · 09-16-2016, 06:02 AM

Quote:

Originally Posted by berndbausch

It is. The site contains the documentation of HPE's Helion products and had better be up at all times. I forgot to mention that I can access it via a proxy (but I haven't found a free proxy that makes that process painless enough).

It's just not reachable from here, and my baby-level networking skills are insufficient to understand what's wrong. How can I find out?

ping failure, is not an absolute indicator of much.
Ping is unreliable as a test.
ICMP packets can be dropped.

http://downforeveryoneorjustme.com/h...173.205.188.47
since there's no DNS A Record on that HP host, I can only assume it if for protection by obfuscation.

ping showing **** does not mean "down" as packets can be dropped. They're called "hops"

Visit the site or test port 80 instead, using

Code:

nc -zv 173.205.188.47 80

anything but ping.

Emerson · 09-16-2016, 07:38 AM

I was thinking traceroute uses ICMP by default ... it does use UDP. I'm getting thru using ICMP and TCP, only UDP fails.

Habitual · 09-16-2016, 09:20 AM

Quote:

Originally Posted by Emerson

I was thinking traceroute uses ICMP by default ... it does use UDP. I'm getting thru using ICMP and TCP, only UDP fails.

I'd have to take your word for it.

I just don't think ping is worth spit.

jpollard · 09-16-2016, 06:52 PM

Sometimes this is just a temporary problem with the routers between you and the target (usually when traceroute starts putting ***, either the ISP disables ICMP OR the router is currently confused/being updated).

ISPs tend to disable ICMP (AT&T does this) to avoid ping floods. Traceroute has alternate methods of tracing (using TCP) that usually work.

Emerson · 09-16-2016, 06:55 PM

It is Windows traceroute that uses ICMP, Linux traceroute seems to default to UDP, although TCP, GRE, ICMP and others are available.

Rinndalir · 09-16-2016, 11:14 PM

What access do you need to the site? What protocol? Http, ftp, ssh? My point is that you might be asking the wrong question and/or drawing the wrong conclusions.

berndbausch · 09-16-2016, 11:15 PM

Well I pinged the site only after I was unable to reach it via web browser. I also tried nc and telnet. This is hardly a temporary glitch; it has been like this for a week at least.

Habitual's remark

Quote:

there's no DNS A Record on that HP host

is very interesting. I can't imagine this site is supposed to be obfuscated; it contains the official documentation of HPE's cloud products. And by the way, I get an A record for the site's name:

Code:

$ dig docs.hpcloud.com

; <<>> DiG 9.9.5-9+deb8u4-Raspbian <<>> docs.hpcloud.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41645
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 6, ADDITIONAL: 7

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;docs.hpcloud.com.              IN      A

;; ANSWER SECTION:
docs.hpcloud.com.       900     IN      CNAME   docs.hpcloud.net.
docs.hpcloud.net.       900     IN      A       173.205.188.47

but not the other way round:

Code:

$ dig 47.188.205.173.in-addr.arpa

; <<>> DiG 9.9.5-9+deb8u4-Raspbian <<>> 47.188.205.173.in-addr.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 7368
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;47.188.205.173.in-addr.arpa.   IN      A

Is this related to this outage? But why only me, then?

Rinndalir · 09-16-2016, 11:24 PM

Just use a proxy to access it. There are plenty around, pick one and use it until they fix it.

Habitual · 09-17-2016, 07:48 AM

Quote:

Originally Posted by berndbausch

Habitual's remark

is very interesting. I can't imagine this site is supposed to be obfuscated; it contains the official documentation of HPE's cloud products. And by the way, I get an A record for the site's name:
[code]
$ dig docs.hpcloud.com

I meant the result of

Code:

host 173.205.188.47

and no rDNS, my bad.
and I didn't know of any docs.hpcloud.com host.

berndbausch · 09-18-2016, 12:44 AM

Quote:

Originally Posted by Rinndalir

Just use a proxy to access it. There are plenty around, pick one and use it until they fix it.

Yes, I guess that will be my fate. I just thought it might be possible to find out what's going on in the plumbing of the global machine.