Network Time Protocol

The Network Time Protocol (NTP) enables you to synchronize system clocks with a centralized time source. Troubleshooting network problems rarely involves a single system. Searching through log files ”looking for error messages that were recorded at a particular time of day as a result of a particular event ”is made much simpler when all the systems potentially involved in the event use the same clock time to time stamp the error messages.

Overview of NTP

NTP synchronizes timekeeping among distributed devices. Each device makes peer associations with the time sources. The reliability of the time sources is defined by stratum levels. A stratum 1 server is directly connected to a reliable time source, such as radio clocks, GPS satellite timing receivers, or atomic clocks. Stratum 2 servers obtain their time from a stratum 1 source. The stratum 2 server may connect to a publicly available stratum 1 server via the Internet. You can find a list of public NTP servers and information about using them at www.eecis.udel.edu/~ntp/ (from the University of Delaware).

A couple of reliable NTP servers configured in an organization could associate with the stratum 2 public NTP servers and then provide time services to all the routers in the organization's network. A router can be the NTP server as well. In fact, if no Internet connection is available, or the NTP protocol is not permitted through the firewall to the Internet, routers can be configured to be the authoritative NTP server. The router uses its own system clock as the time reference. Only a router that maintains its time after a reset ”a router with a calendar ”can be used as an authoritative time source. Any other router will not have a valid reference clock. If NTP is running on a router with a calendar system, and the router is obtaining time via NTP, the calendar may be updated by NTP to compensate for the inherent drift in the calendar time. It may not be quite as accurate as an atomic clock, but at least all the routers in the network will have synchronized times, which eases troubleshooting problems.

NTP is very efficient. One packet per minute allows two devices to synchronize within 10 milliseconds .

Router Configuration for NTP

When configuring NTP, first create an association. Use the following commands to initiate the creation of the associations:

  ntp server   ip_address  [  version   number  ] [  key   keyid  ] [  source   interface  ] [  prefer  ]  ntp peer   ip_address  [  version   number  ] [  key   keyid  ] [  source   interface  ] [  prefer  ] 

Create a server association if this router is going to synchronize its clock to another NTP clock source. Create a peer association if this router is willing to synchronize to another device or allow another device to synchronize to it.

The default version number is 3. No authentication keyid is configured, and the source IP address is that of the outgoing interface, by default. The prefer keyword tells the IOS to prefer this peer for synchronization.

To control access to the router's NTP services, use the following command:

  ntp access-group  {  query-only   serve-only   serve   peer  }  access-list-number  

Use the query-only option to allow only NTP control queries from the listed IP addresses. Control queries are used in lieu of an SNMP management station to monitor the NTP process.

The serve-only option allows only time requests from the IP addresses listed in the access list. This router will not synchronize its clock to the remote system.

The serve option allows time requests and control queries. This system will still not synchronize its clock to the remote system.

The peer option allows both time requests and control queries, and it does allow this router to synchronize its clock to the remote system.

The configuration in Example 9-19 permits one router, Seattle, to synchronize its clock to a secondary public time source. Another router, Tacoma, in the same network as Seattle, is allowed to synchronize with Seattle.

Example 9-19 Synchronizing the Seattle Router Clock to a Secondary Public Time Source; the Tacoma Router Synchronizes with Seattle

  Seattle   access-list 1 permit 172.16.0.0 0.0.255.255   access-list 2 permit 128.105.39.11   ntp access-group peer 2   ntp access-group serve 1   ntp server 128.105.39.11  _____________________________________________________________________________________________  Tacoma   ntp server 172.16.1.5  

Seattle is permitted to synchronize its clock with only 128.105.39.11. Any node with an address in the range 172.16.0.0/16 can synchronize its clock with Seattle's clock.

A router can be configured as the master time source if no external time source is available. The router must have an internal calendar that maintains the date and time through a reboot or power cycle. To enable this calendar as the authoritative time source for the router, configure the clock calendar-valid command.

