It's merely a network status probe for me, but the sudden leap in latency which has now been sustained for ~50 hours doesn't point to something healthy. When my ping to 8.8.8.8 was sitting around 120ms I could accept that as ordinary (if very average) connection latency. Now it's sitting another 40+ms higher. Until the weekend my latency right to the end was about the same as the latency I'm now seeing to the intermediate hop where it suddenly gets ugly.
If it's simply a routing change so be it, but it's one that's introduced a whole lot of extra latency.

On 17/09/2013 09:02, Liam Farr wrote:
You lot sure its not just being served from the USA rather than domestically or Sydney. If so I don't think there is any real problem with this. Not an optimised route sure, but that's Telstra/voda/hug's prerogative.  

If your using it for DNS resolution (its intended purpose), don't. Due to the anycast nature of 8.8.8.8 using it will break most regional CDN's and stuff like your Akamai will end up being served from somewhere close by like Singapore. 

Is there any real impact to your service, or have you just noticed "an interesting change in routing"?

--
Liam Farr
+64-22-6107884
+64-27-5222624

Sent from my iPhone

On 17/09/2013, at 8:55 AM, Tim Price <tim@initech.co.nz> wrote:

Same here on Telstra Fibre.

traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets
 1  192.168.64.254  1.129 ms  0.843 ms  1.355 ms
 2  10.255.1.9  0.512 ms  0.482 ms  0.500 ms
 3  192.168.255.1  0.855 ms  0.693 ms  0.702 ms
 4  203.97.40.1  18.487 ms  6.760 ms  3.610 ms
 5  218.101.61.50  2.832 ms  2.457 ms  2.185 ms
 6  203.98.50.2  11.479 ms  11.595 ms  11.396 ms
 7  203.98.50.251  12.533 ms  12.012 ms  12.252 ms
 8  203.98.42.18  12.438 ms  12.381 ms  12.312 ms
 9  203.109.130.33  13.124 ms  13.500 ms  13.398 ms
10  * * *
11  203.109.130.6  175.716 ms  173.951 ms  172.882 ms
12  209.85.249.3  191.824 ms  192.721 ms
    209.85.249.5  191.274 ms
13  209.85.250.64  191.326 ms
    209.85.250.66  191.357 ms  191.684 ms
14  216.239.49.198  195.631 ms
    72.14.232.63  199.293 ms
    216.239.49.198  195.777 ms
15  72.14.233.200  202.215 ms
    72.14.233.138  198.278 ms  198.168 ms
16  216.239.48.165  190.833 ms
    64.233.174.131  193.692 ms
    64.233.174.129  194.517 ms
17  * * *
18  8.8.8.8  190.718 ms  190.846 ms  190.563 ms

And on Telstra wholesale

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 40 byte packets
 1  218.185.224.129  0.594 ms  0.581 ms  0.570 ms
 2  218.185.224.65  1.111 ms  1.109 ms  1.098 ms
 3  203.167.136.129  15.814 ms  15.841 ms  15.977 ms
 4  203.98.42.18  15.974 ms  16.098 ms  16.096 ms
 5  203.109.130.33  17.088 ms  17.087 ms  17.083 ms
 6  * * *
 7  203.109.130.6  166.600 ms  166.643 ms  166.622 ms
 8  209.85.249.5  144.881 ms  144.961 ms  144.418 ms
 9  209.85.250.64  167.404 ms  167.395 ms 209.85.250.60  167.722 ms
10  216.239.49.198  167.142 ms 72.14.232.63  160.291 ms  160.214 ms
11  72.14.233.140  161.390 ms 72.14.233.200  185.323 ms 72.14.233.202  160.620 ms
12  216.239.48.167  163.625 ms  163.100 ms 216.239.48.165  186.152 ms
13  8.8.8.8  163.081 ms  163.295 ms  164.068 ms





On 17/09/2013, at 8:46 AM, Stephen Farrar <stephen@sf.net.nz> wrote:

Hi Matthew,

Not sure if this helps at all, but I get similar results from a TCL Cable connection here in Wellington:

traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets
 1  gateway (192.168.1.1)  0.956 ms  0.697 ms  0.635 ms
 2  * * *
 3  lo0.internet.ivpn.pe19.telstraclear.net (218.101.61.100)  11.469 ms  11.214 ms  9.799 ms
 4  ie2-g-0-0-0.telstraclear.net (203.98.50.2)  18.642 ms  20.183 ms  18.590 ms
 5  ge-0-2-0-1.xcore1.acld.telstraclear.net (203.98.50.251)  20.239 ms  23.168 ms  21.402 ms
 6  ge-0-2-0-914.xcore2.acld.telstraclear.net (203.98.42.18)  20.222 ms  20.372 ms  37.712 ms
 7  gi1-2.akl-grafton-bdr2.ihug.net (203.109.130.33)  32.948 ms  20.299 ms  19.991 ms
 8  * * *
 9  tu20232901.akl-grafton-core1.ihug.net (203.109.130.6)  150.555 ms  151.977 ms  151.098 ms
