应使用ethtool查看网卡实际协商速率和双工模式，speed显示当前链路速率（如1000mb/s），duplex应为full，link detected为yes表示连通，auto-negotiation须为on以确保正确协商。
直接看网卡协商状态，再比对交换机配置，就能快速确认是不是速率不匹配导致的丢包。
先查本机网卡实际协商结果
运行 ethtool eth0（把 eth0 换成你的网卡名），重点关注三行：
- Link detected: yes —— 否则物理链路已断
- Speed: 比如 1000Mb/s、100Mb/s，不是你“以为”的值，而是真实协商结果
- Duplex: 必须是 Full；若显示 Half，基本可判定双工不匹配
如果看到 Auto-negotiation: off 或 failed，说明自动协商失败，两端很可能各自按默认或强制模式运行，极易错配。
对比交换机端口的实际配置
登录交换机，查对应端口的当前状态。不同厂商命令略有差异：
- 华为/华三：display interface GigabitEthernet 0/0/1
- Cisco：show interfaces gi0/1 status 或 show interfaces gi0/1
- Juniper：show interfaces ge-0/0/1 detail
关键看输出中的 Speed 和 Duplex 字段，是否与 ethtool 查到的一致。常见错配场景包括：
- 服务器端设为 1000/full 强制模式，交换机端 auto-negotiation 成功但降为 100/full
- 一端启用 auto，另一端强制 1000/full，而交换机不支持该速率或光模块不兼容
- 光纤链路中一端用单模模块、另一端用多模，导致协商不稳定，反复 up/down
验证是否由错配引发丢包
错配通常不会报错，但会引发大量底层异常，重点检查这些指标：
- /proc/net/dev 中 RX-ERR（CRC 错误）持续上升 → 典型半双工/速率错配表现
- ethtool -S eth0 | grep -i "crc\|frame\|errors" 查具体错误计数器，如 rx_crc_errors、rx_frame_errors 非零
- 交换机侧查看同一端口的 input errors、runts、giants 是否明显偏高
这类丢包发生在物理层，数据包根本没进协议栈，tcpdump 在 eth0 上抓不到出问题的包，所以不能只依赖抓包。
临时修复与长期建议
快速恢复通信可统一协商模式：
- 双方都启用 auto-negotiation（推荐）：确保网线、模块、固件均支持；重启网卡和交换机端口
- 双方都强制相同速率和双工：ethtool -s eth0 speed 1000 duplex full autoneg off（注意：部分万兆网卡不支持强制）
长期建议：
- 避免混用强制模式与 auto 模式
- 升级交换机和网卡固件，解决老版本协商 Bug
- 在生产环境部署前，用 ethtool 和交换机命令交叉验证链路状态