To configure the Cisco IOS Software as an NTP master clock to which peers synchronize, use the ntp master [ stratum ] command. Configure a high stratum number to ensure that this router does not override the clock on another system with a lower stratum number (and therefore a more reliable clock). The default stratum is 8. The router with NTP master configured still attempts to find a server with a lower stratum number. If it cannot, the router will becomes synchronized at the configured stratum number. After it has been synchronized, other systems can synchronize to it.

NTP time is UTC. If you want a router to maintain a different time zone, you can still use the following commands to maintain local time:

  clock timezone PST -8   clock summer-time PDT recurring  

To update a router's calendar with the time obtained via NTP, use the ntp update-calendar command.

The NTP protocol can use authentication. The following configuration commands enable authentication:

  ntp authenticate   ntp authentication-key   number   md5   key   ntp trusted-key   number   ntp server   ip-address   key   number  

The ntp authenticate command is required on both the NTP server and the router requesting time synchronization. It globally enables authentication. The ntp authentication-key command also is required on both routers. This command defines an authentication string and assigns it a number.

The router requesting time synchronization is configured with the ntp trusted-key command. This command lists key numbers that have already been defined with the ntp authentication-key command, which the server must include in its NTP packets, before this router will synchronize to it. The ntp trusted-key command is therefore only required on the client router.

The key number option must also be included in the client's ntp server command. This adds the key to the NTP packets from the client to the server. When the server sees the key, if the key has been defined on the server, the server includes it in its NTP packets to the client.

Authentication is enabled between Seattle and Tacoma in the configurations in Example 9-20.

Example 9-20 Enabling Authentication Between Routers Seattle and Tacoma

  Seattle   ntp authenticate   ntp authentication-key 10 md5 ntpkey  _____________________________________________________________________________________________  Tacoma   ntp authenticate   ntp authentication-key 10 md5 ntpkey   ntp trusted-key 10   ntp server seattle key 10  

Tacoma's ntp server seattle key 10 command specifies that the server, Seattle, must provide key number 10 in its NTP packets, before Tacoma will synchronize its clock with Seattle's clock. Seattle sees the key 10 in the NTP packets from Tacoma. Seattle's ntp authentication-key 10 md5 ntpkey enables Seattle to include the authentication key 10 in its reply back to Tacoma. To illustrate the authentication, the authentication-key command is left out of the server's configuration. Example 9-21 displays the output of the debug ntp packet command. Initially, the time server, Seattle, is not configured for authentication. The client router, Tacoma, requires authentication before it will synchronize its clock with the time server.

Example 9-21 1NTP Packet Exchange with No Authentication Key Configured on the NTP Server

  Seattle   ntp clock-period 17179873   ntp server 128.105.39.11  _____________________________________________________________________________________________  NTP: xmit packet to 172.16.1.105:  leap 3, mode 3, version 3, stratum 0, ppoll 64 rtdel 1813 (94.040), rtdsp 3E25 (242.752), refid AC100169 (172.16.1.105) ref BDD13136.BEAD46C0 (15:04:06.744 Eastern Thu Nov 30 2000) org BDD13580.2FF266EC (15:22:24.187 Eastern Thu Nov 30 2000) rec BDD13580.272011D4 (15:22:24.152 Eastern Thu Nov 30 2000) xmt BDD13580.BD318A8C (15:22:24.739 Eastern Thu Nov 30 2000)  Authentication key 10   NTP: rcv packet from 172.16.1.105 to 172.16.1.106 on Ethernet0:  leap 0, mode 4, version 3, stratum 3, ppoll 64 rtdel 0FD1 (61.783), rtdsp 080C (31.433), refid 8069270B (128.105.39.11) ref BDD1355B.9F07E00F (15:21:47.621 Eastern Thu Nov 30 2000) org BDD13580.BD318A8C (15:22:24.739 Eastern Thu Nov 30 2000) rec BDD13580.CB4EBD34 (15:22:24.794 Eastern Thu Nov 30 2000) xmt BDD13580.CB6623DA (15:22:24.794 Eastern Thu Nov 30 2000) inp BDD13580.C5C23E0A (15:22:24.772 Eastern Thu Nov 30 2000) 

