Specific IP Address won't display, ran a tracert

This topic is way above my head, so please bear with me. I am a web designer. Out of the blue yesterday, I was not able to browse to any web sites that I developed and have hosted with a small company out of Iowa. First, I thought it was there server. I called and they said all was fine. He had me ping the sites and all came back with Request Timed Out. Next, I contacted a friend in Alaska (I am in Budapest) and had him go to the sites www.europewithasmile.com, www.saveourcritters.com, and tmh.netdbs.com. He had no problem doing so. This morning I called my ISP and they had me run a tracert from the command prompt. It returned several (11 total) IP addresses, then beginning with the 12th, started sending Request Timed Out. MY ISP told me the problem lay with the 11th. Is that right? Where do I even begin to resolve this. I have put a Image on the net to show you the message from my tracert effort. Please help me.
Tom H

I believe tracert has a limit in time to a return. If out of that time slot there is no return. A number of routers on the internet are configured not to return a icmp packet [ping] also.

I think this is a false lead. It could be that you are just too far away and speed [response time] is too long for the programs, like ie, to wait.

Apasa trace! si asteapta pana se completeaza traceroutele

Traceroute catre 206.72.14.234 - 2004-06-26


1 brasov-cr-fe1-1.brasov.rdsnet.ro (213.157.185.161) 0.506 ms 0.465 ms 1.186 ms
2 brasov-bb-fe1-0.rdsnet.ro (81.196.37.185) 0.544 ms 0.978 ms 0.931 ms
3 buh1-bb2-ge4-0-0.v95.rdsnet.ro (193.231.253.193) 4.651 ms 4.621 ms 3.781 ms
4 buh1-gsr2-ge4-0.rdsnet.ro (62.231.127.130) 4.078 ms 3.614 ms 4.888 ms
5 fra2-cr1-atm1-330.rdsnet.ro (62.231.127.94) 34.424 ms 33.679 ms 42.170 ms
6 so-1-3-2.ar2.FRA3.gblx.net (67.17.159.101) 41.851 ms 37.885 ms 36.254 ms
7 so1-0-0-2488M.ar3.JFK1.gblx.net (67.17.72.26) 119.074 ms 132.181 ms 131.333 ms
8 208.50.13.170 (208.50.13.170) 129.387 ms 137.179 ms 130.166 ms
9 jfk-core-02.inet.qwest.net (205.171.30.17) 127.273 ms 139.021 ms 142.938 ms
10 ewr-core-01.inet.qwest.net (205.171.8.245) 151.993 ms 149.956 ms 149.892 ms
11 kcm-core-03.inet.qwest.net (205.171.8.185) 189.735 ms 208.978 ms 206.351 ms
12 dsm-core-01.inet.qwest.net (205.171.205.197) 219.320 ms 212.760 ms 213.128 ms
13 des-edge-01.inet.qwest.net (205.171.159.18) 212.901 ms 203.080 ms 205.778 ms
14 65.127.134.2 (65.127.134.2) 183.264 ms 174.075 ms 184.689 ms
15 * ins-border10-at-0-3-0-un0.desm.netins.net (167.142.57.215) 281.833 ms *
16 stanton.desm.netins.net (167.142.53.202) 173.247 ms stanton2.desm.netins.net (167.142.61.102)
166.507 ms stanton.desm.netins.net (167.142.53.202) 181.345 ms
17 newmarketida.nwmr.netins.net (167.142.190.194) 179.911 ms 180.275 ms 182.116 ms
18 * * *


looks like it should be working now, I traced from a route server in Romania (closest I could find to budapest) and it jumps into the same path yours took and past the 205.171.159.18 router in qwest network. if you are still getting the same results I would get qwest on the phone as they have a routing issue getting back to you from the 65.127.134.2 router (ie.. Qwest Communications NET-QWEST-BLKS-4 (NET-65-112-0-0-1) 65.112.0.0 - 65.127.255.255) (although this is probably netins peering router using qwest's IP )or an issue with MPLS or something of that nature. ( thats odd I took an OC-48 accross the ocean wonder what happened to the two OC-192's they had oh well)