Home > Articles > Cisco > CCNA Routing and Switching

Introduction to Network Time Protocol (NTP)

  • Print
  • + Share This
Network Time Protocol (NTP) is very important for modern networks. If the time across network devices is not accurate, this can have a direct impact on network security and network management, just to name two. The key to accurate time in the network is to have your devices receive the correct time from an atomic clock, and then synchronize this correct time across all of the devices. Network Time Protocol ensures this process is automated and secure. This article serves as your introduction to this critical network function.
Like this article? We recommend

When it comes to networking, there are only a handful of things that have as broad an impact as time. Once we begin trying things—like troubleshooting network issues, implementing security event logging, or the automation of authentication key rotation—time rapidly becomes very relevant. Imagine having an internetwork of a hundred or more routers and twice that many switches. Now imagine the effort that would be associated with making sure all these devices have the same time. You just asked, "Why would I even be worried about time?"

The answer is because time provides the only frame of reference between all devices in a network. Thus synchronizing time becomes extremely important. Without synchronized time it becomes difficult, if not impossible, to accurately correlate information between devices. Where network security is concerned, if it is not possible to accurately compare logs between each of your routers and servers, you may find it very hard to extrapolate an accurate picture of a penetration incident.

The simplest tool in our arsenal to handle this issue of time synchronization is Network Time Protocol (NTP). In this blog we will outline the operation, configuration and verification of this protocol as it applies to Cisco IOS devices.

NTP Modes of Operation

NTP synchronizes timekeeping between a group of distributed time servers and clients. This synchronization allows events to be correlated when system logs are created and other time-specific events occur. NTP operates in four different modes.

  • Server Mode is configured such that a device will synchronize NTP clients. Servers can be configured to synchronize all clients or only a specific group of clients. NTP servers, however, will not accept synchronization information from their clients. This restriction will not allow clients to update or manipulate a server’s time settings.
  • Client Mode is configured used to allow a device to set its clock by and synchronized by an external timeserver. NTP clients can be configured to use multiple servers to set their local time and can be configured to give preference to the most accurate time sources available to them. They will not, however, provide synchronization services to any other devices.
  • Peer Mode is when one NTP-enabled device does not have any authority over another. With the peering model, each device will share its time information with its peer. Additionally, each device can also provide time synchronization to the other.
  • Broadcast/Multicast Mode is a special server mode where the NTP server broadcasts its synchronization information to all clients. Broadcast mode requires that clients be on the same subnet as the server, and multicast mode requires that clients and servers have multicast capabilities configured.

Configure an NTP Server

Here we will configure R1 as an NTP Server. For our subsequent configurations we will assume that R1 is reachable from all devices in the infrastructure with the IP Address

R1(config)#ntp master 3

The number used in this command represents the stratum number that we have assigned the NTP Server. Stratum numbers represent how accurate the time source is, and with each hop the time is perceived as less accurate. This means that a lower stratum number will be preferred. We have to note that assigning a Stratum of 1 is not practically possible because it would be the absolutely most accurate time possible like an atomic or cesium clock.

Configure an NTP Client

Now that we have created an 'authoritative time source' on R1, we can configure other devices in the infrastructure to synchronize their time from it. In this instance we will configure R2 such that it synchronizes time from R1.

R2(config)#ntp server

Configure an NTP Peer

If a particular device is configured as an NTP peer it means that it will peer with another system and accept the time from that system. The 'ntp peer' command only needs to be configured at one end. In this scenario we will peer R3 with R2 using the IP Address of

R3(config)#ntp peer

Configure NTP with Multicast/Broadcast Support

This type of NTP deployment requires modifications to be made on both the NTP Server and any potential NTP clients. First on R1 we need to add the configurations necessary to enable it to send server-side NTP multicast packets. We could just as easily use broadcast packets but we will instead use multicast in this demonstration.

R1(config)#interface FastEthernet0/0
R1(config-if)#ntp multicast ttl 1

