用於調查 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 具有獨特、未文件化的特性。
問題處於休眠狀態，等待合適的時機奇蹟般地自行解決（嘿，這確實會發生！）。
或者，最終的解決方案可能尚未發明。

如果以上都未能讓您感到安慰，那麼還有最後一步：貢獻您的力量！如果您發現了新的或不尋常的問題，或者有創新的診斷方法，請隨時分享您的發現並擴充套件本文件。共同努力，我們可以逐一追查每個難以捉摸的網路問題——一次解決一根雙絞線。

請記住：有時解決方案只是重啟一下，但如果不是，那就該深入挖掘——或者報告那個錯誤！

Linux 核心

目錄

本頁