NTP in IPv6
-
I did a search in this forum on "NTP IPv6" before posting, so I hope I'm not covering old ground. OpenNTPD does not seem to respond to queries sent to IPv6 addresses. It works for IPv4. This took awhile to figure out, but now I'm certain that's what is happening. Is this a pfSense or FreeBSD issue?
-
Sidebar: what is supposed to be logged under the OpenNTPD tab? This is running now (IPv4 only), but nothing is ever logged.
-
Not a fan of openntp - not sure if it does ipv6 either. Which for sure support ipv6 and lots of other things, like actually doing a query to it for status, etc. ntpq or ntpdc both work, etc.
I just replaced the ntpd bin of openntp with the actual ntpd
just do a pkg_add -r ntp to get 4.2.6p5
copy over the ntpd to where pfsense has it sorted – you can find it with, find / -name ntpd
edit your /etc/ntp.conf how you like it and then just manually start ntpd
There you go -- why they go with openntp I have no close, its no where close to a the real ntp.
-
Thanks for the info. I have both of my pfSense boxes syncing to the NIST server in Virginia (however often they exchange NTP packets–I haven't checked that yet), my domain controllers syncing to the pfSense boxes every five minutes, and all other clients/servers using AD DS to sync to the DCs (I think every hour--must check that too). The difference between the NIST clock and the clocks on my (stratum four or five?) clients has yet to exceed 1/20th of a second. That's far more accurate than I expected and certainly more than I require. I would just like to break any dependence on IPv4 (even though I won't be getting rid of it anytime soon).
-
why would you be syncing every anything?
setup your dc as authoritative time source yes for your members - but just run ntp client on them. Here is a great port of ntp to windows
http://www.meinberg.de/english/sw/ntp.htm
I sure would not set anything to sync every 5 minutes, ntp is designed to make minor adjustments to the clock to keep in sync with good time source. You should not have to set it to any source every 5 minutes, just let ntp do its thing.
Not a fan of the built in windows time sync, but it can be adjusted to work ok for all windows boxes other than your authoritative time source you setup.
-
I'm sorry; I guess I wasn't clear. I am using AD DS to sync the clients with the DCs. The DCs are manually configured as NTP clients (using the DC GPO) so that they are synced to a domain-external time source (pfSense in this case). The DCs are the authoritative time source for the domain. Actually only the PDC is authoritative, but I have the other DC synced to pfSense also (rather than to the PDC) so there will be less configuration to contend with should I ever need to move the PDC role to the other DC. I know I could have synced them directly to NIST, but I wanted to experiment with pfSense's NTP functionality.
When configuring the DC as an NTP client, I set the NtpServer 0x1 (SpecialInterval) and 0x8 (Client) flags (see
http://technet.microsoft.com/en-us/library/cc779560(v=ws.10).aspx) when specifying the NTP server. This is the Windows default for manual NTP configuration (in Server 2008 and 2008 R2), incidentally. The 0x1 flag tells the client to use the value of the SpecialPollInterval instead of the one calculated by NTP's timing algorithm. This does (as the mentioned article states) sacrifice clock accuracy for less network traffic, but 0.05 seconds is accurate enough and polling once every five minutes is insignificant, I should think. I've used Meinberg before and I may again should it prove necessary, but after spending much of yesterday determining how to do it with Windows, I'll try that first. If I've harbored any doubt about how NTP works, I don't any longer.I was hasty in my last post–while it's true that my DCs have yet to differ from NIST by more than 0.05 seconds, my clients are getting off by significantly more. That is why I am concerned with the polling interval (if in fact there even is one) used by Windows when using AD (NT5DS) for synchronization between clients and DCs. It seems like I had read somewhere that they exchange timing info every hour, but that's incorrect. An hour is the default for manual NTP configuration in Windows--not the built-in AD mechanism. I've been monitoring the client machine I'm using now for over four hours and it just this minute resynced (having diverged by 8 seconds in that time). I would like more accuracy than that. Does this mean it went over four hours between polls? How then is the SpecialPollInterval going to conserve traffic? If AD is using an NTP algorithm internally and convergence is this slow, then I'll have to configure the clients manually with group policy to sync more regularly and traffic be damned (once every fifteen minutes or so is nothing anyway). I chose to do it this way initially because it is default, but after I get a chance to see how much traffic is generated by NTP "do[ing] its thing", I'll reevaluate. I know NTP makes adjustments to the clock (presumably adjustments which become finer as the accuracy climbs). Does it also elongate its polling interval as a function of accuracy?
-
"but I have the other DC synced to pfSense also (rather than to the PDC)"
Not really the MS way to do it ;) Only one of your DC (your correct the one with the PDC emulator role) should sync to external, and others should sync of it.
"but I wanted to experiment with pfSense's NTP functionality. "
If your going to continue to run openntp – you will soon find a complete and utter lack of anything to do with ntp really? Not sure why they don't just use native ntp client vs that nonsense openntp thing. You can not even query it for status - you can not create any logs from it, etc. It might be fine for a router, but as a time source for your other devices on your local network to use - not so much.
"once every fifteen minutes or so is nothing anyway"
make sure you are doing a poll for time, not a actual adjustment.
-
I got the idea from http://technet.microsoft.com/en-us/library/cc784800(v=WS.10).aspx. My thinking is, rather than having to reconfigure a backup if the primary fails, why not have the backup in a sort of hot-standby mode. Right now, configured as it is, both DCs are acting as Always/Always Reliable time sources (both have AnnounceFlags set to 5). And, being identically configured and synchronized to the same source, they should converge to being as closely synchronized with one another as they would be if one were directly synchronized to the other. I could disable the NtpServer setting on the backup if I only wanted one time source available at a time, but leave the NtpClient enabled so it would remain in sync. What could go wrong with this scenario if I leave it as it is? If I disable NtpServer on the backup? (Not rhetorical questions ;D)
Yeah, I am questioning why I don't just bypass the pfSense box entirely and sync directly to NIST. Still nothing in the OpenNTPD log; I don't get that. I might have determined the IPv6 problem faster with better feedback from the server and logs. It is keeping my DCs within 0.05 seconds of NIST, though, and it is in default mode (there is no other :)), so whatever traffic is getting sent over my WAN is (un)throttled by OpenNTPD. I need to check that for curiosity's sake.
What do you mean by your final statement? Something tells me this relates to my last question in the last post. I get NTP's making clock adjustments and I get that there is a tipping point at which NTP will just resync the time (even though it may appear to "skip" briefly) instead of adjusting the clock rate for a more gradual convergence. My question is: does the polling interval get adjusted as well? As the clock becomes more accurate relative to the trusted source, are fewer polls necessary (and hence fewer used) in a given time span to keep it accurate? That would seem sensible and the presence if MinPollInterval and MaxPollInterval would seem to verify that being the case, but that would mean there would be more traffic at the beginning of the synchronization process and less as it continued. Why did my client allow over four hours to elapse before correcting an eight second discrepancy? Did the size of the discrepancy (small by NTP's reckoning?) affect the duration of the polling interval? The default MaxPollInterval when clients are configured manually is 1024 seconds (about 17 minutes), but it must be considerably longer when the clients are in automatic mode (or else I'm missing something).
