You might have been provisioned originally onto Zen's network if it was in place at your exchange, and I believe in that case you may have no evidence in your account info that you can see. It could be worth asking Support if you are on the Zen GEA backhaul network or on BTW. Zen have some form for ungenerously stringing along / more generously being unable to resolve performance issues for quite a few customers fortunate to find themselves on Zen's "Next generation" network... for a few of us the only fix they ever managed to do was to migrate us back to a BTW backhaul, which Zen resist.

With it having gone on for so long, and with Openreach finding no fault, it doesn't seem like too much of a stretch that this could be a part of your issues.

I asked the question of Zen. I was moved to their backhaul in February. It was done when my service was moved to SOGEA. Nothing in my account specifically about the move to their backhaul. So it's bundled under the Residential Copper to Fibre Regrade order now it seems.

My issues presented in May, so unsure if it's related as I didn't notice any major issues in February when the move happened. That's not to say something hasnt broken since then...

I have asked about being moved back to BTW to rule out a GEA problem and they have refused until they've carried out more testing.

If the connection hasn't been working since May, I'd have been trying to get out of their service a long time ago.

Think about it this way, if you move and it's no better, you can try with your new supplier. Zen aren't exactly covered in glory here, it would be hard for a new supplier to be worse at fixing it.

If you move and it is fixed (every chance, just make sure not to move to a Zen backhaul customer) then job is done.

In reply to a post by jimbof:

or a few of us the only fix they ever managed to do was to migrate us back to a BTW backhaul, which Zen resist.

They resist because it costs them far more to use a BT Wholesale service and their pricing is effectively blended. They charge everyone the same regardless if on or off-net, they make more on the on-net (their own) connections but less, or even at a loss, on the off-net. Similar to what Talk Talk did in the early 2000s where they gradually unbundled more and more exchanges.

We've used Zen in the past for some services, although no new orders due to performance and reliability concerns. Many of which have been reported here.

Whilst I cannot say much at the moment about the repeat issues we've seen. Just this week we moved one customer with continued and repeat packet loss and after the change it stopped. There was no resync during the change. https://ibb.co/8gnS9tG (The red block is just our monitoring pausing and restarting after the internal service alignment and unrelated).

It's a shame that there are still inherent issues but the run around for customers and wholesale partners alike continues.

Matt

For me it makes their services untenable - not because everyone will see the issues (clearly they won't) - but it seems that if you do, you're basically going to be playing support tag with people who appear - for whatever reasons - incapable of fixing the issues until you either leave or convince them to migrate you off-net. And even the later wasn't a solution for me, as they migrated me off only to migrate me back less than a month later...

Disappointing that wholesale customers are doing little better though, you'd expect them to have a better route into support than the great unwashed....

In reply to a post by jimbof:

And even the later wasn't a solution for me, as they migrated me off only to migrate me back less than a month later...

When they started doing the moves to on-net by stealth (no warning or notice), we asked them to stop. Even when they were doing them to exchanges which they had known congestion issues on. As you say, reversion was only temporary as their automation will just do the same later as their goal to move as much away from off-net has not changed.

Matt

In reply to a post by uno:

When they started doing the moves to on-net by stealth (no warning or notice), we asked them to stop. Even when they were doing them to exchanges which they had known congestion issues on. As you say, reversion was only temporary as their automation will just do the same later as their goal to move as much away from off-net has not changed.

Hi Matt

Appreciate the honesty and it has been an eye opener but as you're tagged here as an ISP should you really be making comments like this about another ISP? I am not linked to Zen in any way and also not a fan of theirs but I do question the professionalism of these comments as you really should be discussing this directly with them and pulling all you customers from using their backhaul if you feel that strongly.

Zen has since advised me they are seeing similar issues with a number of customers in the area and they are investigating it. I also know of non-Zen customers having the same problem so I'm led to believe this isn't Zens backhaul at fault. I've run some wiresharks and am seeing drops inbound from Zens London DC. I think the fault is in the parent exchange rather than the local one as some of the zen customers, while in the same area, do not connect to my local exchange but go back to the same headend in town. If it does turn out to be Zens backhaul at fault I'll update here as I'm sure a fault in our headend isn't of massive interest to people here.

Since my fault got escalated to the NOC team at Zen the support has been good. They've been very responsive to my emails and kept me up to date. The main complaint I have was getting it escalated in the first place and the amount of time its taken to get to this point. Since I first raised the fault in May, the ticket has been closed twice (without telling me) and I've been offered no less than 3 new routers and had my WLAN blamed. Some of the suggestions to fix my WLAN were comical, one guy asked me to change my WLAN channel to channel 8. Anyone who knows anything about WLAN knows that would actually make WLAN interference worse on the 2.4Ghz spectrum. When they eventually agreed to send an OR engineer out it was nearly 4 months from when I flagged the issues. So its just been pure pain from May until around now where there seems to be some progress.

In reply to a post by dect:

as you really should be discussing this directly with them and pulling all you customers from using their backhaul if you feel that strongly.

The comments are fair as Zen has not been just a retail provider for many years, where if that was the case, I would agree. When they started to become a channel partner, it opens this up. In reality, it is no different to commenting on BT Wholesale or Talk Talk Business; which in the past have both seen issues affecting all sorts of customers on varying CPs and has welcomed across the board comments both from "end users" and other ISP/CPs alike - this is no different.

Similarly, we are a customer of Zen too, have suffered much of what others reports and still now, years on, the same pattern and faults are reported. The two replies were not only to demonstrate how things can change from their on-net network but also explain why services moved back to off-net find themselves back on-net soon after.

Matt

Give Zen a realistic deadline to either sort it or move you to BTW backhaul, otherwise this could run and run.

Remind them if they move you to BTW backhaul it will help them prove if the local issues are with the Zen Backhaul or somewhere else, thats assuming they want to find the issue.