Latency / Packet Loss to Cloudflare
 

Hey,

Just wondering if anyone else has noticed some issues today with latency to cloudflare, seems to be stalling at a core router of virgins again, IP 212.250.14.2

Reply from 212.250.14.2: bytes=32 time=130ms TTL=57
Reply from 212.250.14.2: bytes=32 time=123ms TTL=57
Request timed out.
Reply from 212.250.14.2: bytes=32 time=123ms TTL=57
Reply from 212.250.14.2: bytes=32 time=36ms TTL=57
Reply from 212.250.14.2: bytes=32 time=59ms TTL=57
Request timed out.
Reply from 212.250.14.2: bytes=32 time=112ms TTL=57
Request timed out.
Reply from 212.250.14.2: bytes=32 time=37ms TTL=57
Reply from 212.250.14.2: bytes=32 time=44ms TTL=57
Reply from 212.250.14.2: bytes=32 time=126ms TTL=57
Reply from 212.250.14.2: bytes=32 time=115ms TTL=57
Request timed out.
Reply from 212.250.14.2: bytes=32 time=34ms TTL=57
Reply from 212.250.14.2: bytes=32 time=131ms TTL=57
Reply from 212.250.14.2: bytes=32 time=115ms TTL=57
Reply from 212.250.14.2: bytes=32 time=53ms TTL=57
Reply from 212.250.14.2: bytes=32 time=90ms TTL=57
Reply from 212.250.14.2: bytes=32 time=73ms TTL=57
Request timed out.
Request timed out.
Reply from 212.250.14.2: bytes=32 time=31ms TTL=57
Request timed out.
Reply from 212.250.14.2: bytes=32 time=71ms TTL=57
Reply from 212.250.14.2: bytes=32 time=70ms TTL=57
Reply from 212.250.14.2: bytes=32 time=164ms TTL=57
Reply from 212.250.14.2: bytes=32 time=55ms TTL=57
Reply from 212.250.14.2: bytes=32 time=43ms TTL=57
Reply from 212.250.14.2: bytes=32 time=144ms TTL=57
Reply from 212.250.14.2: bytes=32 time=25ms TTL=57
Reply from 212.250.14.2: bytes=32 time=181ms TTL=57
Reply from 212.250.14.2: bytes=32 time=114ms TTL=57
Reply from 212.250.14.2: bytes=32 time=57ms TTL=57
Request timed out.
Reply from 212.250.14.2: bytes=32 time=45ms TTL=57
Reply from 212.250.14.2: bytes=32 time=116ms TTL=57
Reply from 212.250.14.2: bytes=32 time=102ms TTL=57
Reply from 212.250.14.2: bytes=32 time=88ms TTL=57
Reply from 212.250.14.2: bytes=32 time=67ms TTL=57
Request timed out.
Reply from 212.250.14.2: bytes=32 time=75ms TTL=57
Reply from 212.250.14.2: bytes=32 time=62ms TTL=57

Ping statistics for 212.250.14.2:
Packets: Sent = 65, Received = 56, Lost = 9 (13% loss),
Approximate round trip times in milli-seconds:
Minimum = 25ms, Maximum = 181ms, Average = 83ms

Just wondering if anyone else is seeing the same?

1.1.1.1 seems to be giving similar results

Pinging 1.1.1.1 with 32 bytes of data:
Reply from 1.1.1.1: bytes=32 time=72ms TTL=51
Reply from 1.1.1.1: bytes=32 time=83ms TTL=51
Reply from 1.1.1.1: bytes=32 time=91ms TTL=51
Reply from 1.1.1.1: bytes=32 time=36ms TTL=51
Reply from 1.1.1.1: bytes=32 time=114ms TTL=51
Reply from 1.1.1.1: bytes=32 time=37ms TTL=51
Reply from 1.1.1.1: bytes=32 time=139ms TTL=51
Reply from 1.1.1.1: bytes=32 time=46ms TTL=51
Reply from 1.1.1.1: bytes=32 time=139ms TTL=51
Reply from 1.1.1.1: bytes=32 time=145ms TTL=51
Reply from 1.1.1.1: bytes=32 time=45ms TTL=51
Reply from 1.1.1.1: bytes=32 time=55ms TTL=51
Reply from 1.1.1.1: bytes=32 time=61ms TTL=51
Reply from 1.1.1.1: bytes=32 time=74ms TTL=51

