用于在 OSI 物理层调查双绞线以太网变体的诊断概念¶

简介¶

本文档旨在服务于两个主要受众：

用户和系统管理员：对于那些处理现实世界以太网问题的人员，本指南提供了一个实用的、循序渐进的故障排除流程，以帮助识别和解决 OSI 物理层双绞线以太网中的常见问题。如果您遇到不稳定的链接、速度下降或神秘的网络问题，请直接进入逐步指南并按照它找到解决方案。
内核开发人员：对于从事网络驱动程序和 PHY 支持的开发人员，本文档概述了诊断过程，并突出了 Linux 内核诊断接口可以扩展或改进的领域。通过了解诊断流程，开发人员可以更好地确定未来增强功能的优先级。

Linux 逐步诊断指南（通用以太网）¶

本诊断指南涵盖了常见的以太网故障排除场景，重点关注不同以太网环境中的链路稳定性和检测，包括单对以太网 (SPE) 和多对以太网 (MPE)，以及诸如 PoDL（数据线供电）和 PoE（第 33 条 PSE）之类的供电技术。

本指南旨在帮助用户诊断运行 Linux 内核 6.11 或更高版本、使用 ethtool 6.10 或更高版本和 iproute2 6.4.0 或更高版本的系统上的物理层（Layer 1）问题。

在本指南中，我们假设用户可能对链路伙伴的访问受限或没有访问权限，并将专注于在本地诊断问题。

诊断场景¶

链路已建立且稳定，但没有数据传输：如果链路稳定，但数据传输存在问题，请参考 OSI 第二层故障排除指南。
链路不稳定：链路重置、速度下降或其他波动表明硬件或物理层可能存在问题。
未检测到链路：接口已启动，但未建立链路。

验证接口状态¶

首先验证以太网接口的状态，以检查其是否已在管理上启动。与 ethtool（提供有关链路和 PHY 状态的信息）不同，它不显示接口的管理状态。要检查这一点，您应该使用 ip 命令，该命令在其输出的尖括号 “<>” 中描述接口状态。

例如，在输出 <NO-CARRIER,BROADCAST,MULTICAST,UP> 中，重要的关键字是

UP：接口处于管理的“UP”状态。
NO-CARRIER：接口在管理上处于启动状态，但未检测到物理链路。

如果输出显示 <BROADCAST,MULTICAST>，则表示该接口处于管理的“DOWN”状态。

命令：ip link show dev <interface>

预期输出

4: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 ...
   link/ether 88:14:2b:00:96:f2 brd ff:ff:ff:ff:ff:ff

解释输出
- 管理 UP 状态:
  - 如果输出包含 “UP”，则表示该接口在管理上已启动，并且系统正在尝试建立物理链路。
  - 如果您还看到 “NO-CARRIER”，则表示尚未检测到物理链路，这表明可能存在物理层问题，例如电缆故障、配置错误或链路伙伴没有连接。在这种情况下，请继续检查链路状态和 PHY 配置部分。
- 管理 DOWN 状态:
  - 如果输出缺少 “UP” 并且仅显示 “<BROADCAST,MULTICAST>” 之类的状态，则表示该接口在管理上处于关闭状态。在这种情况下，请使用以下命令启动接口
    ip link set dev <interface> up
后续步骤:
- 如果接口在管理上已启动但显示 NO-CARRIER，请继续检查链路状态和 PHY 配置部分，以排除潜在的物理层问题。
- 如果接口在管理上处于关闭状态，并且您已将其启动，请务必重复此验证步骤以确认接口的新状态，然后再继续操作。
- 如果接口已启动并检测到链路:
  - 如果输出显示 “UP” 并且没有 `NO-CARRIER`，则表示该接口在管理上已启动，并且已成功建立物理链路。如果一切按预期工作，则物理层诊断完成，无需采取进一步操作。
  - 如果接口已启动且检测到链路但未传输任何数据，则问题很可能超出物理层范围，您应该继续诊断 OSI 模型的更高层。这可能涉及检查第二层配置（例如 VLAN 或 MAC 地址问题）、第三层设置（例如 IP 地址、路由或 ARP）或第四层及以上（防火墙、服务等）。
  - 如果链路不稳定或频繁重置或掉线，则可能表示物理层问题，例如电缆故障、干扰或供电问题。在这种情况下，请继续本指南中的下一步。

