用于调查 OSI 第 1 层双绞线以太网变体的诊断概念¶
引言¶
本文档主要面向两类受众
用户和系统管理员:对于处理实际以太网问题的用户,本指南提供了一个实用的、循序渐进的故障排除流程,以帮助识别和解决 OSI 第 1 层双绞线以太网中的常见问题。如果您遇到链接不稳定、速度下降或神秘的网络问题,请直接跳到循序渐进的指南,并按照它找到您的解决方案。
内核开发者:对于从事网络驱动程序和 PHY 支持的开发者,本文档概述了诊断过程,并强调了 Linux 内核诊断接口可以扩展或改进的领域。通过理解诊断流程,开发者可以更好地优先考虑未来的增强功能。
Linux 循序渐进诊断指南(通用以太网)¶
本诊断指南涵盖了常见的以太网故障排除场景,重点关注不同以太网环境下的链接稳定性和检测,包括单对以太网 (SPE) 和多对以太网 (MPE),以及 PoDL(数据线供电)和 PoE(Clause 33 PSE)等供电技术。
本指南旨在帮助用户诊断运行 Linux 内核版本 6.11 或更高版本的系统上的物理层(第 1 层)问题,需要使用 ethtool 6.10 或更高版本和 iproute2 6.4.0 或更高版本。
在本指南中,我们假设用户可能无法访问或有限访问链接伙伴,并将重点放在本地诊断问题。
诊断场景¶
链接已建立且稳定,但无数据传输:如果链接稳定但存在数据传输问题,请参考OSI 第 2 层故障排除指南。
链接不稳定:链接重置、速度下降或其他波动表明硬件或物理层可能存在问题。
未检测到链接:接口已启动,但未建立链接。
验证接口状态¶
首先验证以太网接口的状态,以检查它是否在管理上已启动 (administratively up)。与提供链接和 PHY 状态信息的 ethtool 不同,它不显示接口的管理状态。要检查此项,您应该使用 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”,则表示未检测到物理链接,表明可能存在第 1 层问题,例如电缆故障、配置错误或链接伙伴端没有连接。在这种情况下,请继续阅读检查链接状态和 PHY 配置部分。
管理 DOWN 状态:
如果输出缺少 “UP” 并且仅显示诸如 “<BROADCAST,MULTICAST>” 之类的状态,则表示接口在管理上已关闭 (administratively down)。在这种情况下,使用以下命令启动接口
ip link set dev <interface> up
后续步骤:
如果接口在管理上已启动但显示 NO-CARRIER,请继续阅读检查链接状态和 PHY 配置部分以排除潜在的物理层问题。
如果接口在管理上已关闭且您已将其启动,请务必重复此验证步骤以在继续之前确认接口的新状态
如果接口已启动并检测到链接:
如果输出显示 “UP” 并且没有 `NO-CARRIER`,则表示接口在管理上已启动,并且物理链接已成功建立。如果一切正常,则第 1 层诊断已完成,无需进一步操作。
如果接口已启动并检测到链接但没有数据正在传输,则问题可能超出第 1 层,您应该继续诊断 OSI 模型的更高层。这可能涉及检查第 2 层配置(例如 VLAN 或 MAC 地址问题)、第 3 层设置(例如 IP 地址、路由或 ARP)或第 4 层及以上(防火墙、服务等)。
如果链接不稳定或频繁重置或掉线,这可能表明存在物理层问题,例如电缆故障、干扰或供电问题。在这种情况下,请继续本指南的下一步。
检查链接状态和 PHY 配置¶
使用 ethtool -I 检查链接状态、PHY 配置、支持的链接模式以及其他统计信息,例如链接断开事件计数器。此步骤对于诊断第 1 层问题至关重要,例如速度不匹配、双工问题和链接不稳定。
对于单对以太网 (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(Clause 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
或者,对于 Clause 33 PSE (PoE)
ethtool --set-pse <devname> c33-pse-admin-control enable
启用 PSE 管理状态后,返回检查供电(PoDL 或 PoE)步骤的开头,重新检查供电状态。
未供电:如果 Power Detection Status 显示“delivering power”以外的内容(例如 over current),请对 PSE 进行故障排除。检查潜在问题,例如电缆短路、供电不足或 PSE 本身故障。
已供电但无链接:如果已供电但未建立链接,请通过执行电缆诊断或查看检查链接状态和 PHY 配置步骤进行进一步诊断,以识别物理链接或设置中的任何潜在问题。
电缆诊断¶
使用 ethtool 测试物理层问题,例如电缆故障。测试结果会根据电缆状况、所用技术和链接伙伴的状态而异。电缆测试结果将有助于诊断开路、短路、阻抗不匹配和噪声相关问题。
命令: ethtool --cable-test <interface>
以下是单对以太网 (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 可能会报告对内短路,即使电缆中没有实际短路。
为了帮助用户更有效地解释结果,扩展内核 UAPI(用户 API)以根据硬件特性提供额外的上下文或可能的问题变体可能会很有益。由于这些特性通常是硬件特定的,因此内核驱动程序将是此类信息的理想来源。通过为每个测试结果提供与潜在误报相关的标志或提示,用户将更好地理解需要验证什么以及需要进一步调查哪里。
在进行此类改进之前,用户应了解这些限制并根据需要手动验证电缆问题。物理检查可能有助于解决与误报结果相关的不确定性。
结果可能是以下之一:
OK:
电缆功能正常,未检测到任何问题。
后续步骤:如果您仍然遇到问题,则可能与高层问题有关,例如双工不匹配或速度协商,这些都不是物理层问题。
`BaseT1` 的特殊情况 (1000/100/10BaseT1):在 BaseT1 系统中,“OK”结果通常也意味着链接已建立并且可能处于从属模式,因为电缆测试通常仅在此模式下通过。对于某些 10BaseT1L PHY,即使电缆超出 PHY 配置的范围(例如,当范围配置为短距离模式时),也可能出现“OK”结果。
开路:
开路结果通常表示电缆在报告的故障长度处损坏或断开。请考虑以下可能性:
如果链接伙伴处于管理关闭状态或已断电,即使电缆功能正常,您也可能仍然获得“开路”结果。
后续步骤:检查故障长度处的电缆是否有可见损坏或松动连接。验证链接伙伴是否已通电并处于正确模式。
对内短路:
对内短路表示同一对线内存在意外连接,通常由电缆的物理损坏引起。
后续步骤:更换或修复电缆,并检查是否有任何物理损坏或压接不当的连接器。
对间短路:
对间短路表示不同对的电线短路,这可能是由于物理损坏或接线错误造成的。
后续步骤:更换或修复损坏的电缆。检查电缆是否存在不正确的端接或压接。
阻抗不匹配:
阻抗不匹配表示由电缆中的阻抗不连续性引起的反射。这可能发生在电缆的某个部分具有异常阻抗时(例如,当不同类型的电缆拼接在一起或电缆存在缺陷时)。
后续步骤:检查电缆质量并确保其长度范围内的阻抗一致。更换任何不符合规范的电缆部分。
噪声:
噪声意味着时域反射仪 (TDR) 测试因电缆上的过度噪声而无法完成,这可能是由电磁源干扰引起的。
后续步骤:识别并消除电缆附近的电磁干扰 (EMI) 源。考虑使用屏蔽电缆或将电缆重新布线远离噪声源。
无法解析:
无法解析意味着 TDR 测试由于测试的分辨率限制或故障超出测试可测量距离而无法检测到问题。
后续步骤:如果可能,手动检查电缆,或使用可以处理更长距离或更高分辨率的替代诊断工具。
未知:
当测试无法分类故障或特定问题超出工具的检测能力范围时,可能会出现未知结果。
后续步骤:重新运行测试,验证链接伙伴的状态,并在必要时手动检查电缆。
验证链接伙伴 PHY 配置¶
如果电缆测试通过但链接仍然无法正常工作,则必须验证链接伙伴 PHY 的配置。速度、双工设置或主从角色不匹配可能导致连接问题。
自动协商不匹配¶
如果两个链接伙伴都支持自动协商,请确保双方都启用了自动协商,并且通告了所有支持的链接模式。不匹配可能导致连接问题或次优性能。
快速修复: 将自动协商重置为默认设置,这将通告所有默认链接模式
ethtool -s <interface> autoneg on
检查配置的命令: ethtool <interface>
预期输出: 确保双方都通告兼容的链接模式。如果自动协商已关闭,请验证两个链接伙伴是否配置为相同的速度和双工。
以下示例显示了本地 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 <interface>
预期输出
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 视为解决方案。
监控错误计数器:
如果驱动程序支持统一接口,请使用 ethtool -S <interface> --all-groups 检索标准化接口统计信息:
命令: ethtool -S <interface> --all-groups
示例输出(如果支持):
phydev-RxFrames: 100391 phydev-RxErrors: 0 phydev-TxFrames: 9 phydev-TxErrors: 0
如果不支持统一接口,请使用 ethtool -S <interface> 检索 MAC 和 PHY 计数器。请注意,非标准化的 PHY 计数器名称因驱动程序而异,必须据此解释:
命令: ethtool -S <interface>
示例输出(如果支持):
rx_crc_errors: 123 tx_errors: 45 rx_frame_errors: 78
注意:如果无法获取有意义的错误计数器或不支持计数器,您可能需要依靠物理检查(例如,电缆状况)或内核日志消息(例如,链接向上/向下事件)来进一步诊断问题。
比较计数器:
比较 PHY 和 MAC 报告的出站和入站帧计数。
MAC 和 PHY 驱动程序之间采样率差异,或者 PHY 和 MAC 在其 UP 或 DOWN 状态下并非总是完全同步,都可能导致微小差异。
显著差异表明 MAC 和 PHY 之间的数据路径可能存在问题。
当一切都失败时...¶
所以您已经检查了电缆,监控了日志,禁用了 EEE,但仍然……一无所获?别担心,您并不孤单。有时候,以太网小鬼就是不肯合作。
但在您放弃(或扔掉以太网线)之前,深吸一口气。总有可能:
您的 PHY 具有独特、未文档化的特性。
问题处于休眠状态,等待合适的时机奇迹般地自行解决(嘿,这确实会发生!)。
或者,最终的解决方案可能尚未发明。
如果以上都未能让您感到安慰,那么还有最后一步:贡献您的力量!如果您发现了新的或不寻常的问题,或者有创新的诊断方法,请随时分享您的发现并扩展本文档。共同努力,我们可以逐一追查每个难以捉摸的网络问题——一次解决一根双绞线。
请记住:有时解决方案只是重启一下,但如果不是,那就该深入挖掘——或者报告那个错误!