Ping statistics for 1.1.1.1:
Packets: Sent = 14, Received = 14, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 36ms, Maximum = 145ms, Average = 81ms



Cheers!

Re: Latency / Packet Loss to Cloudflare
 

Pinging 1.1.1.1 with 32 bytes of data:
Reply from 1.1.1.1: bytes=32 time=20ms TTL=50
Reply from 1.1.1.1: bytes=32 time=21ms TTL=50
Reply from 1.1.1.1: bytes=32 time=17ms TTL=50
Reply from 1.1.1.1: bytes=32 time=17ms TTL=50
Reply from 1.1.1.1: bytes=32 time=18ms TTL=50
Reply from 1.1.1.1: bytes=32 time=18ms TTL=50
Reply from 1.1.1.1: bytes=32 time=16ms TTL=50
Reply from 1.1.1.1: bytes=32 time=19ms TTL=50
Reply from 1.1.1.1: bytes=32 time=17ms TTL=50
Reply from 1.1.1.1: bytes=32 time=17ms TTL=50

Ping statistics for 1.1.1.1:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 16ms, Maximum = 21ms, Average = 18ms




Pinging 212.250.14.2 with 32 bytes of data:
Reply from 212.250.14.2: bytes=32 time=28ms TTL=57
Reply from 212.250.14.2: bytes=32 time=24ms TTL=57
Reply from 212.250.14.2: bytes=32 time=20ms TTL=57
Reply from 212.250.14.2: bytes=32 time=23ms TTL=57
Reply from 212.250.14.2: bytes=32 time=19ms TTL=57
Reply from 212.250.14.2: bytes=32 time=20ms TTL=57
Reply from 212.250.14.2: bytes=32 time=21ms TTL=57
Reply from 212.250.14.2: bytes=32 time=21ms TTL=57
Reply from 212.250.14.2: bytes=32 time=24ms TTL=57
Reply from 212.250.14.2: bytes=32 time=20ms TTL=57
Reply from 212.250.14.2: bytes=32 time=20ms TTL=57
Request timed out.
Reply from 212.250.14.2: bytes=32 time=26ms TTL=57
Reply from 212.250.14.2: bytes=32 time=26ms TTL=57
Reply from 212.250.14.2: bytes=32 time=20ms TTL=57
Reply from 212.250.14.2: bytes=32 time=21ms TTL=57
Reply from 212.250.14.2: bytes=32 time=28ms TTL=57
Reply from 212.250.14.2: bytes=32 time=19ms TTL=57
Reply from 212.250.14.2: bytes=32 time=21ms TTL=57
Reply from 212.250.14.2: bytes=32 time=20ms TTL=57
Reply from 212.250.14.2: bytes=32 time=21ms TTL=57
Reply from 212.250.14.2: bytes=32 time=22ms TTL=57
Reply from 212.250.14.2: bytes=32 time=22ms TTL=57
Reply from 212.250.14.2: bytes=32 time=19ms TTL=57
Reply from 212.250.14.2: bytes=32 time=25ms TTL=57
Reply from 212.250.14.2: bytes=32 time=38ms TTL=57
Reply from 212.250.14.2: bytes=32 time=24ms TTL=57
Reply from 212.250.14.2: bytes=32 time=21ms TTL=57
Reply from 212.250.14.2: bytes=32 time=20ms TTL=57
Reply from 212.250.14.2: bytes=32 time=25ms TTL=57
Reply from 212.250.14.2: bytes=32 time=29ms TTL=57
Reply from 212.250.14.2: bytes=32 time=19ms TTL=57
Reply from 212.250.14.2: bytes=32 time=18ms TTL=57
Reply from 212.250.14.2: bytes=32 time=28ms TTL=57
Reply from 212.250.14.2: bytes=32 time=23ms TTL=57
Reply from 212.250.14.2: bytes=32 time=27ms TTL=57
Reply from 212.250.14.2: bytes=32 time=22ms TTL=57
Reply from 212.250.14.2: bytes=32 time=22ms TTL=57
Reply from 212.250.14.2: bytes=32 time=21ms TTL=57
Reply from 212.250.14.2: bytes=32 time=31ms TTL=57
Reply from 212.250.14.2: bytes=32 time=23ms TTL=57
Reply from 212.250.14.2: bytes=32 time=24ms TTL=57
Reply from 212.250.14.2: bytes=32 time=20ms TTL=57

