华为交换机NTP STRATUM_CHANGE告警深度解析与排障指南

在华为交换机上，NTP/4/STRATUM_CHANGE 这条告警几乎每个做过网络运维的人都见过，但真正理解它的并不多。我第一次在现网看到这条告警时，下意识以为是设备时间不同步，赶紧准备重新配置NTP，后来仔细查了才发现，交换机本机时间是对的，告警说的是“源参考时钟的系统层数”变了，而不是“时间同步丢失”。这篇文章就把这条告警从日志解读、底层原理、触发场景、排查链路到加固配置一次讲透，适合网络运维、数通售后和IDC值班同学作为参考。

1. 先看懂这条告警：STRATUM_CHANGE 在说什么

1.1 一条告警日志的逐字拆解

华为交换机上通过 display logbuffer 看到这条告警时，日志一般长这样：

text复制Mar 12 10:23:45 10.10.10.1 %%01NTP/4/STRATUM_CHANGE(l)[0]:OID 1.3.6.1.4.1.2011.5.25.129.2.4.1.6 The stratum of the source reference clock changed, Source: 10.10.10.2, Old stratum: 2, New stratum: 3.

这里的几个关键字段值得逐个拆解。NTP/4 表示模块是NTP，日志级别是4，也就是警告级别。STRATUM_CHANGE 是告警名称，描述核心事件：stratum发生了变化。Source 是发生变化的参考时钟源IP，这个源不一定就是当前选中的同步源，也可能是候选源。Old stratum 和 New stratum 是改变前后的层数。

不同型号、不同软件版本的OID可能不一样，后面那一串数字不用死记。真正要关注的是Source地址、Old stratum和New stratum三个字段。整条日志的含义可以理解为：交换机发现某个参考时钟源的层级关系发生了变化，但它并没有直接说“设备时间失准了”。

1.2 最容易看漏的两个细节

第一个细节是“来源”不等于“当前同步源”。华为交换机在运行NTP时，会同时维护所有已配置的候选源，通过选源算法从里面挑一个作为当前同步源。STRATUM_CHANGE告警里报出来的Source，只是某个参考源发生了变化，不一定是设备正在使用的源。所以看到这条告警后，必须用 display ntp-service status 确认当前参考时钟是谁，否则很容易误判。

第二个细节是“Old stratum 和 New stratum 都是有效数值”的情况，比如从2变成3，或者从3变成2。很多同事看到数值不是16就认为不重要，结果忽略了它背后可能是一次上游主备切换。如果整网设备都跟随同一台上游NTP服务器，这种变化会迅速向下扩散，导致一批设备在同一时间段内上报同样的告警。遇到这种批量告警，基本可以判断问题出在NTP服务器或链路，而不是某台交换机本身。

2. 系统层数为什么重要：NTP分层机制的底层逻辑

2.1 Stratum 到底在衡量什么

NTP时间体系用stratum表示时钟源的层级，取值范围是0到16。这个概念可以类比供应链：stratum 0是原子钟、GPS授时模块这类直接获取标准时间的硬件设备；stratum 1是直接连接stratum 0的服务器，相当于一级供应商；stratum 2从stratum 1同步，相当于二级供应商，以此类推。stratum 16表示不可达或者未同步，属于无效状态。

stratum之所以重要，是因为在NTP选源算法里，它是首要比较项。客户端会在同一层数内再去比较距离、延迟、抖动等指标。如果当前同步源的stratum突然从2变成3，即使交换机本机时间还没发生明显偏差，下一次选源也可能因为层数变化而切换到另一个候选源，进而影响整网时间基准。

2.2 层数改变不等于时间错误

很多人把“stratum改变”和“时间跳变”划等号，这是我对这条告警最大的一个观察。stratum描述的是层数，NTP报文里的时间戳才是真正用于对时的数据。层数改变了，只能说明这条时间链路的“信用等级”变了，链路本身可能还是通的，时间偏差也不一定变大。

举个例子：你平时从一家直营店采购原料，今天直营店临时从总仓调货，发货单上的产地变了，但原料还是同一批。NTP也是一样，上游源从stratum 2变成stratum 3，可能只是上游服务器的上级源发生了变化，不代表它给出的时间就不准。

有一种例外要特别注意：如果新旧两个源之间的时间偏差比较大，比如一个源跟随A厂商的时钟服务器，另一个源跟随B厂商的时钟服务器，两者差了100毫秒以上，交换机切换到新源后，就可能出现明显的时间调整。这种场景下，STRATUM_CHANGE告警往往会和系统时钟调整日志一起出现。如果只有层数变化、没有时间跳变，可以按低优先级处理。

