Why use pfsense as an NTP server?
-
@occamsrazor
You have a low reachability : 7 vs 377
And the jitter of you peers seems "crazy".The delay seems very high : Is this a heavy loaded line or radio/sat based ?
Something seems fishy
-
@bingo600 said in Why use pfsense as an NTP server?:
You have a low reachability : 7 vs 377
And the jitter of you peers seems "crazy".
The delay seems very high : Is this a heavy loaded line or radio/sat based ?
Something seems fishyAgree something seems odd. It's a 50mb fiber line, albeit in Africa. Pings to most NTP servers are around 200ms.
On the Mac side, something is odd. I read these threads:
https://forums.macrumors.com/threads/time-synchronization-command-line-in-macos-big-sur.2279396/
https://apple.stackexchange.com/questions/414088/macos-timed-wont-keep-accurate-time..and it seems there is some weirdness. I tried installing ChronyControl on the Mac:
https://chrony.tuxfamily.org/index.html
https://whatroute.net/chronycontrol.html#overview....and then using that to set the time direct from pfSense server and it seemed to work:
MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== ^* 192.168.0.1 2 6 17 24 +41us[ +148us] +/- 114ms
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev ============================================================================== 192.168.0.1 4 3 6 +38.937 455.940 +1482us 52us
Remote address : 192.168.0.1 (C0A80001) Remote port : 123 Local address : 192.168.0.10 (C0A8000A) Leap status : Normal Version : 4 Mode : Server Stratum : 2 Poll interval : 6 (64 seconds) Precision : -24 (0.000000060 seconds) Root delay : 0.202484 seconds Root dispersion : 0.011719 seconds Reference ID : 11FD7A7D () Reference time : Sun Aug 22 16:57:16 2021 Offset : -0.000148106 seconds Peer delay : 0.002995686 seconds Peer dispersion : 0.000007154 seconds Response time : 0.000051314 seconds Jitter asymmetry: +0.00 NTP tests : 111 111 1111 Interleaved : No Authenticated : No TX timestamping : Daemon RX timestamping : Kernel Total TX : 4 Total RX : 4 Total valid RX : 4
I think the best troubleshooting would be to try sntp from a non-Mac machine to see if that was different, but at the moment I don't have any.
-
Was going to point you to this one
https://forums.macrumors.com/threads/time-synchronization-command-line-in-macos-big-sur.2279396/Until i saw your post there 34min ago
Seems like chrony is the way to go
Btw: Can you post your ntp stats again ?
Maybe Reach has improved/Bingo
-
@bingo600 said in Why use pfsense as an NTP server?:
Seems like chrony is the way to go
It does, if this kind of thing is critical. Which in my case it isn't really, I just liked the idea of all my devices syncing to pfSense. But as most are Macs and there seems to be an issue, it doesn't seem all that worthwhile to pursue the force redirect to pfSense option.
Btw: Can you post your ntp stats again ?
Maybe Reach has improvedYou must be clairvoyant....
It seems I may have restarted the NTP server shortly before I posted the stats in the previous post, as after restarting the Reach slowly continues to rise until it hits 377.... some googling brought me this...
https://www.linuxjournal.com/article/6812
-
Yeah reach can take a few checks before it shows 377, which just means you have gotten answers for your last 8 checks.
-
@johnpoz said in Why use pfsense as an NTP server?:
Yeah reach can take a few checks before it shows 377, which just means you have gotten answers for your last 8 checks.
Precisely
https://www.ntp.org/ntpfaq/NTP-s-trouble.htm8.1.4. What does 257 mean as value for reach? (Inspired by Martin Burnicki) The value displayed in column reach is octal, and it represents the reachability register. One digit in the range of 0 to 7 represents three bits. The initial value of that register is 0, and after every poll that register is shifted left by one position. If the corresponding time source sent a valid response, the rightmost bit is set. During a normal startup the registers values are these: 0, 1, 3, 7, 17, 37, 77, 177, 377 Thus 257 in the dual system is 10101111, saying that two valid responses were not received during the last eight polls. However, the last four polls worked fine.
Btw:
It's not often you see a Stratum 2 server selected as Active Peer , when there's several Stratum 1 servers available.
Something must be disqualifying them./Bingo
-
@occamsrazor said in Why use pfsense as an NTP server?:
albeit in Africa
You prob want to use the Africa pool then
https://www.pool.ntp.org/zone/africa
server 0.africa.pool.ntp.org server 1.africa.pool.ntp.org server 2.africa.pool.ntp.org server 3.africa.pool.ntp.org
Not sure exactly where your at in Africa - but these should be closer to you.. See the link for all the different pools for the Africa Zone..
Those ones with huge delays are not really going to be good sync choices.
-
@johnpoz said in Why use pfsense as an NTP server?:
You prob want to use the Africa pool then
https://www.pool.ntp.org/zone/africaVery good point! I'm in Kenya and just did some ping tests. Often I avoid servers located in Africa and prefer others as sometimes routing can be weird here, e.g. traffic via undersea cable often goes via Dubai/Mideast, so other places in Africa can often have higher pings than Europe does. But in this case it does seem to be faster...
PING pool.ntp.org (162.159.200.1): 56 data bytes 64 bytes from 162.159.200.1: icmp_seq=0 ttl=52 time=142.945 ms PING ntp1.glb.nist.gov (128.138.141.172): 56 data bytes 64 bytes from 128.138.141.172: icmp_seq=0 ttl=40 time=270.877 ms PING europe.pool.ntp.org (162.159.200.1): 56 data bytes 64 bytes from 162.159.200.1: icmp_seq=0 ttl=52 time=143.169 ms PING africa.pool.ntp.org (41.220.128.73): 56 data bytes 64 bytes from 41.220.128.73: icmp_seq=0 ttl=51 time=110.317 ms PING 0.africa.pool.ntp.org (41.78.128.17): 56 data bytes 64 bytes from 41.78.128.17: icmp_seq=0 ttl=49 time=67.826 ms PING 1.africa.pool.ntp.org (197.82.150.123): 56 data bytes 64 bytes from 197.82.150.123: icmp_seq=0 ttl=50 time=75.761 ms
I still don't seem to be getting a Stratum 1 server though, if that matters...
It then occurred to me - should time.nist.gov, apple, google, etc and the other servers that are not xxx.ntp.org - should they be marked as "Pool" type ones in settings? When I un-mark them as pool I get different results:
-
@occamsrazor no they wouldn't or shouldn't be marked as pool if they come back as single IPs..
So if your going to call out just time vs time1 and time2, etc. for googles ntp, that could very will be a pool.. Same with time.apple.com, but for say time.nist.gov I only show this as answer
;; ANSWER SECTION: time.nist.gov. 3600 IN CNAME ntp1.glb.nist.gov. ntp1.glb.nist.gov. 3600 IN A 132.163.97.4
If the Africa pool is bad for you - yeah could very well be bad peering to cause what you would think should be much lower latency.
I would find some good servers that are as close as you can find.. There are full public lists that you can try and find some that have low delay to you and set those specific vs trying to use a pool. What about the ones listed to be in kenya, what sort of pings do you get to them?
;; QUESTION SECTION: ;ke.pool.ntp.org. IN A ;; ANSWER SECTION: ke.pool.ntp.org. 3600 IN A 160.119.216.202 ke.pool.ntp.org. 3600 IN A 160.119.216.206 ke.pool.ntp.org. 3600 IN A 162.159.200.1 ke.pool.ntp.org. 3600 IN A 162.159.200.123
If your interested in time servers - you could always run your own ;) They can be made with some inexpensive pi or other type low cost sort of computers. There are few here on the board that run them.. I run my own on a pi, etc. Just because its a fun project and ntp is a fascinating protocol..
If that is something that might interest you - here is a link that could get you started.. There are many other resources around as well.
-
@johnpoz said in Why use pfsense as an NTP server?:
@occamsrazor no they wouldn't or shouldn't be marked as pool if they come back as single IPs..
What command do you use to generate that "Answer section" to see if they are Pool or not?
If the Africa pool is bad for you - yeah could very well be bad peering to cause what you would think should be much lower latency.
I would find some good servers that are as close as you can find.. There are full public lists that you can try and find some that have low delay to you and set those specific vs trying to use a pool. What about the ones listed to be in kenya, what sort of pings do you get to them?I added ke.pool.ntp.org and africa.pool.ntp.org and it found some quite local servers with 10ms delays which were sometimes chosen as the active peer, but other times their jitter was higher than time.google.com even though its delay was around 140ms and time.google.com got chosen. It seemed to like time.google.com much of the time.
If your interested in time servers - you could always run your own ;) They can be made with some inexpensive pi or other type low cost sort of computers. There are few here on the board that run them.. I run my own on a pi, etc. Just because its a fun project and ntp is a fascinating protocol..
If that is something that might interest you - here is a link that could get you started.. There are many other resources around as well.
Thanks, it does look interesting, but a bit above my time and effort possibilities at the moment. I do find NTP interesting though...
-
@occamsrazor the command is just dig.. Pretty standard on any linux or bsd box, and you can install it on windows with the isc bind, just the tools only.
here is from my windows 10 machine
C:\ $ dig pool.ntp.org ; <<>> DiG 9.16.19 <<>> pool.ntp.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50475 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;pool.ntp.org. IN A ;; ANSWER SECTION: pool.ntp.org. 30 IN A 38.229.52.9 pool.ntp.org. 30 IN A 150.136.0.232 pool.ntp.org. 30 IN A 66.151.147.38 pool.ntp.org. 30 IN A 66.85.78.80 ;; Query time: 6 msec ;; SERVER: 192.168.3.10#53(192.168.3.10) ;; WHEN: Sun Aug 22 17:30:24 Central Daylight Time 2021 ;; MSG SIZE rcvd: 105 C:\
-
@johnpoz said in Why use pfsense as an NTP server?:
@occamsrazor the command is just dig.. Pretty standard on any linux or bsd box, and you can install it on windows with the isc bind, just the tools only.
Thanks, I wasn't aware of that command, and it is inbuilt on OSX as well. Testing the various public servers it would seem that:
xxx.pool.ntp.org
time.apple.com
time.google.com
time.cloudflare.com...are all POOL type addresses, in that dig reports multiple addresses. While these report single addresses...
time.nist.gov
time.facebook.com
time.windows.comSo that's good to know.
I did some more testing with the redirect rule and just can't work out what is happening but I feel it is OSX specific. When I enable the rule with logging I see that NTP requests from some devices on my network get passed to pfSense server and are successful. But requests from my Mac and IOS devices seem to have several attempts failing and others succeeding:
From Macbook running OS Big Sur 11.5.2
~ % sntp time.nist.gov sntp: Exchange failed: Server not synchronized sntp: Exchange failed: Timeout sntp: Exchange failed: Timeout sntp: Exchange failed: Timeout +0.333886 +/- 0.074646 time.nist.gov 128.138.141.172
States
LAN udp 192.168.0.10:50683 -> 127.0.0.1:123 (128.138.141.172:123) NO_TRAFFIC:SINGLE 1 / 0 76 B / 0 B LAN udp 192.168.0.10:57476 -> 127.0.0.1:123 (128.138.141.172:123) SINGLE:MULTIPLE 1 / 1 76 B / 76 B LAN udp 192.168.0.10:60443 -> 127.0.0.1:123 (128.138.141.172:123) SINGLE:MULTIPLE 1 / 1 76 B / 76 B LAN udp 192.168.0.10:64340 -> 127.0.0.1:123 (128.138.141.172:123) NO_TRAFFIC:SINGLE 1 / 0 76 B / 0 B LAN udp 192.168.0.10:64702 -> 127.0.0.1:123 (128.138.141.172:123) NO_TRAFFIC:SINGLE 1 / 0 76 B / 0 B
And I get exactly the same when trying to NTP directly to pfSense server:
~ % sntp 192.168.0.1 sntp: Exchange failed: Server not synchronized sntp: Exchange failed: Timeout sntp: Exchange failed: Timeout sntp: Exchange failed: Timeout +0.335554 +/- 0.072990 192.168.0.1 192.168.0.1
Whereas here is that same Macbook using chronyd to sync, instead of the native ntp client:
LAN udp 192.168.0.10:57610 -> 127.0.0.1:123 (132.163.96.1:123) SINGLE:MULTIPLE 1 / 1 76 B / 76 B
While other devices seem to have only one attempt and succeed (an APC UPS here) to external NTP servers being redirected to pfSense:
LAN udp 192.168.0.210:38141 -> 127.0.0.1:123 (132.163.97.4:123) SINGLE:MULTIPLE 1 / 1 76 B / 76 B
So I'm starting to think it's maybe not something about the redirect, but rather OSX NTP client implementation issue with the pfSense NTP server.
-
Try running it with the debug flag. Perhaps OSX defaults to some authentication?
Steve
-
@occamsrazor I had to use -S switch to get it to work on MacOS
sntp -S pool.ntp.org
-
Thanks for the replies. I installed ChronyControl on both my Macs and disabled the inbuilt NTP client and it seems to be working. Unfortunately I don't have enough time to investigate it all much further now, and in any case I like the functionality that ChronyControl brings so will stick with that for now.