I manage a KVM VPS at that for some reason cannot reach http://pecl.php.net.

When I ping the IP address of the PECL server (, to make sure that it isn't a DNS problem, and each time I get Destination Host Unreachable.

How can I debug whether the root cause is a misconfiguration of my server, or the ping being rejected by the destination server?

I have no issues pinging PECL from various other servers that I manage, so I know PECL isn't blocking all pings.

I also have no issues pinging any other sites I try from my VPS, the problem is solely with the PECL server.

I used the looking glass of my VPS host (http://lg.las1.ultravps.net/), and it has no issues pinging PECL. I also filed a support ticket with the host, and they logged into the hypervisor for this node and said they could successfully ping PECL.

I ran a traceroute to the PECL server from another server to find the IP address of a next-to-last hop. I can successfully ping that IP ( from my VPS.

When I run traceroute from the VPS, I get:

[jeffwidman@ultravps ~]$ traceroute pecl.php.net
traceroute to pecl.php.net (, 30 hops max, 60 byte packets
 1  ultravps.jeffwidman.com (  3005.478 ms !H  3005.400 ms !H  3005.270 ms !H
[jeffwidman@ultravps ~]$ traceroute
traceroute to (, 30 hops max, 60 byte packets
 1  ultravps.jeffwidman.com (  3005.916 ms !H  3005.877 ms !H  3005.867 ms !H
[jeffwidman@ultravps ~]$

I checked multiple blacklist sites, just to make sure I hadn't inherited a bad IP address... none of them listed my IP. I also don't regularly hit PECL, and this issue has occurred for several days, so I'd be very surprised if I was hitting rate-limiting.

What else can I do to debug whether PECL is blocking my IP address or if I have something misconfigured on my VPS?

Output of ip route:

[jeffwidman@ultravps ~]$ ip route
default via dev eth0  proto static  metric 100 dev eth0  proto kernel  scope link  src  metric 100

Output of ip addr:

[jeffwidman@ultravps ~]$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:16:3c:d1:49:f6 brd ff:ff:ff:ff:ff:ff
    inet brd scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3cff:fed1:49f6/64 scope link
       valid_lft forever preferred_lft forever
[jeffwidman@ultravps ~]$

Now the problem is apparent.

Your network interface has the wrong prefix set.

It is set to /8 (or in the old netmask notation,, which tells your operating system that every address in the through inclusive is on the same LAN as your VPS.

This obviously is not the case. Most of this range is subdivided into very small networks scattered all over the Americas.

Because of this, your computer does not know it is meant to route the packets, and tries to contact any address beginning with 104. on the same LAN, where it cannot be found.

To fix the problem, you need to reconfigure your network for the correct netmask or CIDR range. You can obtain this information from your VPS provider.

  • Do you mind expanding your answer slightly on what made you suspect it was a routing issue on my VPS and that I should check using the ip tool? Was it because traceroute didn't even get to one hop? I'd like to not just diagnose this issue, but also become better at having a mental checklist/framework for diagnosing similar issues in the future. – Jeff Widman Jan 27 '16 at 6:51
  • 1
    Right, it was exactly because the traceroute did not even get to one hop. That the host was unreachable was returned by your own VPS, so it never attempted to route anything anywhere. – Michael Hampton Jan 27 '16 at 6:56
  • If the IP had been blocked by the destination server, traceroute would navigate correctly all the way until the final hop, correct? Also, thank you--I really appreciate the help. – Jeff Widman Jan 27 '16 at 7:01
  • Yes, at the end of such a traceroute you would receive a completely different response, or none at all. – Michael Hampton Jan 27 '16 at 7:24

Since you are testing against a publicly-available web site, the aptly-named down for everyone or just me web service is very helpful. Just put the address of the site in question into their web form, and they will ping the address from a few locations. I've yet to run into a situation in which a server was up but they were not able to reach it, even in some badly-configured Africa and Middle Eastern locations.

You can use it from the CLI as well, just grep the output for span to make it easier to read:

$ curl -s http://www.downforeveryoneorjustme.com/serverfault.com | grep span
  It's just you.  <a href="http:&#x2F;&#x2F;serverfault.com" class="domain">http:&#x2F;&#x2F;serverfault.com</a></span> is up.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.