NTP Overview

NTP was designed to provide an accurate and stable clock to remote sources across an unmanaged, global Internet environment. Before NTP, other protocols such as Daytime protocol, Time protocol, and ICMP timestamp provided this service. Digital Time Service (DTS) accomplished many of the same objectives as NTP. However, NTP provides for the use of stratum information in clock selection and provides an accurate compensation for inherent clock frequency errors. DTS does not use a stratum or compensate for inherent frequency errors.

The concept of a stratum was conceived directly from the telephone industry, under BELL 86. The accuracy of each NTP server was defined with a stratum number. The most accurate server stratum starts at 1 and increments from there. The implementation of a stratum allows NTP to select from multiple clock sources and judge which one to synchronize with.

The stratum value of 1 requires the accuracy provided by atomic clocks. You will not be able to configure a Cisco router to supply or have a stratum 1 clock, for obvious reasons.

NOTE

Atomic clocks have oscillators that can maintain extremely precise frequencies that correspond to natural phenomenon. The earliest and ultimate oscillators are our celestial bodies. But because of their vastness and our lack of scientific knowledge about them, scientists base atomic clocks on the orbital states of an electron instead of the orbital states of planets and our solar system. The atom provides a stable and accurate model on which scientists can perform accurate measurements. Atomic oscillators are based on the transitions of hydrogen, cesium, and rubidium atoms.

NOTE

To test NTP, I used the shareware TARDIS2000 V1.2, available at c/net's DOWNLOAD.COM or http://download.cnet.com. Two public NTP/SNTP clocks' addresses that you can use in your models are zeus.tamu.edu or 128.194.103.14, and tmc.edu or 128.249.1.1.

After you synchronize with them, most atomic clocks provide a stratum level of 3 or greater to the client. Consider 3 to be a highly reliable stratum level when using NTP.

NTP was specifically designed to produce three products:

• Clock offset— Clock offset is the amount by which to adjust the local clock so that it corresponds to the reference clock.

• Round-trip delay— Round-trip delay makes it possible for a reference clock to launch a message to arrive back at the reference clock at a specific time.

• Dispersion— Dispersion is the maximum error of the local clock relative to the reference or NTP server.

These products are all produced in relation to the local clock, and they use Greenwich Mean Time, UTC, or Coordinated Universal Time as a common reference in time. If the local clock is unreliable, it will affect NTP synchronization, as well as the values provided by NTP, which also provides these values with a relatively simple data flow and little overhead to the network. NTP accomplishes this by using User Datagram Protocol (UDP) port 123. Data integrity is provided by UDP checksums; no flow control or retransmission facilities are provided or necessary.

NTP can be used in a variety of ways. Perhaps the most common use of NTP is for an NTP client to obtain a valid clock from an external source through IP. If multiple clients are synchronizing off the same source, this allows for entire network synchronization. Network clock synchronization can provide several useful functions:

• As the tragic story of Bob illustrates, NTP can be a useful protocol when trying to correlate network anomalies, such as link or neighbor failures.

• Network clock synchronization helps to correlate time accurate logs and debug information from multiple routers.

• Network-management platforms, such as CiscoWorks and HP OpenView, will be more effective and accurate in reporting network statistics.

NTP was first described in RFC 958, but since its first release, it has evolved many times. NTP version 3 is the dominant version of NTP today. RFC 1305 outlines NTP and obsoletes RFCs 1119, 1059, and 958. RFC 2030 outlines the Simple Network Time Protocol (SNTP), which is an adaptation of NTP Version 3. The only significant change in SNTP Version 4 is its adaptation to properly interpret an IPv6 header and OSI addressing.

NOTE

You can find all RFCs online at www.isi.edu/in-notes/rfcxxxx.txt, where xxxx is the number of the RFC.

Configuring NTP

NTP can be configured to support a number of different environments. The following are the most common implementations of NTP and are the ones that you will be configuring in this chapter:

