FCTEL オリジナル技術記事 · FCTEL技術チーム
初公開：2026-10-07 · 最終更新：2026-10-07
産業用スイッチでリンクがアクティブと表示されていても、PLCで断続的にタイムアウトが発生することがあります。それだけで直ちに性能上の問題と判断することはできません。ケーブル、端末処理、トランシーバー回路によって受信ビットが変化することがある一方、輻輳によって、本来は正常なフレームが破棄されることもあります。CRCは計算方法であり、FCSはその結果を格納するEthernetフィールドです。受信経路における両者の位置付けを理解すると、エラーカウンターの意味が明確になり、あらゆる事象を「パケット損失」という同じ曖昧な説明で片付けずに済みます。本記事は一般的な仕組みを説明するものです。例示データはFCTELの試験データではありません。
詳細は元の画像を開いてご確認ください。横方向にスクロールすると、図中のラベルを原寸で読めます。
Ethernetフレームの末尾にFCSが付く理由
送信側MACは、宛先アドレス、送信元アドレス、タイプまたは長さ、データ、および必要なパディングを組み立てた後、4バイトのFCSを付加します。802.1Qタグが存在する場合は、それも保護対象のフレーム内容に含まれます。プリアンブルとフレーム開始デリミタは同期を支援しますが、このCRCの保護範囲には含まれません。フレーム間ギャップも保護対象データではありません。フレーム末尾にFCSを描くと、重要なタイミング上の制約が明確になります。つまり、受信側は検査フィールドを受信するまで、そのフレームのチェックを完了できません。
銅線は電気信号を、光ファイバーは光信号を伝送します。PHYはこれらの信号からビットを復元します。減衰、反射、クロストーク、トランシーバーの故障により、送信された0が1と解釈されることがあります。リンクUPは物理接続の確立を示しますが、すべてのフレームが正常であることを保証するものではありません。受信側MACは再計算を行い、完全性の検証関係をチェックします。このチェックに失敗したフレームは、信頼性のある受け渡しには適しません。
FCSと上位層のチェックは区別してください。これは現在のEthernetフレームを保護するものであり、TCP、UDP、またはアプリケーションの完全性確保の仕組みを置き換えるものではありません。スイッチがVLANタグなどの保護対象内容を変更した場合、送信時のFCSは送信内容と一致していなければなりません。したがって、ある受信ポートでチェックに成功しても、アプリケーションデータの経路全体が正常であることや、送信者が最初から正しい情報を生成したことの証明にはなりません。
CRCは通常の加算ではなく、シフトとXORを使用する
理解に役立つモデルでは、ビット列を二進多項式として扱い、指定された生成多項式を用いて法-2の演算を行います。加算と減算はXORとなり、通常の算術演算のような桁上がりはありません。ハードウェアでは、多くの場合、シフトレジスタとフィードバックXOR回路網を使って実装し、ソフトウェアですべてのバイトを処理するのではなく、ビットが到着するたびに状態を更新します。Ethernetは32ビットのCRCを使用します。送信側と受信側では、多項式、初期状態、ビット順序、最終処理規則が一致している必要があります。CRC32という名前の任意の実装に、自動的に互換性があるわけではありません。
説明上は、送信側がFCSを生成し、受信側が受信内容から結果を再計算して比較する形で示すと分かりやすくなります。実際の回路では、代わりにFCSを含むフレーム全体を処理し、規定の固定剰余になるかを検査することもできます。どちらの方法も同じ関係を検証します。CRCは多くの種類のビットエラーを検出しますが、訂正すべきビットを特定するものではなく、あらゆるエラーパターンの検出を保証するものでもありません。秘密鍵を含まず、暗号化、認証、改ざん耐性のある署名の代わりにはなりません。
詳細は元の画像を開いてご確認ください。横方向にスクロールすると、図中のラベルを原寸で読めます。
通常のパケットキャプチャに不正なフレームが現れない場合がある理由
一般的な受信経路は、インターフェース、PHY、MACの完全性チェック、スイッチングまたは受信バッファ、上位層処理の順に進みます。MACやNICがドライバーへ渡す前に不正なフレームを拒否すると、通常のキャプチャプログラムには、拒否されずに残ったトラフィックしか見えません。したがって、キャプチャにCRCエラーがないからといって、電気リンクに問題がないとは判断できません。また、多くのNICはFCSを除去するため、キャプチャされた長さと回線上のフレームの長さは一致しません。スイッチの受信カウンター、端末のNIC統計、キャプチャ記録を併せて保存してください。
ストアアンドフォワード動作では、フレーム全体を受信してからチェックし、転送を判断します。チェックに失敗した場合、通常は受信側で拒否されます。カットスルー動作では、末尾が到着する前にヘッダーの送信を開始する場合があるため、破損したフレームが後続のリンクに到達することがあります。処理方法とカウンターの動作は、チップセットとファームウェアによって異なります。「産業用スイッチ」という名称だけから転送方式を推測したり、複数の機器でエラーが発生したことを、複数の独立した故障の証拠と考えたりしないでください。実際のFCTELモデルについて、転送動作とカウンターの意味を確認してください。
詳細は元の画像を開いてご確認ください。横方向にスクロールすると、図中のラベルを原寸で読めます。
受信カウンターが示すのはリンク区間であり、原因となった機器ではない
PLC AがスイッチBに向けて送信し、Bの受信CRCカウンターが継続的に増加する場合、まずAからBまでの区間、すなわちAの送信部、パッチケーブル、配線接続部、Bの受信回路を調べます。Bは完全性チェックの失敗を報告していますが、そのカウンターだけで原因をAに帰することはできません。逆方向のトラフィックは別の受信経路を通るため、異なる挙動を示すことがあります。同様に、双方向の光ファイバー接続でも、ローカルTXからリモートRXと、リモートTXからローカルRXを個別に調べる必要があります。
稼働開始以来の累積値ではなく、同じ観測期間の差分を使用してください。ベースラインを保存し、一定時間待ってから、CRCの増分、受信フレーム数の増分、アプリケーションのタイムアウトを比較します。新たにエラーとなったフレームが10個という説明用の例は、製品仕様ではありません。入力エラーにはCRC、長さ、その他の原因が含まれる場合があり、破棄にはポリシーやリソースに基づく判断が含まれる場合があります。カウンターは必ずしも互いに独立していないため、無差別に加算しても有効な全体損失率は得られません。
カウンターをリセットした後は、異なるポートの差分が同じ観測期間に対応するよう、時刻と操作の記録を保存してください。
破損と輻輳を別々の仮説として検証する
複数の入力が低速な出力に集中し、キューに空きがなくなると、正常なフレームでも破棄されることがあります。ビットエラーが発生している必要はありません。CRCが変化しなくても、出力破棄やバッファ関連のカウンターが増加することがあります。逆に、低負荷時にCRCが増加する場合は、ケーブル、接点、インターフェース、干渉を調べる根拠が強まります。CRCがゼロでも、ネットワーク全体が健全である証明にはなりません。別のポートでエラーが発生している場合や、機器が関連する統計を提供していない場合があります。
まず、正常であることが確認済みのパッチケーブルを使用してください。一度に変更する部品は1つだけにし、トラフィックと観測期間をできるだけ比較可能な条件に保ちます。銅線では、ペア線の端末処理、接触状態、電力配線からの離隔を確認します。光ファイバーでは、端面の清浄度、TX/RXの方向、モジュールの互換性、および光パワーが実際の仕様に適合しているかを確認します。DDMパワーは補助的な証拠であり、フレームの完全性チェックの代わりにはなりません。1回の測定値だけでは、モジュールの故障は証明できません。必要に応じて保守時間帯を設け、条件を管理したトラフィックを両方向で比較してください。
タイムアウトは、アプリケーションタスクのブロック、機器の再起動、設定の誤りによっても発生することがあります。症状を記録したうえで、どの層を観測しているかを明確にしてください。リンクは確立しているか、フレームは正常か、キューはそれを受け入れるか、アプリケーションは時間内に応答するか、という順に確認します。アプリケーションログしか得られない場合は、診断の代わりにスイッチを交換するのではなく、原因を未確認のままとしてください。
別の技術者が再現できる受入検証記録を残す
FCTELが公開している、24個のギガビット電気ポートと4つのギガビットSFP光／電気オプションを備えたマネージドスイッチは、産業用の銅線および光ファイバー接続に関する資料を調べる際の関連する出発点です。本記事は、その製品について未公開のCRCコマンドやチップセット構成を約束するものではありません。導入されているファームウェアが、どの受信、送信、光関連の指標を提供するかを、リセット、桁あふれによる折り返し、クリアの動作も含めて確認してください。ベースラインを保存する前に、便宜上の理由で本番環境のカウンターを消去しないでください。
受入検証記録には、トポロジー、ポート番号、伝送媒体とモジュール、観測期間、負荷条件、前後のカウンター値、各交換作業、アプリケーションの復旧状況を含めてください。不正フレーム数の増加が止まることは伝送改善の証拠ですが、タイムアウト、遅延、連続性も確認する必要があります。パケットが決して失われないと約束するのではなく、試験した条件下で新たなエラーが発生しなかったと記載してください。仕組み、観測結果、結論を分けることで、調査の再現性が確保されます。
技術参考資料： CRC/FCSの仕組みに関するCiscoの資料。関連するFCTEL資料： 技術記事 および 産業用スイッチの製品資料.
