{{ result.summaryTitle }}
{{ result.primary }}
{{ result.summaryLine }}
{{ badge.label }}
NTP configuration inputs
The selected platform controls source directives, access rules, and validation warnings.
Examples: 0.pool.ntp.org,pool,iburst or ntp1.example.internal,server,iburst,prefer.
Samples stay local and replace the current form.
Off creates a client-only config. On emits client access rules for the networks below.
Use narrow internal CIDRs unless this host is meant to be a public NTP server.
Example: Loopback0 or Vlan44.
Leave blank when the NTP sources are reachable in the default routing table.
Accepted range is 1-4; version 4 is the normal default.
Default works for common RHEL-style chrony deployments.
Use 1.0 3 to step large startup offsets only during initial updates.
Keeps the hardware clock synchronized when supported by the OS.
Use only when every selected source supports Network Time Security.
Default matches common classic ntpd packaging.
Leave blank to omit Cisco symmetric authentication stanzas.
No spaces or newlines. The generated Cisco config will include the literal secret.
Off is safest. On emits chrony local, ntpd orphan, or Cisco ntp master fallback syntax.
Accepted range is 1-15; use fallback only for isolated networks.
Adds short file headers and section labels to the generated artifact.
{{ result.configText || '# Fix validation errors to generate NTP config.' }}
Source Mode Options Emitted line Note Copy
No source rows parsed yet.
{{ row.source }} {{ row.mode }} {{ row.options }} {{ row.emitted }} {{ row.note }}
Severity Check Detail Recommendation Copy
{{ row.severity }} {{ row.check }} {{ row.detail }} {{ row.recommendation }}

        
Customize
Advanced
:

Network Time Protocol configuration gives a host or network device a trusted path for setting its clock. The source list decides which servers, pools, or peers can discipline time, while access rules decide whether the same node only consumes time or also answers client requests from a local network.

Clock drift is easy to overlook until logs no longer line up, certificate checks fail, Kerberos tickets are rejected, or clustered systems disagree about event order. A practical NTP draft therefore has to cover more than a list of servers. It should show the target daemon syntax, source reachability assumptions, client-serving scope, authentication choices, and fallback behavior clearly enough to review before a change window.

Time sources server, pool, peer Target syntax chrony ntpd Cisco IOS XE Review checks errors, warnings, ledger Test with chronyc, ntpq, or show ntp status before deployment
A useful NTP draft keeps source intent, platform syntax, and review cues connected before the generated text reaches a host or device.

Different platforms express the same time-source plan in different ways. chrony commonly uses server, pool, driftfile, makestep, and rtcsync. Classic ntpd uses restrict lines and tos orphan for fallback behavior. Cisco IOS XE uses global ntp commands, source-interface choices, VRF-aware server statements, and optional key-based authentication.

A generated NTP config should still be treated as a deployment draft. Package defaults, existing include files, firewalls, DNS, routing tables, VRF reachability, authentication secrets, and the quality of upstream clocks all remain outside the copied text.

Technical Details:

NTPv4 synchronizes clocks by comparing timestamps between clients, servers, and peers, then selecting and disciplining time sources through the local daemon or device operating system. Source quality is usually expressed through stratum, offset, delay, jitter, reachability, and selection state, but a config generator can only prepare the candidate directives. The real clock state appears after the daemon starts polling reachable sources.

The source row shape is simple: a target host or IP address first, followed by an optional mode and option tokens. server is the default mode, pool asks a daemon to use multiple sources from a pool name where supported, and peer describes a symmetric association. Options such as iburst, prefer, version, key, source, vrf, and nts are emitted only where the selected target profile supports them.

Rule Core:

NTP configuration generation rules by target profile
Area chrony output ntpd output Cisco IOS XE output
Time source row server, pool, or peer with supported Linux source options. server, pool, or peer with classic ntp.conf options. ntp server or ntp peer; pool rows are warned because IOS XE output expects concrete servers.
Client access Optional allow directives for entered CIDRs, including allow all when deliberately chosen. Default restrictions plus optional IPv4 restrict entries for client networks. Not generated; the Cisco profile focuses on device time-source commands.
State and startup behavior driftfile, optional makestep, and optional rtcsync. driftfile and default restriction lines. ntp source when a source interface is supplied.
Security and authentication nts can be appended to chrony source directives when the selected sources support Network Time Security. NTS is not emitted for ntpd output. ntp authenticate, ntp authentication-key, ntp trusted-key, and per-source key are emitted when key data is complete.
Fallback clock local stratum N. tos orphan N. ntp master N.

Fallback clock directives deserve a conservative review. They let a node keep serving time inside an isolated network when upstream sources disappear, but they can also hide a broken upstream path if the fallback stratum is too attractive. A high value such as 10 keeps genuine external sources preferred whenever they are reachable.

