There is UFB that works like UFB and then there's Vodafone's UFB.

Forums › One New Zealand (including Vodafone, WxC, Farmside) › There is UFB that works like UFB and then there's Vodafone's UFB.

1 | 2 | 3 | 4 | 5 | 6 | 7 | 8

637 posts

Ultimate Geek

Trusted

#1244042 22-Feb-2015 10:45

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.

Zeon

3916 posts

Uber Geek

Trusted

#1244096 22-Feb-2015 12:35

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!

Speedtest 2019-10-14

Lurch

1061 posts

Uber Geek

#1244098 22-Feb-2015 12:45

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.

AsylumSkitzo

13 posts

Geek
Inactive user

#1244119 22-Feb-2015 13:51

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.

yitz

2080 posts

Uber Geek

#1244126 22-Feb-2015 14:19

^ 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.

PenultimateHop

637 posts

Ultimate Geek

Trusted

#1244130 22-Feb-2015 14:31

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.

yitz

2080 posts

Uber Geek

#1244132 22-Feb-2015 14:35

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.

Quic Broadband

Move to New Zealand's best fibre broadband service (affiliate link). Free setup code: R587125ERQ6VE. Note that to use Quic Broadband you must be comfortable with configuring your own router.

FierceGuppy

134 posts

Master Geek

#1244148 22-Feb-2015 15:02

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.

yitz

2080 posts

Uber Geek

#1244175 22-Feb-2015 15:15

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.

PenultimateHop

637 posts

Ultimate Geek

Trusted

#1244201 22-Feb-2015 15:51

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.

FierceGuppy

134 posts

Master Geek

#1244215 22-Feb-2015 16:04

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.

FierceGuppy

134 posts

Master Geek

#1244219 22-Feb-2015 16:10

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?

PenultimateHop

637 posts

Ultimate Geek

Trusted

#1244234 22-Feb-2015 16:21

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.

FierceGuppy

134 posts

Master Geek

#1244245 22-Feb-2015 16:48

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?

PenultimateHop

637 posts

Ultimate Geek

Trusted

#1244255 22-Feb-2015 17:04

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