URGENT: Connectivity problems

benr77 · 12-03-2004, 04:50 AM

I am based in the UK. I have a web host based in the US. Yesterday I found out that the server was unavailable from certain places in the UK. I then checked from my location and was able to access the server perfectly.

After some further testing, it appears that certain locations in the UK can see the server in the US, and other UK locations can't.

I've definitely been able to ping the US machine from certain UK locations, so the server is definitely up and running. The web host technical support also assure me that they've checked the server and it's operating correctly.

So, does anyone know how I go about debugging this issue, and even more importantly rectifying it? This is now urgent as I have clients demonstrating web sites to their clients today and I've no idea whether they'll be able to access them from their various locations !!

Any help much appreciated

musicman_ace · 12-03-2004, 05:07 AM

from one of the locations that doesn't work, do a trace route and see where the packets are being lost.

Also, if you have shell access on the server, start pinging your IP and the ones that don't work.

benr77 · 12-03-2004, 05:14 AM

From a location where I can't connect, traceroute outputs the following:

Code:

traceroute to traprocedures.com (209.197.252.118), 30 hops max, 38 byte packets
 1  * * *
 2  gadamer-dsl.zen.net.uk (62.3.83.3)  17.088 ms  19.953 ms  20.249 ms
 3  erazmus-ge-0-0-1-1.wh.zen.net.uk (62.3.80.193)  19.602 ms  17.407 ms  19.923 ms
 4  lorenz-so-0-1-0-0.te.zen.net.uk (62.3.80.45)  24.062 ms  25.218 ms  29.915 ms
 5  suarez-ge-0-2-0-0.te.zen.net.uk (62.3.80.42)  26.201 ms  25.417 ms  25.932 ms
 6  sl-gw22-lon-2-1.sprintlink.net (213.206.158.57)  23.966 ms  24.814 ms  27.966 ms
 7  sl-bb22-lon-9-0.sprintlink.net (213.206.128.104)  29.895 ms  27.102 ms  25.902 ms
 8  sl-bb20-nyc-2-0.sprintlink.net (144.232.9.163)  217.732 ms  304.748 ms  111.870 ms
 9  sl-bb22-nyc-8-0.sprintlink.net (144.232.7.106)  98.003 ms  93.098 ms  91.775 ms
10  sl-bb21-chi-9-0.sprintlink.net (144.232.9.149)  113.830 ms  113.257 ms  113.769 ms
11  sl-bb21-che-5-1.sprintlink.net (144.232.18.5)  131.802 ms  131.104 ms  129.985 ms
12  sl-gw10-che-10-0.sprintlink.net (144.232.15.166)  129.643 ms  131.739 ms  128.740 ms
13  sl-internap-101-0.sprintlink.net (160.81.54.46)  147.821 ms  179.204 ms  210.744 ms
14  border9.ge3-1-bbnet1.den.pnap.net (216.52.40.14)  132.811 ms  134.246 ms  132.931 ms
15  data393-3.border9.den.pnap.net (63.251.181.210)  136.022 ms  135.303 ms  137.328 ms
16  core-b.v23.ge-2-7.Internap-2.edge2.data393.net (208.42.224.9)  140.265 ms  139.310 ms  141.890 ms
17  rtr-dc-dist-d.v24.hosting.data393.net (208.42.224.27)  139.764 ms  139.285 ms  140.098 ms
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

So presumably the packets are being stopped at a machine called "rtr-dc-dist-d.v24.hosting.data393.net". But surely a single machine blocking packets should force an alternate route to be taken?

What's the next step, now I've identified this machine that's stopping the packets?

musicman_ace · 12-03-2004, 11:22 PM

can you ping that IP from your computer?

benr77 · 12-04-2004, 03:33 AM

No, I was getting no response from pinging the server either.

Fortunately, the problem machine (rtr-dc-dist-d.v24.hosting.data393.net) is now passing on data and the connection to my server has been restored.

However, I still don't know how I'm supposed to deal with problems like this. I thought the whole robustness of the internet was based on the fact that there was no single route to a machine, and that if one machine was unavailable an alternative route would be taken to the destination? In this case it appears that a single machine failure totally blocked the request...

How are issues like this normally resolved?

musicman_ace · 12-04-2004, 04:56 AM

To my knowledge, it all depends on the routing tables that are setup. If the ISPs and Telecommunication offices aren't up to par, they could conceivably create a 1 link to the world. The next steps I would take would be:

Report this to your local ISP and have them keep you in the loop as to why this happened. They may want the tracert output
If it isn't thier problem, go to a regional ISP. (or whomever the address where communication was lost.)
email the people where the packets are being dropped. Perhaps this was a scheduled downtime/upgrade?