📚 课程目录第2章以太网自动协商协议基础

以太网自动协商协议基础

自动协商，说白了就是让两个网口在连接前先「聊一聊」。

它解决一个实际问题：两端设备能力不一样，怎么自动匹配到双方都支持的最高速率？

我早些年调试一个交换机项目，就因为自动协商没搞清楚，折腾了整整两天。从那以后，我把这套协议翻来覆去啃了好几遍。嗯，今天就跟大家聊聊它的底细。

90年代初，以太网还是10M半双工的天下。后来100M快起来了，问题就来了——设备不知道对面是10M还是100M。

IEEE 802.3u在1995年首次定义了自动协商机制。最初只支持10/100M速率协商，到了千兆时代扩展到802.3ab，再到2.5G/5G BASE-T，功能越来越多。但核心框架，还是那套FLP信号交换。

我记得第一次看到FLP波形时还愣了一下——这玩意儿怎么长得和普通数据帧不一样？

自动协商靠的是FLP（Fast Link Pulse）突发信号。

什么叫FLP？就是一组脉冲串，两端设备在空闲时不断发送，用来交换能力信息。

FLP结构关键点：

这些脉冲里藏着二进制数据——每个时钟周期有脉冲表示「1」，没有脉冲表示「0」。17个脉冲中有16个是数据位，最后一个是时钟同步。

说白了，就是用电平跳变来传输一串二进制码。

我在项目中遇到过一个问题：某款PHY芯片发送的FLP幅度偏低，对方死活检测不到，一直Link Down。最后发现是电源纹波干扰了脉冲发射，换了LDO就好了。

基本FLP只能传16位数据，不够怎么办？

Next Page机制就是用来扩展信息的。它允许两端协商完基本能力后，继续交换更多参数。

Next Page有什么用？

流程是这样的：

为什么要设计这么复杂？你想想看，千兆以太网需要协调主从时钟，还得指定哪端提供125MHz参考时钟。一旦没对上，时钟抖动直接超标，丢包就来了。

我曾经踩过一个坑：某款PHY在Next Page交互时，Ack响应延迟超标，导致对方超时重传，反复协商了十几次才成功。后来发现是固件处理优先级太低，语音数据流把协商队列堵住了。

假设两端能力列表不一样，怎么选？IEEE 802.3定义了明确的优先级规则。

规则很简单：两端各自宣告自己的技术能力（用位图表示），取交集后选优先级最高的那个。

举个例子——A端支持1000M全双工和100M全双工，B端只支持100M全双工和100M半双工，交集是100M全双工，那就选它。

为什么这么设计？全双工比半双工优先，高速比低速优先。你想想看，如果选了半双工，网络效率直接减半，那还不如别协商了。

注意：

并行检测（Parallel Detection）是自动协商的降级机制。当一端不支持自动协商（或FLP信号异常），另一端靠检测线路信号（如100M的Idle信号）来判断速率。但这种情况下双工模式无法协商，默认强制为半双工。这很容易导致全双工/半双工不匹配，造成大量CRC错误。

我调试过一个工厂网络，总是间歇性丢包，排查下来发现一台老式PLC不支持自动协商，交换机这边协商超时后进入并行检测，两端双工模式不一致。解决办法是在交换机端口手动固定双工模式。

把自动协商这套机制串起来看，其实就三层：

这张图把自动协商的协议栈画得很清楚。底层是FLP物理信号，中间层是Next Page交换，顶层是做最终决策。

实际调试时，我一般先从物理层看——FLP有没有发出来？幅度、间隔对不对？然后看协商日志——Base Page和Next Page交互是否完整？最后看结果——选出来的速率和双工是否符合预期？

明白这套机制，以后再碰到Link Down、协商失败、速率不对等怪问题，心里就有底了。