Ping statistics for 212.250.14.2:
Packets: Sent = 43, Received = 42, Lost = 1 (2% loss),
Approximate round trip times in milli-seconds:
Minimum = 18ms, Maximum = 38ms, Average = 22ms

Re: Latency / Packet Loss to Cloudflare
 

Ok on BT

PING 212.250.14.2 (212.250.14.2): 56 data bytes
64 bytes from 212.250.14.2: seq=0 ttl=59 time=18.711 ms
64 bytes from 212.250.14.2: seq=1 ttl=59 time=21.519 ms
64 bytes from 212.250.14.2: seq=2 ttl=59 time=18.700 ms
64 bytes from 212.250.14.2: seq=3 ttl=59 time=18.772 ms
64 bytes from 212.250.14.2: seq=4 ttl=59 time=18.671 ms
64 bytes from 212.250.14.2: seq=5 ttl=59 time=19.243 ms
64 bytes from 212.250.14.2: seq=6 ttl=59 time=18.927 ms
64 bytes from 212.250.14.2: seq=7 ttl=59 time=19.687 ms
64 bytes from 212.250.14.2: seq=8 ttl=59 time=19.387 ms
64 bytes from 212.250.14.2: seq=9 ttl=59 time=45.499 ms
64 bytes from 212.250.14.2: seq=10 ttl=59 time=20.864 ms
64 bytes from 212.250.14.2: seq=11 ttl=59 time=22.014 ms
64 bytes from 212.250.14.2: seq=12 ttl=59 time=26.704 ms
64 bytes from 212.250.14.2: seq=13 ttl=59 time=22.866 ms
64 bytes from 212.250.14.2: seq=14 ttl=59 time=26.236 ms

--- 212.250.14.2 ping statistics ---
15 packets transmitted, 15 packets received, 0% packet loss
round-trip min/avg/max = 18.671/22.520/45.499 ms

PING 1.1.1.1 (1.1.1.1): 56 data bytes
64 bytes from 1.1.1.1: seq=0 ttl=58 time=13.554 ms
64 bytes from 1.1.1.1: seq=1 ttl=58 time=13.300 ms
64 bytes from 1.1.1.1: seq=2 ttl=58 time=12.930 ms
64 bytes from 1.1.1.1: seq=3 ttl=58 time=12.965 ms
64 bytes from 1.1.1.1: seq=4 ttl=58 time=13.388 ms
64 bytes from 1.1.1.1: seq=5 ttl=58 time=13.104 ms
64 bytes from 1.1.1.1: seq=6 ttl=58 time=13.038 ms
64 bytes from 1.1.1.1: seq=7 ttl=58 time=13.470 ms
64 bytes from 1.1.1.1: seq=8 ttl=58 time=14.407 ms
64 bytes from 1.1.1.1: seq=9 ttl=58 time=13.428 ms
64 bytes from 1.1.1.1: seq=10 ttl=58 time=13.060 ms
64 bytes from 1.1.1.1: seq=11 ttl=58 time=13.091 ms
64 bytes from 1.1.1.1: seq=12 ttl=58 time=13.405 ms
64 bytes from 1.1.1.1: seq=13 ttl=58 time=13.019 ms
64 bytes from 1.1.1.1: seq=14 ttl=58 time=13.465 ms

