Geekzone: technology news, blogs, forums
Guest
Welcome Guest.
You haven't logged in yet. If you don't have an account you can register now.


Filter this topic showing only the reply marked as answer View this topic in a long page with up to 500 replies per page Create new topic
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8
637 posts

Ultimate Geek
+1 received by user: 2

Trusted

  Reply # 1244042 22-Feb-2015 10:45
Send private message

FierceGuppy:
johnr: Confused where which hop/s?


202.84.223.85
202.84.140.242
202.84.251.98

Google for "IP locator".


Those routers are in California. IP locators are giving you registration data, not physical location of the router. If the traffic was actually traversing HKG you would see significantly higher end-to-end latency (13000 mile path vs. 6500 mile path at ~120000 miles per second gives you 108ms vs 216ms RTT).

As for the two different Vodafone UFB services giving different performances, one is clearly on the legacy TelstraClear network with its associated upstream connectivity and one is on the Vodafone network with its separate upstream connectivity. The two networks are not really merged at all; thus the performance is significantly different.

3422 posts

Uber Geek
+1 received by user: 410

Trusted

  Reply # 1244096 22-Feb-2015 12:35
Send private message

johnr: Hong Kong is in Hong Kong and China is it's own country, I have visited both

Hong Kong use to be under British rule but I am sure then it was not in Britain and still in the same location as it is now

So the traffic is going via Hong Kong

John


Hong Kong is China these days!






 
 
 
 


1054 posts

Uber Geek
+1 received by user: 71


  Reply # 1244098 22-Feb-2015 12:45
Send private message

Watching twitch.tv fine (also streaming HD netflix on the Roku in the lounge ;-)) on a lowly ADSL2+ connection through Vodafone. Tracert below...

Twitch.tv

Tracing route to video3.sfo01.justin.tv [199.9.253.233]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2    41 ms    37 ms    23 ms  be2-100.bras1ftc.akl.vf.net.nz [203.109.129.37]
  3    55 ms   128 ms    78 ms  be5-100.ppnzftc01.akl.vf.net.nz [203.109.129.38]
  4    23 ms    23 ms    38 ms  be7-188.ppnzftc02.akl.vf.net.nz.180.109.203.in-addr.arpa [203.109.180.226]
  5    28 ms    22 ms    29 ms  be8-188.ppnzftc02.akl.vf.net.nz.180.109.203.in-addr.arpa [203.109.180.225]
  6   183 ms   151 ms   192 ms  10.123.80.69
  7   149 ms   163 ms   199 ms  v407.core1.sjc1.he.net [216.218.254.57]
  8   305 ms   166 ms   148 ms  10ge1-4.core1.pao1.he.net [72.52.92.113]
9     *        *        *     Request timed out.
 10     *        *        *     Request timed out.
 11     *        *        *     Request timed out.
 12   etc......


Battlefield...

Tracing route to gsd3.cmg.internode.on.net [203.26.94.188]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2    34 ms    69 ms    69 ms  be2-100.bras1ftc.akl.vf.net.nz [203.109.129.37]

  3   107 ms   110 ms    68 ms  be5-100.ppnzftc01.akl.vf.net.nz [203.109.129.38]

  4    23 ms    26 ms    23 ms  be7-188.ppnzftc02.akl.vf.net.nz.180.109.203.in-a
ddr.arpa [203.109.180.226]
  5    31 ms    23 ms    37 ms  be8-188.ppnzftc02.akl.vf.net.nz.180.109.203.in-a
ddr.arpa [203.109.180.225]
  6     *        *        *     Request timed out.
  7    56 ms    48 ms    55 ms  as4739.syd.equinix.com [202.167.228.20]
  8    93 ms    87 ms   105 ms  ae3.cr1.mel8.on.ii.net [150.101.33.27]
  9    89 ms    73 ms    70 ms  ae0.cr1.mel4.on.ii.net [150.101.33.10]
 10   132 ms   117 ms    71 ms  ae1.cr1.adl2.on.ii.net [150.101.33.41]
 11   112 ms    81 ms   122 ms  ae0.cr1.adl6.on.ii.net [150.101.33.3]
 12    96 ms   114 ms   111 ms  te7-2.cor1.adl6.on.ii.net [150.101.225.230]
 13   124 ms   120 ms   123 ms  gsd3.cmg.internode.on.net [203.26.94.188]

Trace complete.

