200M : Issues accessing a website on VM connection

[spiderplant]

Originally Posted by SnoopZ

Is that the same as the CMD ping command?

It's similar, but shows every step of the route, so you can see where the packets are getting lost. Like this:

$ traceroute www.neowin.net
traceroute: Warning: www.neowin.net has multiple addresses; using 5.10.17.165
traceroute to www.neowin.net (5.10.17.165), 30 hops max, 40 byte packets
1 (censored)
2 (censored)
3 (censored)
4 (censored)
5 brnt-bb-2a-ae31-0.network.virginmedia.net (62.254.42.61) 2.095 ms 2.400 ms 2.131 ms
6 brnt-ic-2-ae0-0.network.virginmedia.net (62.254.42.98) 2.001 ms 1.973 ms 1.967 ms
7 brnt-bb-2a-ae2-0.network.virginmedia.net (62.254.42.97) 2.121 ms 2.295 ms 2.260 ms
8 m686-mp2.cvx1-b.lis.dial.ntli.net (62.254.42.174) 2.781 ms 2.638 ms 2.564 ms
9 213.46.174.118 (213.46.174.118) 2.585 ms 18.019 ms 9.935 ms
10 ldn-bb3-link.telia.net (62.115.134.134) 10.975 ms 10.048 ms ldn-bb4-link.telia.net (62.115.134.138) 9.993 ms
11 slou-b1-link.telia.net (62.115.117.123) 10.332 ms slou-b1-link.telia.net (62.115.117.193) 10.644 ms slou-b1-link.telia.net (62.115.117.123) 10.353 ms
12 everestdata-ic-321418-slou-b1.c.telia.net (213.248.95.63) 10.871 ms 10.863 ms 10.924 ms
13 aggr.b.dh2.rdg.everestdc.com (185.28.167.235) 11.299 ms 11.297 ms 11.296 ms
14 edge1.dh2.rdg.everestdc.com (185.28.167.223) 12.030 ms 12.183 ms 11.961 ms
15 gw.rdg-transit.neow.in (5.10.27.250) 11.277 ms 11.218 ms 11.253 ms
16 * * *
17 * * *

The 15th hop shows it reaching neowin's network. The subsequent hops within their network do fail for me, but they might be blocking traceroute.

The command is sometimes called tracert instead.

[heero_yuy]

Quote from SnoopZ:

SnoopZ_s.jpg

Is that the same as the CMD ping command?

Tracert It uses ping underneath but gives much more data:



Looks like it's down at the moment.

[edit] Beaten to it by Spiderplant.

neowin_trace.JPG

[Synthetic]

Loading fine here still, chances are their routers are configured to not respond to pings.

Routing looks a bit weird.

1 1 ms 2 ms 3 ms USG [192.168.1.1]
2 11 ms 12 ms 8 ms 10.118.88.1
3 14 ms 9 ms 10 ms gate-core-2a-xe-223-0.network.virginmedia.net [62.252.170.253]
4 * * * Request timed out.
5 * * * Request timed out.
6 23 ms 29 ms 23 ms 86.85-254-62.static.virginmediabusiness.co.uk [62.254.85.86]
7 23 ms 23 ms 23 ms ldn-b1-link.telia.net [213.248.84.25]
8 27 ms 25 ms 23 ms ldn-bb3-link.telia.net [62.115.114.234]
9 31 ms 25 ms 22 ms slou-b1-link.telia.net [62.115.117.193]
10 25 ms 24 ms 23 ms everestdata-ic-321418-slou-b1.c.telia.net [213.248.95.63]
11 27 ms 25 ms 25 ms aggr.b.dh2.rdg.everestdc.com [185.28.167.235]
12 26 ms 31 ms 24 ms edge1.dh2.rdg.everestdc.com [185.28.167.223]
13 30 ms 26 ms 22 ms gw.rdg-transit.neow.in [5.10.27.250]
14 * * * Request timed out.
15 * * * Request timed out.
16 * * * Request timed out.
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.

[heero_yuy]

Agreed. Site still loads OK.

[SnoopZ]

Originally Posted by spiderplant

It's similar, but shows every step of the route, so you can see where the packets are getting lost. Like this:


The 15th hop shows it reaching neowin's network. The subsequent hops within their network do fail for me, but they might be blocking traceroute.

The command is sometimes called tracert instead.

Access seems back to its normal speed now, but this traceroute doesn't look good?

[spiderplant]

It's fine. It's normal for some intermediate routers to not respond. But you are consistently getting to neowin and back in 20ms, which is good.

We'll probably never know where the problem was

[General Maximus]

my trace route is pretty much the same as yours so I wouldn't worry