NTP Config Generator

Clock drift usually becomes visible only after something else breaks. A log entry appears before the request that caused it, a certificate is judged not yet valid, a Kerberos ticket fails, or a database cluster has to compare writes from machines that disagree about time. The fix is not just choosing a famous server name. The whole time path has to match the operating system, routing table, firewall, daemon, and risk of the service depending on it.

Network Time Protocol, usually shortened to NTP, lets a system compare its local clock with one or more time sources and adjust gradually toward Coordinated Universal Time. Replies are useful because they include timing information that lets the client estimate offset, delay, and jitter, not because one received timestamp is blindly trusted. A good configuration creates candidate associations, controls who may ask the host for time, and avoids fallback rules that can make a failed upstream source look healthy.

Source

A hostname or IP address that can provide time, usually reached over UDP port 123.

Pool

A DNS name that can return changing sets of servers, useful for diversity when the client can reach public or internal pool names.

Peer

A symmetric relationship where two NTP systems can exchange time with each other instead of a simple client-to-server pull.

Stratum

A hop count from a reference clock. Lower stratum is closer to the reference source, but route quality and jitter still matter.

Time design changes with the role of the machine. A workstation or small VM often needs a client-only setup. A Linux host serving a subnet needs explicit client networks, firewall alignment, monitoring, and enough upstream diversity to survive one bad source. Routers and switches often need a stable source interface, and management traffic may need a VRF so replies use the expected routing table. Public pool names are convenient for many clients, while critical environments often prefer internal relays, source diversity by network path, or carefully operated private sources.

The common mistake is treating generated text as proof that time is synchronized. It is only a proposed plan. DNS, routing, UDP port 123, daemon support, authentication keys, Network Time Security support, and device syntax all have to work on the real system. After deployment, status output should show a selected source, reachability, offset, delay, jitter, stratum, and any authentication state before the clock is trusted.

How to Use This Tool:

Choose the platform first because the same source list becomes different syntax for chrony, ntpd, systemd-timesyncd, and Cisco profiles.

1. Choose Target platform. Use chrony for chronyd-style Linux hosts, ntpd for classic ntp.conf, systemd-timesyncd for a small client-only host, or a Cisco profile when the output should be device commands.
2. Enter Time sources with one source per line. Put the hostname or IP address first, then a mode such as server, pool, or peer, followed by supported tokens such as iburst, prefer, version=4, key=10, source=Loopback0, vrf=Mgmt-vrf, or nts.
3. Turn on Serve LAN clients only when a Linux host should answer downstream clients. Add narrow IPv4 values in Allowed client networks, such as 10.44.0.0/16 or 10.44.0.0 255.255.0.0.
   all is accepted for chrony with a warning and is not emitted as an ntpd client-network rule. Use it only for an intentional public service with firewall review.
4. Set Source interface and Management VRF for Cisco profiles when the device should source NTP from a loopback, SVI, or management routing table. Leave Management VRF blank when the sources are reachable through the default routing table.
5. Open Advanced for NTP version, drift files, chrony makestep, rtcsync, Network Time Security, Cisco authentication, Add local fallback clock, Fallback stratum, and generated comments.
   Version is normalized to 1 through 4, and fallback stratum is normalized to 1 through 15.
6. Read the summary and Validation Review. Fix Error rows for missing sources, invalid targets, empty client networks, malformed masks, or Cisco authentication secrets that contain whitespace. Treat Warning rows as deployment-review prompts.
7. Compare Source Ledger with NTP Config before copying. The ledger shows the parsed source, mode, source options, emitted line, and notes, so platform-specific omissions are visible before deployment.

Interpreting Results:

The generated config is usable only when the summary has no blocking errors. A badge such as 3 sources means three rows were parsed, not that those sources are reachable, healthy, or selected by the daemon. Use the warning count and ledger details to decide what needs review before deployment.

