Hey!Broadband High Latency to Specific Network

I had Hey Broadband installed on Friday - thanks to everyone here for the information on what to expect 👍

I have an issue where the latency to/from the leased line at work is much higher than expected

If I ping my HB IP address from various connections I get the following results

Office LL - 55ms
Trooli FTTP - 10ms
Talk Talk FTTP - 11ms
Talk Talk FTTC - 13ms

(These number are similar if I ping from my HB connection, all the services are located in the South East)

What would cause the route between our Office LL and HB to have such a high latency? and who should I be talking too to try and get it resolved?

TIA
John

Use a tool like MTR to compare routes. That'll show where the latency is being added.

As has been mentioned, do a traceroute and put the results here. An indication of where you are physically located would be good as well.

In terms of what you can do about it, probably nothing - residential broadband has no latency SLA and a consistent 55ms is not going to cause you any problems.

Is that ping direct to Office Network appliance, or is it ping over a tunnel (VPN/SSH) to the Office.

Really 55ms isn't that long.

You should be able to do voice comms without an issue.

The more important number is data transfer rate ie Mbps. Let say got large file to download and it 1GB, if transfrate will take
1Mbit = 02h:13m
5Mbit = 00h:26m
10Mbit = 00h:13m

https://www.omnicalculator.com/other/data-transfer

Thank you, that is a new tool to me

https://photos.app.goo.gl/r9FMQZ74YAwyfikH8

Here is the trace, both endpoints are located in the South East of England

1 <1 ms <1 ms <1 ms x.x.x.x
2 3 ms 2 ms 1 ms x.x.x.x
3 6 ms 2 ms 2 ms 172.26.0.122
4 2 ms 1 ms 2 ms 185.246.132.8
5 3 ms 3 ms 3 ms 185.246.132.5
6 3 ms 3 ms 3 ms te0-2-1-15.rcr51.lon10.atlas.cogentco.com [149.11.23.193]
7 3 ms 3 ms 3 ms be2592.ccr42.lon13.atlas.cogentco.com [154.54.60.245]
8 10 ms 10 ms 9 ms be12489.ccr42.par01.atlas.cogentco.com [154.54.57.70]
9 26 ms 26 ms 25 ms be2318.ccr32.bio02.atlas.cogentco.com [154.54.61.117]
10 36 ms 25 ms 25 ms be2325.ccr32.mad05.atlas.cogentco.com [154.54.61.134]
11 25 ms 25 ms 25 ms 149.14.243.210
12 * * * Request timed out.
13 * * * Request timed out.
14 45 ms 45 ms 45 ms 194.35.42.13
15 * * * Request timed out.
16 51 ms 51 ms 51 ms x.x.x.x

Trace complete.

I am talking to the Leased Line supplier, as you say I am more likely to get some traction with them if the routing issue is in their network

Edited by john_32 (Tue 10-Oct-23 14:10:26)

The ping is direct public IP to Public IP, although pinging through a VPN tunnel gives similar results as expected.

Pinging 192.168.240.1 with 32 bytes of data:
Reply from 192.168.240.1: bytes=32 time=52ms TTL=63
Reply from 192.168.240.1: bytes=32 time=51ms TTL=63
Reply from 192.168.240.1: bytes=32 time=52ms TTL=63
Reply from 192.168.240.1: bytes=32 time=52ms TTL=63

Transfer rate is where I would expect it (peaking around 200Mbps) which is the limitation of the leased line.

That's good news if we have to live with the 55ms, just made me question if there is a routing issue and therefore best to get it addressed.

Traffic is going London > Paris > Bilbao? > Madrid > London
Hence the unexpected latency, my own non-Hey connection goes via LINX to 194.35.42.13 with minimal latency much like your Trooli/TalkTalk connections probably do.

You could see if the other direction is a similar path via Cogent.

There is not much you can do but I expect your leased line supplier is your best bet to see they can do anything or persuade Cogent to change the route.

I expect I'll be a strugle to speak to anyone at Hey who will have any idea about routing or be willing do do anything about it.

Surprisingly it doesn't look like Hey!Broadband peer at LINX or LONAP.

I don't know much of anything about routing but it's not the first time I've seen Cogent take strange paths, not sure if it's on purpose because it's cheaper.

The routing/peering of altnets does seem to be a weak point.

edit: Looks like maybe Hey use AS207645 whos only upstream is at linx/lonap so maybe something can be done if LL is also there

Edited by miken06 (Tue 10-Oct-23 16:33:08)

Thank you for the explanation - the distance travelled is not ideal

This is the trace from HB to LL - very different nodes but a similar latency