--- 1.1.1.1 ping statistics ---
15 packets transmitted, 15 packets received, 0% packet loss
round-trip min/avg/max = 12.930/13.308/14.407 ms

Re: Latency / Packet Loss to Cloudflare
 

Thanks guys, looks like it might be a local thing then

Re: Latency / Packet Loss to Cloudflare
 

C:\WINDOWS\system32>ping 212.250.14.2

Pinging 212.250.14.2 with 32 bytes of data:
Reply from 212.250.14.2: bytes=32 time=17ms TTL=59
Reply from 212.250.14.2: bytes=32 time=17ms TTL=59
Reply from 212.250.14.2: bytes=32 time=15ms TTL=59
Reply from 212.250.14.2: bytes=32 time=15ms TTL=59

Ping statistics for 212.250.14.2:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 15ms, Maximum = 17ms, Average = 16ms

C:\WINDOWS\system32>ping 1.1.1.1

Pinging 1.1.1.1 with 32 bytes of data:
Reply from 1.1.1.1: bytes=32 time=18ms TTL=58
Reply from 1.1.1.1: bytes=32 time=18ms TTL=58
Reply from 1.1.1.1: bytes=32 time=13ms TTL=58
Reply from 1.1.1.1: bytes=32 time=13ms TTL=58

Ping statistics for 1.1.1.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 13ms, Maximum = 18ms, Average = 15ms

Mine works fine as u can see.

Re: Latency / Packet Loss to Cloudflare
 

I was seeing a lot of packet loss to 1.1.1.1 earlier on this evening, but it seems to have gone away now.
https://www.cableforum.uk/images/local/2020/12/9.png

Re: Latency / Packet Loss to Cloudflare
 

Aggregate stats from 4 VM users here, all showing packetloss to 1.1.1.1 and 212.250.14.2 this morning indicating cloudflare issues again.

2 of the users are on RFoG, 2 on HFC, across the country (southwest, london, east anglia)

https://www.cableforum.uk/images/local/2020/12/10.png

Re: Latency / Packet Loss to Cloudflare
 

I'm back with packet loss, trying to do anything on the web is painful, timeouts because of DNS problems.

I'm temporarily switching DNS to 8.8.8.8 until this problem with cloudflare (again!) is cleared up.

Re: Latency / Packet Loss to Cloudflare
 

The issue doesn't seem to actually be with cloudflare, given the losses to 212.250.14.2 (which is inside VM's network). It's an internal VM network issue that impacts cloudflare.

Re: Latency / Packet Loss to Cloudflare
 

That's a red herring, that node is either rate limiting ICMP, blocking them as it thinks there's a DDOS or just treating ICMP packets as low priority, you can see there's a bump in latency to that node before it drops down to the final node.

I've left it capturing for last hour or so and here's the last few minutes of data.

https://www.cableforum.uk/images/local/2020/12/11.png

Re: Latency / Packet Loss to Cloudflare
 

Glad to see it's not just me, but slightly frustrating the same issue has returned

Re: Latency / Packet Loss to Cloudflare
 

You say that, but I have been running monitoring for weeks and the packet loss to the VM IP is only when there is also packet loss to Cloudflare.

So maybe that gateway is just running hot or something, but either way the issue seems to be VM's to me.

Re: Latency / Packet Loss to Cloudflare
 

Seems to be VM's last hop before handing off to cloudflare, wonder if Virgin have all their cloudflare peering running through a single endpoint...

