|
|
|
Since switching to cityfibre I've been mostly connected to one of the Manchester BNGs (despite living very much in the south, and orders of magnitude closer to London than Manchester).
Now we all saw this before on BT FTTC and you could just bounce and more often than not end up on a London PPPoE endpoint and solve all your problems.
But for me at least on cityfibre, that's not been the case. I was first connecting to Manchester BNGs and I could see that (as would make sense) the BNG first hop was 8ms and then almost everything of course routes via London and had a 15ms ping.
So, after a while of waiting for it to fix itself, I sat down and bounced the connection until I got a telehouse north BNG connection. Great, right?
Well, no. It seems that either cityfibre or Zen are routing me to Manchester behind the scenes. Now, first hop is the telehouse north BNG with 15ms RTT.
I was wondering if anyone else is seeing this. I was also wondering if a factory reset of the ONT might do something (seems like a long shot, but perhaps it stores some cityfibre node it connects to).
It's minor in the scheme of things, and I'm not THAT bothered. But of course if I could get a lower RTT I'd not say no.
|
|
|
Did you ever manage to get this sorted as I think it's happened to me now? Last night the router dropped my CityFibre Zen connection briefly at around 2:30am and now I'm connecting via Manchester despite being in Berkshire.
You can see the result on the BQM graph below. I tried rebooting the ONT and router a couple of times at around 11am.
My Broadband Ping
I have VPN connections to two locations in Finland and today the connection speed to the two locations has dropped from about 45Mbps to 25Mbps. Not sure if that's just a coincidence.
|
|
|
|
I'm afraid not. Also, it seems they've made it much much much less likely to end up on a London BNG if it sees you as coming in from Manchester.
I put in a support ticket about it. Mainly because, with more people connecting at these speeds if it's quite common it's really going to put a lot of pressure on their internal connection between Manchester and London. Almost all of my traffic goes from my location (not far from Heathrow airport) to Manchester and then back down to telehouse and out to the internet.
I got a really good detailed response, essentially saying they're aware of the problem and there's not much they can do about it right now. I replied thanking the guy for the detailed response. At which point I got a rather obtuse reply telling me that 20ms is "fine" and I shouldn't be complaining. Someone that clearly didn't read the content of my ticket at all. Since if they did, they would have seen I was more concerned with the traffic beting routed up/down the country on already congested links unnecessarily.
So, support at Zen has become a bit chequered, it seems. You either get excellent, or pretty much dire responses now, it seems.
I've tried the following to see if it helped. None did.
- Reset PPP session until getting London based BNG. As mentioned before, this just results in the same ping, but it looks like you're directly connected to London. I get a better speedtest (always >900) this way. But no difference in ping.
- Disconnect router and ONT for 1hr+. This resulted in no change.
- Resetting ONT using the reset pinhole. This resulted in no change.
This seems to be a cityfibre/zen problem that, I'm sure they MUST be noticing since my speedtests vary wildly when connected to Manchester. Anything from 600-900 on downstream but generally 900+ on upstream. It really suggests their internal connectivity is being impacted by this problem. But if I do manage to get onto a London BNG (as I say, it is pretty much almost impossible last time I tried), I get more consistent speeds. But, I suspect now the load is somehow on cityfibre's end?
Like I say, right now, it's a minor problem. 20ms IS a decent latency and nothing to complain about, even in FPS games. But, the longer term impact as they sign up more customers, if there's many being routed this way is my concern. And as I say I already see it in speed test results.
|
|
Register (or login) on our website and you will not see this ad.
|
|
|
they would have seen I was more concerned with the traffic beting routed up/down the country on already congested links unnecessarily.
Who says those links are "already congested"? Do you have any evidence to back that up?
Maybe they have dual 400G circuits and it's peaking at 100G of traffic(*), in which case, they're not at all worried about traffic over that link. Indeed, given there are LNSes in Manchester and most of the Internet is reached via London, I would expect that link to be very closely monitored and over-provisioned.
(*) I just made up those figures, as an example
|
|
|
Well, if they create bigger circuits to deal with routing everyone in the south via Manchester, I'd lose the respect I have for Zen. It's a totally nonsensical way to deal with the situation.
It's not about how much bandwidth they have, it's that they're needlessly routing customers in the south to North and then back south again.
I would expect though, that given the rest of my comment where I make it clear that when on the London BNGs I get a distinctly higher average speed than when connected via the Manchester ones. That would suggest there might be some level of congestion involved.
Actually, here's an example. These tests were done back to back.
Vodafone Manchester: https://www.speedtest.net/result/16319556697 (908/826)
Zen London: https://www.speedtest.net/result/16319559565 (626/884)
Edited by agent_r00t (Fri 31-May-24 12:58:24)
|
|
|
|
And yet the faster speedtest shows a longer ping time.
If the speed are slow in the evening but fast in the middle of the night, that would be an indication of congestion. If that's not the case, then the problem probably lies elsewhere.
I've seen people reporting issues of low-level packet loss on the Zen backhaul network, and I don't know if those have been resolved.
|
|
|
I did notice that. But, what we don't know is whether the latency is added in Zen's network, or the target network. E.g. is how much of my route that seems to be going South->North->South->North is in Zen, and how much is within peering networks or within the speedtest target's network.
I could probably spy the IP being used and see that in a traceroute.. Well actually I could see MY side of the route in a traceroute.
What we do know is that the speedtest to Zen's own server in London is considerably slower than speedtests to other networks in Manchester. With me, based in the South. Which, is mainly what this was about if you'll recall.
If the speed are slow in the evening but fast in the middle of the night, that would be an indication of congestion. If that's not the case, then the problem probably lies elsewhere.
Well actually I find Zen is more congested during work hours. I think a lot of us that are remote workers use Zen. Probably explains it.
Edited by agent_r00t (Fri 31-May-24 14:10:40)
|
|
|
I'm in the north-west MCR 1st hop is 7ms London is 12 -13ms but more consistent and less jitter , this latency is the same via BT WBMC and tt wholesale, Zen's GEA has improved routing from the n'west or for me at least The 13msto 1st hop London has been consistent with other isp's like Plus not and UKOnline (Now sky) apart from BE iicr Zen's old routing was 20+ms to London, no MCR option
Edited by tommy45 (Fri 31-May-24 22:10:09)
|
|
|
|
I don't think there's anything wrong with the routing or latency from Manchester. I'm just not sure why they (or cityfibre, or both) are routing me via Manchester in the first place, when I'm 20 miles away from London, in the westerly direction.
Just seems a bit weird and wasteful to do so. If their only peering point with cityfibre is in Manchester, it might make sense. But the other commenter above shows their latency shift from what would make sense for someone in the south routing via London to the same situation I have. So it seems they do have a presence with cityfibre in the south. It's just not being used in my case, for some unknown reason.
|
|
|
|
It looks like City Fibre are terminating your connection at Manchester. It doesn’t look like they are load distributing, nor do we know if they’ll fail you over to London (if it is failover, it’s unlikely reconnecting will help during normal operations).
Once you have reached the Zen network in Manchester, it looks like the first preference for PPPOE is Manchester and London as a failover. You’ve managed to get it to failover, but that’s still going from your location —> Manchester —> London, which leaves you in a worse situation.
Although the majority of stuff will still breakout via London, they do have a CDN in Manchester and they may even have some transit.
In an ideal world you would route via London, from what you have said. It would be worthwhile to send an e-mail to see if it possible to have some more sensible routing. In the meantime, your best bet is to have your pppoe termination in Manchester.
|
|
|
I don't think there's anything wrong with the routing or latency from Manchester. I'm just not sure why they (or cityfibre, or both) are routing me via Manchester in the first place, when I'm 20 miles away from London, in the westerly direction.
Just seems a bit weird and wasteful to do so. If their only peering point with cityfibre is in Manchester, it might make sense. But the other commenter above shows their latency shift from what would make sense for someone in the south routing via London to the same situation I have. So it seems they do have a presence with cityfibre in the south. It's just not being used in my case, for some unknown reason. Makes zero sense to me either,Maybe it's due to city fibre pop's ?
|
|
|
It looks like City Fibre are terminating your connection at Manchester. It doesn’t look like they are load distributing, nor do we know if they’ll fail you over to London (if it is failover, it’s unlikely reconnecting will help during normal operations). Yes, that was my guess too. But I tried a bunch of things to try and get that to change. But nothing doing. I do wonder why that's the case though.
Once you have reached the Zen network in Manchester, it looks like the first preference for PPPOE is Manchester and London as a failover. You’ve managed to get it to failover, but that’s still going from your location —> Manchester —> London, which leaves you in a worse situation. Well for a while I could hop and get London sometimes. And in that case latency wouldn't change, but speed did seem to improve. Lately it's not possible not to get Manchester BNGs. In fact I seem to go between one of two only now. Having said that, even when connecting to a Manchester BNG routing is still very weird. Many connections to Manchester based services still go Manchester -> London -> Manchester. I guess most peering is in London and that's how it is.
In an ideal world you would route via London, from what you have said. It would be worthwhile to send an e-mail to see if it possible to have some more sensible routing. In the meantime, your best bet is to have your pppoe termination in Manchester. I did email Zen about it. As mentioned elsewhere, I got a very helpful reply that demonstrated they knew about the situation. But, I also got another reply where the next guy didn't even read the entire ticket and simply said the latency is fine and I should just move on. So, it's pot luck who you might get support wise.
But in both cases, it seems there's not much Zen can do. Maybe they should have a mechanism to pass on problems like this to Cityfibre to investigate. I don't think they do right now.
|
|
|
Makes zero sense to me either,Maybe it's due to city fibre pop's ?
My initial thought was that they only had termination for cityfibre in the north. But I suspect there'd be more complaints if every single cityfibre user on Zen had this issue. There's people way more sensitive to latency than me, for sure.
I think I was somehow assigned to pop out of cityfibre's network in the north. With Zen I remember I used to have a similar problem with VDSL quite some years ago now. For probably a year I would always connect to Manchester pppoe endpoints. Then one day it fixed itself. No amount of support tickets would fix it for me.
Maybe something similar here.
|
|
|
|
I would personally get them to escalate it, especially if your speeds are suffering.
Traffic definitely shouldn’t be routing from Manchester —> London —> Manchester —> Internet, someone is definitely up with their internal routing.
Unfortunately, Zen isn’t the company it used to be. Having Manchester was a huge selling point in resiliency, which it is if it’s managed properly, clearly it isn’t.
I personally think this will only get the attention it needs is if the finance team get involved. However, I suspect the transit between London and Manchester is cheap, so it may never get looked at.
|
|
|
I would personally get them to escalate it, especially if your speeds are suffering.
Traffic definitely shouldn’t be routing from Manchester —> London —> Manchester —> Internet, someone is definitely up with their internal routing.
Unfortunately, Zen isn’t the company it used to be. Having Manchester was a huge selling point in resiliency, which it is if it’s managed properly, clearly it isn’t.
I personally think this will only get the attention it needs is if the finance team get involved. However, I suspect the transit between London and Manchester is cheap, so it may never get looked at. Some parts of the internet used to peer from Manchester , but everything is now peering through london regardless of which of zen's pop's you are connecting to
|
|
|
Traffic definitely shouldn’t be routing from Manchester —> London —> Manchester —> Internet, someone is definitely up with their internal routing.
I think it is purely down to peering between Zen and other ISPs as to whether the route is seen as cheaper via London or Manchester.
Example. Speedtest Exascale Manchester I get 8ms ping which means it's being routed from Manchester.
Almost all other Manchester speedtests are around 20ms. That means they're routing to London and back again. From my point of view it means it's going South->North->South->North. But it's just down to the combination of bad routing via cityfibre and then the peering between Zen and the network on the speedtest.
So for Exascale in the traceroute I can see they're peering direct at Linx Manchester. But trying IDS Manchester it routes down to ixn-lon on Zen's network then back up to their server in Manchester on IDS's network.
This is not a uniquely IDS thing though. I tried with Vodafone's network (all sites seem to route via London even those in Manchester and further north).
|
|
|
Traffic definitely shouldn’t be routing from Manchester —> London —> Manchester —> Internet, someone is definitely up with their internal routing.
I think it is purely down to peering between Zen and other ISPs as to whether the route is seen as cheaper via London or Manchester.
Example. Speedtest Exascale Manchester I get 8ms ping which means it's being routed from Manchester.
Almost all other Manchester speedtests are around 20ms. That means they're routing to London and back again. From my point of view it means it's going South->North->South->North. But it's just down to the combination of bad routing via cityfibre and then the peering between Zen and the network on the speedtest.
So for Exascale in the traceroute I can see they're peering direct at Linx Manchester. But trying IDS Manchester it routes down to ixn-lon on Zen's network then back up to their server in Manchester on IDS's network.
This is not a uniquely IDS thing though. I tried with Vodafone's network (all sites seem to route via London even those in Manchester and further north).
This is an interesting conversation, I remember a data centre I used in Germany a couple of decades ago.
This data centre offered a choice of traffic routing standard or premium, the standard option was no extra charge and the default. When looking at the descriptions for the options, they were described something like this.
Standard - routing is cost optimised to have as low cost as possible to ourselves, the standard for how most networks are run.
Premium - routing is latency optimised, this does not assure higher performance.
I do expect Zen route their sessions to give the lowest running cost, and I dont think this would be unusual practice either, Vodafone seem to do the same thing, and I also expect this is how transit/peering is commonly managed across the industry as well. If you have one bit of kit only 10% utilised and another fully utilised, logically a ISP would shift traffic the first bit of kit before adding extra kit at the second kit's location to manage their expenditure.
As a user I think I would personally prefer to have the session in London, as logically thats where most UK internet infrastructure is for peering links CDN infrastructure etc. The way to assure this is to use an ISP that only uses London, but if you in the north or west, there is advantages to what Zen are doing as some stuff can be served locally from these other locations including cloudflare content which would be an advantage.
|
|
|
Thanks for the detailed reply and it's a shame it hasn't been resolved.
It sounds like you may be fairly close to me, I'm in Maidenhead. My main issue with the routing through Manchester is not really the increase in latency but the fact that my speeds have dropped to the two site to site VPN connections I have in Finland. This is still an ongoing issue.
Their service alert page mentions "Zen Core Network maintenance - BNG" for the next few nights, maybe things will improve soon?!
Having said that, this evening my connection to CityFibre has been completely down for the past couple of hours and no mention of anything on their service alert page. Also rather alarmingly I just realised their technical support ended at 8pm! At least I don't have to worry about where my connections are routing anymore as I have none. 😂
Edited by timo_w2s (Mon 10-Jun-24 20:46:03)
|
|
|
|
Yes, not too far. I'm not far from Bracknell.
I'm actually not too fussed about latency either. It's around 18ms to London (it's improved somewhat) and 7-8ms to Manchester. But yes the speed when accessing network resources that involve returning to London are definitely slower especially in working hours. I did some speedtests for this to show the effect.
London (YouFibre) 10/06/2024 at 02:31: 908/926Mbit/s 15ms RTT
London (YouFibre) 10/06/2024 at 13:25: 622/885Mbit/s 13ms RTT
Manchester (Exascale) 10/06/2024 at 13:33: 915/911 8ms RTT
Which is indicative that when the network is quiet, traffic to and via London can achieve the max speed. But during working hours when the network is busy, they don't reach the top speed. However, at that time if connecting to resources that don't run via London can achieve the full speed. Kinda indicates they're feeling some constraints on the link between north and south. That's the real problem. Yes, I'd like a lower RTT but 18-20ms is not bad, and not really causing me a problem.
As for the BNG maintenance. It seems to suggest this might be happening first overnight tonight, and in a couple of days. I'm not too confident it will do anything for us, because it's quite generic (maintenance) and I don't think BNGs are specific to Cityfibre connections. But, we'll see I guess.
For your loss of connectivity. It's all fine over here, and as I'm sure you've checked there's no alert on Zen status for this. So, hopefully nothing too serious there.
|
|
|
|
Keep at them, this should be an issue they can resolve.
You shouldn't be seeing this slowdown between Manchester and London, the chances of that link running hot are very slim. The only place it may run hot is between the provider (City Fibre) and Zen, due to the contended nature of the service (due to the high costs of bandwidth at this point).
It could be a genuine fault impacting certain types of traffic within their network.
Kev
|
|
|
|
Since I was moved to Manchester my FTP connections between my two VPN locations sometimes just randomly drop during a large file transfer, which is annoying. This didn't happen before the move.
Still not heard back from their technical department regarding my connection dying yesterday afternoon either.
I think that once my 18 month contract expires, I'll be looking to try a new ISP unless things change for the better soon. It's not been a good start for me with Zen.
|
|
|
|
Everything is definitely pointing back to a fault, likely to be within the Zen network (I’m not referring to your service outage).
You never know, they may have tried shifting your connection to London, which is causing the issue you currently have. We can hope! If this was initiated by CityFibre (hence the lack of updates), you could be terminated onto a piece of Zen equipment in London that isn’t configured for your FTTP. This is all wishful thinking though.
I’ve found Zen to be ok, apart from when you need support. I tend to find if they can’t fix it immediately, it quickly becomes a bit of a nightmare, as nobody takes ownership of the issue, me the end user ends up organising them in order to resolve things.
|
|
|
I think it's a bit worse today. But I might blame most of it on youfibre.
London: Youfibre just now
https://www.speedtest.net/result/16362672552.png
London: Zen just now, considerably better
https://www.speedtest.net/result/16362675394.png/url]
Manchester: Exascale
https://www.speedtest.net/result/16362678030.png/url]
So still Manchester getting top speed when London gets various values below. Maybe I should do these tests daily for a week and make a graph.
I would need to check a traceroute to see if it is using Zen's network for the North/South transit though. It could be peering with someone else in Manchester and then using their network to London.
|
|
|
Makes zero sense to me either,Maybe it's due to city fibre pop's ?
My initial thought was that they only had termination for cityfibre in the north. But I suspect there'd be more complaints if every single cityfibre user on Zen had this issue. There's people way more sensitive to latency than me, for sure.
I think I was somehow assigned to pop out of cityfibre's network in the north. With Zen I remember I used to have a similar problem with VDSL quite some years ago now. For probably a year I would always connect to Manchester pppoe endpoints. Then one day it fixed itself. No amount of support tickets would fix it for me.
Maybe something similar here.
Zen only take the CityFibre local product. That means the handover from CityFibre to Zen is in your local CityFibre exchange in your City, this is the site the OLT for your connection is in so very close to your home.
How it gets to Zen and why it prefers Manchester is 100% down to Zen and their network. CityFibre don’t have anything to do with it. Other ISPs use national services from CF but not Zen.
|
|
|
Zen only take the CityFibre local product. That means the handover from CityFibre to Zen is in your local CityFibre exchange in your City, this is the site the OLT for your connection is in so very close to your home.
How it gets to Zen and why it prefers Manchester is 100% down to Zen and their network. CityFibre don’t have anything to do with it. Other ISPs use national services from CF but not Zen.
Well that makes even less sense regarding what is happening. Since my local exchange was already on Zen's network for VDSL and I was connecting via London. When I swapped to cityfibre, that's when it changed. It's very visible on my BQM for the day. https://www.thinkbroadband.com/broadband/monitoring/...
Pretty clear what time I swapped that over.
|
|
|
|
CityFibre have just been and fixed my connection. To be fair to Zen once they actually answered my emails things moved a bit quicker but it took a couple of days before it was fixed. The CityFibre guys said it looked like a squirrel had chewed through the fibre by the pole. It wouldn't surprise me as the pole is half in the trees and the lines go through several more trees and shrubs over the neighbour's property.
Anyway, the interesting thing is I'm back on the London connection, speeds are up, latency is down to what it was originally, and a few quick speed tests show my site to site VPN speeds are back up to were they where before the switch to Manchester. So all is good at the moment, but not sure for how long.... will the squirrels return or will Zen switch me back on to Manchester at some point... 😬
|
|
|
Anyway, the interesting thing is I'm back on the London connection, speeds are up, latency is down to what it was originally, and a few quick speed tests show my site to site VPN speeds are back up to were they where before the switch to Manchester. So all is good at the moment, but not sure for how long.... will the squirrels return or will Zen switch me back on to Manchester at some point... 😬
I wonder if the extended disconnection did it for you? Cleared out any configuration that was being sticky. It was the advice when this happened with the VDSL/ADSL connections.
I did try disconnecting it overnight once. Which is about as long as I can get away with (two people working from home on the connection). That didn't do anything.
|
|
|
I wonder if the extended disconnection did it for you? Cleared out any configuration that was being sticky. It was the advice when this happened with the VDSL/ADSL connections.
I was thinking the same, which is why I'm not holding my breath. I wouldn't be surprised if I end up back on the other one sometime.
|
|
|
I was thinking the same, which is why I'm not holding my breath. I wouldn't be surprised if I end up back on the other one sometime.
I tried turning it off overnight again (1am to 8am). Still on Manchester. So, not sure how long it needs to be off to clear whatever it might be.
I'm so not sure whether to email them again though. It's so random now whether you will get someone that wants to help, or someone that just wants to close another call to keep their stats up.
|
|
|
I tried turning it off overnight again (1am to 8am). Still on Manchester. So, not sure how long it needs to be off to clear whatever it might be.
I'm so not sure whether to email them again though. It's so random now whether you will get someone that wants to help, or someone that just wants to close another call to keep their stats up.
If I end up back on Manchester I'll post back on this thread. The fact that you are still connected via Manchester makes me think I might end up back there too. I've only been with Zen since CityFibre came along in our area earlier this year but I do get the occasional brief disconnect at night and it was after one of those disconnects that the switch from London to Manchester happened.
|
|
|
Well, I had just over a month connected to London before I was put back on Manchester last night. You can see the time it happened on the BQM graph below. VPN speeds to Finland are down by about 30% again and pings are up a bit.
My Broadband Ping
Edited by timo_w2s (Fri 19-Jul-24 08:21:34)
|
|
|
Well, I had just over a month connected to London before I was put back on Manchester last night. You can see the time it happened on the BQM graph below. VPN speeds to Finland are down by about 30% again and pings are up a bit.
Yep, I've not been able to get off Manchester. I do wonder why they don't look into it. It surely cannot be good for them to route people this way.
|
|
|
I had it over the weekend and raised a complaint. It took 4 days to get back on to the london gateway.
I pointed out to them that doubling the latency contradicts their very own gaming page https://www.zen.co.uk/broadband/gaming-broadband/
- "Everyone knows ping is king"
- "Our tech support team is full of gaming experts who know their stuff, and know how to resolve any unlikely technical issues you may find"
- "We are providing you with the best high speed internet."
They spoke to their NOC team who came back and said nothing they can do. Zen then asked me how they could resolve the complaint for me, so I said because I'm out of contract I pay £63 a month and they could lower it to the current £55 a month and they refused.
I then asked them why are they even bothering to ask me then if they are just going to refuse everything. I requested they suggested how to resolve it and they said they would by closing the complaint.
Utterly useless service, complete pack of lies on their website. Tempted to report them to the ASA.
Edited by zebb_edi (Fri 19-Jul-24 11:49:29)
|
|
|
I'm in South Oxfordshire with IDNet (FTTC with Zen backhaul); when I checked this morning my BQM was very similar to yours... I don't know how backhaul routing works, but around 1pm (and more in hope than expectation) I rebooted the router and now everything is back where it should be:
My Broadband Ping
|
|
|
Am new to Zen after many years of waiting for Fibre to be installed in my street.
I have been activated by City Fibre and after the first day of service I raised a support ticket with Zen followed by a complaint for the issue with Latency and speeds all over the place (supposed to be 900/900 symetric).
I have been on many calls with Support now trying to review how to fix this issue.
I am based in Berkshire and use the Bracknell exchange which is over 200 miles from Zen Manchester.
London is less than 50miles from me and it is maddening that I cannot connect via London.
Every time I restart the PPPOE connection I am connected to Zen manchester gateway 51.148.77.130
I havent been able to connect to a London gateway at all.
tracert www.bbc.co.uk
Tracing route to bbc.map.fastly.net [151.101.36.81]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms TUF-AX6000-3718 [192.168.50.1]
2 13 ms 34 ms 28 ms lo0-0.bng3.wh-man.zen.net.uk [51.148.77.130]
3 13 ms 13 ms 13 ms lag-7.p2.wh-man.zen.net.uk [51.148.73.14]
4 14 ms * 13 ms 51-148-244-49.dsl.zen.co.uk [51.148.244.49]
5 17 ms 14 ms 23 ms ldn-bb1-link.ip.twelve99.net [62.115.120.74]
6 22 ms 20 ms 20 ms adm-bb1-link.ip.twelve99.net [62.115.139.144]
7 22 ms 20 ms 20 ms adm-b10-link.ip.twelve99.net [62.115.120.227]
8 21 ms 19 ms 19 ms fastly-ic-319760.ip.twelve99-cust.net [62.115.151.49]
9 22 ms 20 ms 19 ms 151.101.36.81
When I spoke to the complaints team I had said please fix or I will look to change providers as the Latency is twice that of my former Broadband on BT which was copper cables. They have told me as soon as my service was activated my 14 day cooling off period was null and void and I would have to pay the full contract to exit.
I am stuck now unable to know how to escalate this.
I wondered if the routing was a mistake of City Fibre provisioning? but Zen say the latency is fine which is ridiculous IMHO and their latency advertising a lie.
I also had spoken to their sales team prior to ordering and was assured that I would get routed by geography and thus london instead of Manchester given my proximity.
I would have expected that latency and geography would have some bearing on routing but Zen say this is by design and down to load.
Any ideas please? I am not sure technically why this is happening so anyone that can help explain I would appreciate.
cheers
|
|
|
I am based in Berkshire and use the Bracknell exchange which is over 200 miles from Zen Manchester.
London is less than 50miles from me and it is maddening that I cannot connect via London. I think I'm either connected to Cityfibre's aggregation point (or whatever they call it) for either Bracknell or Wokingham. So, maybe it's a thing with cityfibre's deployment in this area?
Nothing I've tried which on xDSL would usually give you a chance to be moved back to London has not worked with cityfibre.
I would have thought with every cityfibre connection being up to a gigabit in speed (and potentially soon even faster), they might want to not be wasting their internal capacity with this bizarre routing. But, it seems they have no real interest in solving this.
One difference mind you, is that my first hop in Manchester is usually a bit lower latency:
| Text | 1
23
45
67
| traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 zen-gw.[REDACTED] (77.104.[REDACTED]) 0.190 ms 0.157 ms 0.144 ms 2 lo0-0.bng3.wh-man.zen.net.uk (51.148.77.130) 7.992 ms 7.979 ms 7.965 ms
3 lag-7.p2.wh-man.zen.net.uk (51.148.73.14) 12.842 ms 12.830 ms 12.880 ms 4 51-148-244-49.dsl.zen.co.uk (51.148.244.49) 12.805 ms 12.854 ms *
5 192.178.98.1 (192.178.98.1) 13.123 ms 192.178.97.115 (192.178.97.115) 14.119 ms 192.178.97.189 (192.178.97.189) 12.672 ms 6 216.239.63.219 (216.239.63.219) 13.068 ms dns.google (8.8.8.8) 12.655 ms 12.632 ms |
Edited by agent_r00t (Thu 25-Jul-24 11:51:29)
|
|
|
Any ideas please? I am not sure technically why this is happening so anyone that can help explain I would appreciate. Zen routing people in the south through the Manchester gateway has been a bugbear for many many year, they have always refused to accept that it's an issue as they tell everyone its by design. Whoever come up with the design needs to be fired as its a really poor concept.
It has been suggested before that they should have a portal option to specify your preferred gateway and where possible they should route customers through their chosen gateway but as they refuse to accept that it's an issue they will never find a solution to it.
The fact that they have customers in the north going to the London gateway and customers in the south going to the Manchester gateway seems to be lost on them but you can guarantee their devices will be going to the most suitable gateway.
Edited by PCJM40 (Thu 25-Jul-24 12:12:33)
|
|
|
Zen routing people in the south through the Manchester gateway has been a bugbear for many many year, they have always refused to accept that it's an issue as they tell everyone its by design. Whoever come up with the design needs to be fired as its a really poor concept.
With cityfibre it's a bit different though. Until around a month ago if I kept reconnecting enough times I would get a London based BNG. But the latency would remain the same (as if it were still going via Manchester, outside the main IP network).
On xDSL if you got the London gateway you would get the lower latency.
For the last month or so it's not even been possible to get a London gateway unless the Manchester ones are down.
|
|
|
|
I tried raising a complaint, but I never got past their support team, and it was never treated as an actual complaint. As soon as I posted a poor review on trustpilot i've been assigned a complaints manager who is reviewing the case.
|
|
|
I tried raising a complaint, but I never got past their support team, and it was never treated as an actual complaint. As soon as I posted a poor review on trustpilot i've been assigned a complaints manager who is reviewing the case. And this is the sad state we live in now. Your problem isn't a problem until you make it a public problem.
I'm not imagining it, 10 years ago things weren't like this. Right?
Zen at least support wise, you're going to get pot luck. I had one guy actually read and understand my complaint. He couldn't do a thing about it, but understood and replied politely. When I reply thanking him, another support agent (paraphrased) replied "your ping is fine, go away".
I don't know. If I didn't make use of the netblock I have with Zen, I'd likely move as soon as my contract were up. Not because of the latency (or the lower speeds during peak time associated with this routing), but because I pay more to Zen precisely for the good support I've previously received on the rare occasion I needed help.
|
|
|
|
Zen's attitude towards their gateway routing has always been a disgrace. As others have said it's gone on a long time, but they never do anything about it. It did seem reasonably stable for me for a while now, but something has changed over the last few weeks imho.
It is very noticeable. I use mine alot for gaming and also write regulatory reporting financial software, and I notice it alot for that too because i work from home.
Don't get me wrong, i'm fine if it fluctuates a little, i'm not expecting the sort of SLA's that our financial customers pay through the nose for, but to more than double the latency based on their gateways is definitely not providing a decent service.
The hypocrisy of their gaming page stating "ping is king" and "we always provide the best connection" is just outright a pack of lies and false advertising. You can't actively advertise that to attract gamers and then allow your support staff to tell anyone who reports it to go away because a ping of 25ms one minute and 10ms the next is perfectly acceptable.
|
|
|
I was going to post the usual Zen run their network for cost efficiency meaning if Manchester is under utilised, they wouldnt bump up London capacity and instead reroute traffic via Manchester to get more utilisation out of their investment.
However I noticed you mentioned Zen sales mentioned latency and then found this page.
https://www.zen.co.uk/broadband/gaming-broadband/
I cant remember if the ASA consider companies own website's to be part of what they look at but I would think at the very least that they have "We’ve invested in our network to ensure consistently low latency" on their web page would allow you a penalty free exit.
Looks like the sales team are on a different wavelength to whoever is making the decision on gateway session steering.
I think its unlikely Zen will change their policy and investment decisions, so if it bothers you, use the above to get a penalty free exit and go to an ISP that only has London gateways.
Edited by Chrysalis (Thu 25-Jul-24 14:41:06)
|
|
|
I reported problems with ping doubling depending which gateway I was on in 2021. This is the reply I got:
Zen servers work to ensure that latency is spread as evenly as possible between our customers. Rather than have one customer with high latency and 10 with tiny latency we want our servers to ensure that no individual has significantly more or less latency than anyone on the server as nobodie's traffic should be prioritized.
Multiple online sources state latencies of less than 50Ms as good. A latency of 20Ms is universally considered excellent or even unrealistic to aim for. Your latency could have increased due to a number of factors, but the most likely one is that usage in your area increased so to ensure everybody had a good browsing experience everyone's latency increased slightly to allow for the greater throughput needs without impacting service.
If internet traffic increases in your area further your latency is likely to increase along side that in order to ensure everyone has the best browsing experience. We cannot save particularly good latencies for individual customers as it would give all our other users a worse experience. If your latency regularly reaches 200-500Ms unloaded then there may be a loading issue on your line that could need investigation and addressing, but with it still being at above excellent rates we are unable to take further action.
David
BT (poor) -> Zen (excellent) -> O2 (started well, went downhill -> IDNet (No complaints - but 100GB cap) -> Zen (gone a long way downhill) -> A & A
|
|
|
I am stuck now unable to know how to escalate this.
I wondered if the routing was a mistake of City Fibre provisioning? but Zen say the latency is fine which is ridiculous IMHO and their latency advertising a lie.
I also had spoken to their sales team prior to ordering and was assured that I would get routed by geography and thus london instead of Manchester given my proximity.
I would have expected that latency and geography would have some bearing on routing but Zen say this is by design and down to load.
Any ideas please? I am not sure technically why this is happening so anyone that can help explain I would appreciate.
cheers
As mentioned before Zen only take Local services from CityFibre, that means your service is handed over to Zen from the CityFibre exchange which serves your house.
Zen take the traffic from their local location into their network within the town/city you are in so any routing issue is down to how Zen have chosen to direct your traffic. From what I recall of Zen all the BNGs are in the same group for PPPoE so which BNG you get is down to which responds first, why that appears to always be a BNG in Manchester for people in the south is the question.
All you can do is keep pushing Zen to sort their network out and route you sensibly.
|
|
|
I'm in South Oxfordshire with IDNet (FTTC with Zen backhaul); when I checked this morning my BQM was very similar to yours... I don't know how backhaul routing works, but around 1pm (and more in hope than expectation) I rebooted the router and now everything is back where it should be:
My Broadband Ping
I didn't manually reboot my router or ONT as I'm not at home at the moment and didn't want to risk doing it remotely but a couple of days ago I got briefly disconnected at about 6am and was put back on London so everything is working better again for now. I guess we should be grateful that we can switch to London occasionally unlike those in Bracknell!
|
|
|
When I spoke to the complaints team I had said please fix or I will look to change providers as the Latency is twice that of my former Broadband on BT which was copper cables. They have told me as soon as my service was activated my 14 day cooling off period was null and void and I would have to pay the full contract to exit.
I am stuck now unable to know how to escalate this..
Hmm is this normal tactics across the industry or just Zen, as I think I'm in a similar boat whereby I made my order and magically the go-live date was exactly 14 days after sign-up date?
|
|
|
Reviving this. For 10 short minutes last night I was mysteriously routed via London.
Zen Cityfibre BQM 24/02/2025
So it is possible. Not really sure why it went back again though. I want to note that the ping increased while I was still connected to one of the London BNGs. So the routing is definitely happening somewhere else, either on the cityfibre side, or Zen outside the visible IP network.
|
|
|
When I spoke to the complaints team I had said please fix or I will look to change providers as the Latency is twice that of my former Broadband on BT which was copper cables. They have told me as soon as my service was activated my 14 day cooling off period was null and void and I would have to pay the full contract to exit.
I am stuck now unable to know how to escalate this..
Hmm is this normal tactics across the industry or just Zen, as I think I'm in a similar boat whereby I made my order and magically the go-live date was exactly 14 days after sign-up date?
I know this is an old post but the 14-day cooling-off period on contracts was never intended to create a try-and-buy service. Some ISPs do start the 14-day period from the date of activation and bill you pro-rata for the days you use, but these tend to be the massive ones that can afford to absorb activation/installation charges.
The point of the 14-day period is that you have time to review the offer that you signed up to, and to look around at other providers, to review terms and conditions etc. rather than saying "yes" to something on the phone and then being locked in for 24 months.
|
|
|
They have told me as soon as my service was activated my 14 day cooling off period was null and void and I would have to pay the full contract to exit.
If activation is within the 14 days the cooling period should stand until and unless the customer agrees a waiver. AIUI
|
|
|
|
How can I tell if I am connecting via London or Manchester?
I am in Milton Keynes, on Zen via CityFibre and our PCs all run Linux.
Also, does anyone know where, (which town), CityFibre's exchange for the Milton Keynes area is please?
.
|
|
|
How can I tell if I am connecting via London or Manchester?
So, generally Zen have locked down the randomness in your gateway assignment. So if cityfibre is routing you via Manchester you will connect to a Manchester BNG and if via London you will get onto a London BNG.
Do a traceroute somewhere. I use 8.8.8.8 (google DNS) but you can also use 1.1.1.1 or literally anywhere.
The very first hop after your home router (the hostname will contain "bng") will be your gateway.
London example:
| Text | 1
23
45
67
| traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 _gateway (192.168.178.253) 0.093 ms 0.106 ms 0.164 ms 2 lo0-0.bng4.thn-lon.zen.net.uk (51.148.77.132) 6.327 ms 6.298 ms 6.314 ms
3 lag-14.p2.thn-lon.zen.net.uk (51.148.73.96) 4.118 ms 4.134 ms lag-14.p1.thn-lon.zen.net.uk (51.148.73.94) 4.072 ms 4 72.14.223.28 (72.14.223.28) 3.530 ms 72.14.217.190 (72.14.217.190) 5.194 ms 72.14.223.28 (72.14.223.28) 3.493 ms
5 * 192.178.97.115 (192.178.97.115) 5.197 ms 192.178.97.49 (192.178.97.49) 4.600 ms 6 dns.google (8.8.8.8) 4.024 ms 4.452 ms 4.447 ms |
In this case you can see it is BNG4, and right after that you can see thn-lon. Which means telehouse north (I believe) in London. So you're looking for the "lon"
Manchester example:
| Text | 1
23
45
67
| traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 _gateway (192.168.178.253) 0.104 ms 0.121 ms 0.113 ms 2 lo0-0.bng4.wh-man.zen.net.uk (51.148.77.131) 11.466 ms 11.432 ms 11.453 ms
3 lag-8.p2.wh-man.zen.net.uk (51.148.73.118) 12.699 ms 13.460 ms 13.429 ms 4 be26.p1.thn-lon.zen.net.uk (51.148.244.49) 13.340 ms 13.356 ms *
5 192.178.97.189 (192.178.97.189) 13.378 ms 13.395 ms 192.178.98.1 (192.178.98.1) 13.925 ms 6 172.253.66.101 (172.253.66.101) 13.991 ms 142.251.52.143 (142.251.52.143) 13.209 ms dns.google (8.8.8.8) 11.882 ms |
Here you can see this in BNG4 with wh-man. The man denoting Manchester.
Unlike the FTTC network, even if you get a different BNG (it's much harder to do now it's ALWAYS manchester for me now), it doesn't seem to change your physical route. The traffic for me still goes via manchester even when on the telehouse one (except for those magic 10 minutes last night).
Edited by agent_r00t (Tue 25-Feb-25 13:28:14)
|
|
|
Do a traceroute somewhere. I use 8.8.8.8 (google DNS) but you can also use 1.1.1.1 or literally anywhere.
Thanks - looks like I am correctly on London:
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 fritz.box (192.168.178.1) 0.475 ms 0.598 ms 0.680 ms
2 lo0-0.bng5.thn-lon.zen.net.uk (51.148.77.133) 20.579 ms 20.610 ms 20.649 ms
3 lag-15.p2.thn-lon.zen.net.uk (51.148.73.100) 7.286 ms * 7.893 ms
4 72.14.217.190 (72.14.217.190) 11.233 ms 72.14.223.28 (72.14.223.28) 11.163 ms *
5 192.178.97.49 (192.178.97.49) 11.295 ms 192.178.97.189 (192.178.97.189) 11.239 ms 192.178.97.49 (192.178.97.49) 11.344 ms
6 142.251.52.143 (142.251.52.143) 11.386 ms 192.178.46.87 (192.178.46.87) 6.153 ms dns.google (8.8.8.8) 5.976 ms
Is there any way to tell which CityFibre exchange I am connected to?
.
|
|
|
Is there any way to tell which CityFibre exchange I am connected to?
Not digitally that I am aware of. But I believe the exchange name is stamped on some of the green boxes. The one I am connected to doesn't have it on but there's one on the main road that does.
|
|
|
How can I tell if I am connecting via London or Manchester?
Run trace route (tracert in Windows-speak) in a terminal window.
Also, does anyone know where, (which town), CityFibre's exchange for the Milton Keynes area is please?
No idea.
|
|
|
How can I tell if I am connecting via London or Manchester?
So, generally Zen have locked down the randomness in your gateway assignment. So if cityfibre is routing you via Manchester you will connect to a Manchester BNG and if via London you will get onto a London BNG.
I said it last year and I'll say it again. With Zen CityFibre don't route you anywhere. Zen only take the local products from CityFibre, which means you connect to the Zen network straight off the back of your local CityFibre exchange. Normally that is where your OLT is located so very close to where you live.
Any routing is down to how Zen have connected from that city back into their network. Zen use PPP so the first hop you see is their BNG, there could be many hops between the local Zen device in your city and their BNGs.
In MK65's case their connection will be from a CityFibre exchange within Milton Keynes, I think they have more than one to cover the whole of the city.
|
|
|
Any routing is down to how Zen have connected from that city back into their network. Zen use PPP so the first hop you see is their BNG, there could be many hops between the local Zen device in your city and their BNGs.
But now how does this explain the situation I have where, no matter what BNG I am on, I get the ping for connecting via Manchester. EXCEPT for those 10 minutes the other night where I was properly (and correctly) routed via London with the lower ping to show for it?
Zen are deliberately doing this? For certain this extra route is happening outside of the PPP session since the latency doesn't get lower when connecting via London BNGs except for that 10 minute interval.
At any rate, seems really weird and pointless routing and if it's not just me that is setup this way, with the adoption of the 2.5g service this pointless traffic will start to hurt them I'm fairly sure.
|
|
|
Yes, CityFibre have a product called CityFibre local, used by providers like Zen, it will save Zen money as their own operational costs are cheaper than leasing a national backhaul.
Zen are likely doing it deliberate for cost reasons, there probably isnt anything in your contract that says you have to go over to their London location.
Edited by Chrysalis (Wed 26-Feb-25 19:17:24)
|
|
|
Yes, CityFibre have a product called CityFibre local, used by providers like Zen, it will save Zen money as their own operational costs are cheaper than leasing a national backhaul.
Zen are likely doing it deliberate for cost reasons, there probably isnt anything in your contract that says you have to go over to their London location. This isn't about a contract. I don't really do things that are particularly latency sensitive (maybe NTP server, but it's not really latency, but jitter that hurts there).
I'm trying to fathom the cost saving of sending users in the south into the Manchester BNGs (and via Manchester even when connecting to London BNGs). Then sending 90%+ of the traffic back down to London for peering anyway. Even routing to sites in Manchester very often route Machester -> London -> Manchester. If it's on their network they still need to pay for the cable they're now using capacity in both directions. The fact that for 10 minutes I had a 4ms ping means they have a link from my exchange into London. So, it's just bizarre to choose to send traffic that way.
I'm also going to lay money down that they have people North of Manchester feeding into the London gateways. It just seems non-sensical to me and as people take up full fibre more (and especially the max products), they're going to see capacity hit on these links because of, what seems to me at least to be wastage.
|
|
|
This isn't about a contract. I don't really do things that are particularly latency sensitive (maybe NTP server, but it's not really latency, but jitter that hurts there).
I'm trying to fathom the cost saving of sending users in the south into the Manchester BNGs (and via Manchester even when connecting to London BNGs). Then sending 90%+ of the traffic back down to London for peering anyway. Even routing to sites in Manchester very often route Machester -> London -> Manchester. If it's on their network they still need to pay for the cable they're now using capacity in both directions. The fact that for 10 minutes I had a 4ms ping means they have a link from my exchange into London. So, it's just bizarre to choose to send traffic that way.
I'm also going to lay money down that they have people North of Manchester feeding into the London gateways. It just seems non-sensical to me and as people take up full fibre more (and especially the max products), they're going to see capacity hit on these links because of, what seems to me at least to be wastage.
It is Zen's own backhaul and fibre as far as I know, so if that is the case then there are no extra costs even if they do go a long way around. If they just let everyone take the shortest route its likely they have an imbalance with one side of their network under utilised and the other segment over utilised, so to keep things balanced some customers end up going the long way around.
BT Wholesale are very similar and don't always route customers on the shortest link. On my FTTP connection, no matter the ISP I've had, when using BT Wholesale backhaul to get to London, my latency to the gateway in London can vary, seems to be three routes I can be assigned from my location, happens at random when first connecting giving me either 9ms, 7ms, or 5ms latency. A couple of times the 9ms route has changed overnight to 5ms without the connection dropping for a few hours then changed back up again (as seen on the BQM), presumably because of some overnight work and I've failed over to another route then moved back again when the work has finished.
The big difference with BT Wholesale is they don't seem to be doing it for load balancing or at least don't get imbalances that they have to correct like Zen, as with Zen backhaul I never had more than 2 weeks uptime before I was dropped in the early hours to come back up on the Manchester route, with a big jump in latency. With BT Wholesale I've gone over 200 days without a disconnection, I'd be getting onto almost 300 days if it wasn't for a line card that needed replacing that knocked me off.
This routing issue with Zen has been a constant reoccurring theme in these forums, it has been going on for years and years, its not going to get fixed, as it is working as far as Zen are concerned, i.e. its by design.
Edited by E300 (Thu 27-Feb-25 09:22:39)
|
|
|
Just in case someone is interested, I've been connecting via London for the vast majority of the time for a good few months now after initially getting stuck on Manchester for a bit earlier last year (I'm in Maidenhead, Berkshire) but occasionally I do get disconnected (usually in the early hours) and end up on Manchester for a while but most of the time it seems to kick me off and put me back on London again without me having to do anything.
It happened again last night, I was routing via Manchester for about 16 minutes (02:57-03:13):
My Broadband Ping
Also, trace routes suggest I'm not being routed to Manchester and back when I'm connecting via London.
|
|
|
It happened again last night, I was routing via Manchester for about 16 minutes (02:57-03:13): Seems like the exact opposite to me. I'm only around 10 miles from you and it's the opposite situation. I had 10 minutes or so when I was bounced to London with a nice ping, higher speeds on speedtest etc. Then back to Manchester.
|
|
|
It is Zen's own backhaul and fibre as far as I know, so if that is the case then there are no extra costs even if they do go a long way around. If they just let everyone take the shortest route its likely they have an imbalance with one side of their network under utilised and the other segment over utilised, so to keep things balanced some customers end up going the long way around.
Here's the problem I have with this.
I'm not in London, I'm to the west, but only a little. From my Cityfibre "exchange" or whatever Cityfibre call their local nodes Zen picks it up on their own network.
Now, I cannot possibly see a reason that Zen would run their own network from an exchange in the south to both Manchester AND London. This was why I initially assumed Cityfibre were routing me internally toward the Zen BNG I was connecting to (Manchester).
As such, if Zen are using their own backhaul network. It would make sense that they would run from localised exchanged to the nearest larger node and onward to either London or Manchester. It would seem wasteful to run parallel to both from everywhere. I admit I don't know this of course. But, it would seem pretty wasteful to be running independent connections from the south to the North. They would almost certainly rather aggregate connections like this to the largest pipe they can between London and Manchester and route in from exchanges to the nearest physically no?
As such, I can only imagine they're running from my exchange into London, then up to Manchester, to the BNG and then routing almost all my traffic back down to London.
Essentially I don't mind the ping, it's just the whole situation seems to be a bizarre choice to me.
|
|
|
It happened again last night, I was routing via Manchester for about 16 minutes (02:57-03:13):
My Broadband Ping Interesting to see that- I'm with IDNet on Zen backhaul and saw the same- https://www.thinkbroadband.com/broadband/monitoring/...
(Post here: https://forums.thinkbroadband.com/idnet/t/4773185-ve... )
Edited by billford (Thu 27-Feb-25 12:12:49)
|
|
|
Now, I cannot possibly see a reason that Zen would run their own network from an exchange in the south to both Manchester AND London.
It would seem wasteful to run parallel to both from everywhere. I admit I don't know this of course. But, it would seem pretty wasteful to be running independent connections from the south to the North.
Diversity?
Failure of the single link in your scenario could take out a large number of customers.
I used to work in broadcast transmission and I know that every main TV transmitter in the country has at least two programme feeds to it, approaching from different geographical directions, (they are set up in rings). The two feeds go in to a slipless switch at the transmitter, so that failure or degradation of one of the paths would be seamless to the viewer at home.
.
|
|
|
Diversity?
Failure of the single link in your scenario could take out a large number of customers.
I'd expect it to make more sense from here (150+ miles from Manchester, ~30 miles from telehouse) to run redundant links to more than one London peering point and then have redundant links between sites than to run multiple redundant links from exchanges in the south to both London and Manchester.
Even if you did have redundant links. It doesn't make sense to put someone on a link that's not too busy when over 90% of the traffic comes right back to London. I don't know. Just seems a weird network design to me.
I'm also not convinced the comparison to a broadcast network is a good one. Because in a broadcast network you have a single programme feed. If you send it round in a ring you have a predictable amount of traffic to handle. When it comes to the internet, if you have almost all of your peering in London, and you route users in the south into Manchester, you're going to just put all of that traffic on your connection with London.
Any time you route someone 100+ miles out of their way you're putting almost all their traffic back onto that link between Manchester and London. Albeit putting a user in the North onto the London gateway doesn't really detract from their experience, except for the small amount of traffic that has actual peering in Manchester.
Having said all that, I would be prepared to say fine balance the load. EXCEPT you also hear stories of people far in the North connecting to London gateways! It just seems wholly inefficient to me. But, the main problem with the theory of using this as a solution to direct route capacity limitations is that on the rare occasion I do fail over to the more direct route, speedtests etc are faster! So clearly there's some level of congestion on the "best" route over the "worse" one.
I feel like this is one of those legacy things Zen has, and they just don't want to do anything about it. Like I've said already. As people pick up (and actually use) 2.5gbe circuits. I wonder if this will finally cause enough of a problem for them to react.
|
|
|
I'd expect it to make more sense from here (150+ miles from Manchester, ~30 miles from telehouse) to run redundant links to more than one London peering point and then have redundant links between sites than to run multiple redundant links from exchanges in the south to both London and Manchester.
Even if you did have redundant links. It doesn't make sense to put someone on a link that's not too busy when over 90% of the traffic comes right back to London. I don't know. Just seems a weird network design to me.
I'm also not convinced the comparison to a broadcast network is a good one. Because in a broadcast network you have a single programme feed. If you send it round in a ring you have a predictable amount of traffic to handle. When it comes to the internet, if you have almost all of your peering in London, and you route users in the south into Manchester, you're going to just put all of that traffic on your connection with London.
Any time you route someone 100+ miles out of their way you're putting almost all their traffic back onto that link between Manchester and London. Albeit putting a user in the North onto the London gateway doesn't really detract from their experience, except for the small amount of traffic that has actual peering in Manchester.
Having said all that, I would be prepared to say fine balance the load. EXCEPT you also hear stories of people far in the North connecting to London gateways! It just seems wholly inefficient to me. But, the main problem with the theory of using this as a solution to direct route capacity limitations is that on the rare occasion I do fail over to the more direct route, speedtests etc are faster! So clearly there's some level of congestion on the "best" route over the "worse" one.
I feel like this is one of those legacy things Zen has, and they just don't want to do anything about it. Like I've said already. As people pick up (and actually use) 2.5gbe circuits. I wonder if this will finally cause enough of a problem for them to react.
Without seeing how their network runs across the UK its hard for us to guess the reasoning behind it. However taking data up to Manchester and back to London doesn't mean its arriving into London over any of the same fibre that it would do if going to London directly. I suspect the backbone from Manchester to London is completely different fibre to anyone finding themselves going directly to London.
According to Zen's website, they have 8 points of presence, 2 in Manchester and 6 in London. From each exchange they say they have two connections into their backhaul, each of which goes to two different core sites for resiliency, so that is probably one to Manchester and one to London. For reasons of economy and load balancing and simply knowing both routes are up and running, they have both connections in operation from each exchange, rather than one (i.e. the least optimal distance wise) simply sat doing nothing unless required. On connecting which route a customer gets is assigned round-robin style.
https://business.zen.co.uk/our-network
I'm sure this is no different to BT Wholesale as I see varying latency at random where I'm routed different ways, its just BT Wholesale have many more points of present so its not just a choice of Manchester or London so its not quite the extreme change.
Edited by E300 (Thu 27-Feb-25 16:08:23)
|
|
|
E300 beat me to it, but the cost could be something like this.
Without load balancing certain routes might need capital to upgrade the capacity, whilst having other routes under utilised, so they balance it out to get a batter return on the investment.
The vast majority of consumers wont notice this stuff, throughput is by far more important than latency. I personally would be annoyed which is why I dont use Zen, the nice thing about the UK is it does have lots of retail options. So if you dont like it move to another provider, as I agree with the others, Zen are unlikely to change how its working.
Edited by Chrysalis (Thu 27-Feb-25 18:05:50)
|
|
|
E300 beat me to it, but the cost could be something like this.
Without load balancing certain routes might need capital to upgrade the capacity, whilst having other routes under utilised, so they balance it out to get a batter return on the investment.
The vast majority of consumers wont notice this stuff, throughput is by far more important than latency. I personally would be annoyed which is why I dont use Zen, the nice thing about the UK is it does have lots of retail options. So if you dont like it move to another provider, as I agree with the others, Zen are unlikely to change how its working.
Making sure that your new provider is not another IDNet using Zen backhaul.
|
|
|
Without seeing how their network runs across the UK its hard for us to guess the reasoning behind it. However taking data up to Manchester and back to London doesn't mean its arriving into London over any of the same fibre that it would do if going to London directly. I suspect the backbone from Manchester to London is completely different fibre to anyone finding themselves going directly to London.
The problem is that with cityfibre there's no round-robin assignment about it. Once you're on Manchester, you're stuck on Manchester. Even if you connect to a London BNG (which for the last 6 months or so, just doesn't happen unless the Manchester ones are down) the route will be going via manchester (the second hop ping time will become the first hop ping time).
It used to be this way with FTTC that if you got onto a London gateway, you'd be directly connected to London. But on cityfibre something else is going on in the routing before the public IP network that makes the route you take more fixed and not connected to the BNG you connect to.
|
|
|
The vast majority of consumers wont notice this stuff, throughput is by far more important than latency. I personally would be annoyed which is why I dont use Zen, the nice thing about the UK is it does have lots of retail options. So if you dont like it move to another provider, as I agree with the others, Zen are unlikely to change how its working. I'd agree, except throughput is also lower. Speed is extremely variable when connecting via Manchester. Speedtests to the Zen London speedtest server (so I am ONLY using Zen's transit) can vary between 600/600 and 950/950. On the rare occasion I've been "failed over" to the closer London link, not only does latency drop from 13-14ms to 3-4ms. But I get consistent 900+/900+ speedtests onto the Zen speedtest server.
It's not enough to be annoying for me, and the majority of the time I am getting more than enough in terms of speed. But, I just feel like as more users upgrade to 2.5gbe, this contention is only likely to increase.
|
Pages in this thread: 
Print Thread