• NTP broadcast client mode— The router can be configured to passively listen for NTP broadcasts, avoiding a static entry to one specific time server.

• NTP static client mode— The router can be configured to listen and exchange messages between statically configured NTP servers.

• NTP master mode— The router can be configured as an NTP server forwarding NTP broadcasts.

• NTP peer associations— The router can be configured to form an NTP peer association with another router. The router can either synchronize to the other system or allow the other system to synchronize to it.

• NTP options and time-related configurations— NTP options include perform authentication and setting the calendar. Time-related options include setting daylight saving time and the current time zone.

Configuring NTP Broadcast Client Mode

Cisco routers can be configured to receive NTP broadcasts on an interface-by-interface level. This type of configuration should be used in LAN environments and can be used to avoid the need to statically configure multiple NTP servers. To configure a router to receive NTP broadcasts, use the ntp broadcast client command under the interface nearest the NTP server or on the interface receiving the NTP broadcast. Figure 17-1 shows a LAN configured with an NTP server. The NTP server has a stratum of 5 and an IP address of 206.191.241.44.

Figure 17-1. NTP Broadcast Client

Figure 17-1. NTP Broadcast Client

Cisco Ntp Stratum

Example 17-1 provides the configuration for the router to receive NTP broadcasts on its Ethernet 0 interface.

Example 17-1 Configuring an NTP Broadcast Client ntp_client(config)#int ethernet 0 ntp_client(config-if)#ntp broadcast client ntp_client(config-if)#exit

To verify that the clock has synchronized, use the show ntp associations and show ntp status commands. Examples 17-2 and 17-3 demonstrate the use of these commands on the ntp_client router.

Example 17-2 The show ntp associations Command ntp_clent#show ntp associations address ref clock st when poll reach delay offset disp

* 206.191.241.44 128.194.103.14 5 7 8192 76 4.1 0.05 910.5

* master (synced), # master (unsynced), + selected, - candidate, ~ configured ntp_clent#

Example 17-2 highlights the key values to look at. When NTP is synchronized, an asterisk (*) denotes that the router has received UDP packets from the address listed immediately after the asterisk and that the router has synchronized with that NTP server. The st field indicates that the clock source is a stratum 5 clock. The ref clock field (reference clock) indicates the clock that the NTP source synchronized to. If the number is 127.127.7.1 and the device is a Cisco router, the clock is synchronized with itself.

Example 17-3 The show ntp status Command ntp_clent#show ntp status

Clock is synchronized, stratum 6, reference is 2 0 6.191.241.44

nominal freq is 250.0000 Hz, actual freq is 250.0093 Hz, precision is 2**19

reference time is BCF2162C.BDF0EE87 (09:33:16.741 CSTDST Wed Jun 14 2000)

clock offset is -91.9576 msec, root delay is 4.14 msec root dispersion is 135.64 msec, peer dispersion is 43.67 msec ntp_clent#

The first line in Example 17-3 provides a clear indication that the clock has synchronized from an address of 206.191.241.44. Here, the stratum has been adjusted to one greater than the original stratum of the master clock. In this example, the router has some optional time-related commands configured. We have set daylight savings time and have set an offset from UTC of six hours. These options will be covered in later sections.

Configuring NTP Static Client Mode

Another way to configure the NTP client is to statically map it to a specific time server. A static NTP server should be used when you want to receive an NTP broadcast from a specific host. An example is when you want to point to the Internet and synchronize the router with one of the atomic clocks on it.

Building on the first model, let's configure another NTP client on the same router, pointing to an atomic clock on the Internet. At TMC.EDU, or 128.249.1.1, is an atomic clock that you can use as a NTP server. Figure 17-2 illustrates the new NTP configuration performed in Example 17-4.

Figure 17-2. NTP Static Client

Broadcast Master Clock

Example 17-4 Configuration of the ntp_client Router hostname ntp client clock timezone

