网络接口层排查：网卡状态检查

网络出问题了，第一反应是什么？很多人会去 ping 网关。但我个人的习惯是——先看网卡。你想想看，如果网卡本身都挂了，ping 再多次也是白搭。网络接口层是数据流动的起点，也是故障隔离的第一道关卡。

这一节，我们聚焦三个核心动作：查状态、看驱动、对协商。说白了，就是搞清楚网卡到底在不在干活，干得怎么样。

1. 用 ethtool 和 ip link 看网卡状态

先来两个最常用的命令。我几乎每天都会敲它们。

# 查看网卡基本状态
ip link show eth0

# 查看网卡详细能力与当前协商状态
ethtool eth0

ip link 的输出里，最关键的是 state UP 还是 state DOWN。如果看到 DOWN，别急着怀疑硬件——先看看是不是被 ip link set eth0 down 给关了。我曾经遇到过一起事故，运维同事在调试时执行了 ifdown eth0，然后忘了恢复，结果业务报警说网络不通，查了半天才发现是网卡被手动关闭了。

ethtool eth0 的信息更丰富。重点关注这几项：

字段	含义	正常值参考
Speed	当前链路速率	1000Mb/s、10000Mb/s
Duplex	双工模式	Full（全双工）
Auto-negotiation	是否开启自动协商	on
Link detected	物理链路是否连通	yes

2. 网卡驱动与固件问题

驱动和固件出问题，表现往往很诡异——网卡能起来，但跑着跑着就丢包、断流，甚至直接卡死。我遇到过最典型的一次：某台服务器的 ixgbe 驱动版本太老，在流量超过 2Gbps 时就开始疯狂丢包，升级驱动后立刻恢复正常。

怎么查驱动信息？

# 查看网卡驱动名称和版本
ethtool -i eth0

# 查看内核模块详情
modinfo ixgbe

# 查看固件版本
ethtool -e eth0  # 转储 EEPROM，部分网卡可读固件版本

ethtool -i 的输出示例：

driver: ixgbe
version: 5.1.0-k
firmware-version: 0x800003e1

这里有个坑：驱动版本不是越新越好。我曾经在 CentOS 7 上强行装了最新的 ice 驱动，结果跟内核不兼容，直接导致网卡无法识别。后来老老实实用了系统自带的 kmod 包才解决。

3. 链路协商与双工模式

这是网络接口层最经典的故障场景。两台设备之间，如果一端强制设为 100M/全双工，另一端开启自动协商，结果往往不是协商到 100M/全双工，而是协商失败，回退到 100M/半双工。半双工模式下，冲突域变大，丢包率飙升，延迟剧增。

为什么会这样？自动协商的机制是双方互相发送 FLP（快速链路脉冲）来交换能力信息。如果一端强制固定了速度和双工，它就不再发送 FLP，另一端收不到脉冲，就只能按默认规则回退。这个默认规则通常是：速度按对方能支持的最高速率，双工强制设为半双工。

检查当前协商状态：

ethtool eth0 | grep -E "Speed|Duplex|Auto-negotiation"

如果看到 Duplex: Half，基本可以断定是协商出了问题。解决办法：

1. 两端都开启自动协商（推荐）
2. 如果必须强制固定，确保两端设置完全一致

# 设置自动协商
ethtool -s eth0 autoneg on

# 强制固定（不推荐，除非有特殊需求）
ethtool -s eth0 speed 1000 duplex full autoneg off

4. 知识体系总览

下面这张图，把网络接口层排查的核心逻辑串起来了。你可以把它当作一个快速检查清单。

5. 实战排查清单

最后，给你一份我平时用的排查清单。遇到网络接口层的问题，按这个顺序走一遍，基本不会漏。

• 第一步：ip link show 确认网卡状态是否为 UP
• 第二步：ethtool eth0 确认 Link detected 为 yes
• 第三步：检查 Speed 和 Duplex 是否符合预期（千兆网卡跑在 100M 就是异常）
• 第四步：ethtool -i eth0 确认驱动版本，对比厂商官网是否有已知 bug
• 第五步：检查 /var/log/messages 或 dmesg 中是否有网卡相关的错误日志
• 第六步：如果怀疑协商问题，用 ethtool -s 尝试重新协商