5 NTP and Quality of Service
Learn how to configure and verify network time synchronization and congestion-aware traffic handling, including their operational limits and Cisco IOS-style examples.
How keeps clocks synchronized
synchronizes device clocks with reference time sources over UDP port 123. Accurate, consistent time helps correlate logs and troubleshoot events. A device can use one or more servers: one can be preferred, while other servers provide alternatives.
adjusts the system clock but does not set the device’s time zone. Configure the time zone separately.
Configure and verify
The Cisco IOS-style example configures two servers. Replace the example addresses with reachable, authorized servers; the prefer setting identifies the preferred server.
Check synchronization status and the selected server with these commands:
Look for a synchronized status and a selected peer in the association output. If synchronization fails, check server reachability, access to UDP port 123, routing, and whether the server itself has a valid time source. In production networks, use trusted servers and follow organizational access-control and authentication practices.
QoS workflow and traffic markings
manages traffic when a link is congested; it does not create additional bandwidth. A basic workflow is to classify packets by a characteristic such as , an access-control list, or an application; mark packets with a QoS value when appropriate; queue and schedule traffic at the congested output interface; and verify policy counters and observed traffic behavior.
Apply markings at a trusted network edge rather than blindly trusting markings from untrusted devices. is a field in the IP header used to indicate a packet’s forwarding treatment. ( 46) is commonly used for delay-sensitive voice traffic and should be reserved for traffic authorized to receive that treatment.
traffic does not automatically need priority. Guidance distinguishes high-accuracy timing within a managed network from ordinary wall-clock synchronization.
Classify and queue voice traffic
This Cisco IOS-style MQC example matches packets already marked , gives that class a low-latency , and assigns the remaining configured bandwidth to other traffic. Apply the policy on the outbound interface where congestion is expected.
The percentages and commands are illustrative. Supported features, syntax, and bandwidth calculations vary by platform and interface. A is intended for bounded, delay-sensitive traffic; excessive priority traffic can starve other classes.
If packets arrive without the intended marking, classify and mark them at a trusted ingress point or revise the classification policy. Do not assume that the egress policy will identify them correctly.
Verify QoS operation
Use platform policy and interface commands to confirm that the policy is attached in the intended direction and that class counters increase when matching traffic passes. A common IOS XE check is:
Inspect matched packet counts, queue or priority treatment, and drops. If a configured policy has no matching packets, possible causes include incorrect classification, no test traffic, or a policy attachment or direction problem. Verification commands and displayed counters differ across platforms.
Operational checklist
Configure clients to use reliable, reachable time servers, then verify synchronization and the selected association. For QoS, classify traffic deliberately, apply suitable markings at trusted boundaries, queue traffic on the congested egress link, and check live policy counters. Treat platform examples as a starting point rather than a universal configuration.