Cisco's Enterprise QoS Solution Reference Network Design suggests classifying NTP as network management traffic and marking it as CS2:

When addressing the QoS needs of Network Management traffic, Cisco recommends the following guidelines:

  • Network Management traffic should be marked to DSCP CS2.
  • Network Management applications should be explicitly protected with a minimal bandwidth guarantee.

Network management traffic is important to perform trend and capacity analysis and troubleshooting. Therefore, you can provision a separate minimal bandwidth queue for Network Management traffic, which could include SNMP, NTP, Syslog, NFS and other management applications.

Given that NTP is jitter-sensitive, why isn't NTP marked as Expediated Forwarding and treated the same as voice data?

Is there a reason why it should not be placed in the same low latency queue as voice?

  • 3
    I don't think "jitter-sensitive" is a fair characterization of NTP. This explains a lot, but I believe the algorithm and polling intervals can deal with a certain amount of jitter. So that would lead me to think it needn't be treated same-as-voice. (I know little about QoS though.) Commented Jun 5, 2015 at 19:50
  • @CraigConstantine That's correct. In most environments, as long as you can get a queue to beat out BE traffic, you're probably ahead of 95% of the data, anyhow.
    – Ryan Foley
    Commented Jun 5, 2015 at 20:31
  • @CraigConstantine have a look at RFP4594 Good catch Stephen. I guess Cisco is not inline with the IETF on this one?... Commented Jun 5, 2015 at 20:59
  • 1
    Cisco is a big company with many different individuals/groups. Not all of them always agree on what is best. Personally, I think the IETF recommendation is better when it comes to "high accuracy timing" but I personally wouldn't want NTP for my network equipment (which I wouldn't generally classify as high accuracy) to be "wall clock timing" or DF as the RFC puts it. The Cisco recommendation seems to be more "middle of the road" and in line with what I would expect would meet general NTP needs for network equipment.
    – YLearn
    Commented Jun 5, 2015 at 22:52
  • 1
    @StevenCraven, for this to be an answerable question, we need to understand what kind of precision requirements you have for NTP and how it is being used. Commented Jun 6, 2015 at 14:28

2 Answers 2


Edited answer: NTP should be placed in the EF class (same as real-time voice packets) according to the IETF's RFC 4594 Configuration Guidelines for DiffServ Service Classes.

5.2. Mapping for NTP

From tests that were performed, indications are that precise time distribution requires a very low packet delay variation (jitter) transport. Therefore, we suggest that the following guidelines for Network Time Protocol (NTP) be used:

o When NTP is used for providing high-accuracy timing within an administrator's (carrier's) network or to end users/clients, the Telephony service class should be used, and NTP packets should be marked with EF DSCP value.

o For applications that require "wall clock" timing accuracy, the Standard service class should be used, and packets should be marked with DF DSCP.


NTP isn't particularly jitter-sensitive because it uses originate and transmit timestamps to keep track of delay. Ntp.org explains in detail how it keeps delay in check, but here's a snippet:

Synchronizing a client to a network server consists of several packet exchanges where each exchange is a pair of request and reply. When sending out a request, the client stores its own time (originate timestamp) into the packet being sent. When a server receives such a packet, it will in turn store its own time (receive timestamp) into the packet, and the packet will be returned after putting a transmit timestamp into the packet. When receiving the reply, the receiver will once more log its own receipt time to estimate the traveling time of the packet. The traveling time (delay) is estimated to be half of "the total delay minus remote processing time", assuming symmetrical delays.

The reason this isn't in the same category as network control is because this isn't directly responsible for the operation of routing/forwarding of packets. All of the things in the network management category are not critical components of the networking system as a whole. If you lost any packets related to SNMP, syslog, or NTP, you likely wouldn't even notice.

SNMP would simply retransmit that information since it's TCP based. Even if the connection dropped all together, nothing catastrophic would happen; you might just get a snmp agent not responding and then try again. If you lost syslog traffic (UDP), you would simply lose a blip of logging information, which is probably still contained within the buffer or in a log file on the device. Since NTP calculates delay based on previous packets, while also accounting for the maximum offset error, you really aren't running into any issues. Worst case scenario, your time drifts by a few picoseconds…

If you lost a packet related to routing, even for a second, you may be facing the entire system going down; rendering any other markings worthless. At that point, NTP would simply fall totally out of sync and rely on it's local ticker to keep time.

  • Actually NTP is sensitive to asymmetric jitter: The protocol works best of the transmit delay equals the receive delay (i.e.: if the actual delay is half of the round-trip delay).
    – U. Windl
    Commented Aug 14, 2023 at 9:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.