Cisco IOS NTP Configuration: Server and Source Interface

Accurate time on network gear is not cosmetic: syslog correlation, RADIUS/TACACS authentication, certificate validation, SNMP time stamps and routing protocol debugging all depend on synchronized clocks. Cisco IOS and IOS XE routers and switches use NTP associations to keep time, and while the configuration is short, the details matter - especially the source interface, which decides which IP address the device advertises as its NTP source. This guide walks through the standard Cisco IOS NTP configuration with the commands that make it reliable in production.

Time is a hidden dependency of almost every security control and observability tool. A syslog entry with the wrong timestamp is nearly useless during an incident. A TACACS or RADIUS login that fails because the shared secret is validated against a skewed clock locks engineers out. Certificate validation fails when the device clock drifts outside the certificate validity window. Even debugging a routing flap across two devices with different clocks becomes guesswork. Getting NTP right is therefore less about the clock and more about everything that reads it.

NTP Modes on Cisco IOS

Before configuring anything it helps to know which role a device plays. In client mode the device polls one or more upstream servers and disciplines its own clock to them. In server mode it answers requests from downstream clients, normally because it already has a reliable source and a stable stratum. In symmetric active, or peer, mode two devices at the same stratum exchange time and compare clocks, giving redundancy between data center switches without either being subordinate to the other.

Cisco IOS also supports broadcast and multicast NTP, in which a server pushes time onto a segment instead of waiting for clients to poll. These modes reduce load on busy servers but are less precise and are open to spoofing unless authentication is enabled. For most enterprise networks a small number of authenticated unicast client associations plus a loopback source interface is the design that survives audits.

Configuring NTP Servers

Point the device at one or more upstream NTP servers from global configuration mode. Use the prefer keyword to mark your most authoritative or closest server; Cisco then prefers that server among the valid associations:

Router(config)# ntp server 203.0.113.1 prefer
Router(config)# ntp server 203.0.113.2
Router(config)# ntp server 2001:db8::1

The prefer keyword does not make an association mandatory. If the preferred server becomes unreachable or drops below the validity threshold, the device falls back to another valid association, which is exactly the behaviour you want for resilience. Configure at least three sources reached over independent paths so that a single upstream failure, or a single falseticker, can be outvoted by the NTP intersection algorithm.

Avoid pointing production devices directly at public pool servers. The pool is a shared, best-effort resource whose members change without notice, and depending on it makes your clock availability someone else's problem. Use your own internal stratum two servers, synchronized from a hardened source, and let the access network poll those. If you must list a public address as a last resort, list it last and set a sane maximum poll interval.

On platforms with a dedicated management VRF, bind the NTP association to that VRF so time sync does not depend on the production routing table:

Router(config)# ntp server vrf Mgmt-vrf 203.0.113.1 prefer

Binding to the management VRF is a common production requirement: it keeps out-of-band time synchronization working when the production routing protocol is in a failure state, and it keeps NTP traffic off the production forwarding path.

Setting the NTP Source Interface

The source interface determines the IP address in the NTP packets and, more importantly, which address the server and other peers reply to. Loopbacks are the usual choice because they stay up regardless of WAN link state:

Router(config)# ntp source Loopback0

Without an explicit source, the router uses the outgoing interface address, which can change after routing changes and break NTP access lists or server-side restrictions. A server configured with an access list that permits only 192.0.2.1 will silently drop replies to a packet sourced from a temporary physical interface address, and the device will simply never synchronize.

Choosing a loopback also decouples NTP from interface events. If the primary uplink flaps and traffic reroutes over a backup path, a device without a source interface presents a different source address after every event, so servers re-learn the client and access control behaves unpredictably. A stable loopback address makes the client identity constant for the lifetime of the device.

Serving Time to Your Own Devices

Once a core device is synchronized, it can serve time to downstream access switches and servers. Make it a stratum-consistent server rather than a master, so it advertises its real stratum and downstream devices can judge its quality:

Router(config)# ntp access-group serve-only 10
Router(config)# access-list 10 permit 10.0.0.0 0.255.255.255
Router(config)# ntp server local

If a device has no upstream source at all but must act as the reference for a lab or an isolated enclave, the ntp master command makes it a stratum one server driven by its own clock. This is appropriate only for isolated test environments, because a free-running hardware clock can drift by seconds per day and there is nothing behind it to catch the error.

Optional: NTP Authentication

In environments where an attacker could spoof NTP, enable symmetric-key authentication and trust only known keys:

Router(config)# ntp authenticate
Router(config)# ntp authentication-key 1 md5 Sup3rSecretKey
Router(config)# ntp trusted-key 1
Router(config)# ntp server 203.0.113.1 key 1

Authentication must be configured on both sides with the same key number, algorithm and key string; a mismatch produces a device that stays permanently unsynchronized while the packets themselves look perfectly healthy in a capture. Note that ntp authenticate enables authentication but does not by itself enforce it for every association - each ntp server statement needs a key argument, and only keys listed with ntp trusted-key are accepted.