Re: Latency / Packet Loss to Cloudflare
 

Yeah, sorry I wasn't clear, what I meant was don't take too much stock from that hop because it always looks funny. The issue last time (a few weeks back) was a VM fault so it's most likely it is them.

Also if you run back to back traceroutes to a destination with a 1s delay you'll quickly see that Hop 2 starts dropping ICMP packets.

Re: Latency / Packet Loss to Cloudflare
 

It's been wonky all evening, browsing the web was a miserable experience of page timeouts.

Suddenly though, all packet loss has stopped. The same thing happened last night.

Re: Latency / Packet Loss to Cloudflare
 

I have a server based in Germany that was having issues with cloudflare dns yesterday evening (using 1.0.0.1, at 8pm & 9pm)

Re: Latency / Packet Loss to Cloudflare
 

And looks like issue is back this evening

Re: Latency / Packet Loss to Cloudflare
 

Yep, browsing is painful.

https://www.cableforum.uk/images/local/2020/12/12.png

Re: Latency / Packet Loss to Cloudflare
 

Wonder what the best way to get someone at virgin to look at this? I can't remember how it got sorted last time, I believe there was a thread in the VM forums but I can't find it now..

Re: Latency / Packet Loss to Cloudflare
 

I posted my findings on here, there's a member of this forum who works for virgin and confirmed my results and raised a ticket.

---------- Post added at 20:27 ---------- Previous post was at 20:15 ----------

I'm also starting to get a little peeved at the frequency of the issues I'm having on a business service, I'm in south London but sadly the fastest I can get on DSL is the 70Mb service and then it suggests I'll only get 35, so I'm stuck with Virgin.

I know I keep saying it, but my service was 100% spot on and ran perfect prior to the cable being ripped out by workers with a digger in new maldon a year or so ago, and after it was restored the service has been nowhere near as stable or fast as it was previously.

And Pingnoo was born out of the problems I was having with my service!

Re: Latency / Packet Loss to Cloudflare
 

Ah excellent, happy to provide any information anyone needs to get this sorted once and for all!

Seems like saturated links on that xx.2 router as it's been fine (for me) all day until a couple of hours ago.

Re: Latency / Packet Loss to Cloudflare
 

Yep, it was fine most of the day, then like you said it all went pear shaped a few hours ago.

Re: Latency / Packet Loss to Cloudflare
 

It's 00:50 and since about 10 minutes the packet loss seems to have gone away again (this is the behaviour I saw last night)

Re: Latency / Packet Loss to Cloudflare
 

I've seen similar issues to 1.1.1.1 and cloudflare in general recently with pingnoo graphs that basically match the above, but I didn't think to check this forum. Good to know it's not just me. It does seem like VM is running their peering really hot.

Re: Latency / Packet Loss to Cloudflare
 

Surfing is once again an awful experience right now.

---------- Post added at 17:42 ---------- Previous post was at 17:01 ----------

I give up, it's impossible to use this connection.

Re: Latency / Packet Loss to Cloudflare
 

Well you could just change to google dns .....

Re: Latency / Packet Loss to Cloudflare
 

I have. The issue is not just with cloudflare DNS, it's a potential general issue browsing, changing DNS won't help if a website is using cloudflare as a CDN.

https://www.cableforum.uk/images/local/2020/12/13.png

Re: Latency / Packet Loss to Cloudflare
 

I've reported this. Ticket ref F008701533

Re: Latency / Packet Loss to Cloudflare
 

Ok, but you did not really make that very clear, you posts mostly concentrated on DNS issues ;)

Re: Latency / Packet Loss to Cloudflare
 

Yeah and that's fair, I did switch out to google DNS yesterday after this started happening, but negated to remove another entry which meant stuff was round-robbining and still causing me issues, hands up, that's my fault.

But even after solving that, I still experienced a lot of pain because a lot of the stuff I access is behind Cloudflare as a CDN, turning off the CDN on all of those domains would be a painful job! :p