检查链路状态和 PHY 配置¶

使用 ethtool -I 检查链路状态、PHY 配置、支持的链路模式以及其他统计信息，例如链路断开事件计数器。此步骤对于诊断第一层问题（如速度不匹配、双工问题和链路不稳定）至关重要。

对于单对以太网 (SPE) 和多对以太网 (MPE) 设备，您将使用此步骤来收集有关链路的关键详细信息。SPE 链路通常支持单种速度和模式，无需自动协商（10BaseT1L 除外），而 MPE 设备通常支持多种链路模式和自动协商。

命令：ethtool -I <interface>

SPE 接口的示例输出（非自动协商）:

Settings for spe4:
    Supported ports: [ TP ]
    Supported link modes:   100baseT1/Full
    Supported pause frame use: No
    Supports auto-negotiation: No
    Supported FEC modes: Not reported
    Advertised link modes: Not applicable
    Advertised pause frame use: No
    Advertised auto-negotiation: No
    Advertised FEC modes: Not reported
    Speed: 100Mb/s
    Duplex: Full
    Auto-negotiation: off
    master-slave cfg: forced slave
    master-slave status: slave
    Port: Twisted Pair
    PHYAD: 6
    Transceiver: external
    MDI-X: Unknown
    Supports Wake-on: d
    Wake-on: d
    Link detected: yes
    SQI: 7/7
    Link Down Events: 2

MPE 接口的示例输出（自动协商）:

Settings for eth1:
    Supported ports: [ TP    MII ]
    Supported link modes:   10baseT/Half 10baseT/Full
                            100baseT/Half 100baseT/Full
    Supported pause frame use: Symmetric Receive-only
    Supports auto-negotiation: Yes
    Supported FEC modes: Not reported
    Advertised link modes:  10baseT/Half 10baseT/Full
                            100baseT/Half 100baseT/Full
    Advertised pause frame use: Symmetric Receive-only
    Advertised auto-negotiation: Yes
    Advertised FEC modes: Not reported
    Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                         100baseT/Half 100baseT/Full
    Link partner advertised pause frame use: Symmetric Receive-only
    Link partner advertised auto-negotiation: Yes
    Link partner advertised FEC modes: Not reported
    Speed: 100Mb/s
    Duplex: Full
    Auto-negotiation: on
    Port: Twisted Pair
    PHYAD: 10
    Transceiver: internal
    MDI-X: Unknown
    Supports Wake-on: pg
    Wake-on: p
    Link detected: yes
    Link Down Events: 1

后续步骤:
- 记录 ethtool 提供的输出，特别注意主从状态、速度、双工和其他相关字段。此信息对于进一步分析或故障排除很有用。收集并存储 ethtool 输出后，请继续下一步诊断步骤。

检查供电（PoDL 或 PoE）¶

如果已知系统未实现 PoDL 或 PoE，或者 PSE（电源设备）由专有的用户空间软件或外部工具管理，则可以跳过此步骤。在这种情况下，请通过其他方法验证供电，例如检查硬件指示灯（LED）、使用万用表或咨询供应商特定的软件来监控电源状态。

如果已实现 PoDL 或 PoE 并由 Linux 直接管理，请按照以下步骤操作，以确保正确供电

命令：ethtool --show-pse <interface>

预期输出示例:

不支持 PSE:

如果未连接 PSE 或接口不支持 PSE，则预期会看到以下输出
```
netlink error: No PSE is attached
netlink error: Operation not supported
```

PoDL（单对以太网）:

当实现 PoDL 时，您可能会看到以下属性

PSE attributes for eth1:
PoDL PSE Admin State: enabled
PoDL PSE Power Detection Status: delivering power

