ポートエラーや高いCPU使用率だけでは、ハードウェアの損傷は直ちに証明されません。何を計数しているのか、いつ発生したのか、計数値がどのように変化するのかを確認してください。そのうえで、受信した不正フレーム、キューやポリシーによって廃棄された正常なフレーム、CPUで処理される制御トラフィックを分けて扱います。原因が異なれば、必要な対策も異なります。汎用的なコマンドを一つ実行することや再起動することは、診断の代わりにはなりません。
1. カウンターが何を記録するかを理解する
Ethernetフレームは、ハードウェアアドレスと完全性チェック情報を含むデータ単位です。インターフェースでは、受信、送信、フレームチェックエラー、廃棄、レート、リンクの変化などが計数される場合があります。errorsフィールドは複数の下位分類を集計していることが多く、対象範囲は機種によって異なります。ポート、方向、単位、含まれる分類については、実際のマニュアルを参照してください。
累積総数が大きくても、現在進行中の障害があるとは限りません。観測期間、増減、同時点のトラフィックを記録し、正常時と異常時を比較します。再起動、カウンターのクリア、カウンターのロールオーバーによっても表示値は変化します。証拠を保存せずにクリアすると、断続的な問題の調査が難しくなる場合があります。
負荷がかかったときにエラーが増えることは、関連の可能性を示しますが、負荷が原因であるとは限りません。トラフィックの増加によってケーブルの問題が顕在化することもあります。端末のログ、インターフェースの状態、アプリケーションの応答を同じ時系列に並べてください。一枚のスクリーンショットを根拠にスイッチを交換するのではなく、再現可能な関連性を探します。
2. 入力リンク上のフレームチェック失敗を調査する
フレームチェックシーケンスであるFCSにより、受信側は検出可能な伝送エラーを確認できます。チェックの失敗は、不正なフレームを受信したことを示すものであり、出力キューが満杯であることの別名ではありません。ケーブル、コネクター、干渉、対向インターフェース、ネゴシエーションなどが関与する可能性があります。ほかの状態情報も使って可能性を絞り込んでください。
承認された保守時間帯に、正常動作が確認済みの短いジャンパーケーブルへの交換前後を比較し、両端の実際の速度とデュプレックスを確認します。その後、常設配線と端末処理を調査します。8本の導体に導通があっても、電気的な伝送性能が保証されるわけではありません。光ファイバーでは、銅線用の試験方法を適用するのではなく、モジュール、端面、送受信状態を確認してください。
3. デュプレックスとフレームサイズを状況に即して解釈する
全二重では両端が同時に送受信できます。一方、従来の半二重では伝送媒体を共有し、異なる仕組みを使用します。両端の設定が一致していないと、性能が低下する場合があります。片側を固定設定にし、もう片側に互換性のない設定を残すのではなく、まずメーカー推奨のオートネゴシエーションを使用してください。古いFast Ethernetの半二重に関する規則を、すべてGigabitインターフェースに適用しないでください。
インターフェースによっては、衝突、フラグメント、アンダーサイズフレーム、オーバーサイズフレームが報告されます。これらは診断の手掛かりであり、部品の損傷を一意に示すものではありません。タグ、許容される最大サイズ、カウンターの定義が、長さの解釈に影響します。古い解説記事にある数値を超えただけではNICの故障は証明されません。また、アライメントエラーは、バイト数が偶数でなければならないという任意の規則を意味するものではありません。
古い記事で引用されているコマンドやフィールドは、特定のプラットフォームに属するものです。FCTELの機種で同じ名称が公開されているとは限りません。現在の機種のWebインターフェース、CLI、管理ツールから同等の情報を探してください。目的は証拠を理解することであり、全ブランド共通のコマンドスクリプトを一つ作ることではありません。
4. 正常なフレームも廃棄される理由
複数の入力が一つの出力に集中すると、その出力が送信できる量を上回るフレームが一時的に到着する場合があります。フレームは容量に限りのあるバッファーで待機し、需要超過が続くと廃棄が発生することがあります。長い平均化期間では短時間のピークが見えなくなるため、平均使用率が低くても短いバーストがないとは言えません。
出力廃棄は、設定されたレート制限、キューポリシー、そのほかの実装固有の条件によっても発生する場合があります。カウンターの定義を確認してください。バッファーを大きくしても、出力容量を継続的に上回る需要は解消できず、遅延が増える場合もあります。単にケーブルを交換するのではなく、アップリンクの容量、送信スケジューリング、必要なトラフィック管理を評価してください。
損失に対する応答は、アプリケーションによって異なります。TCPは再送や送信動作の調整が可能です。UDP自体には同じ信頼性確保の仕組みはありませんが、それを使用するアプリケーションが独自の回復処理を実装することは可能です。UDPだからといって、すべてのアプリケーションに補完手段がないという意味ではありません。受入検証では、実際の応答とデータの完全性を確認する必要があります。
5. CPUの動作とハードウェア転送を分けて考える
多くの管理型スイッチは、通常の転送の大部分に専用のスイッチングチップを使用し、CPUが管理、制御プロトコル、一部のソフトウェア処理対象フレームを処理します。転送プレーンとコントロールプレーンは相互に作用しますが、端末のすべてのフレームが必ずCPUを通るわけではありません。アーキテクチャーは機種によって異なるため、絶対的な規則を設けるのではなく、実際の機種に即して解釈してください。
管理要求、プロトコルの変化、異常フレーム、ソフトウェアの問題によって、CPUの動作負荷が上がる場合があります。それにより管理やプロトコルの応答が影響を受けることはありますが、ハードウェア転送の障害が証明されるわけではありません。通常時の基準値、継続時間、プロセスまたはフレームの種類、アプリケーションへの影響の有無を確認してください。一時的にアプリケーションが正常に動作していても、持続する異常負荷を無視してよい理由にはなりません。
一部のプラットフォームにコントロールプレーン保護や例外統計があるからといって、FCTELにも同一のメニューがあるとは限りません。対応状況を確認せずに、第三者が示す制限値をそのまま適用したり、保護ルールを無効にしたりしないでください。不適切な変更は、必要な制御通信を妨げる可能性があります。本番環境での作業には、バックアップ、承認、復旧手段が必要です。
6. 文書で確認された製品機能を使って証拠を収集する
該当するFCTELのライトマネージドDINレール型産業用スイッチの製品ページには、ポートトラフィック統計、ミラーリング、ストーム制御が明記されています。統計は変化の観測に役立ち、ミラーリングは選択したトラフィックを分析用に複製し、抑制機能は設定された種類のトラフィックを制限します。いずれも物理層のエラーを修復するものではありません。ここでは、その製品ページで確認された機能のみを説明しています。
調達や診断の前に、必要なエラーの個別カウンター、時間分解能、ログを確認してください。ミラー出力やアナライザーが過負荷になると、複製されたフレームが失われる場合があるため、キャプチャー数が少ないことだけでは、アプリケーションでの損失は直接証明されません。内部CPUキュー、ハードウェアテーブル、保護機構については、より詳細な機種別ドキュメントやベンダーのサポートが必要です。概要から推測しないでください。
7. 各結論をその証拠と結び付ける
適切なジャンパーケーブルへの交換後に入力エラーの増加が止まり、トラフィックが回復した場合は、リンクに関連する証拠を記録します。正常なトラフィックのピークが出力廃棄に対応する場合は、容量とポリシーを調査します。アプリケーションは動作を続けているのに管理だけが遅い場合は、管理と転送を一つの原因として扱わず、別々に調査してください。
対処後は、アプリケーションの継続動作、通常のピーク時、承認済みの復旧ケースについて検証します。対処前後のカウンターと設定を保存してください。原因不明の持続的なエラー、再起動、ハードウェアアラームは、サプライヤーにエスカレーションします。どの結論が検証済みで、どれが仮説のままなのかを明記してください。そうすることで、次の保守担当者は「再起動したので現在は正常」という情報だけを引き継ぐのではなく、観測を再現できます。
参考資料：FCTEL製品の統計機能とミラーリング機能；インターフェースのエラーカウンターの定義;ネゴシエーションの仕組み;コントロールプレーンとCPUの診断。第三者のドキュメントは仕組みを裏付けるものであり、汎用的なFCTELコマンドを示すものではありません。図は一般的な模式図であり、製品写真や測定結果ではありません。
中国語の技術記事から翻訳。原文の初回公開日：2020-03-16。原文の最終改訂日時：2026-10-13T14:51:17+08:00。 中国語の原文を読む
