Debugging NTP
Problem
You want to debug and isolate NTP problems.
Solution
Use the show ntp association command to view the status of the configured NTP associations:
Router>show ntp associations
Use the ping command to ensure connectivity to the NTP server exists:
Router>ping 172.25.1.1
Use the debug ntp packet command to view the NTP packets being generated by the router:
Router#debug ntp packets
NTP packets debugging is on.
Discussion
If the router's internal clock is incorrect and the router has NTP enabled, then the first step is check the status of the NTP associations:
Router>show ntp associations address ref clock st when poll reach delay offset disp ~172.25.1.5 0.0.0.0 16 - 64 0 0.0 0.00 16000. ~10.1.1.1 192.168.15.32 2 60 64 0 27.6 -1100. 16000. * master (synced), # master (unsynced), + selected, - candidate, ~ configured Router>
Notice that there are two NTP associations configured on this router, but neither is currently our synchronized master. The example also indicates that neither of the two NTP associations is currently reachable, since the "reach" statistic is zero.
The most obvious place to begin is to test connectivity. You can test connectivity from the router to its NTP association with the ping command. If the NTP association does not respond to the ping request, then a network path may be obstructed or the peer may be down. Isolate and fix the connectivity issues, and hopefully this will rectify the NTP problem. Note that access control lists between the router and its NTP peer may prevent ping traffic from passing, but allow NTP, or vice versa:
Router>ping 172.25.1.5 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.25.1.5, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms Router>
This shows that at least one of the configured NTP associations is reachable, so the problem might be NTP specific, and it is unlikely to be a connectivity issue. Recall that earlier in the chapter we mentioned that an NTP client never synchronizes its clock to an unsynchronized server. To ensure that the NTP server is stable, you can either log in to the server device to check it or, if you do not have administrative access, you can use the router's debug facility:
Router#debug ntp packet NTP packets debugging is on .Mar 21 02:39:18: NTP: xmit packet to 172.25.1.5: .Mar 21 02:39:18: leap 3, mode 3, version 3, stratum 0, ppoll 64 .Mar 21 02:39:18: rtdel 28C7 (159.286), rtdsp 2444 (141.663), refid AC190101 .Mar 21 02:39:18: ref C043C43F.47A9CD5C (21:30:23.279 EST Wed Mar 20 2003) .Mar 21 02:39:18: org 00000000.00000000 (19:00:00.000 EST Thu Dec 31 1899) .Mar 21 02:39:18: rec 00000000.00000000 (19:00:00.000 EST Thu Dec 31 1899) .Mar 21 02:39:18: xmt C043C656.4DFC7394 (21:39:18.304 EST Wed Mar 20 2003) .Mar 21 02:39:25: NTP: rcv packet from 172.25.1.5 to 172.16.2.2 on Fa0/0.1: .Mar 21 02:39:25: leap 3, mode 3, version 3, stratum 0, ppoll 64 .Mar 21 02:39:25: rtdel 286E (157.928), rtdsp 0EC6 (57.709), refid AC190101 .Mar 21 02:39:25: ref C043C4D7.1D633CDE (21:32:55.114 EST Wed Mar 20 2003) .Mar 21 02:39:25: org 00000000.00000000 (19:00:00.000 EST Thu Dec 31 1899) .Mar 21 02:39:25: rec 00000000.00000000 (19:00:00.000 EST Thu Dec 31 1899) .Mar 21 02:39:25: xmt C043C65D.1D0A6CBC (21:39:25.113 EST Wed Mar 20 2003) .Mar 21 02:39:25: inp C043C65D.1296E3C7 (21:39:25.072 EST Wed Mar 20 2003)
The output above shows a debug trace of NTP packets. The first packet captured is an active NTP poll from the local router to its NTP server, 172.25.1.5. The second packet captured is the passive response from the NTP server, and its current stratum level is set to zero. A zero Stratum level reported by the server means that it is currently not synchronized. If the server is not synchronized, then our router can't use it. The process of debugging the NTP problem can now shift to the NTP server.
NTP is remarkably stable. Typically, when there are problems, they are related to connectivity: a box has failed, a path has become unreachable or an access-list has prevented NTP from communicating. As we have discussed above, upstream problems affect downstream NTP associations, since nothing will synchronize to an unsynchronized server. This means that NTP issues must be isolated one hop at a time.