In the bigger picture though, the issues with the business service (as far as how I experience them) have god considerably worse, whether this is down to COVID and there being higher usage, I don't know, but it's frustrating.

I think this is one area where the residential service is better served than the business service, there's a user forum, that means you can post and get responses from users and staff, meanwhile here on the business service you basically have to phone to get through to support who will go through the usual script before sending an engineer when you plainly know that the issue is not at your end but somewhere in the VM network.

Of course, there's "online chat" but that's almost never available, a number of times I've got onto it and say there for 15 minutes with no response before eventually closing it.

I'd kill for an official support forum for business users, I'm not even sure why this isn't a thing, you'd think that they'd want to have something like that to reduce call volume.

---------- Post added at 22:46 ---------- Previous post was at 22:44 ----------

Thank you. I honestly don't know how we'd do without you being around to help out when issues like this occur.

Imagine trying to explain this problem to the front line support who will suggest turning the router off and on again!

Re: Latency / Packet Loss to Cloudflare
 

Whatever it is, it's either co-incidence that it seems to stop at around 00:30 (people going to sleep) or something else.

https://www.cableforum.uk/images/local/2020/12/14.png

Re: Latency / Packet Loss to Cloudflare
 

It may well be traffic-related. Do you know roughly what time it starts happening? It seems to be OK at the moment.

Re: Latency / Packet Loss to Cloudflare
 

I was running the test all night, the ICMP dropping seemed to start occurring at about 4 in the morning, and got drastically worse as time went on:

https://www.cableforum.uk/images/local/2020/12/15.png

However, today (as you have said) it doesn't seem to be preventing packets getting to the final destination, the hop itself seems to be dropping ICMP packets with a TTL which would cause a time exceeded reply from that hop.

https://www.cableforum.uk/images/local/2020/12/16.png

Re: Latency / Packet Loss to Cloudflare
 

Thank you :)

fizzyade - I was thinking the same, it'd probably be less stressful to just deal with the packet loss than try and explain it to the VM call centre!

Re: Latency / Packet Loss to Cloudflare
 

This should be fixed now. VM have two links to Cloudflare, but one of them was down, so all traffic was being routed down the other, which became overloaded at peak times. The second link is now restored. Please can you check & confirm?

Re: Latency / Packet Loss to Cloudflare
 

Still seeing high packet loss on that hop, but as per the post this morning the cloudflare hop is working fine, so I assume Hop 7 is just dropping ICMP packets.

Re: Latency / Packet Loss to Cloudflare
 

Yes, I see that too, but can't really report it as a fault

Re: Latency / Packet Loss to Cloudflare
 

Out of interest, is there a reason that it does it on Hop 2? I assume it's some sort of rate limiting or DDOS mitigation kicking in.

If you ping the second hop say every 5 seconds, it will happily reply. But start pinging at 1s (or faster intervals) and after a few replies it then stops.

If you run 2 separate pings say at 2s intervals, you'll see that one of the pings losing replies, then all of a sudden it'll switch to the other one losing replies, one of them though will usually reply, you can see it flip flop.

Re: Latency / Packet Loss to Cloudflare
 

Sorry, I don't know why that happens

Re: Latency / Packet Loss to Cloudflare
 

All seemed good last night, thanks again spiderplant for raising, wondering if virgin were already aware, seems like the sort of thing they should be monitoring..

Re: Latency / Packet Loss to Cloudflare
 

Excellent.

I think they were aware that one link was down but didn't realise it was customer-affecting.

Re: Latency / Packet Loss to Cloudflare
 

Ah I see, so if this happens again we might need to (kindly) ask you to give them a prod again? :D

Re: Latency / Packet Loss to Cloudflare
 

That's slightly concerning! Link down, "no bother lads, we've got another one".

