In reply to a post by jpm:

It's not really a "led to believe" thing, CGNAT is easy to spot.

To reply to the replies to my post throwing CGNAT into the ring, thanks to all.

After a working life which involved much hunting for weird happenings, and given Zen's apparent refusal for weeks even to accept there was a problem, I've just started throwing "outside possibilities" into the ring. In the hope it might spark a memory or thought in one of those here who I accept are far more up-to-date than I on networking.

I'm happy to be shot down each time , but more than once in the past I have hit on something that has been simply forgotten as a possibility because others have gone too deep because the obvious is expected to have been ruled out by first-line.

Zen seemed to be working on the premise the fault had to be at the user premises because only the LAN seemed to be affected.

Since my post, the UDP v TCP question has been raised and looks to me to be very relevant.

FakeJake

Apologies mixing threads up. It is not the FTTP part that is causing the issue but a Core or backhaul network issue somewhere. The move to the Zen network has changed the routeing to a different set of boxes some of which appear to be having an issue.

Not sure if ZEN builds it's own network or rents it from others I got the impression from elsewhere that they may be renting some of it from Cityfibre (Rather than BTW) .

Waiting with baited breath.... No new yet....Guess same for you all?

An update from Zen:

I’m still analysing the data we gathered from the testing. I have no immediate conclusions, but I have a couple of areas to investigate further.

The tests do show packet loss on the UDP tests, and poor performance on the TCP tests. I’m analysing the TCP data in more depth as that does have some areas of concern for me.

So.... We must wait....

The data we captured was very useful. We'll now be having further conversations with Openreach. I believe not all data sent into the GEA Cablelink link is getting to the server attached to the ONT.
We'll need to discuss that in more depth.

Thanks for the extra clarity Brandon. It's all very interesting, and I am really keen to understand what actually happened. In the meantime, I will continue using my Apple router as it's a lot better than the Fritz (I tried that one again earlier today)

So it looks like the GEA link is to blame? I guess that makes sense as this wouldn't have been in the picture prior to migration. (I say knowing that I know nothing about how any of this works)

Hope you guys can get this sorted quickly now that you have something to go on.

In the meantime, please can I have my IPv6 back? It hasn't worked since this migration happened. Happy to email the IPv6 team if it's more appropriate🙂

Edited by FakeJake (Wed 13-Apr-22 16:28:29)

FakeJake

As GEA links are site (and equipment) specific is sounds as if some configuration parameters are being set incorrectly across the network. As it has only been reported affecting Zen links it sounds like Zen configuration.

Wondering if (downstream) packet size is incorrect or a rate setting is too high that leads to packets being discarded by the (OR) edge router.

GEA bandwidth sending more than the capacity they have brought could lead to this, eg 10Gb port but only brought 2Gb capacity, bursts to 2.1Gb and loses 0.1Gb as the GEA will take the extra but the Edge router will police it down. by dropping packets.

This is a case of the more you know, the less you realise you know. Thanks for the info 👍

In other news, what happened at midnight? https://www.thinkbroadband.com/broadband/monitoring/...

I know that it's been Easter etc, but wondering if anyone has any updates on this as the situation hasn't changed from my perspective?