【Quick copy/paste】

Google: (Not recommended: static IP addresses: 216.239.35.0 or 216.239.35.4)

Configuring NTP servers with hostnames is a better approach.

TIME.google.com

TIME1.google.com

TIME2.google.com

TIME3.google.com

TIME4.google.com

Cloudflare:

TIME.cloudflare.com

National Time and Frequency Standard Laboratory of Taiwan:

TICK.stdtime.gov.tw

TOCK.stdtime.gov.tw

-----

Maintaining an accurate and synchronized time state across all hardware components is a non-negotiable operational standard in enterprise infrastructure. Network Time Protocol (NTP)—a UDP-based, user-mode network protocol—serves as the foundational baseline for achieving this requirement across servers, network devices, and client nodes.

The Critical Role of Time in Production Environments

Most computing systems rely on battery-powered internal electronic clocks that naturally drift over time, and few organizations can justify the exorbitant expense of dedicated atomic clock hardware for every node. This time variance becomes highly problematic when diagnosing system issues. It is extremely difficult to reconstruct the timeline about what events happen first and what events come after when analyzing log files recorded on different nodes without synchronized system time.

Because a standard NTP implementation delivers millisecond-level precision, it allows engineers to accurately merge, and correlate logs collected across entirely separate infrastructure nodes. Without this synchronization, reconstructing historical event timelines for troubleshooting is nearly impossible.

Protocol Variations: NTP vs. SNTP

NTP is a full feature time synchronization protocol. On the other hand, Simple NTP (SNTP) is a simplified, cut-down protocol variation.

In the full NTP protocol, there are three protocol modes: symmetric, client/server, and broadcast. SNTP reuses the same packet format as NTP and implements only the client/server mode.

Therefore, the good news is that any SNTP-capable clients can synchronize directly to a standard NTP server without requiring any specialized settings or adjustments on the NTP server side. NTP servers can serve NTP clients and SNTP clients simultaneously without modifying any configuration.

Typical NTP deployment scenarios

Case 0

When you have no more than 2 devices/servers, the most practical way is to synchronize both two of your nodes directly to public NTP servers.

Case 1

When you have more than 2 up to hundreds of nodes, and you do not have atomic clocks, you can deploy NTP like Figure 1. You must designate at least two nodes as the local servers. You configure your local servers to synchronize to public NTP servers so they will have trustworthy clock. The local stratum number in the figure is Stratum 2. And finally, you configure all your other local nodes to synchronize to your local servers.

Case 2

When you have thousands of nodes, and you do not have atomic clocks, you can deploy NTP like Figure 2. For thousands of nodes trying to query your few local servers, you might overwhelm these poor local servers’ processing power. In this case, you must add more local servers and rearrange them into multiple stratums of local servers. Level 2 servers synchronize themselves to Level 1 servers, and so on. The remaining nodes are configured based on their designated servers.

Case 3

If you have atomic clocks, and are directly attached to your NTP servers, then these NTP servers are Stratum 1 servers. Below Stratum 1, you may add NTP nodes directly below Stratum 1 or add one Stratum 2 servers like Case 1, or multiple stratums like Case 2. In Figure 3, it is multi-stratum and is like Case 2.

Connecting to Public NTP Servers Configuration Best Practices

When pointing infrastructure to external public resources, administrators should avoid using hardcoded, static IP addresses (such as `216.239.35.0`). Using static IPs introduces structural vulnerabilities because public providers routinely change their underlying network addresses according to management needs. Referencing a hostname instead forces the node to query and refresh the correct IP mapping every time a new session initializes. Furthermore, public providers leverage round-robin DNS load balancing. Using hostnames allows client queries to seamlessly resolve different IP addresses across separate lookup attempts, naturally distributing traffic.

Cisco IOS Configuration Blueprints

For administrators overseeing Cisco network environments, deployment templates can be split into specific device roles: clients, servers, and peers.

Declaring Authentication Key

This example we define a new Key ID 99 with secret “my_secret”. This new key is to be used later for clients, servers, and peers.

ntp authentication-key 99 md5 my_secret

Clients

For infrastructure nodes functioning strictly as clients, the configurations below bind queries to a designated source interface and set a preferred upstream target server:

! For Standard NTP Clients

! In this example, Google’s NTP server is preferred, while Cloudflare’s is the second best. No authentication keys are configured in this example. In reality, Google and Cloudflare public NTP servers do not authenticate clients.

ntp server time.google.com source {source interface name} prefer

ntp server time.cloudflare.com source {source interface name}

! In this example, client and servers are authenticated with Key 99. Server {local_server_IP_or_hostname_1} is preferred.

ntp authenticate

ntp trusted-key 99

ntp server {local_server_IP_or_hostname_1} source {source interface name} key 99 prefer

ntp server {local_server_IP_or_hostname_2} source {source interface name} key 99

! For Legacy / SNTP-Only Clients

! SNTP command is almost identical by changing “ntp” to “sntp”.

sntp server time.google.com source {source interface name} prefer

sntp server time.cloudflare.com source {source interface name}

Servers

Once an NTP node has established working upstream time source session, it will automatically start serving the downstream NTP clients. However, if the upstream session stops, it will also stop serving downstream clients.

We can add a fallback function: if upstream session stops, it will use the node’s local time as an authoritative time provider. The command is this:

ntp master 5

The integer value 5 in this example represents a stratum level ranging from 1 to 15, where a lower number indicates a more trustworthy time source. Normally, a device's stratum is determined dynamically by adding 1 to the stratum of its upstream provider. However, this fallback command instructs Cisco IOS to announce itself as Stratum 5 only if that upstream session stops.

Cisco IOS NTP master feature also supports key authentication. To add authentication:

ntp authenticate

ntp trusted-key 99

ntp master 5

Symmetric Peers

For NTP servers belonging to the same stratum number, they can mutually update each other’s clock. They are symmetric peers. To configure such peer-to-peer NTP sessions, we configure on both nodes with one command:

ntp peer {peer hostname/IP address} source {source interface name}

To add authentication

ntp authenticate

ntp trusted-key 99

ntp peer {peer hostname/IP address} source {source interface name} key 99

Verifying NTP

Once configurations are done, engineers can verify synchronization health and peer connectivity status using the `show ntp status` and `show ntp associations` diagnostic tools.