1

I have an NTP server configured to use another NTP server (10.128.0.10) as its time source. Due to some network address translation, my NTP server (192.0.2.1) has the same IP address as the peer's upstream NTP server (192.0.2.1).

$ ntpq -4 -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 10.128.0.10   192.0.2.1        3 u   18   64    7    0.710   -3.887   0.926

My NTP server discards the peer due to a potential synchronization loop. Is there a means by which to disable this check? Here is my ntp.conf

server remote.peer.com

driftfile   /var/lib/ntp/ntp.drift

interface ignore wildcard
interface listen 192.0.2.1

restrict 192.0.2.0 mask 255.255.255.0 nomodify nopeer notrap

Network looks like this where the NAT is performed by a perimeter device.

192.0.2.0/24 ---> 192.0.2.1 ---NAT to 10.128.0.50/24---> 10.128.0.10/24 ---> 192.0.2.1

I cannot change IP addresses anywhere. Any help or insight would be appreciated. Thanks!

Sgt B
  • 123
  • 1
  • 5
  • Are 1.2.3.4 and 1.1.1.1 the actual IP addresses in question? Please include public IP addresses where possible, and substitute something from a documentation subnet if you want to obfuscate: https://meta.serverfault.com/questions/963/what-information-should-i-include-or-obfuscate-in-my-posts – John Mahowald Jan 06 '18 at 16:44
  • Is remote.peer.com actually using your NTP server "1.2.3.4" as a reference - do you see NTP packets from it? If so, there is little point in you referencing a server at higher stratum. It would actually be a loop. – John Mahowald Jan 06 '18 at 19:37
  • Adjusted IP addresses for clarity. The 10.128.0.10 host is *not* using my 192.0.2.1 as its peer, but another 192.0.2.1 elsewhere. Everything from my 192.0.2.0/24 network is NAT'd behind 10.128.0.50. 10.128.0.10 doesn't know anything about my 192.0.2.0/24 network, it only sees traffic from 10.128.0.50. To be clear the two 192.0.2.1 hosts above are different hosts entirely. – Sgt B Jan 06 '18 at 19:51
  • 3
    NAT breaks the IP end-to-end paradigm that is part of the IP DNA. Many protocols have problems with NAT, which really only works for TCP, UDP, and ICMP. Even protocols above TCP and UDP can have real problems with NAT. You have run into one of those problems. In any case, it is now 2018, and you should have IPv6, at least dual-stacked, and you could use that for NTP. – Ron Maupin Jan 07 '18 at 20:19
  • 1
    @RonMaupin is right - if your upstream server is syncing with a host it knows as 192.0.2.1, you won't be able to sync with it if your local address is 192.0.2.1. You need to change something in the scenario: either change your client's address, or sync with a different upstream server. – Paul Gear Jan 14 '18 at 23:10
  • Thanks everyone for the feedback. I was fairly certain this was the outcome, but it was great to get confirmation, much appreciated. – Sgt B Jan 19 '18 at 21:16

1 Answers1

1

You can confirm the error was peer synchronization loop by dumping the peer variables with ntpdc -c "showpeer 10.128.0.10" substituting the IP or host name of the peer. "flash 0x0800" indicates this error, from ntp.h.

I'm not aware of any means to disable this loop check. If the IP addresses cannot be changed you will need to find other NTP sources.

You will want to add at least 3 more reference clocks to your NTP server. This problem one doesn't count because of the loop. The NTP Pool project has many over the Internet. If you have rack space and can run an antenna outdoors, a GPS or other radio appliance will work even during an Internet outage.

John Mahowald
  • 32,050
  • 2
  • 19
  • 34
  • I used ntpq and received the 0800 code under flash noting the issue was indeed caused by a peer loop. We're working on resolving the issue with the architecture. This is the correct answer as there isn't a means by which to disable peer loop detection and that this is an architecture issue, not an NTP issue. – Sgt B Jan 19 '18 at 21:20