Implementing NTP

Network Time Protocol (NTP) is a protocol designed to time-synchronize devices within a network. Cisco IOS XR software implements NTPv4. NTPv4 retains backwards compatibility with the older versions of NTP, including NTPv3 and NTPv2 but excluding NTPv1, which has been discontinued due to security vulnerabilities.

Information About Implementing NTP

NTP synchronizes timekeeping among a set 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 uses the User Datagram Protocol (UDP) as its transport protocol. All NTP communication uses Coordinated Universal Time (UTC). An NTP network usually receives its time from an authoritative time source, such as a radio clock or an atomic clock attached to a time server. NTP distributes this time across the network. NTP is efficient; no more than one packet per minute is necessary to synchronize two machines to within a millisecond of each other.

NTP uses the concept of a “stratum” to describe how many NTP “hops” away a machine is from an authoritative time source. A “stratum 1” time server typically has an authoritative time source (such as a radio or atomic clock, or a GPS time source) directly attached, a “stratum 2” time server receives its time via NTP from a “stratum 1” time server, and so on.

NTP avoids synchronizing to a machine whose time may not be accurate, in two ways. First, NTP never synchronizes to a machine that is not synchronized itself. Second, NTP compares the time reported by several machines and does not synchronize to a machine whose time is significantly different than the others, even if its stratum is lower. This strategy effectively builds a self-organizing tree of NTP servers.

The Cisco implementation of NTP does not support stratum 1 service; in other words, it is not possible to connect to a radio or atomic clock (for some specific platforms, however, you can connect a GPS time-source device). We recommend that time service for your network be derived from the public NTP servers available in the IP Internet.

If the network is isolated from the Internet, the Cisco implementation of NTP allows a machine to be configured so that it acts as though it is synchronized via NTP, when in fact it has determined the time using other means. Other machines can then synchronize to that machine via NTP.

Several manufacturers include NTP software for their host systems, and a publicly available version for systems running UNIX and its various derivatives is also available. This software also allows UNIX-derivative servers to acquire the time directly from an atomic clock, which would subsequently propagate time information along to Cisco routers.

The communications between machines running NTP (known as associations) are usually statically configured; each machine is given the IP address of all machines with which it should form associations. Accurate timekeeping is made possible by exchanging NTP messages between each pair of machines with an association.

The Cisco implementation of NTP supports two ways that a networking device can obtain NTP time information on a network:

  • By polling host servers

  • By listening to NTP broadcasts

In a LAN environment, NTP can be configured to use IP broadcast messages. As compared to polling, IP broadcast messages reduce configuration complexity, because each machine can simply be configured to send or receive broadcast or multicast messages. However, the accuracy of timekeeping is marginally reduced because the information flow is one-way only.

An NTP broadcast client listens for broadcast messages sent by an NTP broadcast server at a designated IPv4 address. The client synchronizes the local clock using the first received broadcast message.

The time kept on a machine is a critical resource, so we strongly recommend that you use the security features of NTP to avoid the accidental or malicious setting of incorrect time. Two mechanisms are available: an access list-based restriction scheme and an encrypted authentication mechanism.

When multiple sources of time (VINES, hardware clock, manual configuration) are available, NTP is always considered to be more authoritative. NTP time overrides the time set by any other method.


Note


NTP-PTP interworking is not supported on Cisco NCS 540 Series routers till IOS XR Software Release 24.1.1.


Configuring NTP

PTP-NTP Interworking

Table 1. Feature History Table

Feature Name

Release Information

Feature Description

PTP-NTP Interworking

Release 24.1.1

Introduced in this release on the following Cisco NCS 540 router variants running on Cisco IOS XR:

  • N540-ACC-SYS

  • N540X-ACC-SYS

  • N540-24Z8Q2C-SYS

We have improved NTP synchronization and reliability to achieve nanosecond-level accuracy for applications that require high-precision timing. This is achieved by enabling NTP-PTP interworking which allows the use of PTP as the reference clock.

As in previous releases, the NTP client continues to support polling NTP protocol-based external time servers to synchronize the local system clock and achieve accuracy within the millisecond range.

Before the support of PTP-NTP interworking, NTP worked with NTP server to get the clock.

PTP-NTP interworking provides the ability to use PTP, and other valid time of day (TOD) sources such as Data over Cable Service Interface Specification (DOCSIS) Timing Interface (DTI) and global positioning system (GPS), as the time source for the operating system in the units of nanosecond-level accuracy. PTP is capable of achieving nanosecond-level accuracy, while NTP is typically only accurate to within milliseconds. By using PTP as a reference clock, NTP can improve its accuracy and meet the needs of applications that require high precision timing.

PTP-NTP interworking also provides the means to communicate status changes between PTP and NTP processes. It also supports the unambiguous control of the operating system time and backplane time in the event of bootup, switchovers, or card and process failures.

With PTP-NTP interworking, NTP is less likely to lose synchronization. As, PTP is more robust to network delays and disruptions than NTP. Hence, PTP can still maintain accurate synchronization even if there’s a problem with the network.

Enable PTP-NTP Interworking

Prerequisites for PTP-NTP Interworking

Ensure that PTP is enabled, before configuring PTP-NTP Interworking.

Configuration Example for PTP-NTP Interworking

You can configure PTP-NTP Interworking in any of the following ways:

  • Setting NTP Primary Reference Clock as PTP

    Router # Configure
    Router(config) # ntp
    Router(config-ntp) # master primary-reference-clock
    Router(config-ntp) # commit
  • Configuring NTP Server with IP address

    The following example shows an NTP configuration to allow the system clock to be synchronized by time server hosts at IP address 198.51.100.1. You can take IP address of a neighbouring PTP interface.

    Router # Configure terminal
    Router(config)# ntp server 198.51.100.1
    Router(config-ntp) # commit
    
