NTP 网络时间协议
本篇来聊聊NTP协议，相关实验均通过H3C HCL模拟器实现
NTP 基础
NTP-网络时间协议，主要作用是给网络设备（交换机、路由器、PC）等同步时间，源目均使用UDP 123 端口，可以达到毫秒乃至亚毫秒级的精度。
使用场景有三个：
- 需要以时间作为依据，对从不同设备采集来的日志信息、调试信息进行分析的网络管理系统。
- 对设备时间一致性有要求的计费系统。
- 多个系统协同处理同一个比较复杂的事件的场合。为保证正确的执行顺序，多个系统的时间必须保持一致的场景。
比较典型的例子是：部分网络设备开机后时间会丢失，导致设备日志记录的时间不准确。
NTP协议遵守两个RFC规范：
- RFC 1305：Network Time Protocol (Version 3) Specification, Implementation and Analysis
- RFC 5905：Network Time Protocol Version 4: Protocol and Algorithms Specification
NTP报文结构
根据华为和RFC文档，NTP报文结构如下：
相关字段见下表，其中比较重要的有：
VN（Version Number）：NTP的版本号。
目前广泛使用NTP v4 版本，RFC 5904 有说明：NTPv4 的报文格式与 NTPv3 兼容，但在某些字段的解释上有所扩展。
Mode（模式）：3 位，指示报文发送端的工作模式。详细取值参考下表；
Stratum（层数）：8 位，表示本地时钟的层级。
- 1：主参考源（直接连接外部授时设备）
- 2～15：通过 NTP 同步的次级服务器
- 16：未同步
- 0：保留
对于 Stratum 1 服务器，其 Reference Identifier 字段包含参考时钟类型的标识;
Reference Identifier（参考标识符）：32 位。（以下来自RFC 5904 ）
- 对于 Stratum 1 服务器，该字段是一个四字符的 ASCII 字符串，标识参考时钟类型。标准化的标识符包括：
GPS：全球定位系统GAL：伽利略定位系统PPS：秒脉冲（Pulse Per Second）IRIG：美国靶场仪器组时间码WWVB：美国低频无线电授时信号DCF：德国低频无线电授时信号MSF：英国低频无线电授时信号JJY：日本低频无线电授时信号LORC：罗兰-C 导航系统ACTS：美国计算机时间服务（电话授时）NIST：美国国家标准与技术研究院PTB：德国物理技术研究院USNO：美国海军天文台CHU：加拿大短波无线电授时GOES：地球同步环境卫星LOCL：未校准的本地时钟CESM：铯原子钟RBDM：铷原子钟OMEG：奥米伽导航系统（已退役）DCN：DCN 路由协议TDF：法国低频无线电授时
- 对于 Stratum 2 及以上服务器，该字段包含所同步的服务器（系统对等体）的 IPv4 地址（以 32 位二进制表示），或者是第一次与该服务器同步时的 IPv6 地址的 MD5 哈希的低 32 位（如果通信使用 IPv6）。
- 未同步时，该字段置零。
- 对于 Stratum 1 服务器，该字段是一个四字符的 ASCII 字符串，标识参考时钟类型。标准化的标识符包括：
Poll（轮询间隔）：8 位有符号整数，使用以 2 为底的对数秒数，表示 NTP 报文发送的间隔。例如，值为 6 表示 2^6 = 64 秒。取值范围通常为 4（16 秒）到 17（约 36 小时，即 131072 秒）。
H3C 设备会直接标识具体秒数，如下图标识64秒
Precision（精度）：8 位有符号整数，通过以 2 为底的对数秒数表示本地时钟的分辨率。例如，-18 表示大约 3.8 微秒的精度，-20 表示约 0.95 微秒。
Root Delay（根延迟）：32 位有符号定点数，小数部分占 16 位。表示从本地到主参考源（Stratum 0）的总往返延迟，单位为秒。该值始终为正，综合了每一跳的延迟。
Root Dispersion（根离散度）：32 位无符号定点数，小数部分占 16 位。表示相对于主参考源的最大误差，单位为秒。该值为各跳离散度及本机时钟误差的累积。
Reference Timestamp（参考时间戳）：64 位时间戳，表示本地时钟最后一次被设置或校正的时间。若从未同步过，则为 0。
Originate Timestamp（发起时间戳）：64 位时间戳，表示 NTP 请求报文离开客户端时、客户端的本地时间。
客户端在发送请求前，将当前系统时间写入
Transmit Timestamp，同时将该值复制到本地的Origin Timestamp缓冲区。当收到响应时，响应中的Origin Timestamp必须与客户端的Transmit Timestamp一致，否则丢弃该响应。这里的逻辑涉及较为复杂的机制，可参考本篇
NTP 算法浅析-NTP协议操作的说明，简单说NTP报文最开始并不是直接将发送时间写入OT字段，而是为了一致性检查先写入了TT字段，可以抓包验证：
服务器收到后，复制TT到OT，再写入自己的TT值
Receive Timestamp（接收时间戳）：64 位时间戳，表示 NTP 请求报文到达服务器时、服务器的本地时间。
服务器在收到请求后，立即读取系统时间填入该字段。
Transmit Timestamp（传输时间戳）：64 位时间戳，表示 NTP 应答报文离开服务器时、服务器的本地时间。
服务器在发送响应前，立即读取系统时间填入该字段。对于广播模式，服务器周期性地发送带有发送时间戳的广播消息。
| 字段名 | 长度 | 含义 |
|---|---|---|
| Leap Indicator | 2比特 | 这是一个两位的代码，表示在NTP时间标尺中将要插入的下一跳情况。值为“11”时表示告警状态，时钟不能被同步。 |
| VN（Version Number） | 3比特 | NTP的版本号。 |
| Mode | 3比特 | NTP的工作模式。不同值表示的含义如下：0：reserved，保留。1：symmetric active，主动对等体模式。2：symmetric passive，被动对等体模式。3：client，客户模式。4：server，服务器模式。5：broadcast，广播模式。6：reserved for NTP control messages，NTP控制报文。7：reserved for private use，内部使用预留。 |
| Stratum | 8比特 | 时钟的层数，定义了时钟的准确度。层数为1的时钟准确度最高，从1到15依次递减。 |
| Poll Interval | 8比特 | 轮询时间，即发送报文的最小间隔时间。 |
| Precision | 8比特 | 时钟的精度。 |
| Root Delay | 32比特 | 到主参考时钟的总往返延迟时间。 |
| Root Dispersion | 32比特 | 本地时钟相对于主参考时钟的最大误差。 |
| Reference Identifier | 32比特 | 标识特定参考时钟。 |
| Reference Timestamp | 64比特 | 本地时钟最后一次被设定或更新的时间。如果值为0表示本地时钟从未被同步过。 |
| Originate Timestamp | 64比特 | NTP报文离开源端时的本地时间。 |
| Receive Timestamp | 64比特 | NTP报文到达目的端的本地时间。 |
| Transmit Timestamp | 64比特 | 目的端应答报文离开服务器端的本地时间。 |
| Authenticator | 96比特 | （可选）验证信息。 |
NTP 时间戳格式
所有 NTP 时间戳均为 64 位无符号定点数：
- 前 32 位：整数部分，表示自 1900 年 1 月 1 日 00:00:00 UTC 起的秒数。
- 后 32 位：小数部分，分辨率约为 2^−32 秒（约 0.233 纳秒）。
NTP 日期绕回
NTP 时间戳的整数部分只有 32 位，将在 2036 年 2 月 7 日绕回。NTPv4 通过引入一个时代号（Era Number）的概念来处理这一问题。实现应当在 NTP 时间戳绕回时递增内部记录的 Era，从而能够跨越 136 年的时间窗口，正确解释时间戳。
NTP基本工作原理
NTP报文交互原理如图：：
设备A作为客户端从B同步时间
- NTP message 发出时，记录 Originate Timestamp（NTP报文离开源端时的本地时间）写入报文
Transmit Timestamp字段，可以称为T1 - 设备B收到时，记录 Receive Timestamp （ NTP报文到达目的端的本地时间），可以称为T2，并将
Transmit Timestamp复制到Originate Timestamp - 设备返回响应，除了携带 T1和 T2外，重记录 Transmit Timestamp（目的端应答报文离开服务器端的本地时间），可以称为T3
- 设备A收到响应，以收到时间为T4（注意T4并不在报文中体现， Reference Timestamp 是最后一次更新的时间)
那么，NTP报文的往返时延Delay = (T4 – T1) – (T3 – T2) = 2秒。
T4 - T1 为从A发出到收到响应的总用时，T3 - T2 为B设备的处理时间，最后得到的2s 就是链路时延
则AB的时间差Offset = ((T2 – T1) + (T3 – T4)) / 2 = 1小时。
A 同步后的时间应当是 T1 + 时间差，已知：
1、T2 = T1 + AB时间差 + 请求报文单向时延
2、所以请求方向总时间差 = T2 - T1 = A到B的时延 + AB时间差； 同理响应方向总时间差 = T3 - T4 = B到A的延迟 + AB时间差；
3、时差 应当为请求方向时差 + 响应方向时差 的平均 =((T2 – T1) + (T3 – T4)) / 2
综合1可以得到结论： A 同步后的时间为 = T1 + ((T2 – T1) + (T3 – T4)) / 2 ;
Stratum 时钟层数
Stratum 时钟层数这种自洽的层级关系是整个 NTP 体系保持稳定和可追溯的基础。
NTP 时间逐级同步，总是从较低层数的服务器流向较高层数的服务器。NTP报文中使用Stratum 字段表示层数。
NTP 的层次结构最大深度为 15，层数 0 到 16，一台服务器的层数等于其同步源的层数加 1，在失去所有可用同步源时变为 16（层数16代表NTP未同步）。
- 0 层：不提供网络设备使用，指代 Stratum 0为原子钟或GPS等物理时间源。
- 1层：精准NTP服务器，直接从0层的物理时间源获取时间，可以认为是网络总最上级的NTP服务器，对于 Stratum 1 服务器，其 Reference Identifier 字段标识了参考的物理时钟类型（具体参考报文结构部分介绍）
- 2-15：NTP 客户端所处的时钟层数，每同步一层，层数加 1。
- 16：NTP 未同步
综上，严格来说NTP的最大深度为层数累加 > 15 的深度
NTP工作模式
NTP协议在网络设备中有四种工作模式：
客户端/服务器模式
- 客户端服务器模式中，服务器作为时间提供者给客户端同步时间，客户端同步成功后时钟层数为 服务器层数 + 1；
- 一个或多个客户端直接从指定的服务器获取时间。客户端定期向服务器发送 NTP 请求，服务器返回应答，适用于以及几乎所有需要同步时间但不提供时间服务的节点；
- 客户端会维护session 信息，服务器只响应请求，不维护session 信息；
对等体模式
- 对等体模式中设备分为主动对等体和被动对等体两个角色，两者相互交换时间信息，并彼此同步。由主动对等体发起会话，被动对等体收到后被动建立会话，被动对等体无需配置对端；
- 对等体通常用于同一层级（stratum）的设备之间，互为备份，提高整体可用性和可靠性。如果一个服务器丢失了上游同步源，仍可从其对称对等体获得时间；
- 对等体两端都会维护session 信息，比客户端/服务器模式更加消耗资源；
在对等体模式下，主动与被动对等体通过双向交互实现时间收敛。系统会择优选择层级（Stratum）更低（数值更小）的那一方作为主要参考源，最终效果是层级高的向层级低的收敛。
若双方层级相同且均处于同步状态（Stratum < 16），则由于它们各自的上游层级必然更低（更优），时钟选择算法会优先锁定上游，而不会将平级对等体作为主参考源（除非上游失效）。
至少有一方必须保持同步状态，否则双方都无法通过该模式获得准确时间。
由于NTP协议中断并不会影响以同步的时间，并且使用NTP的业务往往对时间精度要求不高，现网不会对NTP提出过多要求所以无需冗余，导致对等体模式配置很少见，绝大多数设备都只配置客户端/服务器模式。
组播模式/广播模式
- NTP 服务器周期性地通过广播或组播发送 NTP 报文，客户端只需被动地监听这些报文即可获得时间，无需发送任何请求。
- 组播/广播模式显著降低了NTP服务器的负载和网络流量，但客户端无法测量往返延迟，因此广播模式的基本精度较低。为了提高精度，组播/广播模式下需要先通过客户端/服务器模式进行一次性的延迟校准，然后发送组播/广播报文。
- 组播模式要求服务器和客户端必须基于组播网络可达。
如图可以看到广播模式NTP在交互前发送了一次客户端/服务器模式报文交互，其具体流程是：
- 客户端收到组播/广播NTP 报文。
- 客户端单播NTP mode 3 (Clinet 模式) 报文给服务器，服务器回复mode 4 （Server 模式），两者校准延迟。
- 客户端接受服务器广播/组播 报文，通过 客户端服务器模式获取的延迟和报文综合计算时间。
当前的组网中，组播/广播模式非常难得一见，几乎没有局点选择组播/广播进行时间同步。
NTP 安全机制
在具体的网络实现中，NTP协议通过 控制访问权限 和 NTP验证 来保证安全性
控制访问权限
控制访问权限的方式有两个关键点，注意两点并非独立。
ACL方式
NTP服务器通过ACL进行限制，只接受ACL permit 的源IP 对应的NTP协议报文。
- 当ACL规则配置源IP地址为permit时，则匹配结果是允许，即允许接收该源IP地址的报文。
- 当ACL规则配置源IP地址为deny时，则匹配结果是拒绝，即拒绝接收该源IP地址的报文。
- 当源IP地址未匹配上ACL规则时，则匹配结果是拒绝，即拒绝接收该源IP地址的报文。
- 当ACL中不存在规则或者引用的ACL不存在时，则匹配结果是拒绝，即拒绝接收所有源IP地址的报文。
权限限制方式
在设备的实现上，H3C 的NTP定义了四种权限级别：peer、server、synchronization、query
华为多一种limited；
- peer：完全访问权限。该权限既允许对端设备向本地设备的时间同步，对本地设备进行控制查询（查询NTP的一些状态，比如告警信息、验证状态、时间服务器信息等），同时本地设备也可以向对端设备的时间同步。
- server：服务器访问与查询权限。该权限允许对端设备向本地设备的时间同步，对本地设备进行控制查询，但本地设备不会向对端设备的时间同步。
- synchronization：仅具有访问服务器的权限。该权限只允许对端设备向本地设备的时间同步，但不能进行控制查询。
- query：仅具有控制查询的权限。该权限只允许对端设备对本地设备的NTP服务进行控制查询，但是不能向本地设备的时间同步。
当设备接收到NTP服务请求时，会按照权限从高到低的顺序依次进行匹配。匹配原则为：
当有一个访问请求到达时，按照最大访问限制到最小访问限制依次匹配，以第一个匹配的为准，匹配顺序为peer、server、synchronization、query；
综上，在设备中其具体的配置范围如下：
| 访问控制权限 | 是否可以接受同步时间（作为客户端时是否可以配置） | 是否可以对外提供同步时间（作为时间服务器时是否可以配置） | 是否可以对本设备进行控制查询 |
|---|---|---|---|
| peer | 可以 | 可以 | 可以 |
| server | 不可以 | 可以 | 可以 |
| synchronization | 不可以 | 可以 | 不可以 |
| query | 不可以 | 不可以 | 可以 |
在表中，由于server和synchronization都只具有访问服务器的权限，所以客户端只能配置 peer 。
第三列所指的控制查询在RFC5905 中已声明废弃，由SNMP替代，实际没有配置场景，且query仅具有控制查询的权限，所以无需关注。
对于服务器可以配置的peer、server、synchronization，三者均允许对端设备向本地设备的时间同步，所以配置任一权限均可，只需要注意权限的匹配顺序。
只允许信任IP时间同步
举个例子，上级单位漏扫发通告：“设备存在NTP mode 6/7 漏洞” ，对于网络设备而言，mode 6/7 是正常的协议交互机制（mode6 是控制消息，7保留，我们认为6、7类型的报文是不安全的），无法单独关闭，此时有三个解决方法：
关闭NTP服务；这显然是不现实的。
不允许非受信IP访问NTP服务（漏扫在网络中是模拟攻击者的角色，也是不受信的）。
如果只是mode 6，可以关闭请求控制能力（部分设备不支持）。
ntp-service noquery enable
综上，我们可以通过ACL 只允许受信IP访问：
# 匹配受信IP 192.168.1.1
acl basic 2000
rule permit source 192.168.1.1 0.0.0.0
# NTP 在peer级别权限调用ACL
ntp-service peer acl 2000
# peer Permit full access
# query Permit control query
# server Permit server access and query
# synchronization Permit server access only
NTP验证
NTP可以MD5摘要算法对NTP报文进行身份验证，只接受合法的NTP报文。
NTP验证功能的工作过程为：
(1) NTP报文发送者利用密钥ID标识的密钥对NTP报文进行MD5运算，并将计算出来的摘要信息连同NTP报文和密钥ID一起发送给接收者。
(2) 接收者接收到该NTP报文后，根据报文中的密钥ID找到对应的密钥，并利用该密钥对报文进行MD5运算。接收者将运算结果与报文中的摘要信息比较，如果相同，则接收该报文；否则，丢弃该报文。
简单来说，就是MD5 Hash校验的流程
NTP验证的配置如下：
# 启动NTP验证功能。
ntp-service authentication enable
# 创建编号为42的NTP验证密钥，密钥值为aNiceKey，以明文形式输入。
ntp-service authentication-keyid 42 authentication-mode md5 simple aNiceKey
# 配置编号为42的密钥为可信密钥。
ntp-service reliable authentication-keyid 42
# 对于NTP客户端，还需指定调用的服务器
# 设置NTP服务器1.0.1.11与编号为42的密钥关联。
ntp-service unicast-server 1.0.1.11 authentication-keyid 42
扩展：
认证报文格式
启用认证后，NTP 报文尾部包含：
- 密钥标识符（Key Identifier，32 位）
- 消息摘要（Message Digest，长度取决于算法，通常为 128 位 [MD5] 或 160 位 [SHA-1]）
预共享密钥方案
- 服务器和客户端通过离线（手动配置）方式共享一组密钥及其标识符。
- 发送方用指定的密钥计算整个 NTP 报文的单向哈希摘要，并附加在报文尾部。
- 接收方根据密钥标识符从自己的密钥库中取回对应密钥，重新计算哈希，并与报文中附加的摘要比较。若一致，则认证通过。
Autokey 自动密钥方案
NTPv4 引入了一种称为 Autokey（自动密钥） 的公钥基础设施，能够实现自动密钥管理和周期性的会话密钥更新，由于安全性评估的发展，Autokey 在后续实践中被发现存在一些脆弱性而废弃（如时间回溯攻击、中间人攻击等），但在当时代表了 NTP 安全性上的重要一步。
- Autokey 利用公钥密码学和数字签名，在 NTP 服务器和客户端之间安全地协商会话密钥。
- 它使用专门的协议报文（NTP 扩展字段）交换证书、验证身份、生成临时对称密钥，并周期性地自动翻转密钥。
NTP 配置案例
NTP 客户端服务器模式
MSRA:
ntp-service enable # 开启NTP服务
ntp-service refclock-master 2 # 设置时钟层数为2
这里模拟器配置
ntp-service refclock-master 2的目的在于让服务器的NTP处于同步状态，实际上服务器还会去同步精度更高的NTP服务，所以无需配置。
NTP 所有的配置模式几乎都要求提供NTP服务的一方要处于同步状态且精度高于被同步方。
客户端服务器模式的限制是：
- 当设备采用客户端/服务器模式时，需要在客户端上指定服务器的地址。
- 当服务器端的时钟层数大于或等于客户端的时钟层数时，客户端将不会与其同步
- 可以通过多次执行ntp-service unicast-server命令和ntp-service ipv6 unicast-server命令为设备指定多个服务器。
- 服务器需要通过与其他设备同步或配置本地时钟作为参考时钟等方式，使得自己的时钟处于同步状态，否则客户端不会将自己的时间与服务器的时间同步。
MSRB:
clock protocol ntp # 指定时钟协议为NTP
ntp-service enable # 开启NTP服务
ntp-service unicast-server 10.0.12.1 # 指定NTP服务器为A
如图，对于客户端服务器模式，服务器不维护客户端的session，但是会维护和服务器的session（这里MSRA设备服务器是自己，所以是LOCL）
从MSRB可以看到B维护了和A的session；
通过display ntp status 可以查看NTP状态
如图，MSRB 时钟层数+1 变为3，peer 地址和Reference clock ID 指向MSRA。
通过display ntp trace 可以看到NTP同步路径的情况
客户端抓包：
服务器抓包：
NTP 对等体模式
MSRA：
clock protocol ntp
ntp-service enable
ntp-service unicast-peer 10.0.12.2
ntp-service refclock-master 2
同理，ntp-service refclock-master 2命令的意义在于让MSRA处于同步状态，对等体模式的限制是：
- 被动对等体上需要执行ntp-service enable命令来开启NTP服务，否则被动对等体不会处理来自主动对等体的NTP报文。
- 主动对等体和被动对等体的时钟至少要有一个处于同步状态，否则它们的时间都将无法同步。
- 可以通过多次执行ntp-service unicast-peer命令或ntp-service ipv6 unicast-peer命令为设备指定多个被动对等体。
MSRB:
clock protocol ntp
ntp-service enable
如图，对等体模式下，NTP两端都会主动维护session关系。
主动对等体抓包：
被动对等体抓包：
NTP 组播/广播模式
MSRA
ntp-service broadcast-server # 配置NTP服务器运行在广播模式
ntp-service multicast-server # 配置NTP服务器运行在组播模式
ntp-service enable
ntp-service refclock-master 2
ntp-service refclock-master 2 配置同理
广播模式：
- 广播服务器需要通过与其他设备同步或配置本地时钟作为参考时钟等方式，使得自己的时钟处于同步状态，否则广播客户端不会将自己的时间与广播服务器的时间同步。
- 当设备采用广播模式时，广播服务器端和广播客户端上都需要进行配置。
组播模式：
- 组播服务器需要通过与其他设备同步或配置本地时钟作为参考时钟等方式，使得自己的时钟处于同步状态，否则组播客户端不会将自己的时间与组播服务器的时间同步。
- 设备采用组播模式时，在组播服务器端和组播客户端上都需要进行配置。
组播模式要求中间网络可以传递组播路由，NTP组播的目的IP可以通过**ntp-service multicast-server** [ *ip-address* ]命令指定，缺省是：224.0.1.1
广播抓包：
组播抓包：
这里比较有趣的是组播广播都是Mode 5 ，RFC也没有对这两种模式做出过区分，唯一可以作为区别的是目的IP，广播255.255.255.255，组播224.0.1.1
NTP配置非常简单，没什么值得刻意拓展的内容，带验证、基于MPLS这里均不在说明。
NTP 问题排查
NTP 一般不会出问题，如果出问题，有两种：
1、NTP无法和服务器同步时间
2、NTP同步的时间和服务器不一致
无法同步时间
无法同步时间的情况基本是：
- NTP报文交互没有完成：没有收到报文或交互失败
- 如果是客户端服务器模式，服务器做了过滤或者时间没有同步，自然就收不到报文；
- 假如上端是NTP广播，下端是NTP对等体，交互失败；
- 提供NTP服务端NTP异常。
如果有其他情况，基本均需要联系原厂研发处理。因为简单，出了预期外的问题反而无法通过配置的手段处理。
同步时间不一致
NTP同步的时间和服务器不一致有三个情况
时区问题
NTP协议不同步时区，加入两端有一方配置了时区，比如服务器东八区客户端无配置，那么客户端就比服务器慢8小时。
单边链路高延时
在NTP工作原理我们有提到，NTP对于时间的计算本质是 两端设备时间差 + 来回时延的一半。
假如请求时延2ms，响应时延100ms，就会导致真实的时间为 时间差 + 2 ms，而NTP 计算的时间为 时间差 + 51ms，两端时间就相差了49ms。
这种情况只能通过改善时延减少差值，无法撤离避免。
这里我就想起以前处理的问题，说现场业务涉及卫星，对于时间精度要求极高，而A设备和B设备NTP时间同步后相差20ms，问怎么解决？
答：NTP无法解决，NTP算法中规定时间差大于128ms才认为异常，虽然宣称是亚毫秒级精度，但实际达到毫秒级已经非常不错。
如果现场对于时间的要求极高，建议使用PTP协议（PTP协议宣称精度亚微秒级）。
软件异常
设备本身NTP进程卡死、设备软件出现异常导致NTP协议同步不一致，只能收集故障信息找原厂研发处理。如果业务不重要，可以考虑重启设备。
debug ntp
上述聊了常见的NTP故障场景，那么如果遇到了这类问题并且检查确认配置无误，怎么判定问题原因？比如时间不一致，怎么判定是单边延时高还是软件异常？
答：抓包或者Debug
抓包动作这里不多说明，涉及流量镜像，并不是所有局点都可以做的，而debug 随时可以操作：
命令：debugging ntp-service all
华三设备debug 开启方法：
<1-MSRA>debugging ntp-service all # 开启NTP debug开关
<1-MSRA>terminal debugging # 开启debug 输出，简写t m
<1-MSRA>terminal monitor # 开启信息打印， 简写t d
debug 关闭方法：
undo terminal monitor # 关闭信息打印，简写u t m (默认开启可以不关)
undo terminal debugging # 关闭debug 输出，简写u t d
undo debugging all # 关闭所有debug, 一般使用快捷键Ctrl + O 代替
注意，debug 本身不影响业务，但是会占用设备CPU资源，NTP协议报文流量很少，可以不加限制的随意debug ，如果是其他流量例如debug ip packet 则一定要加acl进行限制。
这里我的建议是不要debug超过10Mb的流量，否则可能会由于设备CPU不足导致设备挂死。
如果对于网络不够熟悉，建议找懂得人来做。
此外，华三官网没有提供debug手册，那么debug命令的解释在哪可以找到呢？
答：HCL模拟器；这是目前唯一公开debug命令的位置。
服务端
# 收到NTP报文
*Jul 9 20:38:44:283 2026 2-MSRA NTP/7/PACKET_RECV: packet from 2001::2 to 2001::1 on GigabitEthernet0/0/0
leap: 0, version: 4, mode: 3, vrfindex: 0
stratum: 3, poll: 6, precision: 2^-17
rdel: 0.244, rdsp: 30.472, refid: 190.141.134.135
# 报文中的参考时间戳
reftime: edfa8512.4d090abe Thu, Jul 9 2026 20:37:38.300
# 报文中的启始时间戳 T1
orgtime: edfa8512.4d75bcd0 Thu, Jul 9 2026 20:37:38.302
# 报文中的接收时间戳 T2
rectime: edfa8512.4d090abe Thu, Jul 9 2026 20:37:38.300
# 报文中的发送时间戳 T3
xmttime: edfa8554.4cf7cb9e Thu, Jul 9 2026 20:38:44.300
# 处理报文的时间戳 T4
inptime: edfa8554.487267d5 Thu, Jul 9 2026 20:38:44.282
*Jul 9 20:38:44:283 2026 2-MSRA NTP/7/ACL: Access restrict: 0x00000008.
*Jul 9 20:38:44:283 2026 2-MSRA NTP/7/AUTH: Received a packet at 362, from 2001::2, mode 3, key ID 00000000, length 48, authentication result 0
# 响应NTP报文
*Jul 9 20:38:44:283 2026 2-MSRA NTP/7/PACKET_SEND: packet to 2001::2, length: 48
leap: 0, version: 4, mode: 4, vrfindex: 0
stratum: 2, poll: 6, precision: 2^-18
rdel: 0.000, rdsp: 11.353, refid: 127.127.1.0
reftime: edfa8532.4c9bf556 Thu, Jul 9 2026 20:38:10.299
orgtime: edfa8554.4cf7cb9e Thu, Jul 9 2026 20:38:44.300
rectime: edfa8554.487267d5 Thu, Jul 9 2026 20:38:44.282
xmttime: edfa8554.487cd769 Thu, Jul 9 2026 20:38:44.283
客户端
# 发送NTP报文
<2-MSRB>*Jul 9 20:38:44:300 2026 2-MSRB NTP/7/PACKET_SEND: packet to 2001::1, length: 48
leap: 0, version: 4, mode: 3, vrfindex: 0
stratum: 3, poll: 6, precision: 2^-17
rdel: 0.244, rdsp: 30.472, refid: 190.141.134.135
reftime: edfa8512.4d090abe Thu, Jul 9 2026 20:37:38.300
orgtime: edfa8512.4d75bcd0 Thu, Jul 9 2026 20:37:38.302
rectime: edfa8512.4d090abe Thu, Jul 9 2026 20:37:38.300
xmttime: edfa8554.4cf7cb9e Thu, Jul 9 2026 20:38:44.300
*Jul 9 20:38:44:301 2026 2-MSRB NTP/7/PACKET_RECV: packet from 2001::1 to 2001::2 on GigabitEthernet0/0/0
leap: 0, version: 4, mode: 4, vrfindex: 0
stratum: 2, poll: 6, precision: 2^-18
rdel: 0.000, rdsp: 11.353, refid: 127.127.1.0
reftime: edfa8532.4c9bf556 Thu, Jul 9 2026 20:38:10.299
orgtime: edfa8554.4cf7cb9e Thu, Jul 9 2026 20:38:44.300
rectime: edfa8554.487267d5 Thu, Jul 9 2026 20:38:44.282
xmttime: edfa8554.487cd769 Thu, Jul 9 2026 20:38:44.283
inptime: edfa8554.4d203872 Thu, Jul 9 2026 20:38:44.301
*Jul 9 20:38:44:301 2026 2-MSRB NTP/7/ACL: Access restrict: 0x00000008.
# 收到响应
*Jul 9 20:38:44:301 2026 2-MSRB NTP/7/AUTH: Received a packet at 363, from 2001::1, mode 4, key ID 00000000, length 48, authentication result 0
*Jul 9 20:38:44:301 2026 2-MSRB NTP/7/PARAM: Clock filter param: number 8, offset 0.001781, delay 0.000246, dispersion 0.002214, jitter 0.016558, burst 0
*Jul 9 20:38:44:301 2026 2-MSRB NTP/7/SELECT: endpoint -1, -0.028466
*Jul 9 20:38:44:301 2026 2-MSRB NTP/7/SELECT: endpoint 0, 0.001781
*Jul 9 20:38:44:301 2026 2-MSRB NTP/7/SELECT: endpoint 1, 0.032028
*Jul 9 20:38:44:301 2026 2-MSRB NTP/7/SELECT: peer 2001::1, offset 0.001781, low -0.028466, high 0.032028, flags 00000401
*Jul 9 20:38:44:301 2026 2-MSRB NTP/7/SELECT: Survivor 2001::1, distance 2.004165
*Jul 9 20:38:44:301 2026 2-MSRB NTP/7/SELECT: Combine offset 0.001781344, jitter 0.016558046
*Jul 9 20:38:44:301 2026 2-MSRB NTP/7/SYNCH: Synchronized to peer 2001::1
*Jul 9 20:38:44:301 2026 2-MSRB NTP/7/SELECT: Clock update at 363, sample 297, session ID 52082, offset 0.001781
根据debug 信息，我们就可以判定 两端NTP模式是否一致、NTP版本是否兼容，并根据时间戳计算同步到的时间应当是多少，差值应当是多少，来回延时是多少。
以此，就可以知道问题具体是出在什么位置。
到此基本内容已经结束，下面是扩展内容
NTP 算法浅析
NTP 进程
对等体进程（Peer Process）
NTP系统中每个独立的 NTP 对等体（服务器、客户端或对称对等体）都有一个对等体进程实例（Session）。该进程负责：
- 构造和发送 NTP 报文。
- 接收并验证到达的 NTP 报文。
- 从报文携带的时间戳计算出该对等体的时钟偏差（offset）、往返延迟（delay）、离散度（dispersion） 等测量值。
- 将这些测量值存入滤波器寄存器，供后续算法使用。
对等体进程维护关于其对应对等体的可达性、定时器、模式等状态信息，并按照与 NTP 服务器互操作所要求的规则管理关联的状态机。
时钟滤波进程（Clock Filter Process）
每个对等体独立运行，处理来自该对等体的最近若干次测量结果（默认为 8 次），从中选出代表该对等体当前质量的最佳样本。滤波算法的目标是选择延迟最小的样本，因为其受网络排队抖动的影响最小，能够给出最精确的时钟偏差估计。除了选出滤波后偏差和延迟，该进程还计算出对等体离散度，衡量该对等体提供的时间信息的质量。
在有多个NTP源时，客户端以此决定要同步谁的时间。一般我们建议尽可能的减少NTP同时钟层数时钟源的数量，避免多个时钟源产生扰动。
时钟选择进程（Clock Selection Process）
周期性地扫描所有对等体滤波后的数据，执行交集算法（Intersection Algorithm）。根据各对等体的偏差和误差范围，确定出多数对等体一致认同的时间区间，从而将那些时间偏差异常的误报者（falsetickers）与正确报时者（truechimers）区分开来。能够安全参与后续时钟组合的对等体被收集到一个幸存者列表（survivor list） 中。
简单说就是排除掉时间明显错误的NTP时钟源，同样在多个NTP源时有意义。
时钟组合进程（Clock Combining Process）
当幸存者列表中有多个对等体时，时钟组合算法计算它们的偏差的加权平均值，生成一个单一的系统时钟偏差估计值。各对等体的权重由其同步距离的倒数确定——同步距离越小，代表该对等体越接近主参考源，其贡献权重就越大。如果只有一个幸存者，则直接使用该对等体的偏差。
时钟驯服进程（Clock Discipline Process）
采用时钟驯服算法（又称时钟同步算法）在系统进程中周期性运行，其输入是系统偏移（THETA）和系统抖动（PSI）。它的核心目标是：在不引起时间跳跃（或尽量减少跳跃）的前提下，逐步将系统时钟的误差校正到零附近，同时跟踪振荡器的频率漂移。
相当于一个锁相环（PLL）与锁频环（FLL）的混合系统，负责根据系统时钟偏差估计来实际调整本地系统时钟。它的主要功能包括：
- 控制时钟的相位（即时偏差）和频率（漂移率）。
- 决定调整方式：当偏差较小时采用微调（slew），通过临时改变时钟频率来逐步平滑地消除偏差；当偏差超过阈值时则直接步进（step）。
- 训练并记忆本地时钟的固有频率误差，即使暂时失去所有时间源，也能以极高的精度维持时间。
- 使用精密的算法滤除残余抖动、适应变化的网络条件和时钟特性。
当系统时钟偏离参考时间过大时，直接缓慢调整（缓动，slewing）可能需要很长时间才能收敛。因此，算法引入了步进（stepping）机制：
- 缓动（Slewing）：若
|THETA|小于步进阈值（通常为 128 毫秒），则通过adjtime()逐步调整频率，使时钟平滑地向正确方向漂移，不会造成时间跳跃。 - 步进（Stepping）：若
|THETA|大于步进阈值，则判定系统时钟严重失准（通常发生在系统刚启动或长时间失锁后），此时直接通过settimeofday()跳跃式设置系统时间，一次性消除偏移。 - 步进后，频率误差估计被重置，系统进入“初始”状态，随后再通过 PLL/FLL 逐步微调。
为了防止频繁步进造成应用程序混乱，算法还规定：在步进后的一个“稳定期”（通常为 300 秒）内，会临时提高步进阈值，以避免因短暂抖动引发多次跳跃。
这里就可以回答之前实验时为什么说时间差大于128ms才认为异常，H3C 明确规定：
缺省情况下，NTP客户端与服务器端的时间差经过多次采样得到的时间偏移超过128ms时，客户端将进行一次时间同步。
即步进的前提是多次采样的时间偏移超过128ms；
系统进程（System Process）
管理整个 NTP 守护进程的全局状态，包括：
- 更新系统变量（如系统层数、根延迟、根离散度、参考标识符等）。
- 决定何时将时钟选择进程选出的最优对等体切换为系统对等体（system peer）。
- 为对外回复的 NTP 报文提供这些系统变量的值，确保下游客户端看到正确的服务器状态。
轮询进程（Poll Process）
轮询进程是系统进程的一个子模块，负责决定何时向每个对等体发送 NTP 请求。核心在于：轮询间隔越短，同步精度越高，但网络和 CPU 开销也越大；轮询间隔越长，资源消耗越少，但精度会因时钟漂移而下降。
轮询间隔（Poll Interval）的定义:
轮询间隔 p 以 2 的幂次方表示，单位为秒。例如：
p 值（指数） |
轮询间隔（秒） | 说明 |
|---|---|---|
| 4 | 16 秒 | 最小间隔（高速轮询） |
| 6 | 64 秒 | 默认起始值 |
| 10 | 1024 秒（约 17 分钟） | 典型上限 |
| 17 | 131072 秒（约 36 小时） | 绝对上限（极少使用） |
每个对等体拥有自己的 peer.poll 变量，表示当前该对等体所采用的轮询指数。系统全局最小值和最大值通常分别配置为 NTP_MIN_POLL（默认 4）和 NTP_MAX_POLL（默认 10 或 17）。
轮询进程解释了NTP实验中一个很常见的现象：为什么刚开始NTP立即同步，之后无论怎么改动NTP，反应都极慢？
原因就是下文提及的突发模式和轮询间隔，初始状态NTP进行初始突发，时间可以立即同步，后续恢复轮询。
H3C 设备轮询默认64s间隔，也就是修改NTP后，起码要等64s才能看到结果。并且由于轮询时间会逐步增大，对于已经运行了很长时间的NTP服务，修改后建议
undo ntp enable再ntp enable，让轮询间隔回到64s。
轮询间隔的动态调整
轮询间隔的动态调整是一个闭环控制过程，其逻辑如下：
第一步：评估当前误差
计算当前系统同步距离 λ = EPSILON + DELTA / 2（来自时钟组合算法）以及系统抖动 PSI。这两个值反映了当前时间源的可靠性。
第二步：估计最大允许轮询间隔
轮询间隔的上限取决于本地时钟振荡器的质量（频率容差 Φ，通常为 15 ppm）和可容忍的最大时间误差 T_max（通常预设为 1 秒）。理论上，轮询间隔 p_max 应满足：
pmax≤TmaxΦpmax≤ΦTmax
代入典型值：1 秒 / 15e-6 ≈ 66666 秒，约合 18.5 小时。当然，实际网络部署中通常会大大降低此上限，因为过长的轮询间隔会使系统对突发网络变化反应迟钝。
第三步：实际决策逻辑
NTP 实现通常采用以下简化规则来动态调整轮询间隔（自增或自减）：
- 向上调整（减小轮询频率）：如果最近若干次（通常为 8 轮）的测量稳定，且系统抖动
PSI低于某个阈值（例如0.01秒），并且当前轮询间隔尚未达到上限，则将poll加 1（即轮询间隔翻倍），以减少网络流量。 - 向下调整（增大轮询频率）：如果系统偏移
THETA超出预设的预期误差窗口，或者最近出现了丢包或高抖动，则将poll减 1（即轮询间隔减半），以快速获取更新的时间样本。 - 速率限制反馈：如果收到服务器的 KoD（Kiss-o’-Death）包（如
"RATE"），则立即将poll增加一个较大的值（通常是加 2 或更多），并持续保持一段时间，以示对服务器的尊重。
具体实现中，算法还会考虑可达性寄存器的状态：如果对等体长期可达，可适当延长轮询间隔；如果不可达，则可能缩短轮询间隔以加速恢复探测。
轮询定时器
每个对等体都有一个独立的轮询定时器，用于触发下一次请求的发送。当定时器超时时：
- 发送请求（客户端/对称主动模式）或发送广播消息（广播服务器模式）。
- 递增轮询指数：如果当前请求成功（或即使超时），定时器会根据上述动态算法重新计算下一次的超时时间。
- 超时处理：如果在定时器再次超时前未收到响应，则标记该轮为“无响应”，更新可达性寄存器，并继续等待下一次定时触发。
定时器的实现通常基于系统提供的 间隔定时器（interval timer），精度不需要很高（秒级即可），因为 NTP 对毫秒级以下的调度延迟不敏感。
突发模式
NTPv4 支持两种突发模式，用于特殊场景下的快速测量：
- 常规突发（Burst Mode）：客户端在单个轮询周期内，连续发送 N 个请求包（通常为 8 个）。服务器正常响应每个请求。客户端收集所有响应后，过滤出延迟最小的样本作为该轮的有效测量。此模式适用于拨号链路或高质量 LAN 环境，以快速填满时钟过滤器的样本缓冲区。
- 初始突发（Iburst Mode）：在系统刚启动或首次与某个对等体建立联系时，为了加速首次同步，客户端会以密集方式（每 2 秒一个）发送一小批请求（通常 4~8 个），而不是等待正常的轮询间隔。这能确保在数十秒内完成初始同步，而非数分钟。
突发模式结束后，轮询间隔恢复到正常动态值，后续按常规节奏运行。
广播/组播模式的轮询
广播模式下的轮询逻辑有所不同：
- 服务器端：主动按固定周期（通常为配置的
minpoll）发送广播消息，没有“请求”概念。发送间隔通常保持恒定（如 64 秒），不会动态调整，以确保所有客户端能稳定接收。 - 客户端端：不主动发送请求，而是持续监听网络端口。当接收到广播消息时，立即计算偏移并更新本地时钟。客户端可设置一个“超时”监控：如果在一定时间内（如 10 个广播周期）未收到任何广播包，则认为广播源已消失，切换到其他同步源（或退回到客户端/服务器模式）。
最小与最大间隔限制
为防止轮询间隔跑出合理范围，系统强制在 peer.minpoll 和 peer.maxpoll 边界内进行裁剪：
- 初始配置时，
minpoll默认为4（16 秒），maxpoll默认为10（1024 秒），用户可在配置文件中手工调整。 - 如果动态算法计算出
poll < minpoll，则强制设为minpoll；若poll > maxpoll，则强制设为maxpoll。 - 在面对 KoD 限制时，
poll可能临时超过maxpoll，但会有额外机制确保在限制解除后逐步回落。
在设备中查看轮询进程参数
poll ：表示当前的轮询时间，即当前的轮询定时器，单位是s;
reach： 时间服务器的可达性计数，0表示时间服务器不可达;
now： 最近一次接收到NTP报文或更新本地时间到当前时间的时间间隔；可以通过这个值判断上次同步是多久之前。
offset：系统时钟相对于参考时钟的时钟偏移，单位为毫秒；
delay： 本地设备到时间服务器的往返时延，单位为毫秒；
disper：系统时钟相对于参考时钟的最大误差，单位为毫秒；
[12345]：
- 系统选中的时间服务器，即当前与设备进行时间同步的时间服务器
- 该时间服务器的时钟层数小于等于15
- 该时间服务器的时钟通过了时钟选择算法
- 该时间服务器的时钟为候选时钟
- 该时间服务器的时钟是配置命令指定的
stra: 时间服务器的时钟层数
source：
- 参考时钟为本地时钟时，显示为LOCAL(number)，表示本地时钟的地址为127.127.1.number，其中number为NTP的进程号，取值范围为0～3；
- 参考时钟为网络中其他设备的时钟时，显示为时间服务器的IP地址。若该字段显示为0.0.0.0，表示时间服务器的IP地址尚未解析成功；
综上，如果修改完NTP发现不生效，怎么办？
答：看看now的时间是否是修改后，如果不是，静静等待。如果poll 已经很大了，重启下ntp。
时间驯服进程有提及：即使暂时失去所有时间源，也能以极高的精度维持时间。所以不必担心重启NTP产生业务影响（NTP协议本身也不承担重要业务，如果的确不能重启，那就静静等待）
NTP 状态变量（Session）
每个 NTP 实体维护着三类状态变量：系统变量、对等体变量和数据包变量。这些变量描述了 NTP 服务及其关联的当前状态。
系统变量（System Variables）
反映本地 NTP 实体的整体状态。主要系统变量包括：
| 变量 | 说明 |
|---|---|
leap |
闰秒指示符（LI 字段的值） |
stratum |
本地时钟的层数 |
precision |
本地时钟精度 |
rootdelay |
到达主参考源的累积往返延迟 |
rootdisp |
到达主参考源的累积误差（离散度） |
refid |
参考标识符（系统对等体的 IP 地址或 Stratum 1 时钟类型） |
reftime |
参考时间戳（最后一次更新系统时钟的时间） |
sys.offset |
最后一次计算的系统时钟偏差估计值 |
sys.jitter |
系统偏差估计的均方根抖动 |
对等体变量（Peer Variables）
每个关联的对等体都维护一组独立的变量，包括：
| 变量 | 说明 |
|---|---|
peer.srcadr |
对等体的 IP 地址 |
peer.srcport |
对等体的 UDP 端口 |
peer.hostpoll |
对等体使用的轮询间隔（对数秒） |
peer.peerpoll |
对等体报告的轮询间隔 |
peer.mode |
对等体所处的模式（客户端、服务器、对称等） |
peer.stratum |
对等体报告的层数 |
peer.rootdelay |
对等体报告的根延迟 |
peer.rootdisp |
对等体报告的根离散度 |
peer.refid |
对等体报告的参考标识符 |
peer.reftime |
对等体报告的参考时间戳 |
peer.org |
发起时间戳（最后发送给对等体的报文中的传输时间戳） |
peer.rec |
接收时间戳（从对等体最后收到的报文中的传输时间戳） |
peer.xmt |
本机发送给对等体的最后一个报文的传输时间戳 |
peer.dst |
从对等体收到最后一个报文的本地到达时间（目的地时间戳） |
peer.t |
本地时钟最后一次更新时的时间 |
peer.offset |
经滤波后的对等体时钟偏差 |
peer.delay |
经滤波后的往返延迟 |
peer.disp |
对等体离散度（经滤波后的误差估计） |
peer.jitter |
该对等体偏差样本的均方根抖动 |
peer.reach |
可达性寄存器（8 位移位寄存器，记录最近 8 次轮询的成功情况） |
peer.flash |
状态码（指示该对等体在选择/组合过程中的诊断信息） |
数据包变量（Packet Variables）
代表从一个到达的 NTP 报文中直接提取的字段值，用于临时计算。主要包括：
| 变量 | 说明 |
|---|---|
pkt.li_vn_mode |
报文的 LI、VN 和 Mode 的原始字节 |
pkt.stratum |
报文的 Stratum 字段 |
pkt.ppoll |
报文的 Poll 字段 |
pkt.precision |
报文的 Precision 字段 |
pkt.rootdelay |
报文的 Root Delay 字段 |
pkt.rootdisp |
报文的 Root Dispersion 字段 |
pkt.refid |
报文的 Reference Identifier 字段 |
pkt.reftime |
报文的 Reference Timestamp 字段 |
pkt.org |
报文的 Originate Timestamp 字段 |
pkt.rec |
报文的 Receive Timestamp 字段 |
pkt.xmt |
报文的 Transmit Timestamp 字段 |
NTP 协议操作
客户端/服务器模式操作
客户端操作：
- 构造一个 NTP 报文，Mode 设置为 3（客户端）。
- 填充 Transmit Timestamp 字段为当前本机时间（T1）。
- 其他时间戳字段（Originate, Receive）暂填 0。
- 发送报文给服务器（UDP 端口 123）。
- 收到服务器的应答报文后，记录本机到达时间（T4）。
- 从报文中提取 T1（Originate）、T2（Receive）、T3（Transmit）。
- 验证 T1 是否与当初发出请求时的 Transmit Timestamp 一致，以防止重放和重复报文。
- 按公式计算：
- 往返延迟：
delay = (T4 - T1) - (T3 - T2) - 时钟偏差：
offset = [(T2 - T1) + (T3 - T4)] / 2
- 往返延迟：
- 将（delay, offset）样本送入该对等体的时钟滤波器。
服务器操作：
- 收到客户端请求报文，记录到达时间（T2）。
- 将请求报文中的 Transmit Timestamp 拷贝到应答报文的 Originate Timestamp 字段（即 T1）。
- 将 T2 填入应答报文的 Receive Timestamp 字段。
- 在即将发送应答时，将当前本机时间填入应答报文的 Transmit Timestamp 字段（T3）。
- 设置 Mode 为 4（服务器），并填入服务器自身的系统变量（Stratum, Root Delay 等）。
- 发送应答报文给客户端。
对等体模式操作
对等体模式的操作类似于双向的客户端/服务器模式。双方各自维护一个对等体状态，独立地：
- 定期向对方发送 NTP 报文（主动方）。
- 在收到对方报文时，进行与客户端/服务器模式相同的偏差和延迟计算，但必须根据状态变量匹配正确的 T1、T2、T3、T4 序列。
在对等体模式下，仅当收到报文的 Originate Timestamp 与本机保存的 peer.xmt 相匹配时，该报文才被视为有效的“应答”，才能更新偏差与延迟样本。否则，它可能是一个重复报文或者对方主动发起的新请求，需要按情况处理。
广播模式操作
广播服务器操作：
- 周期性地构造 NTP 报文，Mode 设置为 5（广播）。
- 在即将发送时，将当前时间填入 Transmit Timestamp 字段（T3）。
- Originate 和 Receive Timestamp 字段通常填 0。
- 发送到配置的广播或多播地址。
广播客户端操作：
- 初始阶段，通过客户端/服务器模式与广播服务器进行一次（或多次）时间交换，计算出客户端与服务器之间的传播延迟。
- 此后，客户端仅被动接收广播报文，记录本机到达时间（T4）。
- 使用校准时获得的传播延迟值，估计自己的时钟偏差：
offset = T3 + delay_calibrated - T4 - 该偏差样本被送入时钟滤波器，用于驯服本地时钟。
数据包验证策略
收到一个 NTP 报文后，接收端必须执行以下验证步骤，不满足任何一条则丢弃该报文：
- 版本号检查：版本号必须为 4（或协商兼容的早期版本，但 NTPv4 下通常要求为 4）。
- 模式检查：模式必须合法（1~5，且不能为 0、6、7）。
- 层级检查：若层级为 0 或 ≥16，表示该源未同步，则该报文不可用于同步（但可用于控制或调试）。
- 原始时间戳一致性检查（针对非广播模式）：响应报文中的原始时间戳必须等于请求中发送时间戳。否则表示报文无序或伪造，予以丢弃。
- 时间戳合理性检查：所有时间戳（参考、原始、接收、发送）都不应为 0，除非是初始化阶段或特殊状态。此外，接收时间戳必须大于原始时间戳（考虑单方向传播延迟）。
- 根延迟和根离差范围检查：如果根延迟或根离差超过预设上限（如 1 秒），该源可能不可靠。
在进入选择流程前，所有候选对等体必须满足以下基本准入条件，不满足的直接丢弃：
可达性：对等体必须处于可达状态（即最近若干轮询周期内有响应）。
可达性通过一个可达性寄存器（通常为 8 位位移寄存器）来跟踪：每次收到有效响应时，将寄存器左移一位并将最低位置 1；每次超时时，左移一位并将最低位置 0。如果寄存器中的所有位均为 0，则该对等体被标记为不可达（unreachable），其样本不再参与过滤和选择。
这也是为什么NTP源已经中断，但NTP客户端session 状态仍会保持一段时间不变。
层级合理：层级必须在 1 到 15 之间（不能为 0 或 16）。
根离差和根延迟有限：根离差和根延迟不能超过预设上限（通常为 1 秒），否则表示该源自身不够稳定。
同步距离：同步距离
λ = ε + δ/2（离差加半延迟）必须在可接受范围内（通常小于 1 秒）。
SNTP 协议
SNTP简介
SNTP（Simple NTP，简单NTP）是由RFC 4330定义的客户端版本的简单NTP，采用与NTP相同的报文格式及交互过程，但简化了NTP的时间同步过程，以牺牲时间精度为代价实现了时间的快速同步，并减少了占用的系统资源。在时间精度要求不高的情况下，可以使用SNTP来实现时间同步。
SNTP只支持作为客户端，从NTP服务器获得时间同步，不能作为服务器为其他设备提供时间同步。
NTP可以是服务器模式，也可以是广播/组播模式。
如果同时为SNTP客户端指定了多个NTP服务器，则SNTP客户端根据如下方法选择与哪个服务器的时间同步：
(1) 优先选择时钟层数值最小的NTP服务器。
(2) 如果时钟层数相同，则选择接收到的第一个NTP报文对应的NTP服务器。
与SNTP相关的协议规范有： RFC 4330：Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI
SNTP协议原理
SNTP 客户端的操作模式非常简单：
- 周期性地（通常每 1~60 分钟）向配置的 NTP 服务器发送一个标准 NTP 请求（Mode = 3）。
- 接收服务器的响应（Mode = 4），提取四个时间戳。
- 计算偏移
θ和延迟δ（使用与 NTP 完全相同的公式）。 - 立即将系统时钟设置为校正后的时间（步进方式），或者使用简单的
adjtime()缓动调整（取决于偏移量大小）。 - 不维护抖动、离差或频率补偿状态，下一次轮询时完全重新计算。
与完整 NTP 相比，SNTP 客户端不进行以下任何操作：
- 不维护每服务器样本环形缓冲区（无时钟过滤算法）。
- 不执行交叉选择或聚类算法（只信任单一配置的服务器）。
- 不跟踪频率漂移或进行长期补偿。
- 不支持对称主动/被动模式（只支持客户端/服务器和广播监听）。
如果配置了多个服务器，SNTP 客户端可能简单地将它们按优先级列表处理：当首选服务器不可达时，切换到下一个；但仍不进行多源融合或加权组合。
SNTP 客户端必须能够处理来自 NTP 服务器的标准响应，包括：
- 正确处理头部的 LI、Stratum、Poll、Precision 等字段（但可忽略除时间戳外的所有字段）。
- 正确处理根延迟和根离差（可忽略，但如果根离差超过某个阈值，建议丢弃该响应并标记服务器为不可靠）。
- 正确验证原始时间戳（
Origin Timestamp）必须与请求中的发送时间戳一致，防止乱序或重放攻击。
反过来，NTP 服务器对 SNTP 客户端发来的请求没有任何特殊处理，完全按标准流程回复。
SNTP配置步骤(H3C官网)
Device B对时间精度要求不高。为了实现Device B与Device A的时间同步，要求：
· 在Device A上设置本地时钟作为参考时钟，层数为2；
· Device B工作在SNTP客户端模式，指定Device A为NTP服务器。
· Device B要求对NTP服务器进行验证，以保证时间同步的安全性。
配置Device A
# 开启NTP服务。
system-view
[DeviceA] ntp-service enable
# 设置本地时钟作为参考时钟，层数为2。
[DeviceA] ntp-service refclock-master 2
# 在Device A上启动NTP验证功能。
[DeviceA] ntp-service authentication enable
# 创建编号为10的NTP验证密钥，密钥值为aNiceKey，以明文形式输入。
[DeviceA] ntp-service authentication-keyid 10 authentication-mode md5 simple aNiceKey
# 设置编号为10的密钥为可信密钥。
[DeviceA] ntp-service reliable authentication-keyid 10
配置Device B
# 开启SNTP服务。
system-view
[DeviceB] sntp enable
# 在Device B上启动SNTP验证功能。
[DeviceB] sntp authentication enable
# 创建编号为10的SNTP验证密钥，密钥值为aNiceKey，以明文形式输入。
[DeviceB] sntp authentication-keyid 10 authentication-mode md5 simple aNiceKey
# 设置编号为10的密钥为可信密钥。
[DeviceB] sntp reliable authentication-keyid 10
# 设置Device A为Device B的NTP服务器，并将该服务器与编号为10的密钥关联。
[DeviceB] sntp unicast-server 1.0.1.11 authentication-keyid 10
查看Device B的SNTP会话信息，可以看到Device B与Device A建立了会话，并且处于已同步状态。
[DeviceB] display sntp sessions
SNTP server Stratum Version Last receive time
1.0.1.11 2 4 Tue, May 17 2019 9:11:20.833 (Synced)