2.3 层数跳变的几种典型路径

在现网里，stratum跳变最常见的路径有四条。

第一条是上游NTP服务器自身故障。服务器丢失GPS信号或者上游源不可达后，stratum会变成16，客户端收到这个信息后自动放弃该源，切换到备用源，于是产生告警。

第二条是上游NTP服务器主备切换。双机NTP服务器主机宕机，备机接管后，备机的stratum通常比主机高一层，下游所有客户端的当前源层数就会跟着变化。

第三条是网络路径变化。设备通过等价路由或VRRP切换后，到达同一个NTP服务器的路径变了，NTP会话重建，候选源重新排序，也可能触发层数变化。

第四条是工程师的配置变更。有人在NTP服务器或交换机上删除了某个源、调整了优先级，客户端的选源结果随之改变。这类告警多发生在变更窗口内，比较好回溯。

3. 华为交换机NTP同步机制与告警触发条件

3.1 NTP在华为交换机上的角色定位

华为交换机在NTP体系里可以同时扮演客户端、服务器、对等体三个角色。多数局点只用到客户端和服务器两种：交换机向上从企业内部的NTP服务器取时，向下又可以给服务器、PC或下级交换机提供时间同步。通过一条 ntp-service unicast-server 配置，就能让交换机主动向指定服务器发起同步。

以常见配置为例：

text复制ntp-service unicast-server 10.10.10.2 priority
ntp-service unicast-server 10.10.10.3

这条配置的意思是：设备作为NTP客户端，向10.10.10.2和10.10.10.3发起请求，并优先使用10.10.10.2作为同步源。华为设备在运行过程中会周期性检查所有候选源的状态，通过NTP报文中的stratum字段、本地到达该源的距离和延迟等参数，运行选源算法。选源结果不是固定不变的，会跟随网络状态动态调整，所以才会产生STRATUM_CHANGE告警。

不同版本和型号的华为交换机在NTP命令集上有细节差异。S5700、S6700为代表的传统框式盒式交换机基本支持 ntp-service 前缀的命令，部分云园区交换机可能命令风格不同。如果你在设备上执行 ntp 或 ntp-service 显示不支持，建议先 display version 确认版本，再对照产品文档确认命令。

3.2 STRATUM_CHANGE 的触发条件

这条告警的触发条件可以概括为：当NTP模块感知到当前选中的源，或者参与选源的关键源的stratum发生变化时，会上报该告警。

关键点在“变化”这两个字，而不是“变成16”。所以stratum从2变成3会告警，从3变成16会告警，从16变成3同样会告警。如果所有源都正常且没有变化，一般不会周期性上报。

日志级别为4，在华为告警分级里属于警告级别，提醒关注，但不需要像错误级别那样立刻抢修。我的建议是，这类告警应该进入“待观察”列表，先确认当前时间同步状态，再决定是否要动设备。如果一上来就把NTP配置删了重配，反而可能打断正在进行的同步，扩大影响。

4. 真实排障：从看到告警到定位根因的完整链路

4.1 排查前先确认的三件事

收到STRATUM_CHANGE告警后，我先做三件事，而不是急着翻配置。

第一步，看当前时间是否还在合理范围内：

bash复制display clock

如果时间没有明显偏差，业务侧也没有时间相关报障，可以先保持观察。

第二步，查NTP同步状态：

bash复制display ntp-service status
display ntp-service sessions

前者会显示当前同步状态、同步源IP、时钟层数等信息；后者会列出所有配置的NTP服务器及当前状态，通常带 * 标记的是当前同步源。重点看当前源是否已经改变、层数是否在合理范围内。

第三步，回忆告警前后是否有变更。包括NTP服务器端变更、网络割接、防火墙策略调整、交换机上下线等。如果不是变更引起的，再往下走链路排查。

4.2 分场景排查链路

场景一：上游NTP服务器自身故障。

如果 display ntp-service sessions 显示所有源的reach值都偏低，或者源的stratum是16，大概率是上游NTP服务器或中间链路出问题。登录NTP服务器查看 ntpq -p 或系统日志，确认它的上游源是否丢失。也可以先在交换机上ping NTP服务器，确认基础网络连通性：

bash复制ping -c 3 10.10.10.2

