千兆以太网MII寄存器上报链路断开370ms延迟问题咨询

当前在Ubuntu 20.04系统上部署NIC bonding（网卡绑定）网络冗余方案，具体配置如下：

• 硬件：2个千兆以太网接口，以太网控制器为Intel I210
• 绑定模式：active-backup（主备模式）
• 链路监控：采用MII机制做链路状态检测，轮询间隔设置为10ms

配置基础功能正常：主用从接口故障（网线拔出）时，绑定组可自动切换至备用从接口，但切换总耗时最高可达400ms，响应速度未达预期。

排查过程 #

为定位延迟来源，做了如下排查动作：

1. 使用mii-tool -vv ens33读取接口MII寄存器原始内容（-vv参数作用为打印全量原始MII寄存器值）
2. 编写简易bash脚本，通过无暂停的while true循环，持续打印当前时间与存储链路状态的2号MII寄存器值；脚本实际采样间隔为20ms，精度满足排查需求
3. 分速率场景对照测试：
   • 接口强制配置为100Mbit/s全双工模式时：MII寄存器几乎实时更新，从拔线到寄存器值更新的检测耗时约50ms，无可见延迟
   • 接口通过auto-negotiation（自动协商）工作在1Gbit/s全双工模式时：MII寄存器更新延迟显著；配合绑定接口每10ms发送ping报文、接收端Wireshark抓包统计，测得链路检测延迟约为370ms

已查阅Intel I210官方公开数据手册，未找到该延迟相关的说明。

• 为何1Gbit/s速率下的链路断开检测耗时远高于100Mbit/s速率？
• 有哪些可行方案可提升链路故障检测的响应速度？

千兆速率下MII检测延迟更高的根因 #

该延迟来自千兆以太网PHY（物理层芯片）默认的链路容错机制，和bonding模块本身的轮询逻辑无关：

• 100BASE-TX（百兆以太网）物理层默认的链路断连检测阈值极短：PHY持续检测对端发送的链路脉冲，只要连续3~5ms未收到有效脉冲就会判定链路断开，直接更新MII状态寄存器。测试测得的50ms延迟基本为寄存器读取、内核协议栈处理的固有开销，无额外等待时长。
• 1000BASE-T（千兆以太网）开启自动协商的默认配置下，PHY会启用信号能量检测+自动协商重传容错机制：由于千兆铜线同时使用四对差分线传输数据，信号衰减、线间串扰的概率远高于百兆，网卡厂商默认会给PHY配置350ms左右的容错窗口——只有连续超过该窗口未收到对端的有效链路脉冲/空闲信号，才会判定链路真实断开、更新MII寄存器，避免瞬时信号抖动导致的误判。测试测得的370ms延迟，基本对应该PHY默认容错窗口的时长，剩余20ms为bonding轮询、脚本采样的固有开销。
• Intel I210的该容错窗口参数存储在PHY的厂商私有寄存器中，公开数据手册仅会标注IEEE标准定义的通用MII寄存器说明，不会列出厂商自定义的PHY调优参数，因此无法在公开手册中查到对应描述。

提升链路故障检测响应速度的可行方案 #

按落地优先级从高到低排序：

1. 调整PHY快速链路检测阈值
   安装ethtool工具，对绑定组下所有从接口执行ethtool --set-phy-tunable <接口名> fast-link-down on开启快速断连检测，可配合ethtool -C <接口名> link-detect <毫秒数>自定义断连检测阈值，Intel I210支持最低设置为10ms。配置生效后千兆模式下的PHY检测延迟可降至与百兆模式相当的水平。注意该配置需要通过systemd-networkd/NetworkManager的接口配置文件做持久化，避免重启失效。
2. 替换MII监控为ARP连通性监控
   若网卡PHY不支持调整断连检测阈值，可将bonding的监控机制从miimon切换为arp_interval：配置同网段稳定可达的目标IP（如直连交换机的网关IP），设置arp_interval=10，bonding模块会直接发送ARP探针检测链路连通性，无需等待PHY更新MII寄存器状态，检测延迟可压至20ms以内。建议同时配置arp_validate=active参数，避免单向链路导致的误切换。
3. 裁剪bonding切换的固有等待延迟
   将bonding模块的updelay、downdelay参数均设置为0（部分发行版默认配置为200ms），关闭链路切换时不必要的地址刷新等待逻辑，可将故障触发后的总切换耗时压至50ms以内，满足绝大多数低冗余切换场景要求。

不推荐通过强制将千兆接口配置为百兆全双工的方式规避延迟，该方案会直接损失90%的链路带宽，性价比极低。

内容的提问来源于stack exchange，提问作者computer007