以太网自协商（Auto-Negotiation，IEEE 802.3 Clause 28）是两端通过发送快速链路脉冲（FLP）交换"能力字"，自动协商出双方都支持的最高速率和双工模式。本意是免去手工配错——插上线两边自己对齐速率和双工。
千兆（1000BASE-T）对自协商有硬性要求：规范规定千兆链路必须走自协商来确立主从和双工，不能像百兆那样随意硬配。
问题在于：自协商端靠收到对端的协商脉冲来判断对端能力。如果另一端设成"强制 1000Full"，它不发协商脉冲，自协商端就"听不到"对端声明，按标准行为会回退到半双工（half-duplex）工作——哪怕它自身能力是全双工。
于是出现一个诡异组合：强制端认为自己全双工（能同时收发），自协商端却按半双工（先听后发、冲突退避）工作。两边对"这根线该怎么用"的理解不一致。
全双工侧坚信"我能随时发"，在对方以为的半双工窗口里照发不误；半双工侧检测到"链路上有同时存在的信号"就判定为冲突，把帧丢弃并计入 CRC error / late collision。
现场现象很典型：端口灯是绿的、链路显示 UP，但 CRC、错包计数疯涨，业务丢包、吞吐掉一大截。看着"通了"，实际是"通但烂"。
原则只有一条：两端配置对称。
都设 Auto：最稳，现代设备默认如此，自动对齐到最优速率/双工；
都强制：只在老设备兼容性、或明确需要锁定时才用，且两端必须强制成完全相同的速率和双工；
别出现"一端 Auto 一端强制"——这是双工不匹配的最主要来源。
| 本端 \ 对端 | Auto | 强制 1000Full |
|---|---|---|
| Auto | 协商到共同最优 | 自协商端回退半双工 → 双工不匹配 |
| 强制 1000Full | 同上，对称失效 | 两端一致，正常全双工 |
锐应工业以太网交换机的管理口支持 Auto/强制的显式配置，运维可在 Web/CLI 里把上联口和对端锁成一致的速率与双工，避免"灯亮但丢包"。对老设备混接的场景，建议优先两端都 Auto；确需强制时，务必核对两端参数对称。产品与端口配置细节见锐应工业交换机。把交换机和锐应 PON 方案搭配，能覆盖从现场到局端的整段链路。公司背景见关于锐应。
1000BASE-T 规范要求自协商，强制千兆需两端都明确强制且一致；一端 Auto 一端强制极易掉到半双工，是现场高错包的高发原因。
双工/协商错是"端口 UP 但错包计数涨、吞吐低"；光衰是"收光不足、链路闪断或直接 down"。先查双工对称，再查光功率。
回退到半双工或双方能力的最低下限，速率/双工掉档，性能骤降，且往往伴随错包。
能"通"，但多半是半双工，表现为高错包低吞吐，属于典型"通但烂"，不能算正常。
自动协商的初衷是让两端自动对齐，但"一端 Auto 一端强制"会打破这个默契：强制端不发声，对端回退半双工，于是全双工侧猛刷 CRC。排"灯亮但丢包"的故障，双工不匹配要先查——两端要么都 Auto，要么都强制且对称，没有中间态。