网络层通不代表NTP层通。别忘了检查UDP 123端口是否被ACL或防火墙拦截。华为交换机上可以通过 display acl all 检查接口ACL配置，但更直接的验证方式是在NTP服务器上抓包，或者在交换机上查看NTP会话日志，确认报文是否正常发出和收到。我处理过不少次这类告警，根因就藏在ACL里，设备之间的管理VLAN是通的，但UDP 123被拦了。

场景二：网络路径变化导致NTP会话重建。

如果是链路切换导致告警，设备上会看到当前同步源没有变，但选源结果在短时间内发生多次切换，日志里可能连续出现多条STRATUM_CHANGE。此时可以用 display ip routing-table 10.10.10.2 查看去往NTP服务器的路由是否在主备路径间漂移，再配合上游设备日志确认链路切换时间点。这类问题需要从网络架构上解决，比如为NTP规划稳定的管理路由。

场景三：多个NTP源的层数不一致。

如果配置了两个源，一个stratum 2、一个stratum 3，那么当stratum 2的源出现短暂质量下降时，设备可能根据选源算法切到stratum 3的源上，从而触发告警。这种问题不一定要修复，但如果你希望主源始终是stratum 2，可以给主源加 priority 参数，让设备在质量相近时优先选择主源。

场景四：设备配置被误改。

虽然不常见，但确实会遇到。比如有人登录交换机执行了 undo ntp-service 开头的命令，或者在上游NTP服务器上删除了当前交换机的peer关系，都会导致stratum变化。检查当前配置是否和基线一致：

bash复制display current-configuration configuration ntp

如果和备份配置有差异，先diff，再决定是否回滚。

4.3 一个可供参考的现网案例

之前处理过一起核心交换机NTP告警，正好可以复现完整的排查思路。凌晨2点14分，一台核心交换机连续上报两条STRATUM_CHANGE，Old stratum是2，New stratum是3，大约20分钟后恢复成2。

我登录交换机后先执行 display ntp-service status，发现当时的同步源已经切换到备用的10.10.10.4，原同步源10.10.10.3仍在候选列表中，但没有被选中。接着看 display ntp-service sessions，10.10.10.3的stratum已经变成3，reach值也在下降。基本可以判断问题出在10.10.10.3这台上游NTP服务器上。

登录10.10.10.3后，通过 ntpq -pn 查看上游源，发现远端GPS时钟源状态从 *，也就是当前使用状态，变成了 x，也就是不可达状态。NTP服务在丢失GPS源后，会等待一段时间，然后把自身stratum从2调高到3，继续对外提供服务。下游交换机检测到这个变化后，就上报了STRATUM_CHANGE告警。

整个过程中交换机本机时间偏差没有超过10毫秒，业务无感知。后来GPS天线重新定位后，上游NTP服务器恢复了stratum 2，交换机自动切回，告警停止。整个过程没有在交换机上做任何配置修改。

这个案例最关键的一点是：设备告警只是结果，真正的根因在上游NTP服务器。如果只盯着交换机排查，很容易白忙一场。

5. 修复方案与加固配置：不只是清告警

5.1 临时处置与恢复步骤

当STRATUM_CHANGE告警出现，并且你判断设备时间可能已经失准时，需要尽快恢复。临时处置有一个原则：能不做手动调钟就不做手动调钟。手动 clock datetime 会造成时间瞬间跳变，对运行中的数据库、日志系统和认证服务都可能产生冲击。更稳妥的做法是指定当前可用的NTP服务器，让设备自动对时。

比如：

text复制undo ntp-service unicast-server 10.10.10.3
ntp-service unicast-server 10.10.10.4 priority

如果只是想清理一个异常源，直接undo后再加回来就可以。注意，undo和新增配置会导致当前NTP会话中断，建议在维护窗口执行。

命令执行后，观察：

bash复制display ntp-service status

看到Clock stratum恢复到合理值，同步状态为synchronized，基本说明恢复完成。

5.2 华为交换机NTP配置建议

长期来看，我推荐按下面的思路加固NTP配置，可以有效减少STRATUM_CHANGE告警对业务的影响。

第一，每台网络设备至少配置两个NTP服务器地址，且两个服务器最好来自不同的时钟来源和物理链路，避免一个源故障时所有设备同时切换。如果条件允许，使用独立的NTP服务器集群，而不是把核心交换机既当转发设备又当首要时钟源。

第二，用 priority 指定主用源。这样在多个源质量都正常时，设备会优先使用指定主源，减少因选源算法随机性导致的频繁切换。

