Thanks for the update, sounds like an interesting one.

In reply to a post by ft247:

Thanks for the update, sounds like an interesting one.

It is an interesting fault for sure and I'm learning a lot.

Unfortunately it's impacting one of my users quite badly, poor bloke!

Update on the fault:

Spoke to the two senior openreach engineers who visited today. They make a very convincing case that the issue is not in OpenReach domain - it's not a copper fault, DSL statistics are absolutely fine and successive lift-and-shifts have effectively ruled out a fault in a port or linecard on the DSLAM.

They advise that the only troubleshooting step not carried out is a 'soft cease and reprovide' which will need to be requested by BT.

My feeling is that Wholesale need to look at their network harder.

I think openreach will soon be refusing to visit for this fault as it's a waste of everybody's time.

So in summary.... the saga continues

Essentially the openreach guys said that from the DSLAM there's a fibre link to the exchange which terminates on an openreach 'ADVA' and everything beyond that is out of openreach domain, ie BT Wholesale's problem.

Does that sound about right?

Technically I believe it is Openreach's problem to get the packets out of a layer 2 switch (which may or may not be made by ADVA, or be the same box that the DSLAM fibre terminates on) onto a fibre its way to BT Wholesale's equipment.

But it sounds like you might have had people who knew what they were talking about, at least regarding the operation of the DSLAM - if they've made sure that one of the port shifts was to a different line card and concur that the DSL is fine, that makes it pretty unlikely that the DSLAM is at fault.

The only other thing I'd question would be whether the DSLAM has one fibre link to the exchange or multiple - I have heard anecdotally that busy DSLAMs receive extra gigabit links. I don't know how the traffic is balanced across these links - if it's round-robin then this isn't the cause of the fault, as it would affect every customer, if it's a cruder method there could be something there if one of the optics is failing. But this is less likely than a failing optic between L2S and BT Wholesale, which is my guess at this point. BT Wholesale may have multiple in that exchange, and I believe customer circuits are assigned to specific cablelinks, rather than a LAG being formed.

There's a lot of speculation here - hopefully someone with deeper knowledge of the exchange end can tell us more. But if I were BT Wholesale I'd look at whether your problem circuits all share a cablelink in the exchange.

Is the Zen site on BT Wholesale? Can you try the Gamma PPP credentials out there? Someone who knows more than me could probably say whether BTW customers are segregated from each other and whether this is likely to work or not.

In reply to a post by jpm:

Is the Zen site on BT Wholesale?

This is quite possibly the common thread.

VDSL2 layer / copper loop sounds Iike it all checks out OK. What’s common upstream - possibly cablelink(s) if Zen are using BTW backhaul? Line card on the L2S at the exchange?

There could be a over-utilisation issue on common SVLAN? as well. OP might be a able to request a move to a different BTW SVLAN.

Pheasant

Unlikely to be SVLAN issue as these are easily visible to BTW and the ISP..More likely a card on the L2S at the exchange or the distant end of the link at the Core Node. I spent some time trying to identify packet loss on a link many years back and could only pin it down when the card went completely off and the loss stopped due to switching to the resilient card. Tracking back identified the issue to the exact time the card went OOS.

It is very difficult to track when the packets are just dropped in the switch so are never counted on a link and don't show as lost in any stats. Only way we thought about was pulling 'control' cards in the switch when it was suspected to force a switch to the resilient card.

Any issue like this should be affecting every customer on that BTW switch. card, so there should be lost of people complaining. ..

In reply to a post by kitcat:

Pheasant

Unlikely to be SVLAN issue as these are easily visible to BTW and the ISP

You're having a laugh.
I've been on more hot SVLANs with BT Wholesale than I've had hot dinners.

Providers also can't see BT Wholesales SVLAN utilisation.

Just Google "BT Wholesale hot SVLAN" and you will be able to find days worth of reading that will show just how odd your comment above is.

Edited by j0hn83 (Thu 31-Mar-22 21:35:15)

john83

Zen will have a separate SVLAN for it's contracted capacity and can see it's utilisation. BTR will be in different one. To get a 10% packet loss the VLANs would have to be massively over subscribed on both.