The false-confidence risk is copying clean-looking text and skipping live verification. After applying the config, use platform status output such as chrony source tracking, ntpd peer status, systemd-timesyncd status, or Cisco NTP status and associations to confirm the selected source, offset, delay, jitter, reachability, and authentication behavior.

Technical Details:

NTPv4 describes client/server, symmetric peer, and broadcast-style relationships. Most ordinary hosts use client/server mode: a client sends request packets, servers reply, and the local clock discipline estimates offset from the timestamp exchange. Peer mode is a different association, because both systems can exchange time, so it belongs in controlled designs where both sides are known and monitored.

A configuration file names candidate associations and local policy; it does not prove that a source will be selected. The running daemon or network device still resolves names, reaches sources, rejects falsetickers, compares measurements, and adjusts the clock. Stratum is only distance from a reference clock. Offset, delay, jitter, reach, and root distance are better evidence that the running clock is behaving after startup.

Rule Core:

Fallback clock directives deserve extra care. They can keep an isolated network on one shared time base when upstream sources disappear, but they can also hide an outage if the fallback looks too attractive. A high fallback stratum such as 10 makes real upstream sources win whenever they return.

Source Option Map:

Validation Boundaries:

Security and Accuracy Notes:

The config text is created in the browser from the values you enter. It does not test DNS, reachability, installed daemon versions, firewall rules, NTS certificate trust, or whether a Cisco VRF exists.

• Entering a Cisco authentication secret puts that literal secret in the generated Cisco config. The JSON output omits the secret, but copied or downloaded config text can still expose it.
• Serving LAN clients changes the host from a time client into part of the time service. Review client networks, firewall rules, rate limits, and monitoring before deploying that mode.
• Network Time Security requires compatible sources, certificate trust, and reachability for the NTS key-establishment service. Adding nts to an ordinary source line does not make the source support it.
• Public NTP pool names are useful for many clients, but high-impact environments should use a time design that matches business risk, network control, and source reliability requirements.

Advanced Tips:

• Use Linux sample to start a chrony relay, then replace the pool names and Allowed client networks with the site's actual upstreams and internal CIDRs.
• Keep Add local fallback clock off for normal internet-connected clients. If an isolated site needs it, use a high Fallback stratum and monitor for upstream recovery.
• Turn on Add NTS to chrony sources only when every selected chrony source supports Network Time Security. Ordinary NTP pool names may not support NTS.
• For Cisco profiles, prefer literal server addresses when the device may boot before DNS or management VRF reachability is proven.
• Use Source Ledger to review unsupported tokens before change approval. A warning may still produce config text, but the omitted option can change the behavior you expected.

Worked Examples:

These cases show how the same source plan changes when platform syntax, serving scope, or validation errors change.

FAQ:

Glossary:

Source

An NTP server, pool name, or peer used as a candidate time reference.

Pool

A DNS name that can return changing NTP servers for source diversity.

Peer

A symmetric NTP association where two systems can exchange time with each other.

Stratum

A hop count from a reference clock, not a complete measure of time quality.

Offset

The estimated time difference between the local clock and a source.

Drift

The local clock's frequency tendency, learned over time and stored by many NTP daemons.

NTS

Network Time Security, a TLS-based key-establishment and authenticated NTP mechanism for supported client-server sources.

VRF

Virtual Routing and Forwarding, a separate routing table often used for management traffic on network devices.

References:

• RFC 5905: Network Time Protocol Version 4, RFC Editor, June 2010.
• RFC 8915: Network Time Security for NTP, RFC Editor, September 2020.
• chrony.conf(5) Manual Page, chrony project.
• NTP Configuration File User's Manual, NTP Project.
• timesyncd.conf, systemd.
• System Management Configuration Guide, Cisco IOS XE 17.x - Network Time Protocol, Cisco.
• NTP Commands on Cisco IOS XR Software, Cisco.
• How do I use pool.ntp.org?, NTP Pool Project.
• How to synchronize time with NTP in Linux, Simplified Guide.