NTP Config Generator
Generate NTP configuration for Linux daemons or Cisco devices with source compatibility checks and warnings for unsafe fallback settings.{{ summaryTitle }}
{{ summaryLine }}
{{ summaryAnnouncement }}
{{ configExportStatus }}
{{ computation.values.config_text }}
The chart renderer is unavailable. Compatibility counts remain in the source ledger.
| Source | Mode | Accepted | Ignored | Emitted directive | Copy |
|---|---|---|---|---|---|
| {{ row.target }} | {{ row.mode }} | {{ row.accepted }} | {{ row.ignored }} | {{ row.directive }} |
| Level | Check | Detail | Recommendation | Copy |
|---|---|---|---|---|
| {{ row.level }} | {{ row.check }} | {{ row.detail }} | {{ row.recommendation }} |
Clock errors rarely stay confined to the clock. They can scramble log order, break time-limited authentication, confuse monitoring windows, and make distributed systems disagree about when an event happened. Network Time Protocol (NTP) reduces that drift by comparing a local clock with upstream sources and disciplining it toward Coordinated Universal Time (UTC).
An NTP source is not simply a timestamp supplier. A client compares multiple exchanges to estimate offset, network delay, and variability, then selects usable sources according to the time daemon's rules. Several independent sources are more resilient than one, but adding many names from the same provider or network path does not necessarily add real diversity.
| Role | Purpose | Configuration consequence |
|---|---|---|
| Client | Adjusts its own clock from upstream sources. | Does not need downstream client-access rules. |
| Secondary server | Synchronizes upstream and serves other clients. | Needs explicit allowed networks, firewall policy, monitoring, and source diversity. |
| Isolated fallback | Keeps a disconnected site using one local time reference. | Must not masquerade as healthy upstream UTC; use an intentionally high stratum and monitor isolation. |
| Network device | Synchronizes a router or switch. | May require a stable source interface, management VRF, NTP version, and pre-provisioned authentication key. |
The target software determines the syntax and available safeguards. chrony and classic ntpd support association options and can serve downstream clients. systemd-timesyncd is a lightweight client and emits one ordered source list. Cisco IOS XE and IOS XR use device configuration commands whose source-interface, VRF, and key syntax must match the exact platform release.
Security and availability pull in different directions. Network Time Security (NTS) authenticates eligible chrony associations, while a local fallback can preserve continuity when upstream UTC disappears. Requiring NTS from an unsupported source prevents synchronization; enabling an authoritative fallback carelessly can hide an outage. Runtime checks remain essential because a correct-looking configuration cannot prove DNS, routing, firewall access to UDP port 123, or actual clock quality.
How to Use This Tool:
Choose the software or network operating system that will consume the result before entering sources. Association options are translated differently for each target.
- Select Target platform and enter up to 24 Time sources. Each row begins with a hostname or IP address and may add
server,pool, orpeerplus supported options. - Enable Serve downstream clients only for
chronyorntpdand provide narrow IPv4 client networks. The valueallis accepted forchronybut deliberately rejected for classicntpd. - Set platform-specific choices such as a Cisco source interface or VRF,
chronyNTS and startup behavior, drift-file paths, or authentication key details. - Review the source compatibility ledger. Remove ignored tokens or switch platforms when the generated syntax would lose a required association behavior.
- Install the configuration in a staged environment, restart or reload the selected time service, and verify the chosen source, offset, reachability, and firewall policy.
Interpreting Results:
A generated directive is syntactically compatible with the selected profile; it is not evidence that the source is reachable or trustworthy. The compatibility counts distinguish emitted association options from tokens that the target profile cannot represent. Any ignored token deserves review when it controls polling, authentication, source selection, or routing context.
Fallback and NTS warnings need deliberate decisions. Keep local fallback off on ordinarily connected hosts unless an isolated-site design requires it. When NTS is required, confirm every selected source and the installed chronyd build support it. After installation, verify the active source and clock offset rather than treating a running service as proof of synchronization.
Technical Details:
Each source row is parsed into a target, an association mode, standalone flags, and key-value options. Comments beginning with # or ! are ignored. CSV and whitespace-separated rows are accepted, but the final directive is governed by the chosen platform rather than copied verbatim.
Rule Core:
The source vocabulary is filtered through a platform-specific rule set. Unsupported options appear in review evidence and are not emitted.
| Target | Association mapping | Important rule |
|---|---|---|
chrony | Preserves server, pool, or peer and supported polling, selection, NTS, interleaving, offline, and pool-count options. | Global NTS adds nts to every source; maxsources applies only to pools. |
Classic ntpd | Preserves common association modes, polling, preference, key, and supported interleaved-peer options. | NTS, offline, and pool-count options are ignored; client access becomes restrict rules. |
systemd-timesyncd | Writes all source targets into one NTP= list. | Association modes, flags, and key-value options are ignored because the profile is client-only. |
| Cisco IOS XE | Maps pools to server associations and emits version, key, source, preference, and optional VRF syntax. | The requested VRF is part of the association; unsupported Linux-daemon options are ignored. |
| Cisco IOS XR | Emits NTP submode commands with version, key, source, and preference where supported. | VRF handling is used for the source-interface context and must be checked against the device release. |
| Input | Boundary | Failure behavior |
|---|---|---|
| Source rows | 1 to 24 usable rows; source text no longer than 8,192 characters | Generation stops. |
| NTP version | Integer from 1 to 4, inclusive | Generation stops for Cisco targets. |
| Authentication key ID | Integer from 1 to 65,535, inclusive | Generation stops. |
| Fallback stratum | Integer from 1 to 15, inclusive | Generation stops when fallback is enabled. |
Classic ntpd client network | Explicit IPv4 CIDR or address plus contiguous netmask | all and invalid masks stop generation. |
Serving clients changes the trust boundary. chrony emits allow entries, while classic ntpd builds restricted network clauses. Firewall rules remain outside the generated text. For Cisco profiles, a clear-text authentication key is emitted only when both the key ID and secret are supplied; source rows may still reference an existing key by ID.
Security and Accuracy Notes:
- Keep one active clock-disciplining service per host unless a documented design says otherwise.
- Limit downstream access to intended networks and enforce UDP port 123 policy separately.
- Treat clear-text Cisco keys as secrets. Do not place them in shared links, tickets, screenshots, or uncontrolled files.
- A high stratum indicates distance from a reference clock, not a complete measure of accuracy or trust.
- The browser cannot test packages, daemon versions, DNS, routes, interfaces, VRFs, firewall rules, NTS support, or upstream responses.
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 4.8 manual, chrony project.
- NTP Configuration File User's Manual, NTP Project.
- timesyncd.conf, systemd.
- How to synchronize time with NTP in Linux, Simplified Guide.