Validation Boundaries:

Validation boundaries for generated NTP configuration
Check Blocking condition Review condition
Time sources No usable source rows, or a source target that is not an IP address or hostname. Unknown tokens are ignored and listed for review.
Source options Unsupported options do not usually block generation. Profile-specific warnings appear when an option such as nts, source, vrf, or maxsources cannot be emitted for the selected syntax.
Client networks Serve LAN clients is enabled with no networks, malformed CIDR, a bad IPv4 mask, or an unsupported network form. all is accepted for chrony but should be used only for an intentionally public NTP service with firewall controls.
Version and fallback stratum Values are normalized to supported ranges rather than stopping generation. NTP version is clamped to 1 through 4; fallback stratum is clamped to 1 through 15.
Cisco profile A Cisco authentication secret containing whitespace is blocked. Missing global source interface, hostname targets, VRF insertion, or a key ID without a local secret creates review rows.
Network Time Security No direct syntax error is raised for chrony NTS. The review warns that every selected chrony source must support NTS before the added nts option is useful.

The NTS setting is deliberately narrow. Network Time Security adds TLS-based key establishment before authenticated NTP packet exchange, but this generator only appends the chrony source option. Certificate trust, TCP port 4460 reachability, and actual server support have to be verified on the target system.

The config text, source ledger, validation review, and JSON view are built from the same parsed source rows and settings. If the review contains an error, the generated config should be treated as diagnostic text until the named input is corrected.

Everyday Use & Decision Guide:

Start with the target platform. Choose chrony for most modern Linux deployments that use chronyd, ntpd for classic ntp.conf environments, and Cisco IOS XE for device global commands. Use pool rows for Linux pools; for Cisco, enter concrete server IP addresses when possible because the review warns on pool-style input and hostname targets.

Enter one source per line and keep each row readable. A practical Linux row is 0.pool.ntp.org,pool,iburst. A private preferred source can look like ntp1.example.internal,server,iburst,prefer. A Cisco row can add device-specific options such as version=4, key=10, source=Loopback0, or vrf=Mgmt-vrf.

  • Leave Serve LAN clients off for a simple client-only Linux host.
  • Turn Serve LAN clients on only when the host should answer NTP clients, then use narrow internal CIDRs such as 10.44.0.0/16.
  • Set Source interface for Cisco devices when peers should see a stable loopback or management SVI address.
  • Use Management VRF only when the NTP sources are reachable through that existing VRF.
  • Keep Add local fallback clock off unless the network must keep an internal time island running during upstream loss.
  • Enable Add NTS to chrony sources only after checking that all selected chrony sources support NTS.

The common mistake is treating a clean text block as proof of time health. A config can be syntactically reasonable while the DNS name fails to resolve, UDP 123 is blocked, the Cisco VRF cannot reach the source, or an authentication key does not match the upstream server.

Read Validation Review before copying the generated config. Clear every error, then decide whether each warning is intentional for the target platform and change plan.

Step-by-Step Guide:

Build the NTP draft from platform choice, source rows, service scope, and advanced safety settings.

  1. Choose Target platform. The summary title should switch to chrony NTP Config, ntpd NTP Config, or Cisco IOS XE NTP Config.
  2. Paste or edit Time sources. The primary summary should show the parsed source count, and Source Ledger should show each emitted source line.
  3. For Linux profiles, decide whether Serve LAN clients belongs on. If it is on, enter Allowed client networks as IPv4 CIDR, IPv4 plus mask, or all for an intentional chrony public-service shape.
  4. For Cisco IOS XE, set Source interface and optional Management VRF. Confirm the generated config contains the intended ntp source and ntp server vrf shape.
  5. Open Advanced. Review NTP version, drift file paths, makestep, Add rtcsync, NTS, Cisco authentication key fields, fallback stratum, and comments against the target platform.
  6. Open Validation Review. If an error says no source rows, invalid target, missing client network, malformed CIDR, or whitespace in a Cisco secret, fix that input before using the config.
  7. Use Source Ledger to compare each source, mode, option set, emitted line, and note against the change request.
  8. Copy NTP Config only after the review is clean enough for the target. Then test on the host or device with the platform's own status commands.

Interpreting Results:

Needs review means at least one validation error remains and the config copy action is disabled. A source count such as 3 sources means source rows were parsed, not that those sources are reachable or selected by the daemon. The platform badge names the syntax family, and the warning or validated badge tells you whether the current draft needs more review.

