Zen choice of routing via Manchester or London

Hi all,

I've been investigating checking latency to cloudflare recently (don't ask!) and I noticed that I'm talking to CF Manchester (which is all well and good, I'm North of Manchester) but with my PPPoE connection terminated at Zen London, this appears to adding a 5 - 10 ms delay in getting to CF, which is frustrating when I'm investigating the latency to CF, because it adds an extra unpredictable 25 - 50% to the latency which makes it pretty difficult to see anything useful when trying to measure my latency to cloudflare...

Does anyone know a way to change the PPPoE connection so that it terminates in Manchester instead (that would seem to make more sense to me regardless, but maybe there's a good reason for it)

Also if a kind soul who is physically near London and who's PPPoE terminates at Zen London could do a traceroute to cloudflare.com and see if they route to CF London or CF Manchester I'd be very grateful!

You could try and contact technical support, but I know they favour terminating stuff in London where they have more resources but if your data route is Manchester then maybe you got left behind after some maintenance or an outage.

I still have one line which is based in London but route Manchester. One of these days I will raise a ticket.

Trace from London cct terminating in London;

traceroute to cloudflare.com (198.41.214.162), 30 hops max, 60 byte packets
1 gateway (172.16.0.1) 0.336 ms 0.341 ms 0.368 ms
2 * * *
3 ae1-136.cr1.th-lon.zen.net.uk (62.3.86.145) 6.777 ms 7.481 ms 8.177 ms
4 vl-50.ae46.agg3.lond1.ptn.zen.net.uk (51.148.73.56) 10.220 ms 10.452 ms 11.351 ms
5 * * *
6 ae-13.cor2.manc1.ptn.zen.net.uk (51.148.73.25) 20.554 ms 20.813 ms 21.129 ms
7 ixmanchester.as13335.net (195.66.244.71) 22.100 ms 16.493 ms 17.040 ms
8 198.41.214.162 (198.41.214.162) 15.831 ms 14.489 ms 14.783 ms

From a cct in London but connected via Manchester;

traceroute to cloudflare.com (198.41.214.162), 30 hops max, 40 byte packets
1 gatekeeper (172.16.10.1) 0.341 ms 0.297 ms 0.304 ms
2 losubs.subs.dsl6.wh-man.zen.net.uk (62.3.83.21) 26.220 ms 27.685 ms 29.631 ms
3 ae1-127.cr2.wh-man.zen.net.uk (62.3.86.41) 30.850 ms 31.113 ms 32.325 ms
4 vl-50.ph-0-4-3.cor1.manc1.ptn.zen.net.uk (51.148.73.58) 34.286 ms 35.521 ms 36.507 ms
5 ae-22.cor2.manc1.ptn.zen.net.uk (51.148.73.42) 38.683 ms 38.939 ms 39.416 ms
6 ixmanchester.as13335.net (195.66.244.71) 40.157 ms 43.683 ms 44.874 ms
7 (198.41.214.162) 45.109 ms 26.656 ms *

Edited by IamQ (Mon 07-Jan-19 22:01:10)

Zen FTTP connection in Bucks terminating in London

1 <1 ms <1 ms <1 ms fritz.box [192.168.8.1]
2 5 ms 4 ms 4 ms vt1.cor2.lond1.ptn.zen.net.uk [51.148.72.22]
3 11 ms 11 ms 10 ms ae-13.cor2.manc1.ptn.zen.net.uk [51.148.73.25]
4 11 ms 11 ms 11 ms ixmanchester.as13335.net [195.66.244.71]
5 10 ms 10 ms 10 ms 198.41.215.162


As IamQ has stated, when this has been asked before, Zen have stated they have easier access to transit and peering in London.

This does make sense as there is a large concentration of data centres in the Docklands area so most ISPs and internet giants have equipment there so interconnects are short.

As in your case though, traffic gets backhauled to Manchester before handoff to Cloudflare, only Zen can answer why they do this as Cloudflare will have connections in London

Thanks to both of your for your replies, I'm still looking into this further; however the following might be of interest / use, particularly for techguy:

Connections to the vt1.cor2.lond1.ptn.zen.net.uk gateway peer with Cloudflare in Manchester (as you've seem)

Connections to the vt1.cor2.lond2.ptn.zen.net.uk gateway peer with Cloudflare in London, which reduced latency by close to 10ms in my testing.

Lond1 & Lond2 seems to be more or less randomly on reconnecting the PPPoE connection, whereas connecting to a London or a Manchester gateway appears to be set based on geography; but with a few geographical errors!


My investigations remain ongoing and I'll update this thread again if I discover anything else interesting!

Dynamic or static IP? See a change depending which gateway you connect through?

If it's the same IP address on your side it makes no sense at all to take you back to Manchester - routing should be straight out of Zen's network.

If different IPs makes more sense: you're at the mercy of geolocation.

I think all Zen users are static IP's arn't they ?

A looking-glass would be helpful here. I thought Zen may have a public one, but I can't see anything.

Edited by IamQ (Mon 14-Jan-19 00:43:27)

Ignitionnet: No, it doesn't make much sense. I think there's probably more to be discovered on all this yet

As far as I know, Zen is all static IP.

Best information I have at the moment is that this is tied into whether or not the Zen Plexus network is serving the exchange that the cabinet is connected to, in that the gateway can be changed to whichever of Manchester / London is geographically closer if Plexus is used, but not otherwise.

I'll update this thread again if I get any more interesting information.

I've just tested on a FTTC connection in Northamptonshire and get the following result:

Tracing route to cloudflare.com [198.41.215.162]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms *********** [10.***.***.*]
2 10 ms 10 ms 10 ms vt1.cor2.lond2.ptn.zen.net.uk [51.148.72.24]
3 10 ms 10 ms 11 ms ae-21.agg3.lond2.ptn.zen.net.uk [51.148.73.40]
4 11 ms 10 ms 10 ms linx-lon1.as13335.net [195.66.225.179]
5 10 ms 10 ms 10 ms 198.41.215.162

Trace complete.

Seems a lot less hops.

I've just run this again

1 <1 ms <1 ms <1 ms fritz.box [192.168.8.1]
2 41 ms 5 ms 5 ms vt1.cor2.lond2.ptn.zen.net.uk [51.148.72.24]
3 6 ms 6 ms 6 ms ae-21.agg3.lond2.ptn.zen.net.uk [51.148.73.40]
4 6 ms 6 ms 6 ms linx-lon1.as13335.net [195.66.225.179]
5 5 ms 5 ms 5 ms 198.41.214.162

and observed the same but I should note my connection goes via a BTW FTTP connection.

I can think of one very good reason for the difference you are seeing.

One would hope that lond1 and lond2 are actually separate pieces of kit located in different data centres.

Ordinarily both run to balance the load coming into the network from Zen's LLU feeds from it's own exchange kit as well as that from GEA FTTC/FTTP from BT.

It would make sense to have one device all set to send traffic 'long haul' via Manchester in case there were issues with peering and transit in London?

Just wild speculation I might add

Anybody who was interested in this thread will probably be interested in watching this video from UKNOF43: https://www.youtube.com/watch?v=MGTkxrIQXKQ&list=PLj...

In my experience as a Zen customer, who is located in the North West of England Connecting to Zen Via WBMC i connect to Manchester as you would expect , but if via their GEA link i get routed to London , this does not benefit me in terms of latency as well as the single thread throughput issues , why did they not route their GEA cable link to Manchester? not everything revolves around London, and nor should it ever do resilience is what is needed

Edited by tommy45 (Tue 23-Apr-19 00:59:53)

In reply to a post by tommy45:

In my experience as a Zen customer, who is located in the North West of England Connecting to Zen Via WBMC i connect to Manchester as you would expect , but if via their GEA link i get routed to London , this does not benefit me in terms of latency as well as the single thread throughput issues , why did they not route their GEA cable link to Manchester? not everything revolves around London, and nor should it ever do resilience is what is needed

That's one thing I think the video doesn't explain, how they are handling the Manchester/London split. They seemed to be focusing on their own LLU network.

What it does cover however, is that they obviously want to improve this by ultimately going full LLU so they have a more efficient and resilient network.