Wish I kept the ones for Bigpipe ADSL they were shocking, video stuttering, buffering issues and more. I wont use chorus gear again on ADSL.

13 posts

Geek
+1 received by user: 2
Inactive user


  Reply # 1244119 22-Feb-2015 13:51
Send private message

WoT US West server traceroute (increased from 170 to 310 ms):

>tracert 162.213.61.57

Tracing route to us3-slave-57.worldoftanks.com [162.213.61.57]
over a maximum of 30 hops:

  1     *        *        *     Request timed out.
  2    12 ms     9 ms     9 ms  lo0.internet.ivpn.pe25.telstraclear.net [218.101
.61.124]
  3    18 ms    16 ms    18 ms  ie2-g-0-0-0.telstraclear.net [203.98.50.2]
  4    20 ms    18 ms    17 ms  ge-0-2-0-1.xcore1.acld.telstraclear.net [203.98.
50.251]
  5    21 ms    35 ms    22 ms  unknown.telstraglobal.net [134.159.174.41]
  6   148 ms   146 ms   143 ms  i-0-0-4-1.tlot-core01.bx.telstraglobal.net [202.
84.142.106]
  7   175 ms   175 ms   175 ms  i-0-4-0-8.eqnx-core01.bi.telstraglobal.net [202.
84.140.242]
  8   213 ms   211 ms   211 ms  202.84.249.33
  9   280 ms   277 ms   288 ms  202.84.143.234
 10   277 ms   275 ms   277 ms  202.40.148.50
 11   275 ms   276 ms   278 ms  4.68.111.205
 12   309 ms   310 ms   312 ms  ae-3-80.edge2.SanJose1.Level3.net [4.69.152.143]

 13   309 ms   309 ms   309 ms  ae-3-80.edge2.SanJose1.Level3.net [4.69.152.143]

 14   310 ms   309 ms   311 ms  WARGAMING-I.edge2.SanJose1.Level3.net [4.79.238.
114]
 15   308 ms   309 ms   309 ms  92.223.120.163
 16   311 ms   309 ms   310 ms  us3-slave-57.worldoftanks.com [162.213.61.57]

Trace complete.

1292 posts

Uber Geek
+1 received by user: 295


  Reply # 1244126 22-Feb-2015 14:19
Send private message

^ Auckland-->San Jose via London  and for  Battlefield Auckland-->Sydney via Tokyo... seems your classic tier-1 internet routing as they own all the fibre optic cables they don't care about efficient routes.

Although interesting to note it's affecting gaming services, they often employ DDoS mitigation techniques some of which can result in suboptimal routing especially amongst your non-open-peering & tier-1 providers.

637 posts

Ultimate Geek
+1 received by user: 2

Trusted

  Reply # 1244130 22-Feb-2015 14:31
Send private message

yitz: ^ Auckland-->San Jose via London  and for  Battlefield Auckland-->Sydney via Tokyo... seems your classic tier-1 internet routing as they own all the fibre optic cables they don't care about efficient routes.

Where do you see it going via London? Auckland to London is close to 300ms on a good day, which would make Auckland - London - San Jose in excess of 500ms. This looks like a congested interface, or a sub-optimal return path - the outbound path looks fine.

1292 posts

Uber Geek
+1 received by user: 295


  Reply # 1244132 22-Feb-2015 14:35
Send private message

Historical DNS PTR records show ulco.telstraglobal.net for that 202.40.148.50 hop for which "ulco" is some PoP in the UK I believe.
Not sure what's happened to telstraglobal.net DNS, seems they have rate limited it so intermittent resolution/caching.

The return route is fine (you can probably check at lg.wargaming.net), so RTT is effectively a round trip to UK since UK goes via San Jose for most anyway.



129 posts

Master Geek
+1 received by user: 7


  Reply # 1244148 22-Feb-2015 15:02
Send private message

The status of Vodafone/Telstra's network routing today:  Wholly Incompetent.

C:\Windows\system32>tracert 103.231.88.75

Tracing route to 103.231.88.75 over a maximum of 30 hops