PoE（第 33 条 PSE）:

对于标准 PoE，输出可能如下所示

PSE attributes for eth1:
Clause 33 PSE Admin State: enabled
Clause 33 PSE Power Detection Status: delivering power
Clause 33 PSE Available Power Limit: 18000

调整功率限制（如果需要）:
- 有时，可用的功率限制可能不足以满足链路伙伴的需求。您可以根据需要增加功率限制。
- 命令：ethtool --set-pse <interface> c33-pse-avail-pw-limit <limit>
  
  示例
```
ethtool --set-pse eth1 c33-pse-avail-pw-limit 18000
ethtool --show-pse eth1
```
  调整功率限制后的预期输出
```
Clause 33 PSE Available Power Limit: 18000
```
后续步骤:
- 未使用 PoE 或 PoDL：如果系统上未实现或使用 PoE 或 PoDL，则继续下一步诊断，因为供电与此设置无关。
- PoE 或 PoDL 由外部控制：如果使用 PoE 或 PoDL，但不是由 Linux 内核的 PSE-PD 框架管理（即，它由专有的用户空间软件或外部工具控制），则本文档不在此范围内。请查阅供应商特定的文档或外部工具以监控和管理供电。
- PSE 管理状态已禁用:
  - 如果 PSE Admin State: 为禁用，请运行以下命令之一将其启用
    ethtool --set-pse <devname> podl-pse-admin-control enable
    或者，对于第 33 条 PSE (PoE)
    
    ethtool --set-pse <devname> c33-pse-admin-control enable
  - 启用 PSE 管理状态后，返回到检查供电（PoDL 或 PoE）步骤的开头，以重新检查供电状态。
- 未供电：如果 Power Detection Status 显示“正在供电”以外的内容（例如，过流），请对 PSE 进行故障排除。检查潜在问题，例如电缆中的短路、供电不足或 PSE 本身的故障。
- 已供电但无链路：如果已供电但未建立链路，请继续进行进一步诊断，执行电缆诊断或查看检查链路状态和 PHY 配置步骤，以识别物理链路或设置的任何潜在问题。

电缆诊断¶

使用 ethtool 测试物理层问题，例如电缆故障。测试结果可能因电缆状况、所用技术和链路伙伴的状态而异。电缆测试的结果将有助于诊断诸如开路、短路、阻抗不匹配和噪声相关问题。

命令： ethtool --cable-test <接口>

以下是单对以太网 (SPE) 和多对以太网 (MPE) 的典型输出

对于单对以太网 (SPE)：- 预期输出 (SPE)
```
Cable test completed for device eth1.
Pair A, fault length: 25.00m
Pair A code Open Circuit
```
这表示在报告的距离处存在开路或电缆故障，但结果可能受链路伙伴状态的影响。有关这些结果的进一步解释，请参阅“基于电缆测试结果的故障排除”部分。
对于多对以太网 (MPE)：- 预期输出 (MPE)
```
Cable test completed for device eth0.
Pair A code OK
Pair B code OK
Pair C code Open Circuit
```
在此，报告配对 C 出现开路，而配对 A 和 B 工作正常。但是，如果在配对 A 和 B 上使用自动协商，则电缆测试可能会中断。有关这些问题的详细解释以及如何解决这些问题，请参阅“基于电缆测试结果的故障排除”部分。

有关不同可能电缆测试结果的详细说明，请参阅“基于电缆测试结果的故障排除”部分。

基于电缆测试结果的故障排除¶

运行电缆测试后，结果可以帮助识别物理连接中的特定问题。但是，请务必注意，电缆测试结果在很大程度上取决于本地硬件和链路伙伴的功能和特性。不同硬件实现之间的结果准确性和可靠性可能差异很大。

在某些情况下，这可能会在当前电缆测试实现中引入盲点，其中某些结果可能无法准确反映电缆的实际物理状态。例如

