Hi there,

My hosting company seems to be really good and their plans are very feature rich but connection to my site on their server seems problematic. Now the problem may not be them at all but rather a faulty router or other hardward on the way to them.

I sent them a tracer route showing a time out when getting to their server and was told by one apparently very good tech (based on previous communication) that this was due to a technology called ICBM disable being used. And that this technology makes it seem sometimes that a site times out when in fact it may still be reachable.

Another tech at the same company when commenting on a different but related issue said a tracer route was the best thing I could send them to help diagnose issues.

Does a tracer route really do any good when accessing a server that has ICBM diabled? If so what good does it do in terms of showing average times to site?

Are there tests or other techniques I can use besides tracer route to help me determine whether there really is a genuine time out at the hosting servers and whether a problem I am having connecting is being caused by such servers?

Any insight from anyone on this would be appreciated.

Thanks.

Carlos

Can you post the traceroute please? If it's dropping off right before their server then it is their router. If it's somewhere in between it may be your ISP. The traceroute output would be a big help.

I'm guessing its not a rooter

Correction!

I guess the technology is calledl ICMP ....NOT....ICBM ;)

Carlos123,

You write: "connection to my site on their server seems problematic".

What specifically is the problem? FTP timeout? Can not connect? Upload fails??

The tracer route I sent my hosting provider is the following. I have left out details which are irrelevant to the discussion such as my IP and the name of the hosting company - since the problem may not lie with them at all.

BEGIN TRACER ROUTE
Tracing route to <hosting company site> [IP snipped]
over a maximum of 30 hops:

1 31 ms 31 ms 29 ms <IP snipped>
2 30 ms 29 ms 29 ms edtnabkddr00.bb.telus.com [IP snipped]
3 30 ms 31 ms 30 ms edtnabxmbr01.bb.telus.com [IP snipped]
4 44 ms 43 ms 44 ms nwmrbc01br01.bb.telus.com [IP snipped]
5 48 ms 48 ms 48 ms sttlwa01br02.bb.telus.com [IP snipped]
6 48 ms 48 ms 48 ms acr2-so-2-1-0-0.Seattle.cw.net [208.172.81.129]
7 66 ms 65 ms 66 ms acr1-loopback.SantaClara.cw.net [208.172.146.61]
8 68 ms 67 ms 67 ms bpr2-loopback.PaloAltoPaix.cw.net [208.172.146.19]
9 68 ms 69 ms 67 ms 206.24.241.178
10 68 ms 68 ms 68 ms sntcca2lce1-oc48.wcg.net [64.200.210.177]
11 91 ms 91 ms 92 ms chcgil1wcx3-oc48.wcg.net [64.200.240.93]
12 118 ms 116 ms 117 ms nycmny2wcx3-oc48.wcg.net [64.200.240.38]
13 117 ms 117 ms 116 ms nycmnyhlce1-oc48.wcg.net [64.200.87.110]
14 157 ms 166 ms 166 ms nycmny2lce1-netaccess-atm.wcg.net [64.200.86.150]
15 154 ms * 156 ms a9-0-0-1066.msfc1.oct.nac.net [209.123.11.245]
16 170 ms 168 ms 173 ms <hosting company hardware name snipped> [IP snipped]
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
END TRACER ROUTE

Thanks.

Carlos

The problem I am having is like what happened yesterday for example.

I was in the middle of using WinSCP (an SSH - FTP like program) to change some file permissions at my site (*nix hoster). The connection went dead after some time of successfully connecting.

Just in case it might be the WinSCP program I went out and fired up my SSH Telnet client named PuTTY. No entry prompt asking for my user name even showed up like it usually does - so it wasn't my WinSCP program.

I went out to view my site through a web browser and from what I can remember I couldn't get through to that one either.

A few minutes later everything was working fine.

Hoster said nothing unusual had been happening.

On another occassion my shell access was so incredibly slow that I would type in ten letters worth of commands and the shell would still be echoing back my second letter. I would be sitting there tapping my fingers so to speak waiting for the shell to catch up.

These types of problems are happening infrequently and without seeming consistantcy. Sometimes my web site comes up at good speed, sometimes it comes up in my browser after what seems like too many seconds.

It's all intermittant. My hoster is reporting no problems though they have offered to have a network engineer look into it. I am holding off on that until I can do everything I can from my end to figure out where and how these problems are occurring.

I can live with these intermittent connection problems since they rarely last for more than a minute or two but it is a frustrating experience having to re-connect my FTP and shell to get back to work.

On a side note I am in Western Canada and my hoster is on the East Coast of the U.S. So there are a number of hops that have to be gone through before a connection is made.

At one time I would have jumped to the conclusion that my hoster was the problem but they are very well spoken of and it is unlikely that my connection problems are all due to some lack in them. Though I haven't ruled that out either.

Thanks.

Carlos

Carlos,

Are you on dialup or high-speed (cable/dsl)? Sometimes this problem can be on ISP side as well. At the time when you are unable to access your site, do you check any other site is working e.g. www.cnn.com or www.webhostingtalk.com? :D

If everything else seems to be working fine, then the problem can be at your host end.

Hi masood,

Thanks for your input (and to everyone else too).

I am using ADSL high speed and am right next to a connection point (switching station) so I have the highest speed possible.

Other sites (like www.yahoo.com) work just fine when I am unable to access my site. I make sure I am not just re-loading a cached copy either by reloading several times.

I am trying out this really nifty program called Ping Plotter and am starting to realize several things.

I am definitely experiencing a 100% packet loss periodically. I am not sure where these packet losses are occurring or even if such periodic packet losses are normal.

On the second hop of a tracer route my ISP's server returns round trip times of between 100-218 ms. About every 5-10 minutes. My ISP is checking this out though they said it might be due to load surges. It seems to me that it is too consistent to be load surges though and a bit high for a return time from a second hop.

The rest of the trace route looks fine until it gets to New York city somewhere. A couple of servers there are running return trip times of up to 327 ms every 15-20 minutes (roughly) before my hosters first server is hit. The hosting server is showing a very consistent return trip time which is not excessive at all averaging about 111 ms.

All the average times seem normal. It's these spikes and lost packets that occur sometimes that seem to be the problem.

I guess since the evidence shows that my hoster is doing just fine and that the problem lies with either my 2nd hop ISP server and a couple of New York servers (or both) there may not be a whole lot I can do. My ISP might be willing to do something but the two New York servers?

I guess I might be stuck with a great hoster who I am connecting to through a bad route?? In the final analysis it might be better to be with a great hoster on a bad route to me than to be with a poor hoster on a good route. Assuming the route to me is not experienced by most others.

Carlos

Sometimes it helps to do a trace route in both directions, from you to the server, and from the server back to you to help pinpoint problems. The routes taken can be very different.

Note: ICBM technology can have a detrimental effect on networks too. :) Haven't heard of any instances of that happening lately though.

Note: ICBM technology can have a detrimental effect on networks too. Haven't heard of any instances of that happening lately though.

Now thats funny!!!

Try to use third-party tools like http://www.network-tools.com/ and others to traceroute to your server, especially when you cannot connect to it.

These tools provide connection from other locations, so they are very helpful.

Peter