|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
| News | NTP -- Network Time Protocol | Recommended Links | Viewing Syslog Messages | Reference | FAQs |
| ntpdate | ntpq | ntptrace | Humor | Etc |
|
|
You need to use a combination of tools, such as viewing system error logs and using the snoop utility, to troubleshoot NTP.
|
|
The ntpq utility is the standard NTP query program. It is an interactive program but it can also run command in batch mode using option -c. All interactive commands are available with help command:
Commands available:
addvars associations authenticate cl clearvars
clocklist clockvar cooked cv debug
delay exit help host hostnames
keyid keytype lassociations lopeers lpassociations
lpeers mreadlist mreadvar mrl mrv
ntpversion opeers passociations passwd peers
poll pstatus quit raw readlist
readvar rl rmvars rv showvars
timeout version writelist writevar
Use the utility to identify NTP peers on the network. For example:
myhost# ntpq -c peers
remote refid st t when poll reach delay offset disp
==============================================================================
*LOCAL(0) LOCAL(0) 3 l 36 64 377 0.00 0.000 10.06
224.0.1.1 0.0.0.0 16 --64 0 0.00 0.000 16000.0
ntpq>
ntpq> exit
myhost#
Solaris ntpd write messages to syslog /var/adm/messages on start and stop:
Jan 7 13:04:24 myhost xntpd[177]: [ID 866926 daemon.notice] xntpd exiting on signal 15
Jan 7 13:09:43 myhost ntpdate[24288]: [ID 774510 daemon.notice] step time server 10.20
1.145.9 offset 318.644492 sec
Jan 7 13:09:43 myhost xntpd[24290]: [ID 702911 daemon.notice] xntpd 3-5.93e+sun 03/08/
29 1623:05 (1.4)
Jan 7 13:09:43 myhost xntpd[24290]: [ID 301315 daemon.notice] tickadj = 5, tick = 1000
0, tvu_maxslew = 495, est. hz = 100
Jan 7 13:09:44 myhost xntpd[24290]: [ID 266339 daemon.notice] using kernel phase-lock
loop 0041, drift correction 0.00000
If you set time forward ( a minute or two) on the system on which you are trying to debug, then log messages will be generates as the system sends out its periodic NTP requests with the incorrect time. The NTP servers should respond with the correct time and clocks should gradually adjust.
Note: According to Sun, NTP can only sync time if it is off by no more than 17 minutes. Furthermore, adjusting time being off by seconds will take several minutes because NTP is architected to slowly adjust to the NTP master's time.
Use the snoop utility when you attempt to track NTP activities on the network.
To view NTP server multicast advertisements, use the snoop utility.
# /usr/sbin/snoop -d bge1 udp port 123
The following is an example of an NTP client multicast:
myclient -> 224.0.1.1 NTP client (Thu Dec 27 02:25:10 2001)
Samples of a snoop trace of the process follow:
1. The NTP client sends a message to an NTP server with its idea of the local time.
myclient -> NTP client (Thurs December 27 02:16:03 2001)
2. The NTP server responds with the correct time.
-> myclient NTP server (Thurs December 27 02:14:51 2001)
3. This exchange between the NTP server and the NTP client repeats many times. Eventually, the NTP client acknowledges
that its time is incorrect. The client will then take action to change its own time, based on NTP time advertisements received
from one or more NTP servers. Information about the actions taken by the NTP client are
sent to the syslog utility for proper processing.
myclient -> NTP client (Thurs December 27 02:15:27 2001)
4. The NTP server responds again with the correct time.
-> myclient NTP server (Thurs December 27 02:15:27 2001)The following is an example of an NTP server response:
-> 224.0.1.1 NTP broadcast (Thu Dec 27 02:25:33 2001)The following is an example of an NTP client time request:
myclient -> NTP client (Thu Dec 27 02:26:19 2001)The following is an example of an NTP server response:
-> myclient NTP server (Thu Dec 27 02:26:19 2001)Note – Another easy way to monitor NTP traffic by using snoopis to use the command: snoop -V port 123.
ISC provide pretty good description of basic issues in Chapter 9
9.4. Check the syslog output
Look at the contents of your syslog output file. There is a good chance that ntpd has output some information describing any problems it has encountered.
9.5. Problems with RESTRICT
Many people have difficulties with using RESTRICT. They want to set themselves up to be as secure as possible, so they create an extremely limited default RESTRICT line in their /etc/ntp.conf file, and then they find that they can't talk to anyone.
If you're having problems with your server, in order to do proper debugging, you should turn off all RESTRICT lines in your /etc/ntp.conf file, and otherwise simplify the configuration as much as possible, so that you can make sure that the basic functions are working correctly.
Once you get the basics working, try turning back on various features, one-by-one. When turning on the RESTRICT features, make sure that you have read, understood, and followed the instructions found in AccessRestrictions.
9.5.1. Problems with RESTRICT NOTRUST
The behavior of NOTRUST changed between versions 4.1 and 4.2.
In 4.1 (and earlier) NOTRUST meant "Don't trust this host/subnet for time".
In 4.2 (and later) NOTRUST means "Ignore all NTP packets that are not cryptographically authenticated." This forces remote time servers to authenicate themselves to your (client) ntpd. See ConfiguringAutokey for information about configuring NTP Authentication.
Please note that most servers are not set up to do cryptographic authentication. Therefore, if you use RESTRICT NOTRUST in your configuration file, you will most likely be configuring your machine to query one or more upstream servers but then throw away any answer that they may send you. This may result in your client sending out one or more packets per second to each of your configured upstream servers, and that would be considered to be "seriously unfriendly".
Many server operators would be likely to firewall themselves off from you (and perhaps the rest of your network), to try to protect themselves against this kind of abuse.
See the page at Flawed Routers Flood University of Wisconsin Internet Time Server to get an idea of how bad this can be, when a vendor mis-configures commodity-grade hardware and causes all their devices in the field to start bombarding time servers with a packet every second. See http://people.freebsd.org/~phk/dlink/ for a more recent example.
Do NOT use RESTRICT NOTRUST unless you know what it means and you know how to use it properly!!!
9.6. Check the NTP port
The first thing to do is to make sure that UDP port 123 is open on all firewalls between you and the remote time servers that you wish to synchronize to. See 9.8. On-line Troubleshooting Utilities for browser-based tests.
When trying to debug problems using ntpdate and ntpq, note that these utilities may use unprivileged high-numbered ports, while ntpd requires full bidirectional access to the privileged UDP port 123. So, ntpdate -u may work, but ntpd may not. Or ntpq may work, but ntpd may not. OpenNTPD also uses high-numbered source ports so if it is able to synchronize but ntpd is not, it is very probable that the incoming UDP port 123 is blocked.
If you're going to run ntpd, you need to fix your network/firewall/NAT so that ntpd can have full unrestricted access to UDP port 123 in both directions. However, this may not be allowed by your firewall administrators.
If this is not possible, you may need to run ntpd on the firewall itself, so that it can have full unrestricted access to UDP port 123 in both directions, and then have it serve time to your internal clients. However, this may also be disallowed.
If that's not possible, your only other option may be to buy the necessary hardware to connect to one or more of your own computers and run your own Stratum 1 time server (typically $200-300 for the radio or GPS receiver hardware, plus the computer to connect it to), or buy a pre-packaged Stratum 1 time server (frequently $1000-2000 or more). With your own Stratum 1 time server, you can sync your internal clients to it, it will get its signal via a radio signal from WWV/WWVB/DCF77/CHU/etc... (depending on where you live) or maybe a GPS or CDMA radio signal, and no packets will be required to cross your firewall on UDP port 123.
Only your management and your firewall administrators will be able to tell you which options are feasible.
9.7. Check the status of ntpd
Run ntpq -p HOSTNAME, or one of the web-based utilities at 9.8. On-line Troubleshooting Utilities, to see the status of ntpd on HOSTNAME (without HOSTNAME the local host is queried). Check the official documentation for a detailed description of the ntpq utility (http://www.eecis.udel.edu/~mills/ntp/html/ntpq.html). It will report something like this:
remote refid st t when poll reach delay offset jitter ============================================================================== ff05::101 .MCST. 16 u - 64 0 0.000 0.000 4000.00 *example.site.co .PPS. 1 u 320 1024 377 1.955 -1.234 1.368
- The very first column
contains the "tally code" character. See the ntpq page for more information.
- remote
the hostname or IP of the remote machine.
- refid
the identification of the time source to which the remote machines is synced. May be (for example) a radio clock or another ntp server)
- st
the stratum of the remote machine. 16 is "unsynchronized". 0 is the best value, that could be (for example) a radio clock or the ntp servers private caesium clock (see http://www.eecis.udel.edu/~mills/ntp/html/index.html#intro for more information about ntp in general).
- when
how many seconds since the last poll of the remote machine.
- poll
the polling interval in seconds.
- reach
an 8-bit left-rotating register. Any 1 bit means that a "time packet" was received.
- delay
the time delay (in milliseconds) to communicate with the remote.
- offset
the offset (in milliseconds) between our time and that of the remote.
- jitter
the observed jitter (in milliseconds) of time with the remote.
9.8. On-line Troubleshooting Utilities
The following on-line troubleshooring utilities are available for testing an ntpd from an "outside" IP address:
Test the time server at the IP address you are browsing from (time, peers, variables)
Test the time server at any IP address (time, peers, variables, associations, versions AND trace)
9.9. ntp.conf and dhcp
If your /etc/ntp.conf is being automatically overwritten, this may be due to DHCP. Either run your dhcpd (dhcp server) with the dhcpd.conf option "option ntp-servers <your ntp server>;", or run your dhcpcd (dhcp client) with the -N arg to prevent ntp.conf from being rewritten at all.
9.10. synchronizing ntp with a server running w32time
To synchronize ntp with a Windows server 2003 running w32time, you have to install a hotfix on that server first, otherwise ntp cannot reach (and therefore not sync with) that server.
This hotfix is available from Microsoft on request only, see http://support.microsoft.com/?kbid=830092
Andreas Höschler ahoesch at smartsoft.de
Mon Nov 14 06:48:17 EST 2005
- Previous message: SUMMARY: Jumpstart x86 Solaris 10 systems
- Next message: SUMMARY: moving /opt to SVM RAID-5
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi all, thanks to "Jonathan Birchall" <Jonathan.Birchall at ins-sure.com> Hutin Bertrand <Bertrand.Hutin at fr.Fujitsu.com> > The config file is in the same place as the later Solaris,s - ie > /etc/inet/ntp.conf. > > Check what dependencies xntp relies on - svcs -l > svc:/network/ntp:default > If all dependencies exist then > svcadm enable svc:/network/ntp > svcadm refresh svc:/network/ntp > svcadm restart svc:/network/ntp > > This should start xntpd. This is what I was looking for. I now get svcs | grep ntp online 12:31:24 svc:/network/ntp:default Thanks a lot! Regards, Andreas
/usr/sbin/ntpdate [-bBdoqsuv] [-a
key#] [-e authdelay] [-k keyfile] [-m]
[-o version] [-p samples] [-t timeout]
[-w] server…
The ntpdate utility sets the local date and time. To determine the correct time, it polls the Network Time Protocol (NTP) servers on the hosts given as arguments. This utility must be run as root on the local host. It obtains a number of samples from each of the servers and applies the standard NTP clock filter and selection algorithms to select the best of these.
The reliability and precision of ntpdate improve dramatically with a greater number of servers. While a single server may be used, better performance and greater resistance to inaccuracy on the part of any one server can be obtained by providing at least three or four servers, if not more.
The ntpdate utility makes time adjustments in one of two ways. If it determines that your clock is off by more than 0.5 seconds it simply steps the time by calling gettimeofday(3C). If the error is less than 0.5 seconds, by default, it slews the clock's time with the offset, by way of a call to adjtime(2). The latter technique is less disruptive and more accurate when the offset is small; it works quite well when ntpdate is run by cron every hour or two. The adjustment made in the latter case is actually 50% larger than the measured offset. This adjustment tends to keep a badly drifting clock more accurate, at some expense to stability. This tradeoff is usually advantageous. At boot time, however, it is usually better to step the time. This can be forced in all cases by specifying the -b option on the command line.
The ntpdate utility declines to set the date if an NTP server daemon like xntpd(1M) is running on the same host. It can be run on a regular basis from cron(1M) as an alternative to running a daemon. Doing so once every one to two hours results in precise enough timekeeping to avoid stepping the clock.
The following options are supported:
/usr/sbin/ntpq [-inp] [-c command] [host] [...]
ntpq queries NTP servers which implement the recommended NTP mode 6 control message format, about current state. It can also request changes in that state. The program can be run in interactive mode; or it can be controlled using command line arguments. Requests to read and write arbitrary variables can be assembled, with raw and pretty-printed output options available. By sending multiple queries to the server, ntpq can also obtain and print a list of peers in a common format.
If one or more request options are included on the command line, ntpq sends each of the requests to NTP servers running on each of the hosts given as command line arguments. By default, ntpq sends its requests to localhost, if hosts are not included on the command line. If no request options are given, ntpq attempts to read commands from the standard input and execute them on the NTP server running on the first host given on the command line. Again, ntpq defaults to localhost if no other host is specified.
ntpq uses NTP mode 6 packets to communicate with an NTP server. Thus, it can be used to query any compatible server on the network that permits queries. Since NTP is a UDP protocol, this communication will be somewhat unreliable, especially over large distances. ntpq makes one attempt to retransmit requests; requests timeout if the remote host is not heard from within a suitable period.
Command line options are described below. Specifying a command line option other than -i or -n causes the specified query (queries) to be sent, immediately to the indicated host(s). Otherwise, ntpq attempts to read interactive format commands from standard input.
Interactive format commands consist of a keyword followed by up to four arguments. Only enough characters of the full keyword to uniquely identify the command need be typed. Normally, the output of a command is sent to standard output; but this output may be written to a file by appending a `>', followed by a file name, to the command line.
A number of interactive format commands are executed entirely within the ntpq program itself. They do not result in NTP mode 6 requests being sent to a server. If no request options are included on the command line, and if the standard input is a terminal device, ntpq prompts for these commands. The interactive commands are described below:
The data carried by NTP mode 6 messages consists of a list of items of the form
variable_name=value
Each peer known to an NTP server has a 16 bit integer association identifier assigned to it. NTP control messages which carry peer variables must identify the peer that the values correspond to, by including its association ID. An association ID of 0 is special. It indicates the variables are system variables, whose names are drawn from a separate name space.
Control message commands send one or more NTP mode 6 messages to the server, and cause the data returned to be printed in some format. Most commands currently implemented send a single message and expect a single response. The current exceptions are the peers mreadlist and mreadvar commands. The peers command sends a preprogrammed series of messages to obtain the data it needs. The mreadlist and mreadvar commands, iterate over a range of associations.
Control message commands are described below:
The character in the left margin indicates the fate of this peer in the clock selection process. The codes mean:
Since the peers command depends on the ability to parse the values in the responses it gets, it may fail to work from time to time with servers which poorly control the data formats.
The contents of the host field may be given in one of four forms. It may be a host name, an IP address, a reference clock implementation name with its parameter or, REFCLK(implementation number, parameter). On “hostnames no” only IP-addresses will be displayed.
/usr/sbin/ntptrace [-vdn]
[-r retries] [-t timeout] [server]
ntptrace determines where a given Network Time Protocol (NTP) server gets its time from, and follows the
chain of NTP servers back to their master time source. If given no arguments, it starts with localhost.
The following options are supported:
The following example shows the output from the ntptrace command:
% ntptrace localhost: stratum 4, offset 0.0019529, synch distance 0.144135 server2.bozo.com: stratum 2, offset 0.0124263, synch distance 0.115784 usndh.edu: stratum 1, offset 0.0019298, synch distance 0.011993, refid 'WWVB' |
On each line, the fields are (left to right):
All times are given in seconds. Synchronization distance is a measure of the goodness of the clock's time.
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|
|
You can use PayPal to to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Last modified: July 28, 2019
