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