Cisco Nexus 9000 Series NX-OS System Management Configuration Guide, Release 9.3(x) - Configuring NTP [Cisco Nexus 9000 Series Switches] (2023)

The Network Time Protocol (NTP) synchronizes the time of day among a set of distributed time servers and clients so that you can correlate events when you receive system logs and other time-specific events from multiple network devices. NTP uses the User Datagram Protocol (UDP) as its transport protocol. All NTP communications use Coordinated Universal Time (UTC).

An NTP server usually receives its time from an authoritative time source, such as a radio clock or an atomic clock attached to a time server, and then distributes this time across the network. NTP is extremely efficient; no more than one packet per minute is necessary to synchronize two machines to within a millisecond of each other.

NTP uses a stratum to describe the distance between a network device and an authoritative time source:

• A stratum 1 time server is directly attached to an authoritative time source (such as a radio or atomic clock or a GPS time source).
• A stratum 2 NTP server receives its time through NTP from a stratum 1 time server.

Before synchronizing, NTP compares the time reported by several network devices and does not synchronize with one that is significantly different, even if it is a stratum 1. Because Cisco NX-OS cannot connect to a radio or atomic clock and act as a stratum 1 server, we recommend that you use the public NTP servers available on the Internet. If the network is isolated from the Internet, Cisco NX-OS allows you to configure the time as though it were synchronized through NTP, even though it was not.

Note	You can create NTP peer relationships to designate the time-serving hosts that you want your network device to consider synchronizing with and to keep accurate time if a server failure occurs.

The time kept on a device 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.

NTP has the following prerequisites:

• To configure NTP, you must have connectivity to at least one server that is running NTP.

NTP has the following configuration guidelines and limitations:

• NTP server functionality is supported.

• Before configuring a name based NTP server (FQDN) in a non-default VRF, you must configure a DNS server under that specific VRF. If you configure the DNS server from the global configuration mode using use-vrf option, then that name based NTP server configuration will not be added to the running configuration. If you attempted to configure NTP server using this method, you must remove the NTP configuration using the no version of the command, add the DNS server under that VRF, and then add name based NTP server to the VRF.

• We recommend that you configure a peer association with another device only when you are sure that your clock is reliable (which means that you are a client of a reliable NTP server).

• A peer that is configured alone takes on the role of a server and should be used as a backup. If you have two servers, you can configure several devices to point to one server and the remaining devices to point to the other server. You can then configure a peer association between these two servers to create a more reliable NTP configuration.

• If you have only one server, we recommend that you configure all the devices as clients to that server.

• You can configure up to 64 NTP entities (servers and peers).

  (Video) Cisco Nexus 9000 - Initial Configuration

• If you configure NTP in a VRF, ensure that the NTP server and peers can reach each other through the configured VRFs.

• Manually distribute NTP authentication keys on the NTP server and Cisco NX-OS devices across the network.

• If you are using the switch as an edge device and want to use NTP, we recommend using the ntp access-group command and filtering NTP only to the required edge devices.

• If the system has been configured with the ntp passive , ntp broadcast client , or ntp multicast client commands, when NTP receives an incoming symmetric active, broadcast, or multicast packet, it can set up an ephemeral peer association in order to synchronize with the sender.

  Note	Make sure that you specify ntp authenticate before enabling any of the preceding commands. Failure to do so will allow your device to synchronize with any device that sends one of the preceding packet types, including malicious attacker-controlled devices.

• If you specify the ntp authenticate command, when a symmetric active, broadcast, or multicast packet is received, the system does not synchronize to the peer unless the packet carries one of the authentication keys that are specified in the ntp trusted-key global configuration command.

• To prevent synchronization with unauthorized network hosts, the ntp authenticate command should be specified any time the ntp passive , ntp broadcast client , or ntp multicast client command has been specified unless other measures, such as the ntp access-group command, have been taken to prevent unauthorized hosts from communicating with the NTP service on the device.

• The ntp authenticate command does not authenticate peer associations that are configured via the ntp server and ntp peer configuration commands. To authenticate the ntp server and ntp peer associations, specify the key keyword.

• A maximum of four IP ACLs can be configured for a single NTP access group. IPv4 and IPv6 ACLs are supported.

The following table lists the default settings for NTP parameters.

To display the NTP configuration, perform one of the following tasks:

Use the clear ntp session command to clear the NTP sessions.

Use the clear ntp statistics command to clear the NTP statistics.

This example shows how to configure the device to synchronize only to time sources that provide authentication key 42 in their NTP packets:

switch# configure terminalEnter configuration commands, one per line. End with CNTL/Z.switch(config)# ntp authentication-key 42 md5 aNiceKeyswitch(config)# ntp server 192.0.2.105 key 42switch(config)# ntp trusted-key 42switch(config)# ntp authenticateswitch(config)# copy running-config startup-config[########################################] 100%switch(config)#

This example shows an NTP access group configuration with the following restrictions:

• Peer restrictions are applied to IP addresses that pass the criteria of the access list named “peer-acl.”

  (Video) 03 Instalacion y actualizacion de Cisco Nexus NX-OS (Upgrade)

• Serve restrictions are applied to IP addresses that pass the criteria of the 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.”

switch# configure terminalswitch(config)# ntp peer 10.1.1.1switch(config)# ntp peer 10.2.2.2switch(config)# ntp peer 10.3.3.3switch(config)# ntp peer 10.4.4.4switch(config)# ntp peer 10.5.5.5switch(config)# ntp peer 10.6.6.6switch(config)# ntp peer 10.7.7.7switch(config)# ntp peer 10.8.8.8switch(config)# ntp access-group peer peer-aclswitch(config)# ntp access-group serve serve-aclswitch(config)# ntp access-group serve-only serve-only-aclswitch(config)# ntp access-group query-only query-only-aclswitch(config)# ip access-list peer-aclswitch(config-acl)# 10 permit ip host 10.1.1.1 anyswitch(config-acl)# 20 permit ip host 10.8.8.8 anyswitch(config)# ip access-list serve-aclswitch(config-acl)# 10 permit ip host 10.4.4.4 anyswitch(config-acl)# 20 permit ip host 10.5.5.5 anyswitch(config)# ip access-list serve-only-aclswitch(config-acl)# 10 permit ip host 10.6.6.6 anyswitch(config-acl)# 20 permit ip host 10.7.7.7 anyswitch(config)# ip access-list query-only-aclswitch(config-acl)# 10 permit ip host 10.2.2.2 anyswitch(config-acl)# 20 permit ip host 10.3.3.3 any

Note

When only a single ACL group is applied, then all the packets relevant for other ACL categories are denied and only packets relevant for the configured ACL group is processed, as mentioned in below scenarios: If serve ACL is configured, then only client, control, and private packets are processed and all the other packets are denied. If serve-only ACL is configured, then only client packets are processed and all the other packets are denied. If more than a single ACL is configured, it follows the order of processing as mentioned in below scenario: If serve and serve-only both are configured for the same IP address without match-all configured, where the IP is permitted in serve-acl and denied in serve-only, the client, control, private packets are permitted for that IP.