Difficulty accessing eevblog.com - Internet routing problem?

[splin]

For the last week or so (25th Jan was the last date I can find in browser history), I can't access this site via my ISP (Demon), or my colleagues (Virgin) ISP. Both are major UK ISPs. However I can access it, from the same laptop through a dongle on the '3' network and via my mobile (on Orange). I can't ping www.eevblog.com from any machine - presumably the site has disabled pings.

IE11 says "This page can't be displayed", Firefox similar. Wireshark shows the TCP connect requests being sent with no responses, so it's not a browser problem.

Traceroute shows odd results on both my non-working Demon ISP and the working '3' Network, with "Request timed out" after 69.195.64.132. Normally it stops after displaying the last hop being the destination IP being reached. None of the traceroutes to eevblog ever show it reaching eevblog (198.1.64.143).

Traceroute from Demon shows:

C:\>tracert www.eevblog.com

Tracing route to www.eevblog.com [198.1.64.143]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.2.1
  2    16 ms    17 ms    17 ms  194.159.169.242
  3    17 ms    17 ms    17 ms  anchor-access-3-s2008.router.demon.net [194.217.23.29]
  4    17 ms    17 ms    17 ms  gi7-0-0-dar3.lah.uk.cw.net [194.159.161.90]
  5    17 ms    17 ms    17 ms  xe-0-1-0-xur1.lns.uk.cw.net [193.195.25.70]
  6    17 ms    17 ms    18 ms  10gigabitethernet5-1.core1.lon1.he.net [5.57.80.128]
  7    18 ms    18 ms    24 ms  10ge3-1.core1.lon2.he.net [72.52.92.222]
  8    83 ms    92 ms    83 ms  100ge1-1.core1.nyc4.he.net [72.52.92.166]
  9   100 ms   100 ms   100 ms  100ge7-2.core1.chi1.he.net [184.105.223.161]
 10   123 ms   123 ms   123 ms  10ge4-1.core1.den1.he.net [72.52.92.234]
 11   147 ms   136 ms   138 ms  10ge4-2.core1.slc1.he.net [184.105.222.154]
 12   159 ms   149 ms   184 ms  ace-data-centers-inc.10gigabitethernet1-4.core1.slc1.he.net [66.160.133.118]
 13   147 ms   146 ms   150 ms  rtr-b.unifiedlayer.com [199.58.199.118]
 14   152 ms   148 ms   151 ms  69-195-64-132.unifiedlayer.com [69.195.64.132]
 15     *        *        *     Request timed out.
 16     *        *        *     Request timed out.
 17     *        *        *     Request timed out.
 18     *        *        *     Request timed out.
 19     *        *        *     Request timed out.
 20     *        *        *     Request timed out.
 21     *        *        *     Request timed out.
 22     *        *        *     Request timed out.
 23     *        *        *     Request timed out.
 24     *        *        *     Request timed out.
 25     *        *        *     Request timed out.
 26     *        *        *     Request timed out.
 27     *        *        *     Request timed out.
 28     *        *        *     Request timed out.
 29     *        *        *     Request timed out.
 30     *        *        *     Request timed out.

Trace complete.

Using Demon it always routes through  69.195.64.132.

Traceroute when using the "three" dongle, that can see www.eevblog.com shows it sometimes routing via 199.58.199.118 then 69.195.64.42, sometimes via 199.58.199.118 and 69.195.64.132, and sometimes via 199.58.199.114 and 69.195.64.132. A typical example:

C:\>tracert www.eevblog.com