The fact that it took us, end-users, using monitoring tools to identify and confirm that there was an issue is not great, as I said earlier if you weren't around then I dread to think how long this could have rolled on for.

This is especially true when the frontline support will invariably run some diagnostics, possibly put our routers back into routed mode before declaring that an engineer needs to be sent out.

As I've said multiple times, business users desperately need an online support forum where there are actually people who are technically switched on so that when issues occur we can get them fixed. I t just seems very strange that residential users have a support forum (with techs who actually know that many issues don't involve resetting the hub or sending out an engineer).

Anybody who's lost the will to live speaking to technical support will probably feel the same.

Re: Latency / Packet Loss to Cloudflare
 

My thoughts exactly, how long would this have gone on for if we didn't have spiderplant to help us!

Re: Latency / Packet Loss to Cloudflare
 

It's because of the Christmas change freeze. Faults that aren't believed to be customer-affecting don't get fixed until after freeze ends. As soon as I pointed out this one actually was customer-affecting, it was fixed straight away.

Re: Latency / Packet Loss to Cloudflare
 

Makes sense, and to be fair i was impressed how quick it was sorted after you raised it :)

Re: Latency / Packet Loss to Cloudflare
 

I think "Sir Spiderplant" has a certain ring to it!

Seriously though, I'm very grateful that you hang out here and that you're so proactive in getting things done when us more technical bods think something isn't right.

The funny thing is, that when we spot a fault of this kind (that others probably wouldn't even think is a fault or notice) we are much less likely to even consider talking to customer support because we know beforehand how the conversation is going to go.

The flakyness of the connection is partly what inspired me to write pingnoo, so that I would have the ability to see what was going on with the connection over a period of time, the other part was that pingplotter is crippled and I didn't feel like buying it....so I did what any programmer does, rolls their own.

Re: Latency / Packet Loss to Cloudflare
 

It's a common failure scenario. One link goes down, other links take the strain and everything looks okay and you can sort the dead link in due course. But because the links and kit on them were specced years ago and are now carrying 25% more traffic individually, they aren't going to handle 2x the present load.

The signs of an overloaded route are also incredibly hard to create alerting for, as different bits of kit will do different things when faced with too much to do. Way too easy to create false alarms and those are the bane of monitoring systems, so unless you know what the failure looks like exactly and it has been accounted for in your alerting, you usually wont know it's happening without someone experiencing it directly.

And don't get me started on asynchronous routing...

Re: Latency / Packet Loss to Cloudflare
 

Was just working on some stuff and noticed that routing to Cloudflare has changed now, it seems to hop across to Europe for a laugh now.

https://www.cableforum.uk/images/local/2021/01/6.png

Re: Latency / Packet Loss to Cloudflare
 

Interesting, those twelve99 hops look new

1 10.53.34.245 (10.53.34.245) 11.661 ms 9.542 ms 10.772 ms
2 gate-core-2b-xe-705-0.network.virginmedia.net (62.252.43.45) 11.037 ms 11.897 ms 13.197 ms
3 * * *
4 86.85-254-62.static.virginmediabusiness.co.uk (62.254.85.86) 27.816 ms 28.488 ms 28.142 ms
5 ldn-b1-link.telia.net (213.248.84.25) 26.882 ms 25.126 ms 33.002 ms
6 ldn-bb1-link.ip.twelve99.net (62.115.120.74) 36.019 ms 39.188 ms
ldn-bb4-link.ip.twelve99.net (62.115.122.180) 29.973 ms
7 dln-b2-link.ip.twelve99.net (62.115.120.105) 37.692 ms
dln-b2-link.ip.twelve99.net (62.115.120.101) 38.170 ms 36.564 ms
8 cloudflare-ic-310815-dln-b2.c.telia.net (62.115.55.14) 40.052 ms 42.718 ms 38.989 ms
9 one.one.one.one (1.1.1.1) 35.234 ms 39.239 ms 37.009 ms