In this example we have configured the server so that it will send multicast packets with a Time-To-Live (TTL) value of one. This effectively limits the range of the NTP multicast packets to the local segment. This also means that we do not have to enable multicast routing on our devices because no multicast forwarding will be required. Keep in mind we could choose to route the multicast packets further by increasing the TTL value and enabling multicast routing.

R4(config)#interface FastEthernet0/0
R4(config-if)#ntp multicast client
R4(config-if)#ntp multicast version 3

Note that since multicast traffic is far more efficient than broadcast traffic, it is a much preferred method of providing NTP service over local LAN segments where all clients will support NTP multicasting.

Verifying NTP

It is recommended that we initially set the clock manually on all devices before configuring NTP synchronization. Large time gaps between devices and any NTP server clocks will make time synchronization an extremely long process. Once this is accomplished we can use three steps to verify the status of our configuration:

  • Step 1: Check the status of the Local NTP Process
  • The tool most commonly used to verify the status of NTP is the 'show ntp status' command.

    R2#show ntp status
    Clock is synchronized, stratum 5, reference is
    nominal freq is 250.0000 Hz, actual freq is 250.0001 Hz, precision is 2**18
    reference time is D04096A6.9715EE2B (14:03:18.590 UTC Wed Dec 21 2011)
    clock offset is -7.9613 msec, root delay is 3.83 msec
    root dispersion is 14.74 msec, peer dispersion is 6.74 msec

    This output shows us that the clock is synchronized with the NTP server and operating at a stratum level of five.

  • Step 2: Check any NTP associations
  • An optional tool that is also at our disposal is the 'show ntp association' command.

    R2#show ntp association
          address             ref clock       st  when  poll reach  delay  offset    disp
    *~       4         9     64    377       5.6    4.22    13.4
     * master (synced), # master (unsynced), + selected, - candidate, ~ configured

    This show command tells us that we have an association with an NTP server with the IP Address and that the status with this server is "synced."

  • Step 3: Check the details of any NTP associations
  • Adding the keyword detail to the 'show ntp association' command provides significantly more information relevant to the NTP master we are synchronized with.

    R2#show ntp association detail configured, authenticated, our_master, sane, valid, stratum 4
    ref ID, time D04097CC.0209500C (14:08:12.007 UTC Wed Dec 21 2011)
    our mode client, peer mode server, our poll intvl 64, peer poll intvl 64
    root delay 0.00 msec, root disp 0.03, reach 377, sync dist 10.239
    delay 7.72 msec, offset 5.1799 msec, dispersion 6.35
    precision 2**24, version 3
    org time D04097E6.97A012CA (14:08:38.592 UTC Sun Sep 19 2010)
    rcv time D04097E6.98D73524 (14:08:38.597 UTC Sun Sep 19 2010)
    xmt time D04097E6.905799B4 (14:08:38.563 UTC Sun Sep 19 2010)
    filtdelay =    33.02    7.72   15.73   22.32    5.65   27.62   23.62   15.66
    filtoffset =   11.77    5.18   13.89   23.08    4.22    7.94   12.65    3.32
    filterror =     0.02    0.99    1.97    2.94    3.92    4.90    5.87    6.85

We can tell a lot from this output, but the key pieces of information are that we are synchronized with a time source located at This is indicated by the designation of 'sane' and the stratum of four indicates the accuracy of the time on the NTP server we are synchronized with.


NTP provides an easy way to guarantee that all of our network devices have the same time. In smaller networks, this is a good thing; in large networks, it is essential. In this blog we have configured a Cisco router as a server, another router (R2) as a client and a third router (R3) as an NTP peer with R2. We then configured R1 and R4 to synchronize their clocks via Multicast Protocol across the FastEthernet segment connecting them. Lastly, we looked at the status of the NTP Process on the client device we configured. That cover everything we need to know about NTP and more, but any time spent understanding NTP is time well spent!

  • + Share This
  • 🔖 Save To Your Account