Introduction
This document describes how to use the show ntp associations command output to determine if NTP works properly.
Prerequisites
Requirements
There are no specific requirements for this document.
Components Used
This document is not restricted to specific software and hardware versions.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
Conventions
Refer toCisco Technical Tips Conventionsfor more information on document conventions.
Background Information
You can use Network Timing Protocol (NTP) to synchronize time and clocks across network connections. On Cisco routers, you can use the show ntp associations command to see the status of NTP peers.
There is a considerable amount of information in the output, which includes packet loss information. This information is intended to supplement the information available in the Cisco IOS® Command Reference.
Understand the show ntp associations Command
We first examine the output of the show ntp associations command and then describe in detail the information that this command presents.
This is an example of output, followed by an explanation of certain output fields.
Router#show ntp associations
address ref clock st when poll reach delay offset disp
~172.31.32.2 172.31.32.1 5 29 1024 377 4.2 -8.59 1.6
+~192.168.13.33 192.168.1.111 3 69 128 377 4.1 3.48 2.3
*~192.168.13.57 192.168.1.111 3 32 128 377 7.9 11.18 3.6
* master (synced), # master (unsynced), + selected, - candidate, ~ configured
The poll field represents the poll interval (in seconds) between NTP poll packets.
As the NTP server and client are better synced (and there are no dropped packets), this number increases to a maximum of 1024.
The offset field is the calculated offset (in milliseconds) between the client and server time. The client slows down or speeds up its clock to match the server time value.
The offset decreases toward zero over time. It likely never reaches zero since the packet delay between the client and server is never exactly the same.
Therefore, the client NTP cannot ever exactly match its clock with the server.
If there is an asterisk (*) next to a configured peer, then you are syncronized to this peer and use them as the primary clock.
As long as one peer is the primary then everything is fine. However, to verify that NTP is works properly, look at the value in the reach field.
Examples of Reach Field Values
The reach field is a circular bit buffer. It gives you the status of the last eight NTP messages (eight bits in octal is 377, so you want to see a reach field value of 377).
If an NTP response packet is lost, the lost packet is tracked over the next eight NTP update intervals in the reach field.
This table provides explanations for possible reach field values with the loss of an NTP response packet as an example.
| Reach Field Value (Reported/Binary) |
Explanation |
| 377 = 1 1 1 1 1 1 1 1 |
Time 0: Last eight responses from server were received |
| 376 = 1 1 1 1 1 1 1 0 |
Time 1: Last NTP response was NOT received (lost in network) |
| 375 = 1 1 1 1 1 1 0 1 |
Time 2: Last NTP response was received |
| 373 = 1 1 1 1 1 0 1 1 |
Time 3: Last NTP response was received |
| 367 = 1 1 1 1 0 1 1 1 |
Time 4: Last NTP response was received |
| 357 = 1 1 1 0 1 1 1 1 |
Time 5: Last NTP response was received |
| 337 = 1 1 0 1 1 1 1 1 |
Time 6: Last NTP response was received |
| 277 = 1 0 1 1 1 1 1 1 |
Time 7: Last NTP response was received |
| 177 = 0 1 1 1 1 1 1 1 |
Time 8: Last NTP response was received |
| 377 = 1 1 1 1 1 1 1 1 |
Time 9: Last NTP response was received |
Differences When Configured as primary
When the router uses its own clock as a primary clock (with the ntp master command), the output from show ntp associations appears similar to this:
address ref clock st when poll reach delay offset disp
*~127.127.7.1 127.127.7.1 6 20 64 377 0.0 0.00 0.0
* master (synced), # master (unsynced), + selected, - candidate, ~ configured
The value of interest is in the stratum field, which is one less than the configured value, ntp master 7 in this case.
The router polls its own internal clock, but the clock is never unreachable, and the router never increases the poll interval to more than every 64 seconds.
What Does a Pound Sign (#) Indicate?
A pound sign (#) displayed next to a configured peer in the show ntp associations command output indicates that the router does not synchronize with the peer even though NTP request and response packets are exchanged.
In this case, check the output of the show ntp associations detail command or the NTP debugs to see why the clocks are not synchronized.
Use the show ntp associations detail and show ntp status commands to obtain additional information about the state of NTP.
One possible reason for the pound sign is that the NTP client clock differs by more than 4000 seconds from the NTP server clock.
On Cisco routers, a time difference of greater than 4000 seconds is considered out of range and prevents the router from synchronization to the server.
This does not apply when you first configure an NTP peer on a Cisco router or at a reload. In this case, the NTP client (the Cisco router) clock is changed to match the NTP server clock, no matter how large the difference.
Verify the time zone of the client clock; local time is displayed, but time values in NTP messages are in UTC (GMT) time zone.
You can manually change the client clock to within a few minutes of the NTP server clock.
Related Information
Feedback