{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

Platform {{ profileLabel }} Review {{ resultsReady ? reviewBadge : 'required' }} Role {{ resultsReady ? roleLabel : '—' }}

{{ summaryAnnouncement }}

NTP configuration builder
NTP configuration inputs
Choose the software or network operating system that will consume the artifact.
CSV and whitespace rows are accepted; comments starting with # or ! are ignored.
Samples replace the source list and platform-specific fields locally.
Off keeps a client-only configuration. On requires explicit client networks.
{{ serve_clients ? 'Enabled' : 'Disabled' }}
Prefer narrow internal networks and enforce UDP/123 policy separately.
Blank is neutral and omits the directive.
Blank leaves the directive out of the artifact.
Adds rtcsync when supported by the operating system.
{{ enable_rtc_sync ? 'Enabled' : 'Disabled' }}
Adds nts to every source; confirm every upstream supports Network Time Security.
{{ enable_nts ? 'Enabled' : 'Disabled' }}
Blank is neutral and omits the directive.
Emits chrony local, ntpd orphan, or Cisco master syntax only when explicitly enabled.
{{ local_fallback ? 'Enabled' : 'Disabled' }}
Fallback time is not an external UTC reference.
Adds short installation and section comments without changing directives.
{{ include_comments ? 'Enabled' : 'Disabled' }}

{{ configExportStatus }}

{{ computation.values.config_text }}
{{ chartExportStatus }}

The chart renderer is unavailable. Compatibility counts remain in the source ledger.

SourceModeAcceptedIgnoredEmitted directiveCopy
{{ row.target }}{{ row.mode }}{{ row.accepted }}{{ row.ignored }}{{ row.directive }}
{{ tableExportStatus }}
LevelCheckDetailRecommendationCopy
{{ row.level }}{{ row.check }}{{ row.detail }}{{ row.recommendation }}
{{ tableExportStatus }}

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.

NTP roles and configuration consequences
RolePurposeConfiguration consequence
ClientAdjusts its own clock from upstream sources.Does not need downstream client-access rules.
Secondary serverSynchronizes upstream and serves other clients.Needs explicit allowed networks, firewall policy, monitoring, and source diversity.
Isolated fallbackKeeps a disconnected site using one local time reference.Must not masquerade as healthy upstream UTC; use an intentionally high stratum and monitor isolation.
Network deviceSynchronizes 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.

  1. Select Target platform and enter up to 24 Time sources. Each row begins with a hostname or IP address and may add server, pool, or peer plus supported options.
  2. Enable Serve downstream clients only for chrony or ntpd and provide narrow IPv4 client networks. The value all is accepted for chrony but deliberately rejected for classic ntpd.
  3. Set platform-specific choices such as a Cisco source interface or VRF, chrony NTS and startup behavior, drift-file paths, or authentication key details.
  4. Review the source compatibility ledger. Remove ignored tokens or switch platforms when the generated syntax would lose a required association behavior.
  5. 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.

NTP source option mapping by target profile
TargetAssociation mappingImportant rule
chronyPreserves 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 ntpdPreserves 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-timesyncdWrites all source targets into one NTP= list.Association modes, flags, and key-value options are ignored because the profile is client-only.
Cisco IOS XEMaps 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 XREmits 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.
NTP validation boundaries
InputBoundaryFailure behavior
Source rows1 to 24 usable rows; source text no longer than 8,192 charactersGeneration stops.
NTP versionInteger from 1 to 4, inclusiveGeneration stops for Cisco targets.
Authentication key IDInteger from 1 to 65,535, inclusiveGeneration stops.
Fallback stratumInteger from 1 to 15, inclusiveGeneration stops when fallback is enabled.
Classic ntpd client networkExplicit IPv4 CIDR or address plus contiguous netmaskall 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: