NTP config verification

[JohnDoucette]

I am verifying the NTP configuration done by former administrator. When I issue command ntpq -p I get the following

localhost: timed out, nothing received
***Request timed out

This is not the expected output. I can ping the NTP server from the RSA server. All other tests seem to work.

I am investigation the NTP config do to a note from the former administrator that said the RSA server would randomly have a time shift of up to 160 seconds, and he suspected this was the cause of RSA token users randomly having to resync their token.

[EdwardDavis · Accepted solution]

You need to edit the ntp.conf file

and unbind it from ipv6

and let it work with ipv4.

Then your standard NTP command line tools will work.

example:

put a hash mark in front of restrict 127.0.0.1, and add a line
to restrict ipv6 like this 

# server 127.127.8.0 mode 5 prefer
tinker panic 0
restrict default kod nomodify notrap nopeer noquery
restrict -6 default ignore

#restrict 127.0.0.1
restrict ::1

restart NTP to load the modified config file

/etc/init.d/ntp restart

then you can do some NTP checks with no errors

NTP Debugging Techniques 

what are you peering with ?

 # ntpdc -pn

remote local st poll reach delay offset disp
=======================================================================
*10.254.140.22 10.101.99.150 2 64 377 0.00351 -0.000087 0.06131

and also the dns name

 # ntpdc -p

remote local st poll reach delay offset disp
=======================================================================
*timesrv.company.com 10.101.99.150 2 64 377 0.00351 -0.000087 0.06131

basic test do a command line sync

 # rcntp ntptimeset

Time synchronized with 10.254.140.22

ntpdc testing,

see where your timeserver is getting it's time from
and verify it shows up correctly and not some error condition 
--------------------------
 ntpdc command line

 # ntpdc
ntpdc>

ntpdc> showpeer -4 10.254.140.22 (10.254.140.22 is your timeserver)

remote 10.254.140.22, local 10.101.99.150
hmode client, pmode unspec, stratum 2, precision -18
leap 00, refid [10.254.225.252], rootdistance 0.00037, rootdispersion 0.02066

more testing with ntpq

 # ntpq
ntpq>

ntpq> as

ind assID status conf reach auth condition last_event cnt
===========================================================
1 13656 9614 yes yes none sys.peer reachable 1

for the next command use the assID from above

ntpq> rv 13656

assID=13656 status=9614 reach, conf, sel_sys.peer, 1 event, event_reach,
srcadr=timesrv.company.com, srcport=123, dstadr=10.101.99.150,
dstport=123, leap=00, stratum=2, precision=-18, rootdelay=0.244,
rootdispersion=11.917, refid=10.254.225.252, reach=377, unreach=0,
hmode=3, pmode=4, hpoll=6, ppoll=6, flash=00 ok, keyid=0, ttl=0,
offset=-0.005, delay=3.583, dispersion=5.421, jitter=3.700,
reftime=da66102a.4309c000 Wed, Feb 10 2016 14:38:18.261,
org=da6610ac.f74d0000 Wed, Feb 10 2016 14:40:28.966,
rec=da6610ac.f8abe0a2 Wed, Feb 10 2016 14:40:28.971,
xmt=da6610ac.f6d380a8 Wed, Feb 10 2016 14:40:28.964,
filtdelay= 7.19 3.63 19.17 3.67 15.18 3.73 3.60 3.58,
filtoffset= -1.76 0.13 7.75 -0.11 5.70 0.07 -0.01 -0.01,
filtdisp= 0.00 0.99 1.99 2.94 3.93 4.92 5.90 6.89

the state of the local clock can also be verified without the assID argument

ntpq> rv
assID=0 status=0644 leap_none, sync_ntp, 4 events, event_peer/strat_chg,
version="ntpd 4.2.4p8@1.1612-o Mon Jun 22 16:09:03 UTC 2015 (1)",
processor="x86_64", system="Linux/3.0.101-0.7.23-default", leap=00,
stratum=3, precision=-20, rootdelay=3.848, rootdispersion=20.470,
peer=13656, refid=10.254.140.22,
reftime=da6611ac.f7c09fea Wed, Feb 10 2016 14:44:44.967, poll=6,
clock=da6611b1.0d26e947 Wed, Feb 10 2016 14:44:49.051, state=4,
offset=0.001, frequency=-33.319, jitter=3.170, noise=0.056,
stability=0.019, tai=0

[EdwardDavis]

FYI  

RSA servers 8.1 and up do not randomly time shift unless they are getting bogus

NTP, or are using a virtual host time, and the host has buggy time....but in general NTP

is rock solid on RSA servers 8.x. We do have an updated NTP for Suse in the 8.1 Third

Party Patch 2.0. So if there is any recommendation I can make, it is always be on the

latest patch version of RSA software, and use NTP, and verify your NTP sources

and refids are sound.

[JohnDoucette]

Edward thanks for the feedback. That is exactly what I ended up doing. Unbind IPV6 which allowed ntpq to work, then via ntpq found that the one NTP source was the likely issue and removed it.