开路结果可能不仅表示电缆损坏或断开，如果电缆正确连接到断电的链路伙伴，也可能出现此结果。
如果链路伙伴处于强制从模式，某些 PHY 可能会报告配对内短路，即使电缆中没有实际短路。

为了帮助用户更有效地解释结果，扩展 kernel UAPI（用户 API）以根据硬件特性提供额外的上下文或问题的可能变体可能会很有益处。由于这些怪癖通常是硬件特定的，因此内核驱动程序将是此类信息的理想来源。通过为每个测试结果提供与潜在的误报相关的标志或提示，用户将更好地了解要验证的内容以及进一步调查的位置。

在进行此类改进之前，用户应注意这些限制，并根据需要手动验证电缆问题。物理检查可能有助于解决与误报结果相关的不确定性。

结果可以是以下之一

正常:
- 电缆功能正常，未检测到任何问题。
- 下一步：如果您仍然遇到问题，则可能与更高层的问题有关，例如双工不匹配或速度协商，这些都不是物理层问题。
- `BaseT1` (1000/100/10BaseT1) 的特殊情况：在 BaseT1 系统中，“正常”结果通常也意味着链路已启动，并且可能处于从模式，因为电缆测试通常仅在此模式下通过。对于某些 10BaseT1L PHY，即使电缆对于 PHY 的配置范围来说太长（例如，当范围配置为短距离模式时），也可能出现“正常”结果。
开路:
- 开路结果通常表示电缆在报告的故障长度处损坏或断开。考虑以下可能性
  - 如果链路伙伴处于 admin down 状态或已关闭电源，即使电缆功能正常，您仍然可能会获得“开路”结果。
  - 下一步：检查故障长度处的电缆是否有可见的损坏或松动的连接。验证链路伙伴是否已打开电源并处于正确的模式。
配对内短路:
- 配对内短路表示同一对导线内存在意外连接，通常是由电缆的物理损坏引起的。
  - 下一步：更换或维修电缆，并检查是否有任何物理损坏或压接不正确的连接器。
与其他配对短路:
- 与其他配对短路表示来自不同配对的导线短路，这可能是由于物理损坏或接线错误引起的。
  - 下一步：更换或维修损坏的电缆。检查电缆是否有不正确的端接或夹住的导线。
阻抗不匹配:
- 阻抗不匹配表示由电缆中的阻抗不连续引起的反射。当电缆的一部分具有异常阻抗时（例如，当不同类型的电缆拼接在一起或电缆存在缺陷时），可能会发生这种情况。
  - 下一步：检查电缆质量，并确保其整个长度的阻抗一致。更换任何不符合规范的电缆段。
噪声:
- 噪声表示由于电缆上存在过多的噪声，时域反射仪 (TDR) 测试无法完成，这可能是由电磁源的干扰引起的。
  - 下一步：识别并消除电缆附近电磁干扰 (EMI) 的来源。考虑使用屏蔽电缆或将电缆改道远离噪声源。
无法解决:
- 无法解决表示由于测试的分辨率限制或故障超出测试可以测量的距离，TDR 测试无法检测到问题。
  - 下一步：如果可能，手动检查电缆，或使用可以处理更大距离或更高分辨率的替代诊断工具。
未知:
- 当测试无法对故障进行分类或特定问题超出工具的检测能力范围时，可能会出现未知结果。
  - 下一步：重新运行测试，验证链路伙伴的状态，并在必要时手动检查电缆。

验证链路伙伴 PHY 配置¶

如果电缆测试通过，但链路仍然无法正常工作，则必须验证链路伙伴 PHY 的配置。速度、双工设置或主从角色的不匹配可能会导致连接问题。

自动协商不匹配¶

如果两个链路伙伴都支持自动协商，请确保在双方都启用了自动协商，并且通告了所有支持的链路模式。不匹配可能会导致连接问题或性能不佳。
快速修复： 将自动协商重置为默认设置，这将通告所有默认链路模式
```
ethtool -s <interface> autoneg on
```
检查配置的命令： ethtool <接口>
预期输出： 确保双方都通告兼容的链路模式。如果自动协商已关闭，请验证两个链路伙伴是否都配置为相同的速度和双工。