1 <1 ms <1 ms <1 ms 192.168.0.1
2 * * * Request timed out.
3 10 ms 10 ms 9 ms 218.101.61.101
4 26 ms 25 ms 25 ms ie2-g-0-0-0.telstraclear.net [203.98.50.2]
5 31 ms 22 ms 23 ms ge-0-2-0-1.xcore1.acld.telstraclear.net [203.98.50.251]
6 25 ms 27 ms 25 ms 134.159.174.37
7 149 ms 152 ms 162 ms 202.84.142.106
8 149 ms 159 ms 150 ms 202.40.149.182
9 148 ms 151 ms 148 ms gtt-peer.tlot02.pr.telstraglobal.net [134.159.61.98]
10 153 ms 149 ms 150 ms giglinx-gw.ip4.gtt.net [199.229.229.10]
11 151 ms 149 ms 149 ms 192.184.12.13
12 180 ms 180 ms 181 ms 208.64.123.97
13 210 ms 209 ms 210 ms 103.231.88.75

Trace complete.

Who's the moron who gets to decide where traffic meant for New South Wales goes from 134.159.174.37?

Incompetent routing.




1292 posts

Uber Geek
+1 received by user: 295


  Reply # 1244175 22-Feb-2015 15:15
Send private message

If you lookup 192.184.12.13 and 208.64.123.97 they are the IPs for a DDoS mitigation provider, maybe the Vodafone  UFB network has been considered amongst sources of the DDoS?

DDoS mitigation and filtering will always mean a crappy route as there is not enough submarine capacity into the Australasian region so has to be coordinated overseas in at high capacity near global internet exchange points.

637 posts

Ultimate Geek
+1 received by user: 2

Trusted

  Reply # 1244201 22-Feb-2015 15:51
Send private message

yitz: Historical DNS PTR records show ulco.telstraglobal.net for that 202.40.148.50 hop for which "ulco" is some PoP in the UK I believe.
Not sure what's happened to telstraglobal.net DNS, seems they have rate limited it so intermittent resolution/caching.

The interesting thing is that 202.40.148.50 is ~130ms from San Jose and ~270ms from London (using an observation point that I have in each location, which are on networks that peer with AS4637 in each location).

The problem with their DNS is that the delegation for 148.40.202.in-addr.arpa points to ns03.net.reach.com which no longer exists. ns03.telstraglobal.net will answer if you give it direct queries.
host$ dig +short @ns03.telstraglobal.net 49.148.40.202.in-addr.arpa ptr
i-0-4-0-13.ulco-core02.bi.telstraglobal.net.
host$ dig +short @ns03.telstraglobal.net 50.148.40.202.in-addr.arpa ptr
i-1-0-0.ams01-grx.bi.telstraglobal.net. However, DNS isn't particularly trustworthy since linknets get reused all the time without DNS being updated. It's at best, a hint.

vitz: The return route is fine (you can probably check at lg.wargaming.net), so RTT is effectively a round trip to UK since UK goes via San Jose for most anyway.

Without knowing the source address it is challenging to validate the exact return, but picking a return from wargaming.net's Silicon Valley location to 203.98.50.2 does not go via London, although it confirms there is a problem (latency as it hits AS4637 jumps to 137ms).

I suppose from a latency perspective it is actually possible to be tromboning via London, from where I sit in Sunnyvale right now, some of those routers are latency close to me (i.e. not in the UK, or Hong Kong), but others are not. If it is going via London, then 300ms is actually pretty impressive for end-user latency given the one-way trip times required for each segment. 

Edit: Actually, I'll concede it is going via the UK. But it's not traversing Hong Kong. As for "which moron decides", normally it's a routing protocol on a router. It's not like a person sits there and individually makes routing decisions.



129 posts

Master Geek
+1 received by user: 7


  Reply # 1244215 22-Feb-2015 16:04
Send private message

yitz: If you lookup 192.184.12.13 and 208.64.123.97 they are the IPs for a DDoS mitigation provider, maybe the Vodafone  UFB network has been considered amongst sources of the DDoS?

DDoS mitigation and filtering will always mean a crappy route as there is not enough submarine capacity into the Australasian region so has to be coordinated overseas in at high capacity near global internet exchange points.


I don't know where you found that information.  In any case, the worst hop by far is between the addresses I highlighted, which is 124ms.




129 posts

Master Geek
+1 received by user: 7


  Reply # 1244219 22-Feb-2015 16:10
Send private message

PenultimateHop:
yitz: Historical DNS PTR records show ulco.telstraglobal.net for that 202.40.148.50 hop for which "ulco" is some PoP in the UK I believe.
Not sure what's happened to telstraglobal.net DNS, seems they have rate limited it so intermittent resolution/caching.

The interesting thing is that 202.40.148.50 is ~130ms from San Jose and ~270ms from London (using an observation point that I have in each location, which are on networks that peer with AS4637 in each location).