interface Ethernet0 ip address 206.191.241.43 255.255.255.248 no ip directed-broadcast ntp broadcast client

ntp clock-period 17179279

This is added by the router

To configure the router to receive its NTP broadcast from a specific host, use the ntp server a.b.c.d command. This is a global command, and the router can have multiple NTP servers configured at any one time.

You can now perform the same show commands, show ntp assoc and show ntp status, to verify the synchroni 1053

Example 17-5 shows NTP slowly converging to the new NTP server. RFC 1305 points out that clock synchronization requires long periods and multiple comparisons to maintain accurate time. The time for synchronization to occur will range, depending on multiple factors. Be prepared to wait a while for clock synchronization; however, if the clocks do not synchronize in an hour or sooner, you might want to review your NTP design. In the labs and examples presented here, NTP synchronized in less than five minutes.

Example 17-5 The show ntp assoc and show ntp status Command ntp_client#show ntp stat

Clock is synchronized, stratum 6, reference is 2 0 6.191.241.44

nominal freq is 250.0000 Hz, actual freq is 250.0096 Hz, precision is 2**19

reference time is BCF258FA.69DAF6F5 (14:18:18.413 CSTDST Wed Jun 14 2000)

clock offset is -16.8153 msec, root delay is 4.06 msec root dispersion is 409.61 msec, peer dispersion is 392.78 msec ntp_client#

ntp_client#show ntp ass address ref clock st when poll reach delay offset disp

-128.24 9.1.1 0.0.0.0 16 - 64 0 0.0 0.00 16000. NTP configured but no synced

* 206.191.241.44 128.194.103.14 5 46 8192 77 4.1 -16.82 392.8

* master (synced), # master (unsynced), + selected, - candidate, ~ configured ntp_client#

ntp_client#show ntp ass address ref clock st when poll reach delay offset disp

^-128.249.1.1 139.78.160.41 3 11 512 377 114.5 30.71 26. 0 * NTP Sync

206.191.241.44 128.194.103.14 5 26 8192 77 4.1 15.23 20.0

* master (synced), # master (unsynced), + selected, - candidate, ~ configured ntp_client#show ntp stat

Clock is synchronized, stratum 4, reference is 128.249.1.1

nominal freq is 250.0000 Hz, actual freq is 250.0093 Hz, precision is 2**19 reference time is BCF26309.F694401F (15:01:13.963 CSTDST Wed Jun 14 2000) clock offset is 30.7128 msec, root delay is 151.06 msec root dispersion is 97.17 msec, peer dispersion is 26.05 msec ntp_client#

Configuring NTP Master Mode

Cisco routers can also use NTP to function as authoritative NTP servers. When configuring a router as an NTP server, you should take care when setting the stratum level. This value should range somewhere between 6 and 15; the default is 8. The clocks in the mid- and upper-class routers, such as the 36xx, 47xx, and 7k series routers, are much more reliable and provide a calendar function. Use these types of routers for your NTP servers.

To configure a Cisco router as an authoritative NTP server, use the ntp master [stratum_number]command in global configuration mode. Figure 17-3 shows a Cisco 4700 router as the NTP master and a Cisco 2500 router as the NTP client. The 4700 is a good choice as the NTP server because it has a more reliable clock than the 2500 router. You will use the ntp master command on the server, and the client can be configured as either a static client or a broadcast client.

Figure 17-3. NTP Configuration: Using a Router as an NTP Server

Directed Broadcast

Example 17-6 illustrates the configuration of an NTP master and an NTP static client. Example 17-6 Configuration of an NTP Master and Client ntp_server#conf t

Enter configuration commands, one per line. End with CNTL/Z.

ntp_server(config)#ntp master 7

ntp_server(config)#exit ntp_server#

ntp_client#conf t

Enter configuration commands, one per line. End with CNTL/Z. ntp_client(config)#ntp server 10.150.10.3

