Are any of you guys running any other monitoring thats showing the same issue at the same time?

Yep - three packet loss events / spikes...

https://www.thinkbroadband.com/broadband/monitoring/...

Theres also a very noticeable step change in minimum latency on the 25th and 26th in the early PM on both days.

See here and here

Which to be fair I've not noticed previously (or for that matter paid much attention to the significance). There have been other step changes in latency as if routing is changing recently.

Edited by Pheasant (Fri 04-Nov-22 22:08:14)

Yes sir. Its evident on other third party (external - as in outside the UK) monitoring I have running.

Edited by Pheasant (Fri 04-Nov-22 22:03:24)

I'm getting alerted that VPN tunnels are flapping, so this isn't just s BQM thing

Just wanted to throw that possibility into the ring just in case but from what you and Pheasant have said its something much more serious

Yep it’s not just a rough looking BQM it’s actual loss of service at the time it’s been flapping. I’m seeing this (a) in the loss of the service from within, (b) BQM graphs and (c) other external (USA) monitoring tools which are alerting to connection loss.

So yes BQM is doing its job; its an accurate reflection of the state of the service under test. It’s not (just) a routing issue / glitch between TalkTalk and TBB servers.

Just to add there’s no indication this is an Openreach ‘last mile’ FTTP connection issue - the PON has been solid throughout from what I could see.

Edited by Pheasant (Sat 05-Nov-22 07:26:09)

In reply to a post by jpm:

I'm getting alerted that VPN tunnels are flapping, so this isn't just s BQM thing

Ditto I have a site to site tunnel that is flapping when this happens. Can’t see that PPPoE session is being dropped**, just heavy / total packet loss. The fact it’s happening approximately around the same peak evening time as previous day suggests to me it could be load related somewhere in their core network.

** need to really inspect router logs properly. This might not be accurate.

Edited by Pheasant (Sat 05-Nov-22 07:36:16)

Well so far today (early doors so prob tempting fate) the graph is far cleaner at the baseline.

I'm wondering why I never did a traceroute back to the connection in question when it was having problems to see if the hop with the issues could be observed. As much as I would like the problem not to come back, I'd at least like to see where it is if it does.