以下示例显示了本地 PHY 通告的链路模式少于其支持的链路模式的情况。这将减少与链路伙伴重叠的链路模式的数量。在最坏的情况下，将没有共同的链路模式，并且不会创建链路
```
Settings for eth0:
   Supported link modes:  1000baseT/Full, 100baseT/Full
   Advertised link modes: 1000baseT/Full
   Speed: 1000Mb/s
   Duplex: Full
   Auto-negotiation: on
```

组合模式不匹配（一侧为自动协商，另一侧为强制模式）¶

当一侧使用自动协商（如在大多数现代系统中）时，另一个可能的问题就会发生，而另一侧设置为强制链路模式（例如，具有单速集线器的旧硬件）。在这种情况下，现代 PHY 将尝试检测另一侧的强制模式。如果建立了链路，您可能会注意到
- 没有或为空的“链路伙伴通告的链路模式”.
- “链路伙伴通告的自动协商：”将为“否”或不存在。
这种类型的检测并不总是可靠地工作
- 通常，现代 PHY 将默认为半双工，即使链路伙伴实际上配置为全双工。
- 如果链路伙伴从一种强制模式切换到另一种强制模式，某些 PHY 可能无法可靠地工作。在这种情况下，只有断开/重新连接才能有所帮助。
下一步：将双方都设置为相同的固定速度和双工模式，以避免潜在的检测问题。
```
ethtool -s <interface> speed 1000 duplex full autoneg off
```

主/从角色不匹配（BaseT1 和 1000BaseT PHY）¶

在 BaseT1 系统（例如，1000BaseT1、100BaseT1）中，链路建立要求将一个设备配置为主设备，将另一个设备配置为从设备。此主从配置中的不匹配可能会阻止链路建立。但是，1000BaseT 也支持可配置的主/从角色，并且可能面临类似的问题。
1000BaseT 中的角色偏好：1000BaseT 规范允许链路伙伴在自动协商期间协商主从角色或角色偏好。某些 PHY 具有硬件限制或错误，阻止它们在某些角色中正常工作。在这种情况下，驱动程序可能会强制这些 PHY 进入特定角色（例如，强制主设备或强制从设备），或者尝试通过设置偏好来使用较弱的选项。如果两个链路伙伴都存在相同的问题并被强制进入同一模式（例如，都被强制进入主模式），则它们将无法建立链路。
下一步：确保将一侧配置为主设备，将另一侧配置为从设备，以避免此问题，尤其是在涉及硬件限制时，或尝试使用较弱的首选选项而不是强制。检查是否有任何驱动程序相关的限制或强制模式。

强制主/从模式的命令:

ethtool -s <interface> master-slave forced-master

或

ethtool -s <interface> master-slave forced-master speed 1000 duplex full autoneg off

检查当前主/从状态:

ethtool <interface>

示例输出

master-slave cfg: forced-master
master-slave status: master

硬件错误和驱动程序强制：如果已知的硬件问题强制 PHY 进入特定模式，则必须检查驱动程序源代码或硬件文档以获取详细信息。确保两个链路伙伴的角色兼容，如果两个 PHY 都被强制进入同一模式，请相应地调整一侧以解决不匹配问题。

监控链路重置和速度下降¶

如果链路不稳定，频繁出现重置或速度下降，这可能表明电缆、PHY 配置或环境因素存在问题。虽然在 Linux 中还没有完全统一的方法通过用户空间工具直接监控降速事件或链路速度变化，但 Linux 内核日志和 ethtool 都可以提供有价值的见解，特别是当驱动程序支持报告此类事件时。

监控内核日志中的链路重置和速度下降:
- Linux 内核将在系统日志中打印链路状态变化，包括降速事件。这些消息通常包括速度变化、双工模式和降速后的链路速度（如果驱动程序支持）。
- 实时监控内核日志的命令
```
dmesg -w | grep "Link is Up\|Link is Down"
```
- 示例输出（如果发生降速）
```
eth0: Link is Up - 100Mbps/Full (downshifted) - flow control rx/tx
eth0: Link is Down
```
  这表明链路已建立，但已从更高的速度降速。