ntp_client(config)#exit ntp_client#

Use the show ntp status to verify that the clock is synchronized, and use show ntp associations for detailed information on the clock/server that the router has synchronized with. Example 17-7 shows the output for these commands. Again, you are looking for the clock to be synchronized and for the reference address to be 10.150.10.3, which is the NTP master.

Example 17-7 show ntp status and show ntp associations Command Output ntp_client#show ntp status

Clock is synchronized, stratum 8, reference is 10.150.10.3

nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**19

reference time is BD13BB90.AE4D80D0 (03:03:44.680 UTC Mon Jul 10 2000)

clock offset is 1.2757 msec, root delay is 3.78 msec root dispersion is 1.97 msec, peer dispersion is 0.67 msec ntp_client#

ntp_client#show ntp associations address ref clock st when poll reach delay offset disp

* master (synced), # master (unsynced), + selected, - candidate, ~ configured ntp_client#

Configuring NTP Peer Associations

An NTP peer association is much like that of a static peer. An NTP association can be a peer association, meaning that it allows this system to synchronize to another system or allows the other system to synchronize to it. This type of NTP configuration can be deployed in the standard Cisco hierarchical three-layer network design practice (core, distribution, and access layers). At the core level reside NTP master servers, which can be routers or actual NTP servers. The distribution-level routers have a single peer to the core routers. The access-level routers, in turn, peer to the distribution routers. This keeps many NTP broadcasts, however slight they may be, from all going to the same host, yet it provides complete network time synchronization across the internetwork. If a peer loses synchronization, by the rules of NTP, it will not synchronize with any other external sources. Therefore, locate your central peers where a potential loss of physical connectivity makes it logical for the clock to become unsynchronized.

In Figure 17-4, the access routers have a single NTP peer pointing to the distribution router's Ethernet segment. The distribution routers have a single NTP peer pointing to the core router.

Figure 17-4. NTP Peer Associations

Figure 17-4. NTP Peer Associations

The core router could be initiating the time source or, in this case, synchronizing to a more reliable external time source. To configure NTP peers, use the ntp peer ip_address command, in which the IP address is the NTP time source that you want to synchronize to. There is no need to put an ntp peer statement on both sides of the connection. The access routers in Figure 17-4 will have a single ntp peer statement, as will the distribution and the core routers, each pointing only at the IP address where they want to get the time source. Example 17-8 lists the syntax needed to accomplish NTP peering for Figure 17-4.

Example 17-8 NTP Peer Configurations for Figure 17-4

Access routers: ntp peer 10.150.10.1

Distribution router: ntp peer 10.150.10.3

Core router:

ntp server 10.150.10.10 or ntp master 6

Configuring NTP Authentication and Other Clock-Related Options

NTP also provides Message Digest 5 (MD5) authentication of NTP packets for applications that require a secure tim 1056ce. For applications that bill and track by the minute or the second, it is critical that a secure and reliable clock is kept across the network. Configuring MD5 authentication involves three steps:

Step 1. Enable NTP authentication. Use the ntp authenticate global command.

Step 2. Define authentication keys. Configure an MD5 password and an authentication key to use with it. Use the ntp authentication-key key_number md5 md5_password global command.

Step 3. Define a trusted key. Using the same key_number as in Step 2, define a trusted key that will be used among the routers when authenticating NTP. Use the ntp trusted-key key_number command to accomplish this.

Figure 17-5 shows two routers configured for NTP authentication. The ntp_t_server router is the NTP master. The ntp_t_client router is the NTP client.

Figure 17-5. NTP Master and Client Configuration with MD5 Authentication

Figure 17-5. NTP Master and Client Configuration with MD5 Authentication

The ntp authentication commands for both routers will be identical. You must enable authentication to each router and then define the authentication and trusted keys. Example 17-9 demonstrates the commands needed to configure the NTP master; Example 17-10 demonstrates the commands needed for the client.