The problem with their DNS is that the delegation for 148.40.202.in-addr.arpa points to ns03.net.reach.com which no longer exists. ns03.telstraglobal.net will answer if you give it direct queries.
host$ dig +short @ns03.telstraglobal.net 49.148.40.202.in-addr.arpa ptr
i-0-4-0-13.ulco-core02.bi.telstraglobal.net.
host$ dig +short @ns03.telstraglobal.net 50.148.40.202.in-addr.arpa ptr
i-1-0-0.ams01-grx.bi.telstraglobal.net. However, DNS isn't particularly trustworthy since linknets get reused all the time without DNS being updated. It's at best, a hint.

vitz: The return route is fine (you can probably check at lg.wargaming.net), so RTT is effectively a round trip to UK since UK goes via San Jose for most anyway.

Without knowing the source address it is challenging to validate the exact return, but picking a return from wargaming.net's Silicon Valley location to 203.98.50.2 does not go via London, although it confirms there is a problem (latency as it hits AS4637 jumps to 137ms).

I suppose from a latency perspective it is actually possible to be tromboning via London, from where I sit in Sunnyvale right now, some of those routers are latency close to me (i.e. not in the UK, or Hong Kong), but others are not. If it is going via London, then 300ms is actually pretty impressive for end-user latency given the one-way trip times required for each segment. 

Edit: Actually, I'll concede it is going via the UK. But it's not traversing Hong Kong. As for "which moron decides", normally it's a routing protocol on a router. It's not like a person sits there and individually makes routing decisions.



By routing protocol do you mean routing table?  If so, some individual set it that way, didn't they?


637 posts

Ultimate Geek
+1 received by user: 2

Trusted

  Reply # 1244234 22-Feb-2015 16:21
One person supports this post
Send private message

No. A routing protocol (such as OSPF, IS-IS and BGP) contributes to the routing table (RIB). Humans may configure the protocol (and associated policies such as metrics, cost, etc), but the protocols themselves exchange routes and determine the best paths. A final RIB is calculated and then pushed to the FIB.

There are >580K routes that make up the Internet DFZ. No human would ever make anything other than macro decisions on it - the protocols do the rest.

Occasionally, things happen that can cause sub-optimal decisions to be made. None of the protocols I mention use latency as an input, so they're making the best decision they can given the decision criteria they use.




129 posts

Master Geek
+1 received by user: 7


  Reply # 1244245 22-Feb-2015 16:48
Send private message

PenultimateHop: No. A routing protocol (such as OSPF, IS-IS and BGP) contributes to the routing table (RIB). Humans may configure the protocol (and associated policies such as metrics, cost, etc), but the protocols themselves exchange routes and determine the best paths. A final RIB is calculated and then pushed to the FIB.

There are >580K routes that make up the Internet DFZ. No human would ever make anything other than macro decisions on it - the protocols do the rest.

Occasionally, things happen that can cause sub-optimal decisions to be made. None of the protocols I mention use latency as an input, so they're making the best decision they can given the decision criteria they use.




Why would a routing protocol not take latency into consideration when deciding the most optimal route?


637 posts

Ultimate Geek
+1 received by user: 2

Trusted

  Reply # 1244255 22-Feb-2015 17:04
Send private message

Routing protocols are designed to convey topology and reachability, not latency information (which is constantly variable, not 'point-in-time').

Given the size of a computed routing table, AND that it would have to consider various source/destination pairings, this is totally impractical for a transit node.

There are companies out there (InterNAP, Noction) that have technology and products to add latency/packet loss into routing decisions as offline TE tools.

1 | 2 | 3 | 4 | 5 | 6 | 7 | 8
Filter this topic showing only the reply marked as answer View this topic in a long page with up to 500 replies per page Create new topic



Twitter »

Follow us to receive Twitter updates when new discussions are posted in our forums:



Follow us to receive Twitter updates when news items and blogs are posted in our frontpage:



Follow us to receive Twitter updates when tech item prices are listed in our price comparison site:



Geekzone Live »

Try automatic live updates from Geekzone directly in your browser, without refreshing the page, with Geekzone Live now.


Geekzone Live »

Our community of supporters help make Geekzone possible. Click the button below to join them.

Support Geezone on PressPatron



Are you subscribed to our RSS feed? You can download the latest headlines and summaries from our stories directly to your computer or smartphone by using a feed reader.

Alternatively, you can receive a daily email with Geekzone updates.