1 5.181.99.3 (5.181.99.3) 5.893 ms 5.797 ms 5.748 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 et-0-0-0-0.cr4-mad5.ip4.gtt.net (212.222.26.41) 35.047 ms 34.977 ms 34.870 ms
7 ae33.cr0-lon1.ip4.gtt.net (89.149.137.105) 52.333 ms 52.965 ms 53.089 ms
8 ip4.gtt.net (46.33.86.166) 49.465 ms 49.521 ms 49.449 ms
9 185.246.132.9 (185.246.132.9) 50.467 ms 50.254 ms 50.517 ms
10 * * *
11 x.x.x.x 50.594 ms 50.580 ms 50.637 ms

It looks like GTT does the same trip to Spain as Cogent in the other direction.

I'd give your LL provider a chance to improve it, probably by contacting those involved themselves.

As a work around you could use a VPN to somewhere that has a better connection between Hey and the LL but would depend on your works policy to VPNs and/or your ability to roll your own via a hosting provider - I'd probably advise against such option unless you know what you're doing, wouldn't want to leave a backdoor into your office network!

Traffic looks like it's going via Paris, Bilbao, Madrid which is wrong. It's happening within Cogent's network though so you will need your supplier to take it up with them.

In reply to a post by miken06:

Surprisingly it doesn't look like Hey!Broadband peer at LINX or LONAP.

edit: Looks like maybe Hey use AS207645 whos only upstream is at linx/lonap so maybe something can be done if LL is also there

A lot of these startup ISPs begin by just taking transit from someone like Cogent (ugh). Many of them will then actually look to peer but some seem happy to leave traffic going to say Google going out via their upstream internet provider.

Lit Fibre (my ISP) are similar, they peer with Google but not Microsoft for some reason, though their peering has been steadily improving which is positive, and their transit provider seems to be Zayo rather than a truly garbage-tier option.

I did some digging out of curiosity on this, looks like the office leased line is from F&W Networks (AS207645) based on the first hop of the traceroute who appear to only have "Near IP" as their sole upstream provider who seem to be a Spanish company. Near IP are on LINX so anyone Near IP peer with (and they appear to be on the route servers, so they'll have good coverage) will have decent latency but it seems like anyone they don't peer with is likely taken to Spain, where GTT/Cogent interconnect.

In this case I think the issue can't be blamed on Cogent, and more on F&W's choice of upstream provider. Hey broadband not being on LINX isn't a negative in my eyes. LINX isn't as cost effective as it once was, so I can understand someone not wanting the bother of peering but Hey Broadband should have a second provider.

Thanks for taking an interest

The FTTP is Hey Broadband and F&W Networks the Office Leased Line is provided by Adept (now part of Wavenet)

Very frustrating that the one IP address I really need has this inefficient route!

Most others I try are sub 10ms

Both Adept & HB are looking into the issue - fingers crossed

If you are connected via HB it would be helpful if you could ping 185.246.132.9 and report the result?

PING 185.246.132.9 (185.246.132.9) 56(84) bytes of data.
64 bytes from 185.246.132.9: icmp_seq=1 ttl=243 time=51.9 ms
64 bytes from 185.246.132.9: icmp_seq=2 ttl=243 time=52.0 ms
64 bytes from 185.246.132.9: icmp_seq=3 ttl=243 time=52.1 ms
64 bytes from 185.246.132.9: icmp_seq=4 ttl=243 time=52.1 ms
64 bytes from 185.246.132.9: icmp_seq=5 ttl=243 time=52.3 ms
64 bytes from 185.246.132.9: icmp_seq=6 ttl=243 time=52.1 ms

HB seem to be convinced it is a problem at my end
TIA

Hey / F and W is / was a Spanish company and their network management is / was done in Spain. Not sure who actuall owns it since Foresight got involved.

You can do a couple of traces from probes on the Hey/F&W network at https://bgp.he.net/AS207645#_traceroute but they'll also be via Spain.

As jcre said, it looks like traffic Hey don't peer with in London they rely on AS49600/NEAR IP a Spanish company who interconnect with thier upstreams such as Cogent and GTT in Spain.

Then Adept don't publically peer very much, upstream with Cogent/GTT so the only option is to go via via Spain (or private peering)

There is probably not much that can be done, Hey/F&W could interconnect with their upstreams in the UK but they've gone through the trouble of doing it via Spain so it seems this is how they want it setup.
The other option is for Hey & Adept to setup private peering, which again seems unlikely given the amount of traffic likely to pass between them.

It's a really difficult 'problem' to get ISPs to fix, most would regard 50ms latency good enough and make no guarantees on latency, hence I think you'd have more luck getting Adept to try to find a solution.

The IRR record suggests F&W might have SSE transit too, but as SSE (now Neos) don't sell burstable IP transit, I can understand why F&W might have it turned off. So unfortunately I think not masses that can be done unless F&W or Near IP bring on additional transit in London.

That being said, F&W should really have another active upstream. Although it could be F&W aren't actually in any actual datacentres so they may literally have to order in an Ethernet circuit to add additional capacity