Introduction to Network Time Protocol (NTP)
Like this article? We recommend
Like this article? We recommend
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 192.168.1.1.
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 192.168.1.1
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 10.1.12.2.
R3(config)#ntp peer 10.1.12.2
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 224.0.1.1 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 224.12.12.12 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 192.168.1.1 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 R1#
This output shows us that the clock is synchronized with the NTP server and operating at a stratum level of five.
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
*~192.168.1.1 127.127.7.1 4 9 64 377 5.6 4.22 13.4
* master (synced), # master (unsynced), + selected, - candidate, ~ configured
R1#
This show command tells us that we have an association with an NTP server with the IP Address 192.168.1.1 and that the status with this server is "synced."
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 192.168.1.1 configured, authenticated, our_master, sane, valid, stratum 4 ref ID 127.127.7.1, 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 192.168.1.1. 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.
Conclusion
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!