I have opted for a Static IP so guessing it will be a PPPoE setup

I think you'll still be DHCP but with a publicly routable IP.

That's handy, assuming it takes a workload off the router

Yes, far less intensive. Unlikely you'll see anything though unless you're using your own router that is currently constrained.

I can confirm this is the case.

"Upgraded" to a static IP and it changed over from the 100.64.0.0/16 IP to a public IP with about 5 mins downtime around 4am the next day.

My new IP is linked to AS207645 and is part of 45.137.18.0/24, which is a pretty small range!

Hi, anyone else got problem with ping 1.1.1.1 latency?

The Hey Broadband 900/900 connection is generally good but I am currently having kind of weird issue that pinging to 1.1.1.1 takes around 300ms where to other sites is only around 5ms.


PING 1.1.1.1 (1.1.1.1): 56 data bytes
64 bytes from 1.1.1.1: seq=0 ttl=56 time=311.371 ms
64 bytes from 1.1.1.1: seq=1 ttl=56 time=313.251 ms
64 bytes from 1.1.1.1: seq=2 ttl=56 time=311.067 ms
64 bytes from 1.1.1.1: seq=3 ttl=56 time=311.022 ms
64 bytes from 1.1.1.1: seq=4 ttl=56 time=311.962 ms

--- 1.1.1.1 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 311.022/311.734/313.251 ms


traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 one.one.one.one (1.1.1.1) 312.697 ms 311.719 ms 313.644 ms

No problem for me (connected to BNG Crawley)

PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=59 time=7.78 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=59 time=7.77 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=59 time=7.71 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=59 time=7.82 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=59 time=7.91 ms
64 bytes from 1.1.1.1: icmp_seq=6 ttl=59 time=7.84 ms
64 bytes from 1.1.1.1: icmp_seq=7 ttl=59 time=7.91 ms
64 bytes from 1.1.1.1: icmp_seq=8 ttl=59 time=7.71 ms

John

Also fine for me (high ping because over WiFi).

$ ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=16.0 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=58 time=16.3 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=58 time=16.5 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=58 time=14.3 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=58 time=16.3 ms
^C
--- 1.1.1.1 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4007ms
rtt min/avg/max/mdev = 14.383/15.944/16.569/0.803 ms
$

Edited by davwheat (Wed 04-Oct-23 14:12:31)

What does https://1.1.1.1/cdn-cgi/trace show, specifically which 'colo' are you on? Maybe cloudflare routing has went wrong.

Oh... that is something. Thanks a lot!

fl=582f17
h=1.1.1.1
ip=xxx.xxx.xxx.xxx
ts=1696684098.69
visit_scheme=https
uag=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36
colo=HKG


That rings the bell that I do have a VPN Director client running (ASUS Merlin).
It is strange that the IP reported by https://1.1.1.1/cdn-cgi/trace is not the same as https://www.myip.com/

Probably a bug some where in the VPN Director as the rule is configured to only apply to some clients, (not the one I am doing the test). Or, I have messed it up somehow.

When I turn off the VPN Director, the IP reported by 1.1.1.1 and myip.com now the same. Ping test to 1.1.1.1 now around 7ms.

Problem solved. Definitely have a closer look at my VPN configs. Thanks guys.