Get Unlimited Access to our 786 Cisco Lessons Now Get $1 Trial
You are here: Home » Cisco » CCIE Routing & Switching Written

Troubleshooting NTP

In this lesson we’ll take a look at troubleshooting NTP (Network Time Protocol). NTP is an important protocol to use since it ensures our logging information has the correct time and date.

There are a couple of things that could go wrong with NTP:

  • NTP traffic filtered: access-lists could block NTP traffic.
  • NTP Authentication issues: NTP supports authentication, client and server need to use the same settings.
  • Time offset too high: When the time offset between client/server is too large it will take a very long time to synchronize.
  • Stratum level too high: The stratum level is between 1 (best) and 15 (worst). A stratum level of 16 is considered unusable.
  • NTP server source filter: NTP servers can be configured to allow only clients from certain IP addresses.

We’ll take a look at these different issues. I will use the following two routers:

NTP Client Server R1 R2

R1 will be our NTP client and R2 will be the NTP server. There are two useful commands that we should start with:

R1#show ntp status
Clock is unsynchronized, stratum 16, no reference clock
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**18
reference time is 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
clock offset is 0.0000 msec, root delay is 0.00 msec
root dispersion is 0.00 msec, peer dispersion is 0.00 msec
R1#show ntp associations

      address         ref clock     st  when  poll reach  delay  offset    disp
 ~192.168.12.2     0.0.0.0          16     -    64    0     0.0    0.00  16000.
 * master (synced), # master (unsynced), + selected, - candidate, ~ configured

These tell us that R1 has 192.168.12.2 configured as the NTP server and it’s currently not synchronized. Let’s check if R1 is receiving NTP packets, we can use a debug for this:

R1#debug ntp packets
NTP packets debugging is on

NTP: xmit packet to 192.168.12.2:
 leap 3, mode 3, version 3, stratum 0, ppoll 64
 rtdel 0000 (0.000), rtdsp 10001 (1000.015), refid 00000000 (0.0.0.0)
 ref 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
 org 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
 rec 00000000.00000000 (00:00:00.000 UTC Mon Jan 1 1900)
 xmt C0295220.A6D7FB14 (01:04:32.651 UTC Fri Mar 1 2002)

This debug tells us that R1 is sending NTP packets but we are not receiving anything from the NTP server. Make sure NTP server is allowed to go through:

R1#show access-lists
Extended IP access list NO_TIME
    1 deny udp any any eq ntp (3 matches)

R1 uses UDP port 123 so make sure it’s not blocked, let’s get rid of this access-list:

R1(config)#interface FastEthernet 0/0
R1(config-if)#no ip access-group NO_TIME in

After removing the access-list, NTP will be able to use the NTP packets from the server:

R1#
NTP: rcv packet from 192.168.12.2 to 192.168.12.1 on FastEthernet0/0:
 leap 0, mode 4, version 3, stratum 1, ppoll 64
 rtdel 0000 (0.000), rtdsp 0002 (0.031), refid 4C4F434C (76.79.67.76)
 ref C02952FA.C3830714 (01:08:10.763 UTC Fri Mar 1 2002)
 org C0295320.A6D6D314 (01:08:48.651 UTC Fri Mar 1 2002)

Here’s the end result:

R1#show ntp status
Clock is synchronized, stratum 2, reference is 192.168.12.2
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**18
reference time is C0295360.FAE093C8 (01:09:52.979 UTC Fri Mar 1 2002)
clock offset is 3.9974 msec, root delay is 47.78 msec
root dispersion is 15879.03 msec, peer dispersion is 15875.02 msec

The clock is now synchronized. Another issue you can spot with the debugging NTP is an authentication mismatch:

R1(config)#ntp server 192.168.12.2 key 1
R1(config)#ntp authentication-key 1 md5 MY_KEY

I’ll configure R1 to only accepts NTP packets from the NTP server that are authenticated with a certain key. The NTP server however doesn’t use any form of authentication. We can find this error with the following debug:

R1#debug ntp validity
NTP peer validity debugging is on

It will tell us this:

R1#
NTP: packet from 192.168.12.2 failed validity tests 10
Authentication failed

Make sure your NTP authentication settings match on both sides.

When the time/date difference between the NTP server and NTP client is significant, it will take a long time to sync. Right now the clocks look like this:

R1#show clock
.01:32:25.208 UTC Fri Mar 1 2002
R2#show clock
18:01:44.327 UTC Fri Jan 30 2015

Setting the clock on the NTP client to something close to the NTP server will speed up the sync process a lot:

R1#clock set 18:00:00 30 January 2015

In a few minutes, the clock on the NTP client should be synced.

Another issue with NTP is that the stratum level is limited, we can use values between 1 (best) and 15 (worst). If the NTP server has a stratum level of 15 then the NTP client won’t be able to sync since 16 is considered unreachable.

Debugging the NTP packets on the client will reveal this:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You’ve Ever Spent on Your Cisco Career!
  • Full Access to our 786 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

Give Membership a try - it's just $1 ►

1441 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags: ,

Forum Replies

  1. Hi
    Due to high root dispersion , NTP clock and local clock have a time difference . Please suggest how to troubleshoot root dispersion .

  2. Hello Sumit

    Root dispersion is a rough estimate of of how much the local time has drifted away from some reference time. This reference time is often referred to as the root source. Root dispersion occurs when there is some malfunction in the time source. A disruption in service or a bad network connection can cause a steady increase in root dispersion. For Cisco IOS devices, any root dispersion in excess of one second will cause an NTP association to fail.

    Root dispersion is also included in NTP updates so that NTP clients receiving them can choose to use

    ... Continue reading in our forum

  3. Hi,

    I’m a bit confused about some NTP issues on my GNS3 lab.

    on R1 ( NTP MASTER ):

    ntp authentication-key 1 md5 <xxxxx> 7
ntp authenticate
ntp trsusted-key 1
ntp master 1

    on R2:

    clock set 00:00:00 01 jun 1996
ntp server X.X.X.X

    I’m expecting on R2 nothing happen but it syncronize the clock with the master…
    I saw with “debug ntp packets” comand.

    How can It be possible?

    Thank you

  4. Hello Giovanni

    One of the most common misconceptions of NTP authentication is the direction of authentication. By configuring authentication on the NTP master, what you have done is to configure R1 to synchronize only to systems providing the authentication key 1 in their NTP packets. In other words, R1 will synchronize (as a client) to any NTP server that has the configured authentication key. This configuration does not affect R2 synchronizing with R1, but affects R1 synchronizing with some other source.

    If you configure authentication on R2 and not on R1,

    ... Continue reading in our forum

  5. Hello Rene/Laz,

    I have a question about NTP which i’ve not been able to find an answer to in the config guides.

    Let’s say R1-R2 have formed an NTP association. R1 is then configured with ntp access-group serve-only 2 - see ACL details below. In this case the IP address of R2 does not match access-list 2 on R1. What is the expected behaviour of R2 in terms of its association?

    When labbing this I was expecting that R2 would tear down the association, but R2 actually continues to maintain it. Is it the case that R2 would simply no longer receive any more replies f

    ... Continue reading in our forum

3 more replies! Ask a question or join the discussion by visiting our Community Forum