I have five servers that I'm configuring for production use based on a configuration we've recently tested. The servers are RHEL6 with NTP version 4.2.4p8@1.1612-o. Right now, though, I'm trying to figure out the solution to this by only having two servers running at one time. When complete it will consist of the five NTP servers, each using a SHA1 key. According to the associations command in ntpq all authentication is working.Server 1:ind assID status  conf reach auth condition  last_event cnt===========================================================  1 50914  9314   yes   yes  none   outlyer   reachable  1  2 50915  9414   yes   yes  none  candidat   reachable  1  3 50916  9314   yes   yes  none   outlyer   reachable  1  4 50917  9414   yes   yes  none  candidat   reachable  1  5 50918  9614   yes   yes  none  sys.peer   reachable  1  6 50919  f014   yes   yes   ok     reject   reachable  1(The last entry is my server. The other five are external time sources).The peer output shows that it is able to communicate with Server 2:ntpq> pe     remote           refid      st t when poll reach   delay   offset  jitter==============================================================================-192.5.41.40     .PTP.            1 u   11   64  177   24.125   -1.858   5.692+ntp-s1.cise.ufl .GPS.            1 u   23   64  177   36.340    0.443   0.235-ntp.colby.edu   .GPS.            1 u   30   64  177   23.204   -0.474   0.221+navobs1.oar.net .GPS.            1 u   26   64  177   26.496    0.671   0.755*gnomon.cc.colum .USNO.           1 u   21   64  177   10.862    0.422   0.304 server2.        128.59.39.48     2 u  366   64  100    0.256   -1.010   0.000Server 2:ind assID status  conf reach auth condition  last_event cnt===========================================================  1 21528  9314   yes   yes  none   outlyer   reachable  1  2 21529  9414   yes   yes  none  candidat   reachable  1  3 21530  9414   yes   yes  none  candidat   reachable  1  4 21531  9614   yes   yes  none  sys.peer   reachable  1  5 21532  9314   yes   yes  none   outlyer   reachable  1  6 21533  e07f   yes   yes   ok     reject              7As you can see, the last entry is able to successfully authenticate, but it does not see Server 1 as reachable. The `peer' output shows that there is an issue with the Autokey protocol:ntpq> pe     remote           refid      st t when poll reach   delay   offset  jitter==============================================================================-192.5.41.40     .PTP.            1 u    1   64  177   26.081   -2.240   4.083+ntp.colby.edu   .GPS.            1 u   15   64  177   23.506    0.343   0.530+navobs1.oar.net .GPS.            1 u   19   64  177   26.477    1.622   0.758*gnomon.cc.colum .USNO.           1 u   13   64  177   11.332    0.985   0.713-navobs1.gatech. .GPS.            1 u   17   64  177   34.621   -1.261   0.753 Server1.        .CRYP.           16 u  410   64    0    0.000    0.000   0.000The cryptstats file on Server 2 indicates error 10f opcode 2010000 ts 3632247548 fs 4259841 repeatedly. However, I can't find anything that explains what either that error or that opcode means in simple, identifiable terms.What makes this even more frustrating for me is that when I have all five servers running some will be able to communicate with Server1 while others, like Server2 cannot.Server1 ntp.confThis file is for Server1. With the exception of peer and server lists, all of the NTP servers are identical. The peer list changes such that a server is not listed as its own peer. The server list is slightly different from one server to the next so that there is at least one different time source on all of them.restrict default kod notraprestrict 127.0.0.1driftfile /var/lib/ntp/driftlogfile /var/log/ntp.logserver tick.usno.navy.mil iburstserver ntp-s1.cise.ufl.edu iburstserver ntp.colby.edu iburstserver navobs1.oar.net iburstserver gnomon.cc.columbia.edu iburstpeer server2 iburst autokey#peer server3 iburst autokey#peer server4 iburst autokey#peer server5 iburst autokeycryptoincludefile /etc/ntp/crypto/pwkeysdir /etc/ntp/crypto/statistics clockstats cryptostats loopstats peerstatsstatsdir /var/lib/ntp/ntpstats/filegen clockstats file clockstats type day enablefilegen cryptostats file cryptostats type day enablefilegen loopstats file loopstats type day enablefilegen peerstats file peerstats type day enableI have also generated new keys on Server1. This did not help.UPDATE: It appears that if I shut down ntpd on both servers and then bring it back up (not a restart but a stop...start), the one that comes up first is able to successfully communicate while the one that comes up second displays the CRYP refid. I've tested this by bringing Server1 up then Server2 and seeing that Server1 is able to successfully communicate while Server2 displays CRYP. I then reversed the order and Server2 was able to successfully communicate while Server1 displayed CRYP.
What causes ntpq refid CRYP when authentication is successful?
ntp