text复制ntp-service unicast-server 10.10.10.2 priority
ntp-service unicast-server 10.10.10.3

第三，为NTP报文指定稳定的源接口。建议使用LoopBack接口或管理VLAN接口，避免因为业务接口状态变化导致NTP会话中断。华为交换机的写法通常是：

text复制ntp-service unicast-server 10.10.10.2 source-interface LoopBack0

如果管理地址就是Vlanif1，可以写 source-interface Vlanif1。

第四，有条件的网络建议开启NTP认证，防止伪造NTP报文攻击。配置参考：

text复制ntp-service authentication enable
ntp-service authentication-keyid 10 authentication-mode md5 cipher %^%#YourKey#%^%#
ntp-service trusted-key 10
ntp-service unicast-server 10.10.10.2 authentication-keyid 10 priority

密钥部分的密文显示方式在不同版本里有差异，建议配置前查阅对应版本手册。一旦开启认证，服务器和客户端必须使用相同的key-id和密钥，否则无法建立同步，反而会导致新的告警。

第五，非必要不要启用 ntp-service refclock-master。这个命令会让交换机把自己当作本地时钟源，在没有真实上游时钟的隔离网络里也许能应急，但在生产环境里会引入多层同步环路，甚至造成stratum乱跳。如果确实要用，也只能在一台设备上配置，并且明确它不向核心生产设备提供同步。

5.3 监控与告警联动配置

STRATUM_CHANGE告警本身并不可怕，可怕的是没人去分析它。建议把NTP状态纳入日常监控。

将交换机日志统一发送到日志服务器：

text复制info-center enable
info-center loghost 10.20.1.100

这样NTP告警可以在日志平台里按设备、源IP、时间维度检索，方便趋势分析。在网管系统里对NTP相关告警设置规则，如果告警在短时间内从多台设备同时上报，大概率是上游NTP服务器整体故障，需要第一时间联系NTP管理员。

也可以定期巡检记录NTP状态，避免只看告警不看状态。一段简单的巡检脚本思路如下：

bash复制#!/bin/bash
info=$(sshpass -p 'YourPasswd' ssh -o StrictHostKeyChecking=no admin@10.10.10.1 "display ntp-service status")
stratum=$(echo "$info" | grep -i "Clock stratum" | awk -F'[:,]' '{print $2}' | tr -d ' ')
reference=$(echo "$info" | grep -i "Reference clock" | awk -F'[ :]' '{print $3}')
echo "$(date) stratum=$stratum ref=$reference" >> /var/log/ntp_check.log

生产环境不建议直接用明文密码，可以用堡垒机、密钥或运维平台替代。这个脚本的价值在于记录NTP状态变化历史，STRATUM_CHANGE告警出现时可以快速对账，判断是偶发还是持续恶化。

6. 几个容易误判的问题和我的处理习惯

6.1 三个常见误区

误区一：stratum越小一定越准。stratum只表示层数，不能直接代表时间准确度。一个配置错误的stratum 1服务器可能比一个稳定运行的stratum 3服务器时间偏差大得多。选源时要综合看stratum、延迟、偏移量和jitter，不要只盯着层数。

误区二：多配置几台NTP服务器就万无一失。如果多个NTP服务器之间的时间不一致，反而可能导致客户端选源在它们之间来回切换，产生更多STRATUM_CHANGE告警，甚至引起时钟震荡。配置多个源的前提是这些源本身已经同步到同一个正确时间基准。

误区三：看到STRATUM_CHANGE就马上处理。这条告警更像一个提醒，提醒你去检查，而不是指令你去修改。贸然修改配置，可能把一个已经自我恢复的正常状态打断。先看 display ntp-service status，再决定怎么操作，这个顺序不能乱。

6.2 我的处理习惯

最后分享一个我的操作习惯：遇到STRATUM_CHANGE告警时，我第一件事不是登录设备，而是先打开日志平台，用源IP、Old stratum、New stratum三个维度检索，看过去24小时是否出现过相同告警。如果是第一次出现，且业务没有异常，我会截图存档，观察1小时；如果一小时内再次出现，再启动完整排查流程。如果告警是批量出现的，就不再单台排查，直接升级到NTP服务器集群和核心网络链路层面。

这个习惯帮我避免了很多次无效排障。网络设备把告警告诉我们，是希望我们关注它，而不是让我们每次都去重配一台设备。把NTP当成整体链路来看，把来源、层级、状态的变化串起来，才能真正理解STRATUM_CHANGE这条告警想表达什么。