The debug packet transmitted from Tacoma to Seattle displays the authentication key 10. Tacoma expects this key to be included in the NTP packet received from Seattle. It is not. Therefore, as shown in Example 9-22, the NTP status remains unsynchronized.

Example 9-22 Display of show ntp status and show ntp association detail Commands with Incorrect Authentication

 Tacoma#  show ntp status   Clock is unsynchronized, stratum 16, no reference clock  nominal freq is 250.0000 Hz, actual freq is 249.9999 Hz, precision is 2**19 reference time is BDD13136.BEAD46C0 (15:04:06.744 Eastern Thu Nov 30 2000) clock offset is 5.8229 msec, root delay is 94.04 msec root dispersion is 242.74 msec, peer dispersion is 70.86 msec Tacoma#  show ntp association detail  172.16.1.105 configured, insane, invalid, unsynced, stratum 16 

Only the first line of the show ntp association detail command is shown. It reveals that the peer is manually configured and that the peer did not pass a basic sanity check (authentication failed). The time is therefore invalid, the peers are unsynchronized, and the stratum level is the default level, 16.

Now, the commands ntp authentication-key 10 md5 ntpkey and ntp authenticate are added to the Seattle configuration. Examples 9-23 and 9-24 display the debug ntp packet and the show ntp status and show ntp association detail output, respectively.

Example 9-23 NTP Packet Exchange with Correct Authentication Key Configured on NTP Server and Client

 Seattle(config)#  ntp authentication  Seattle(config)#  ntp authentication-key 10 md5 ntpkey  Seattle(config)#  ^Z  ______________________________________________________________________________________ Tacoma#  NTP: xmit packet to 172.16.1.105:  leap 3, mode 3, version 3, stratum 0, ppoll 64 rtdel 1813 (94.040), rtdsp 3E25 (242.752), refid AC100169 (172.16.1.105) ref BDD13136.BEAD46C0 (15:04:06.744 Eastern Thu Nov 30 2000) org BDD13600.B85D38DF (15:24:32.720 Eastern Thu Nov 30 2000) rec BDD13600.B5E44B24 (15:24:32.710 Eastern Thu Nov 30 2000) xmt BDD13640.CED09281 (15:25:36.807 Eastern Thu Nov 30 2000)  Authentication key 10  NTP: rcv packet from 172.16.1.105 to 172.16.1.106 on Ethernet0: leap 0, mode 4, version 3, stratum 3, ppoll 64 rtdel 10CE (65.643), rtdsp 0821 (31.754), refid 8069270B (128.105.39.11) ref BDD1361B.9EC9B021 (15:24:59.620 Eastern Thu Nov 30 2000) org BDD13640.CED09281 (15:25:36.807 Eastern Thu Nov 30 2000) rec BDD13640.DAE3EC4F (15:25:36.855 Eastern Thu Nov 30 2000) xmt BDD13640.DB1FC317 (15:25:36.855 Eastern Thu Nov 30 2000) inp BDD13640.D7686AD0 (15:25:36.841 Eastern Thu Nov 30 2000)  Authentication key 10   NTP: 172.16.1.105 reachable   NTP: sync change   NTP: peer stratum change  

Seattle included the expected authentication key in its NTP packet to Tacoma. The peer became reachable within NTP, the peer status changed from unsynchronized state and the stratum changed from the default value. Example 9-24 displays the new NTP status.

Example 9-24 Output of show ntp status and show ntp association detail After Valid Authentication

 Tacoma#  show ntp status   Clock is synchronized, stratum 4, reference is 172.16.1.105  nominal freq is 250.0000 Hz, actual freq is 249.9999 Hz, precision is 2**19 reference time is BDD13640.D7686AD0 (15:25:36.841 Eastern Thu Nov 30 2000) clock offset is 30.8433 msec, root delay is 98.30 msec root dispersion is 15937.61 msec, peer dispersion is 15875.02 msec Tacoma#  show ntp association detail   172.16.1.105 configured, authenticated, our_master, sane, valid, stratum 3  

The clock is now synchronized, the stratum changed from the default of 16 to 4, the peer has become authenticated, and the peer time is believed to be valid.