Verify NTP Status with the Show NTP Associations Command

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

You 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 output, and 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 
* primary (synced), # primary (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 synchronized 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.

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 
* primary (synced), # primary (unsynced), + selected, - candidate, ~ configured

The value of interest is in the stratum field, which is one less than the configured value, ntp primary 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

• Network Time Protocol (NTP) Issues Troubleshooting and Debugging Guide
• Technical Support & Documentation - Cisco Systems