Tracing route to www.eevblog.com [198.1.64.143]
over a maximum of 30 hops:

  1   105 ms    57 ms    59 ms  172.23.99.65
  2    58 ms    58 ms    52 ms  172.31.139.187
  3    60 ms    69 ms    59 ms  188.31.255.58.threembb.co.uk [188.31.255.58]
  4    59 ms    89 ms    49 ms  188.31.255.97.threembb.co.uk [188.31.255.97]
  5    61 ms    58 ms    59 ms  188.31.255.125.threembb.co.uk [188.31.255.125]
  6    55 ms    59 ms    99 ms  te2-2.ccr01.lon11.atlas.cogentco.com [149.11.78.17]
  7   286 ms    59 ms    59 ms  te0-0-0-34.ccr22.lon01.atlas.cogentco.com [154.54.61.53]
  8    86 ms    59 ms    69 ms  be2315.ccr22.lon13.atlas.cogentco.com [154.54.73.109]
  9    69 ms    69 ms    79 ms  be2284.ccr22.lpl01.atlas.cogentco.com [130.117.49.38]
 10   155 ms   179 ms   169 ms  be2385.ccr22.ymq02.atlas.cogentco.com [154.54.44.141]
 11   189 ms   186 ms   154 ms  be2093.ccr22.yyz02.atlas.cogentco.com [154.54.44.105]
 12   225 ms   189 ms   229 ms  be2082.mpd22.ord01.atlas.cogentco.com [154.54.28.9]
 13   212 ms   259 ms   199 ms  be2157.ccr22.mci01.atlas.cogentco.com [154.54.6.117]
 14   239 ms   219 ms   189 ms  be2131.ccr22.den01.atlas.cogentco.com [154.54.26.129]
 15   220 ms   229 ms   209 ms  be2127.ccr21.slc01.atlas.cogentco.com [154.54.25.70]
 16   421 ms   259 ms   379 ms  38.104.174.198
 17   246 ms   208 ms   229 ms  rtr-b.unifiedlayer.com [199.58.199.118]
 18   215 ms   209 ms   249 ms  69-195-64-132.unifiedlayer.com [69.195.64.132]
 19     *        *        *     Request timed out.
 20     *        *        *     Request timed out.
 21     *        *        *     Request timed out.
 22     *        *        *     Request timed out.
 23     *        *        *     Request timed out.
 24     *        *        *     Request timed out.
 25     *        *        *     Request timed out.
 26     *        *        *     Request timed out.
 27     *        *        *     Request timed out.
 28     *        *        *     Request timed out.
 29     *        *        *     Request timed out.
 30     *        *        *     Request timed out.

Trace complete.

Traceroute when accessing via the tethered mobile which can load  the  www.eevblog.com homepage  is similar, but with a few extra timeouts presumably due to the slow mobile connection. The last router it gets to is always 69.195.64.42:

C:\>tracert www.eevblog.com

Tracing route to www.eevblog.com [198.1.64.143]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.42.129
  2     *        *        *     Request timed out.
  3   365 ms   479 ms   479 ms  172.27.182.73
  4   727 ms    89 ms   248 ms  10.247.80.145
  5    96 ms    79 ms    79 ms  10.247.80.166
  6   126 ms    89 ms   131 ms  10.247.80.177
  7   995 ms   439 ms   429 ms  10.247.80.150
  8   216 ms   131 ms   105 ms  172.27.180.254
  9  1155 ms   419 ms   479 ms  172.27.180.253
 10   106 ms   111 ms    87 ms  172.27.180.2
 11    98 ms    99 ms    99 ms  172.27.180.174
 12   404 ms   479 ms   419 ms  109.249.186.2
 13    84 ms    95 ms    87 ms  87.237.20.192
 14     *        *        *     Request timed out.
 15   112 ms    89 ms   101 ms  40ge1-3.core1.lon2.he.net [195.66.224.21]
 16     *        *        *     Request timed out.
 17   523 ms   599 ms   579 ms  100ge7-2.core1.chi1.he.net [184.105.223.161]
 18     *        *        *     Request timed out.
 19   534 ms   579 ms   559 ms  10ge4-2.core1.slc1.he.net [184.105.222.154]
 20   634 ms   608 ms   619 ms  ace-data-centers-inc.10gigabitethernet1-4.core1.slc1.he.net [66.160.133.118]
 21   524 ms   659 ms   639 ms  rtr-b.unifiedlayer.com [199.58.199.118]
 22   514 ms   579 ms   569 ms  mlx02.prov.unifiedlayer.com [69.195.64.42]
 23     *        *        *     Request timed out.
 24     *        *        *     Request timed out.
 25     *        *        *     Request timed out.
 26     *        *        *     Request timed out.
 27     *        *        *     Request timed out.
 28     *        *        *     Request timed out.
 29     *        *        *     Request timed out.
 30     *        *        *     Request timed out.

Trace complete.

Interestingly, loading the eevblog homepage is roughly twice as fast when using the tethered mobile, even though the three network dongle is usually rather faster. My guess is that routing fails when routed via 69.195.64.132 and succeeds through 69.195.64.42. The three network randomly routing through both these nodes causes approx 50% of packets getting lost and so half the speed.
Does this sound reasonable? Any suggestions as to what the problem may be?

