How to fix tracert timeout at mid atlantic hop

SonWebHost

Account Disabled
This month I keep getting a time out at the seven and eight hop, this is outside the data center and not local so how can i fix this: Thanks

Tracing route to sonwebhost.com [199.241.184.155]
over a maximum of 30 hops:

1 1 ms 2 ms 3 ms 192.168.2.1
2 2 ms 2 ms 2 ms 192.168.1.1
3 12 ms 22 ms 9 ms 65.48.175.1
4 13 ms 11 ms 14 ms 200.50.68.103
5 65 ms 64 ms 67 ms bgi4-mia4.caribsurf.com [65.48.251.134]
6 161 ms 175 ms 169 ms te0-0-0-19.ccr21.mia03.atlas.cogentco.com [38.10
4.95.121]
7 * 78 ms 78 ms 4.68.110.169
8 * * * Request timed out.
9 90 ms 79 ms 83 ms CENTRILOGIC.ear1.Atlanta2.Level3.net [4.16.60.20
6]
10 90 ms 103 ms 91 ms dct-cr01--v51.dacentec.com [199.255.156.53]
11 87 ms 97 ms 98 ms dct-ds42-ve33.dacentec.com [199.191.57.194]
12 86 ms 87 ms 89 ms dct-ds08-vl-41.dacentec.com [199.241.190.230]
13 89 ms 89 ms 88 ms 199.241.184.154
14 90 ms 87 ms 87 ms ns1.sonwebhost.com [199.241.184.155]
 
Cogent has some strange filters in place. They refuse to admit it, but we experienced the same situation as you. The best option is creating another route - either by demanding this from Cogent or switching upstream provider entirely.
 
Kindly tell me, you said you experienced, dose this me you no longer have the problem, and 2 how do I contact cogent, and 3 switching upstream provider would mean changing data center? Thanks you.
 
#7 -- 78ms -- is not a problem. There is nothing to worry about unless latency gets into the few hudreds (as a matter of fact, the latency in hops after that are worse - but still not high)

#8 can be due to icmp echoes being disabled at that node.

I believe you are using tracert incorrectly at this point. If I understand your purpose here you should do a ping to the destination first. If the latency is low, there is no need for a tracert. If high (few hundreds) then do a tracert to find the bottleneck. Once you can positively identify the bottleneck, things can be done to mitigate.


Pinging sonwebhost.com [199.241.184.155] with 32 bytes of data:
Reply from 199.241.184.155: bytes=32 time=141ms TTL=55
Reply from 199.241.184.155: bytes=32 time=85ms TTL=55
Reply from 199.241.184.155: bytes=32 time=148ms TTL=55
Reply from 199.241.184.155: bytes=32 time=143ms TTL=55

Ping statistics for 199.241.184.155:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 85ms, Maximum = 148ms, Average = 129ms

Looks ok from here -- no need to bother with tracert
 
Last edited:
Kindly tell me, you said you experienced, dose this me you no longer have the problem, and 2 how do I contact cogent, and 3 switching upstream provider would mean changing data center? Thanks you.

I will reply in order of appearance:
1) We had this issue a couple years ago and we worked out a solution
2) You can contact Cogent through http://www.cogentco.com/ru/customer-service/support-desk
3) Our admins coded a software that manages ustream providers and we developed a hardware scheme which is now installed in all our points of presence. Whenever our customers experience any issues with uplink from one upstream provider, we simply switch them to another provider. No, you do not need to change data center, some DC's even offer this solution, so-called multi-homed network themselves. The only difference is that YOU have to open ticket to datacenter CUstomer Support dept and it takes a couple of days sometimes. Our solution offers switching much faster.
 
Top