NTP config generator output cues and follow-up actions
Output cue Meaning Follow-up
fix required The review found an error that should stop deployment. Correct the named field before copying NTP Config.
warnings The config can be generated, but an option, fallback, NTS choice, broad access rule, or Cisco detail needs approval. Read Validation Review and decide whether the warning is intentional.
Source Ledger Shows the parsed source target, mode, options, emitted line, and note. Use it to catch a row that silently changed shape because an option was unsupported.
client config The selected profile is not serving downstream Linux clients. Leave it this way unless the host is meant to be an NTP server for a LAN.
serves clients Linux client access rules are being emitted. Confirm the allowed CIDRs, host firewall, and monitoring plan.

A ready-looking draft still needs runtime verification. Use commands such as chronyc sources, chronyc tracking, ntpq -p, ntpq -c rv, show ntp status, and show ntp associations on the target platform after applying the final reviewed configuration.

Worked Examples:

Linux chrony client that serves one LAN

A chrony setup with 0.pool.ntp.org,pool,iburst, 1.pool.ntp.org,pool,iburst, and ntp1.example.internal,server,iburst,prefer produces pool and server directives. With Serve LAN clients on and Allowed client networks set to 10.44.0.0/16, NTP Config includes allow 10.44.0.0/16. The summary should show three sources and serves clients, while Validation Review should stay focused on any optional warnings.

Cisco IOS XE through a management VRF

A device profile with 10.44.10.10,server,prefer, 10.44.10.11,server, Source interface set to Loopback0, and Management VRF set to Mgmt-vrf emits a global ntp source Loopback0 line and server commands with vrf Mgmt-vrf. If a row uses a hostname, Validation Review warns because IOS XE documentation describes this server input as an IP address.

Fallback clock for an isolated site

When Add local fallback clock is enabled with fallback stratum 10, the emitted syntax changes by profile: chrony uses local stratum 10, ntpd uses tos orphan 10, and Cisco IOS XE uses ntp master 10. The warning is expected for a time island, but it should stop a normal connected deployment until the team confirms that upstream loss must be masked for local clients.

Broken client-serving draft

If Serve LAN clients is on and Allowed client networks is blank, Validation Review adds a client-access error and the config copy action stays disabled. Enter a real internal CIDR such as 10.44.0.0/16, or turn the client-serving switch off when the host should only synchronize itself.

Security and Privacy Notes:

NTP configuration often contains internal hostnames, management VRF names, source-interface choices, private addresses, and authentication key identifiers. Treat copied text and downloaded tables as change-sensitive material, especially when the Cisco authentication secret field is used.

The generated config, ledger, validation review, and JSON payload are produced in the browser after the page loads. The Cisco authentication secret is kept out of the JSON payload, but it is included literally in the generated Cisco configuration when both a key ID and secret are entered.

Key-based NTP authentication and NTS solve different problems. Cisco symmetric key lines require matching local device and server configuration. chrony NTS requires NTS-capable sources, certificate trust, TCP 4460 reachability for key establishment, and ordinary NTP packet reachability afterward.

FAQ:

Does a validated draft mean time is synchronized?

No. It means the current inputs can produce the selected config syntax without blocking errors. Confirm real synchronization with platform commands after applying the final reviewed config.

Which target platform should I choose?

Choose chrony for chronyd-based Linux systems, ntpd for classic ntp.conf systems, and Cisco IOS XE when you need global device commands.

What time source row formats are accepted?

Use one source per line. Rows may be CSV or space-separated, with a target first, optional mode such as server, pool, or peer, and supported tokens such as iburst, prefer, version=4, key=10, source=Loopback0, or vrf=Mgmt-vrf.

Why did an option appear as a warning?

Options are emitted only when the selected profile supports them. For example, chrony can emit nts, while Cisco output warns on Linux-oriented options such as iburst and expects Cisco-supported values such as version, key, source, vrf, and prefer.

When should I use Network Time Security?

Use the NTS switch only for chrony sources that support NTS. The generated text adds the nts option, but certificate trust and TCP 4460 reachability still need target-side verification.

Should the local fallback clock be enabled?

Usually no. Enable it only for isolated networks that need a local time leader during upstream loss, and use a high fallback stratum so real sources win whenever they return.

Are entered values sent to a generation service?

The config text, tables, and JSON are generated in the browser from the current form state. There is no separate server-side generation endpoint for the values entered here.

Glossary:

NTP
Network Time Protocol, the protocol used to synchronize clocks between clients, servers, and peers.
chrony
A Linux time synchronization suite using chronyd and chrony.conf-style directives.
ntpd
The classic NTP daemon configured with ntp.conf syntax and restrict rules.
NTS
Network Time Security, a TLS-based security extension for NTP source authentication.
Stratum
A hop count from a reference clock; higher fallback stratum values make local fallback less attractive than real upstream sources.
Pool
A source directive that lets a daemon select multiple servers from a pool name where the platform supports it.
Peer
A symmetric NTP association where two systems can act as time clients and servers to each other.
VRF
Virtual routing and forwarding, a Cisco routing context that can have separate reachability for management services.

References: