问题描述
节前业务运维同事提交了一个 case ，说是部署在新业务区域的 Linux 服务器和老业务区域的 Linux 服务器无法对时，脚本里使用的是 clockdiff 命令，无法正常返回结果，而在老业务区域两台服务器之间执行命令就正常，因为跨业务区域就有问题，所以怀疑是网络或是安全上有问题，而新老区域之间并无防火墙，排除掉，遂进入疑似网络故障分析。
问题分析
拿到这样一个问题，基于经验，可以简单梳理出以下处理步骤：
- 新老网络环境区别；
- clockdiff 实现原理；
- 故障复现和验证；
- 网络抓包分析。
新老网络环境区别
老业务区域网络环境为全思科设备，由于国产化替代趋势，新业务区域网络环境为全华为设备，仅此区别，也都是传统基础路由交换环境，配置上并无任何特殊之处。如果能排除服务器或操作系统的问题，那么问题就有可能出现在思科或华为网络设备上。
clockdiff 实现原理
clockdiff 命令用于测量两个主机之间的时钟差异，具体来说 clockdiff 是使用 ICMP 时间戳报文或使用 ICMP ECHO 的 IP 时间戳选项，以 1ms 精度测量两者之间的时钟差。
使用 ICMP 时间戳报文
clockdiff 10.1.1.1
使用 ICMP ECHO 的 IP 时间戳选项
clockdiff -o 10.1.1.1
Linux clockdiff 命令参考：https://linux.die.net/man/8/clockdiff
故障复现和验证
进一步和业务运维同事明确了故障环境和现象，补充了一点说是在老业务区域下成功的两台服务器是同一网段，且命令是加参数的 -o 。
基于上述情况，临时申请了几台新老环境下的虚机服务器，用于验证。验证方式很简单，clockdiff 命令执行的成功否类似网络中的通或者不通，故障很好复现，也很方便抓包排障。
测试环境和验证结果：
| 执行命令 | 网络环境（思科） | 网络环境（华为） | ||
|---|---|---|---|---|
| 同网段 | 不同网段 | 同网段 | 不同网段 | |
| clockdiff | 成功 | 成功 | 成功 | 成功 |
| clockdiff -o | 成功 | 失败 | 成功 | 成功 |
验证结果初步说明可能是思科区域核心网关交换机的问题，同网段二层交换机时正常，只有跨网段三层路由时有问题，而且只有加了参数 -o 也就是使用 IP 时间戳选项时有问题。
网络抓包分析
思科同网段
- 在虚机服务器上执行 clockdiff 成功的现象和抓包结果，如下：
[root@10-1-1-1 ~]$ clockdiff 10.1.1.2
.
host=10.1.1.2 rtt=750(187)ms/0ms delta=22ms/22ms Sun Jan 29 15:34:00 2023
[root@10-1-1-1 ~]$
clockdiff 命令 ICMP 数据包类型为 Timestamp request（Type 13） 和 Timestamp reply （Type 14）。
- 在虚机服务器上执行 clockdiff -o 成功的现象和抓包结果，如下：
[root@10-1-1-1 ~]$ clockdiff -o 10.1.1.2
..
host=10.1.1.2 rtt=562(280)ms/0ms delta=23ms/23ms Sun Jan 29 15:34:05 2023
[root@10-1-1-1 ~]$
clockdiff -o 命令 ICMP 数据包类型实际为普通的 Echo request（Type 8） 和 Echo reply （Type 0），区别是在 IPv4 Options 上使用 Time Stamp。
思科不同网段
在虚机服务器上执行 clockdiff 成功和 clockdiff -o 失败的现象，如下：
[root@10-1-1-1 ~]$ clockdiff 10.2.1.1
.
host=10.2.1.1 rtt=750(187)ms/0ms delta=1ms/1ms Sun Jan 29 15:34:16 2023
[root@10-1-1-1 ~]$ clockdiff -o 10.2.1.1
10.2.1.1 is down
[root@10-1-1-1 ~]$
从抓包结果来说：
- clockdiff 命令不同网段执行没有区别， ICMP 数据包类型仍为 Timestamp request（Type 13） 和 Timestamp reply （Type 14），结果成功；
- clockdiff -o 命令不同网段执行结果失败，源服务器抓包可以看到 ICMP Echo request （Type 8）发出，但是在目的服务器上并没有抓到任何请求包，因此判断为思科区域核心网关交换机丢包。
问题总结
经测试环境实际验证，判断为思科区域核心网关交换机疑似不识别 IPv4 Options 里的 TimeStamp 字段，从而造成丢包。后向原厂开 case 沟通，确认说是 N9K 网关不支持 IPv4 Options 里的时间戳的 standard timestamps，导致丢弃，同时查询内部信息，目前暂没有计划支持，也没有相关的支持配置命令，Over。
参考：
- 在 linux.die.net clockdiff 命令参考页面，还有一句貌似相关的注释：Some nodes (Cisco) use non-standard timestamps, which is allowed by RFC, but makes timestamps mostly useless.
- RFC 791 Options: variable，The options may appear or not in datagrams. They must be implemented by all IP modules (host and gateways). What is optional is their transmission in any particular datagram, not their implementation.
