In reply to a post by candlerb:

Oh, it would also be interesting if the TBB people could post the results of:

* traceroute 212.23.1.19
* traceroute6 2a02:8010::1

Not sure what the use is, but here you go!

Tracing route to lo0.dr1.lr-slo.zen.net.uk [2a02:8010::1]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 2a02:8010:xxxx:0:f29f:c2ff:fe11:2d8
2 4 ms 4 ms 4 ms lo-0.cor2.lond1.ptn.zen.net.uk [2a02:8010::101]
3 12 ms 10 ms 10 ms ae-13.cor2.manc1.ptn.zen.net.uk [2a02:8010:0:b00::8]
4 11 ms 9 ms 9 ms ae-22.cor1.manc1.ptn.zen.net.uk [2a02:8010:0:b00::15]
5 9 ms 9 ms 9 ms 2a02:8010:0:900::
6 16 ms 12 ms 10 ms xe-0-2-0.cr1.th-lon.zen.net.uk [2a02:8010:0:6::2]
7 9 ms 9 ms 9 ms 2a02:8010:0:404::18
8 10 ms 10 ms 10 ms lo0.dr1.lr-slo.zen.net.uk [2a02:8010::1]


Tracing route to smarthost03.mail.zen.net.uk [212.23.1.19]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms Unifi-DPI-Monitor [xxxxxxxxx]
2 3 ms 3 ms 3 ms vt1.cor2.lond1.ptn.zen.net.uk [51.148.72.22]
3 4 ms 3 ms 3 ms ae-10.agg3.lond1.ptn.zen.net.uk [51.148.73.18]
4 3 ms 3 ms 3 ms vl-50.ae6.cr1.th-lon.zen.net.uk [51.148.73.57]
5 5 ms 3 ms 7 ms ae2.cr2.th-lon.zen.net.uk [62.3.84.246]
6 4 ms 4 ms 4 ms xe-2-0-0-173.dr2.lr-slo.zen.net.uk [62.3.80.106]
7 4 ms 4 ms 4 ms smarthost03.mail.zen.net.uk [212.23.1.19]


OK, I think I get what you mean. It takes 'much' longer with IPv6?

> Not sure what the use is, but here you go!

Ah... sorry, it seems I was rather unclear. I was asking for the people who *run* the TBB speedtest server, to do traceroutes to IP addresses inside Zen and post them.

Traceroutes from BT customers to Zen IPs, or Zen customers to Zen IPs, aren't that interesting - except that they do highlight that v4 and v6 often take different paths.

If you are a TBB forum *user*, then what's interesting is the traceroutes to TBB's speedtest server. Now for me, it's these addresses:

* traceroute 80.249.103.8
* traceroute 2a02:68:1:4::2

But if TBB has multiple speedtest servers at different physical locations, then your speedtest may use a different one. One way to find out is to run wireshark or tcpdump to find the remote IP for the test traffic.

Those traceroutes will show the path that your *upload* traffic takes to the TBB speedtest server. To see the *download* path, TBB need to generate traceroutes from their server. It would be cool if they put up a looking glass, or a perfsonar node (which does that, and a lot more)

We run multiple test servers but on the same network in the same datacentre.

I've posted already ipv4 over direct peer, ipv6 via LONAP

My thoughts.

ipv4 vs ipv6, these dont necessarily traverse the same route, could be different transit/peering routes, so different latency patterns as well as congestion conditions.

At higher speeds, you become more likely to hit RWIN and other type of bottlenecks so not hitting the optimal speed is not necessarily congestion, the higher the speed, the more muddy the water gets.

On the USG have you got hardware offloading turned on for IPV6 as well as IPV4?

I also know with my EdgeRouter, its internal throughput was the limiting factor with QoS/SmartQueues enabled.

It would be worth running the tests without the USG in place to eliminate its configuration as an issue.

Simon

In reply to a post by SJHambly:

On the USG have you got hardware offloading turned on for IPV6 as well as IPV4?

I also know with my EdgeRouter, its internal throughput was the limiting factor with QoS/SmartQueues enabled.

It would be worth running the tests without the USG in place to eliminate its configuration as an issue.

Simon

Simon, hm... I don�t think I can change that in the GUI. Good question, I just assumed it is done by hardware offloading (like for IPv4, smartqueue is turned off here)