- 注意：并非所有驱动程序或 PHY 都支持降速报告，因此您可能不会看到所有设备的信息。
使用 `ethtool` 监控链路断开事件:
- 从最新的内核和 ethtool 版本开始，您可以使用 ethtool -I 命令跟踪 链路断开事件。这将提供链路断开的计数器，如果驱动程序支持，这有助于诊断链路不稳定问题。
- 监控链路断开事件的命令
```
ethtool -I <interface>
```
- 示例输出（如果支持）
```
PSE attributes for eth1:
Link Down Events: 5
```
  这表明链路已断开 5 次。频繁的链路断开事件可能表明电缆或环境问题，需要进一步调查。
检查链路状态和速度:
- 即使无法轻松跟踪降速计数或事件，您仍然可以使用 ethtool 手动检查当前链路速度和状态。
- 命令： ethtool <接口>
- 预期输出
```
Speed: 1000Mb/s
Duplex: Full
Auto-negotiation: on
Link detected: yes
```
  预期速度或双工设置的任何不一致都可能表明存在问题。
禁用节能以太网 (EEE) 进行诊断:
- EEE（节能以太网）可能是链路不稳定的根源，因为它在低功耗状态之间切换。为了诊断目的，临时禁用 EEE 可能有助于确定它是否导致链路不稳定。这不是禁用电源管理的通用建议。
- 后续步骤：禁用 EEE 并监控链路是否变得稳定。如果禁用 EEE 解决了问题，请报告该错误以便修复驱动程序。
- 命令
```
ethtool --set-eee <interface> eee off
```
- 重要：如果禁用 EEE 解决了不稳定问题，则应将问题报告给维护人员作为错误，并应更正驱动程序以正确处理 EEE，而不会导致不稳定。永久禁用 EEE 不应被视为解决方案。
监控错误计数器:
- 虽然一些 NIC 驱动程序和 PHY 提供错误计数器，但并非所有硬件都有一组统一的特定于 PHY 的计数器。此外，并非所有 PHY 都提供有关错误（如 CRC 错误、帧丢失或链路抖动）的有用信息。因此，此步骤取决于特定的硬件和驱动程序支持。
- 后续步骤：使用 ethtool -S <接口> 检查您的驱动程序是否提供有用的错误计数器。在某些情况下，计数器可能会提供有关错误的信息，例如链路抖动或物理层问题（例如，过多的 CRC 错误），但结果可能会因 PHY 的不同而有很大差异。
- 命令： ethtool -S <接口>
- 示例输出（如果支持）:
```
rx_crc_errors: 123
tx_errors: 45
rx_frame_errors: 78
```
- 注意：如果没有可用的有意义的错误计数器或不支持计数器，您可能需要依赖物理检查（例如，电缆状况）或内核日志消息（例如，链路启动/断开事件）来进一步诊断问题。

当一切都失败时...¶

因此，您检查了电缆，监控了日志，禁用了 EEE，但仍然...什么都没有？别担心，你不是一个人。有时，以太网小精灵就是不想合作。

但在你放弃（或放弃以太网电缆）之前，深呼吸一下。总是有可能：

你的 PHY 有一个独特的、未记录的个性。
问题处于休眠状态，等待合适的时机神奇地自行解决（嘿，这种情况会发生！）。
或者，可能是最终解决方案尚未发明。

如果以上任何一项都不能让你感到安慰，那么还有最后一步：贡献！如果您发现了新的或不寻常的问题，或者有创造性的诊断方法，请随时分享您的发现并扩展本文档。我们可以一起追踪每一个难以捉摸的网络问题 - 一根双绞线一次。

记住：有时解决方案只需重启一下，但如果没有，就该深入挖掘 - 或报告该错误！

Linux 内核

目录

本页