Where the platform supports it, prefer SHA-based keys over the legacy MD5, because MD5 hashing is no longer considered cryptographically strong. Even with authentication, keep NTP behind a management ACL so that only known subnets can reach UDP port 123 at all.

Securing NTP with Access Groups

An access group restricts what a device will do for its peers and clients. The four modes - query-only, serve-only, serve and peer - let you build a strictly hierarchical synchronization tree:

Router(config)# ntp access-group peer 20
Router(config)# ntp access-group serve-only 30
Router(config)# access-list 20 permit 192.0.2.0 0.0.0.255
Router(config)# access-list 30 permit 10.0.0.0 0.255.255.255

With peer permitting only the designated core addresses and serve-only permitting the access subnets, a rogue device on the access layer cannot advertise itself as a time source to the core even if it is reachable. This is the single most effective hardening step for NTP on a routed network, and it costs one ACL per role.

Verifying NTP Synchronization

Confirm that the device has synchronized and check each association:

Router# show ntp status
Router# show ntp associations
Router# show ntp associations detail

A healthy device shows Clock is synchronized with a stratum number one higher than its server, and the association list marks the preferred peer with an asterisk or a synchronized state. If the clock stays unsynchronized, check UDP port 123 reachability, the source interface, and whether NTP authentication keys match on both ends.

The status output also gives you the reference identifier, the stratum, the last time the clock was set, and the frequency correction the NTP loop has applied in parts per million. A frequency value that is unusually large, or that keeps growing, points at a drifting hardware oscillator rather than a network problem. The detail output adds per-association offset, delay, jitter and the reach register.

Reading show ntp associations Output

The leftmost column is the most-read field. An asterisk marks the system peer, the association currently steering the clock. A plus sign marks a candidate that is acceptable but not selected, a hyphen marks one that was rejected by the intersection or clustering algorithm, and a tilde indicates a configured association that is not contributing. If the asterisk is missing, the device is not synchronized to anything.

The reach register is an eight-bit shift register of the last eight poll results, displayed in octal. A healthy association shows 377, meaning the last eight polls were all answered. A value decaying toward zero means replies are being lost, which almost always points at an ACL, a firewall or a source address mismatch rather than at the server. The when column tells you how many seconds ago the last valid reply arrived, and comparing it against the poll interval is a fast way to spot a broken association.

Troubleshooting Unsynchronized NTP

When the clock refuses to sync, work outward from the packet. First confirm the device can reach UDP port 123; a successful ICMP ping does not prove UDP 123 works, so test explicitly with an extended ping or a packet capture. Second confirm the source address is permitted by the server and by any intermediate filter. Third confirm authentication keys match on both ends. Fourth check the stratum: a server that is itself unsynchronized advertises stratum 16, which is treated as invalid and will never be accepted.

A surprisingly common cause is a server whose own upstream has failed. The remote server continues to answer, so the association looks alive and the reach register stays at 377, yet the device never elects it because its stratum is 16 or its leap indicator reports an unsynchronized state. Checking the remote server's own status is therefore part of a complete NTP investigation, not an optional extra step.

Best Practices

Configure at least three or four upstream servers from independent sources, and mix anycast or public pool entries with your own infrastructure only deliberately. Always set an explicit loopback source interface. Authenticate where the network is not fully trusted. Restrict NTP with access groups. Monitor offset and jitter through SNMP rather than waiting for a clock to visibly drift, and alert when an association is not synchronized. Keep firmware current, because NTP-related defects and mode-six abuse handling have appeared in IOS and IOS XE releases over the years.

Frequently Asked Questions

Does Cisco IOS support NTPv4? Yes. IOS and IOS XE implement NTP version 3 and version 4 semantics, including IPv6 transport, and a device negotiates the version of each association automatically.

What stratum value is normal? A device synchronized to a stratum one server should report stratum two, and one synchronized to a stratum two server reports stratum three. Any value of sixteen means the device considers itself unsynchronized.

Why does show ntp associations show no asterisk? The device has not selected a system peer, which normally means no association passed the validation and intersection tests. Check reach, authentication and the remote server's own stratum.

Can I use the same loopback as the router ID and the NTP source? Yes, and it is a sensible convention, but make sure the address is reachable from the NTP servers and permitted by their ACLs, which is not automatically true for a routing-only loopback.

Related reading on this site: chrony NTP time sync and drift troubleshooting (Linux) and SNMPv3 configuration on Cisco IOS and Junos. For higher precision than NTP can deliver, see PTP vs NTP precision time explained. Distribute accurate time into your log pipeline with Cisco IOS logging and syslog configuration, and see RADIUS vs TACACS+ AAA configuration for why time governs authentication.

原文链接：https://blog.ipspace.net/kb/Internet/NTP/30-configuration/