Example 17-9 Configuring Authentication for NTP on the Master ntp_t_server(config)#ntp master 6 ntp_t_server (config)#ntp authenticate ntp_t_server (config)#ntp authentication-key 3 md5 cisco ntp_t_server (config)#ntp trusted-key 3

Example 17-10 Configuring Authentication for NTP on the Client ntp_t_client(config)#ntp server 10.150.10.3 ntp_t_client(config)#ntp authenticate ntp_t_client(config)#ntp authentication-key 3 md5 cisco ntp_t_client(config)#ntp trusted-key 3

Using the same show commands mentioned previously, show ntp status and show ntp associations, you can verify that NTP is synchronized as demonstrated in Example 17-11.

Example 17-11 show ntp stat and show ntp assoc Command Output ntp_t_client#show ntp stat

Clock is synchronized, stratum 7, reference is 10.150.10.3

nominal freq is 250.0000 Hz, actual freq is 249.9990 Hz, precision is 2**19 1057

reference time is BD15D137.C52F08AF (17:00:39.770 UTC Tue Jul 11 2000)

clock offset is 1.4114 msec, root delay is 3.77 msec root dispersion is 1.46 msec, peer dispersion is 0.03 msec ntp_t_client#show ntp associations address ref clock st when poll reach delay offset disp

* master (synced), # master (unsynced), + selected, - candidate, ~ configured ntp_t_client#

Configure Clock and Time Zones

Inherently critical to having a common clock across the network is having that clock correct and uniform. That includes setting the time zone and daylight saving time. The default time zone is UTC, or Greenwich Mean Time. NTP also can periodically update the calendar, if one is present on the router, as in the Cisco 3600, 7000, and higher-end series routers.

To configure time-zone values, use the following commands from the global configuration mode:

• clock timezone timezone_name [hours_plus_or_minus_from_UTC] [minutes_offset_from_UTC]

• clock summertime summer_timezone_name [recurring|date]

• ntp update-calendar

When you configure a time zone, you can enter the time zone name, such as PAC or CST for Pacific and Central time accordingly, or you can make up a name. You can also set the hours (+23 to -23) and minutes offset from UTC time. When you configure daylight saving time with the clock summertime command, you can enter a time zone name that will appear when running in daylight saving mode. You also can configure any daylight saving offset or specifics that your local government has implemented. The default rules on daylight saving time is that the router or switch will advance the clock one hour on the first Sunday in April at 2:00 a.m., and move the clock back one hour on the last Sunday in October at 2:00 a.m.

Apply these commands to routers in Figure 17-5. Set the time zone on ntp_t_server to U.S. Central time, and enable daylight saving time. CST time is a -6 hour offset from Greenwich Mean Time, so you will want to adjust the offset accordingly. Example 17-12 demonstrates how to set the master clock on Figure 17-5 to Central time.

Example 17-12 Setting the Time Zone and Daylight Saving Time ntp_t_server (config)#clock timezone CST -6 ntp_t_server (config)#clock summer-time CDT recurring

Performing a show clock on the ntp_t_master router results in the output in Example 17-13.

Example 17-13 show clock Command Output Indicates Daylight Saving Time in Effect ntp_t_serverr#show clock 13:44:49.063 CDT Tue Jul 11 2000 ntp_t_server#

Note that the CDT is the time zone name, which denotes that we are running on daylight saving time. TIP

NTP does not pass time zone information in its updates. To configure the proper time zone, you must use the clock timezone command on all the routers in the network. I recommend setting all the clocks to UTC, the default, if the network is large or global. If the network is smaller, the routers should be set to the time zone that the core routers are in. Without a common time zone, problem and event correlation can be much more difficult.

NOTE

The ntp clock-period that appears in the router's configuration listing is added automatically into the router configs when NTP is enabled. It serves to jump-start the NTP frequency compensation when the router is rebooted.

Was this article helpful?

+1 0

Post a comment