Verification
Router#show ntp status
 
Clock is synchronized, stratum 1, reference is 198.51.100.1
nominal freq is 1000000000.0000 Hz, actual freq is 101341889.2967 Hz, precision is 2**24
reference time is 8497CD13.A6AEB9DA (00:02:27.651 UTC Tue Jun 30 1970)
clock offset is -0.077 msec, root delay is 0.000 msec
root dispersion is 3937.89 msec, peer dispersion is 3937.74 msec
loopfilter state is 'CTRL' (Normal Controlled Loop), drift is 0.0000088676 s/s
system poll interval is 64, last update was 4 sec ago
authenticate is disabled, panic handling is disabled,
hostname resolution retry interval is 1440 minutes
Router#Show ntp associations
  address         ref clock     st  when  poll reach  delay  offset    disp
*~198.51.100.1    .PTP.          0     -    64    0   0.00   0.000   16000

Configuring Poll-Based Associations

The following example shows an NTP configuration in which the router’s system clock is configured to form a peer association with the time server host at IP address 192.168.22.33, and to allow the system clock to be synchronized by time server hosts at IP address 10.0.2.1 and 172.19.69.1:

ntp
  server 10.0.2.1 minpoll 5 maxpoll 7
  peer 192.168.22.33
  server 172.19.69.1

Configuring Broadcast-Based Associations

The following example shows an NTP client configuration in which interface 0/2/0/0 is configured to receive NTP broadcast packets, and the estimated round-trip delay between an NTP client and an NTP broadcast server is set to 2 microseconds:

ntp
 interface tengige 0/2/0/0
  broadcast client
  exit
broadcastdelay 2

The following example shows an NTP server configuration where interface 0/2/0/2 is configured to be a broadcast server:

ntp
 interface tengige 0/2/0/0
  broadcast

Configuring NTP Access Groups

The following example shows a NTP access group configuration where the following access group restrictions are applied:

Peer restrictions are applied to IP addresses that pass the criteria of the access list named peer-acl. Serve restrictions are applied to IP addresses that pass the criteria of access list named serve-acl.

Serve-only restrictions are applied to IP addresses that pass the criteria of the access list named serve-only-acl.

Query-only restrictions are applied to IP addresses that pass the criteria of the access list named query-only-acl.

ntp
  peer 10.1.1.1
  peer 10.1.1.1
  peer 10.2.2.2
  peer 10.3.3.3
  peer 10.4.4.4
  peer 10.5.5.5
  peer 10.6.6.6
  peer 10.7.7.7
  peer 10.8.8.8
  access-group peer peer-acl
  access-group serve serve-acl
  access-group serve-only serve-only-acl
  access-group query-only query-only-acl
  exit
ipv4 access-list peer-acl
  10 permit ip host 10.1.1.1 any
  20 permit ip host 10.8.8.8 any
  exit
ipv4 access-list serve-acl
  10 permit ip host 10.4.4.4 any
  20 permit ip host 10.5.5.5 any
  exit
ipv4 access-list query-only-acl
  10 permit ip host 10.2.2.2 any
  20 permit ip host 10.3.3.3 any
  exit
ipv4 access-list serve-only-acl
  10 permit ip host 10.6.6.6 any
  20 permit ip host 10.7.7.7 any
  exit

Configuring NTP Authentication

The following example shows an NTP authentication configuration. In this example, the following is configured:

NTP authentication is enabled.

Two authentication keys are configured (key 2 and key 3).

The router is configured to allow its software clock to be synchronized with the clock of the peer (or vice versa) at IP address 10.3.32.154 using authentication key 2.

The router is configured to allow its software clock to be synchronized with the clock by the device at IP address 10.32.154.145 using authentication key 3.

The router is configured to synchronize only to systems providing authentication key 3 in their NTP packets.

ntp
 authenticate
 authentication-key 2 md5 encrypted 06120A2D40031D1008124
 authentication-key 3 md5 encrypted 1311121E074110232621
 trusted-key 3
 server 10.3.32.154 key 3
 peer 10.32.154.145 key 2

Disabling NTP on an Interface

The following example shows an NTP configuration in which 0/2/0/0 interface is disabled:


ntp
 interface tengige 0/2/0/0
   disable
   exit
authentication-key 2 md5 encrypted 06120A2D40031D1008124
authentication-key 3 md5 encrypted 1311121E074110232621
authenticate
trusted-key 3
server 10.3.32.154 key 3
peer 10.32.154.145 key 2

Configuring the System as an Authoritative NTP Server

The following example shows a NTP configuration in which the router is configured to use its own NTP server clock to synchronize with peers when an external NTP source becomes unavailable:

ntp
  master 6

Updating the Hardware Clock

The following example shows an NTP configuration in which the router is configured to update its hardware clock from the software clock at periodic intervals:

ntp
  server 10.3.32.154
  update-calendar

Configuring NTP Server Inside VRF Interface


Note


No specific command enables NTP; the first NTP configuration command that you issue enables NTP.


RP/0/RP0/CPU0:router# configure
RP/0/RP0/CPU0:router(config)# ntp
RP/0/RP0/CPU0:router(config)# ntp vrf Customer_A
RP/0/RP0/CPU0:router(config)# ntp vrf Customer_A source bvi 70
RP/0/RP0/CPU0:router(config-ntp)# end
or
RP/0/RP0/CPU0:router(config-ntp)# commit