Splin

[EEVblog]

Info passed onto gnif, our resident IT penguin.

[Rigby]

well, the problem is not you.

looks like there is a routing error or misconfiguration within unified layer, whoever that is.

been a long while since I've diagnosed routing errors, though.  gnif will sort it I'm sure.

[grumpydoc]

Normally it stops after displaying the last hop being the destination IP being reached. None of the traceroutes to eevblog ever show it reaching eevblog (198.1.64.143).

Quite often the packets which traceroute uses get blocked at firewalls - very typically this is the last hop before the destination.

If I use traceroute normally I see the same pattern - however the linux version of the command has several options to control what packets are used for the probe so switching to UDP I get: (first few hops obfuscated)

# traceroute -U www.eevblog.com
traceroute to www.eevblog.com (198.1.64.143), 30 hops max, 60 byte packets
 1  ~~~~~.~~~~~~~~.org (aa.bb.cc.dd)  0.281 ms  0.311 ms  0.351 ms
 2  ~~~~~~~.net.uk (ab.bc.cd.de)  20.056 ms  20.070 ms  20.104 ms
 3  ~~~~~~~.net.uk (ww.xx.yy.zz)  20.413 ms  20.450 ms  20.646 ms
 4  10gigabitethernet5-1.core1.lon1.he.net (5.57.80.128)  21.357 ms  21.601 ms  21.814 ms
 5  10ge3-1.core1.lon2.he.net (72.52.92.222)  24.830 ms  24.843 ms  24.566 ms
 6  100ge1-1.core1.nyc4.he.net (72.52.92.166)  87.616 ms  87.122 ms  87.151 ms
 7  100ge7-2.core1.chi1.he.net (184.105.223.161)  103.987 ms  103.465 ms  103.465 ms
 8  10ge4-1.core1.den1.he.net (72.52.92.234)  126.630 ms 10ge3-2.core1.den1.he.net (184.105.213.86)  127.044 ms 10ge4-1.core1.den1.he.net (72.52.92.234)  126.643 ms
 9  10ge4-2.core1.slc1.he.net (184.105.222.154)  145.615 ms  144.672 ms  144.698 ms
10  ace-data-centers-inc.10gigabitethernet1-4.core1.slc1.he.net (66.160.133.118)  160.445 ms  157.871 ms  157.533 ms
11  * * *
12  69-195-64-132.unifiedlayer.com (69.195.64.132)  146.778 ms  150.637 ms  157.859 ms
13  eev.eevblog.com (198.1.64.143)  146.326 ms  154.194 ms  153.916 ms

My guess is that routing fails when routed via 69.195.64.132 and succeeds through 69.195.64.42.

As you can see the trace above went via 69.195.64.132

Not sure what happened at hop 11

[Rigby]

Not sure what happened at hop 11

That router passes ICMP packets, but doesn't respond to them.

[splin]

grumpydoc:

Quite often the packets which traceroute uses get blocked at firewalls - very typically this is the last hop before the destination.

If I use traceroute normally I see the same pattern - however the linux version of the command has several options to control what packets are used for the probe so switching to UDP I get: (first few hops obfuscated)

# traceroute -U www.eevblog.com

Okay; tried that by booting Knoppix livelinux dvd. To tedious to copy 'traceroute -U' output but essentially the same as yours (well 10, 11 and 12 are the same) except it doesn't show the 13th,  www.eevblog.com. 13 onwards are timeouts as before.

Splin

[BravoV]

Not sure if this is related, lately I'm experiencing the forum page is not loading properly at every views, its like the browser is waiting for the page to finish but never did it, although the forum page was loaded properly. Same results from Opera and Chrome from PC Win X64 and Safari & Chrome from tablets.

[Bored@Work]

Not sure if this is related, lately I'm experiencing the forum page is not loading properly at every views, its like the browser is waiting for the page to finish but never did it, although the forum page was loaded properly. Same results from Opera and Chrome from PC Win X64 and Safari & Chrome from tablets.

This is a typically symptom for when some URL referenced by the page does not load or loads very slowly, like the supplyframe or doublecklick advertising, or the google-analytics stuff.

[EEVblog]

gnif has confirmed it's an external routing issue, nothign that can be done about it our our end I'm afraid.

[SeanB]

I still have a bug report with my ISP about that, and as it is an issue of an upstream provider it sux big time for those sites caught by it.  Affects for me SLJ's website.