10  209.85.249.3 (209.85.249.3)  198.609 ms  200.060 ms  199.597 ms
11  209.85.250.64 (209.85.250.64)  199.295 ms
    209.85.250.66 (209.85.250.66)  195.563 ms
    209.85.250.64 (209.85.250.64)  198.689 ms
12  72.14.232.63 (72.14.232.63)  203.499 ms  203.307 ms
    216.239.49.198 (216.239.49.198)  200.577 ms
13  72.14.233.200 (72.14.233.200)  206.175 ms
    72.14.233.140 (72.14.233.140)  207.716 ms  209.516 ms
14  64.233.174.131 (64.233.174.131)  198.878 ms
    216.239.48.167 (216.239.48.167)  198.319 ms
    216.239.48.165 (216.239.48.165)  199.101 ms
15  * * *
16  google-public-dns-a.google.com (8.8.8.8)  433.268 ms  202.334 ms  198.946 ms

For reference, I'm on their 'WarpSpeed' 130Mbps connection.

Good luck getting it sorted!

Cheers,
Stephen


On 17 September 2013 08:25, Matthew Poole <matt@p00le.net> wrote:
Hi all

Breaking with recent tradition and discussing something related to the operation of the NZ tubes...

My employer has a TVH business fibre connection, and since around midnight Saturday/Sunday the latency to 8.8.8.8 (one of my Smokeping test subjects) has been consistently > 160ms.
mtr tells me:
|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                                firewall -    0 |  124 | 124 |    0 |    0 |    1 |    0 |
|                           203.167.222.5 -    1 |  120 | 119 |    0 |    2 |   51 |   51 |
| ge-0-2-0-1.xcore1.acld.telstraclear.net -    0 |  124 | 124 |    0 |    3 |   62 |    1 |
|ge-0-2-0-914.xcore2.acld.telstraclear.net -   0 |  124 | 124 |    0 |    3 |   48 |    2 |
|         gi1-2.akl-grafton-bdr2.ihug.net -    0 |  124 | 124 |    1 |    2 |   29 |   11 |
|                   No response from host -  100 |   24 |    0 |    0 |    0 |    0 |    0 |
|   tu20232901.akl-grafton-core1.ihug.net -    0 |  124 | 124 |  129 |  132 |  192 |  164 |
|                            209.85.249.5 -    0 |  124 | 124 |  176 |  178 |  242 |  200 |
|                           209.85.250.63 -    0 |  124 | 124 |  176 |  187 |  252 |  195 |
|                            72.14.232.63 -    0 |  124 | 124 |  181 |  183 |  246 |  199 |
|                           72.14.233.200 -    0 |  124 | 124 |  189 |  191 |  251 |  213 |
|                          216.239.48.165 -    0 |  124 | 124 |  179 |  182 |  244 |  197 |
|                   No response from host -  100 |   24 |    0 |    0 |    0 |    0 |    0 |
|          google-public-dns-a.google.com -    0 |  124 | 124 |  179 |  183 |  246 |  200 |
|________________________________________________|______|______|______|______|______|______|

The sudden latency jump at akl-grafton-core1.ihug.net kinda leaps out. Is anyone else seeing this? And is this something that the TVH admins are aware of? Please don't make me deal with helpdesk!

Cheers

--
Matthew Poole
"The difference between theory and practice is that
practice is easier in theory than theory is in practice"
_______________________________________________
NZNOG mailing list
NZNOG@list.waikato.ac.nz
http://list.waikato.ac.nz/mailman/listinfo/nznog

_______________________________________________
NZNOG mailing list
NZNOG@list.waikato.ac.nz
http://list.waikato.ac.nz/mailman/listinfo/nznog

_______________________________________________
NZNOG mailing list
NZNOG@list.waikato.ac.nz
http://list.waikato.ac.nz/mailman/listinfo/nznog


_______________________________________________
NZNOG mailing list
NZNOG@list.waikato.ac.nz
http://list.waikato.ac.nz/mailman/listinfo/nznog

--
Matthew Poole
"The difference between theory and practice is that
practice is easier in theory than theory is in practice"