【実務・中級編】イーサネットにおけるエラー検出機構とFCS（Frame Check Sequence） – インフラ・物理＆L2/L3ネットワーク基礎実践ガイド

イーサネットの守護神「FCS」：パケットの正しさを担保する沈黙の番人

ネットワークエンジニアとして現場に立つと、「通信が遅い」「一部のパケットが欠落する」という、いわゆる「ネットワークの霧」に迷い込むことがよくあります。アプリケーション層でどれだけ美しいWeb APIを設計しても、その土台であるイーサネットフレームが物理層のノイズで破壊されていれば、すべては砂上の楼閣です。

今回は、エンジニアなら知っておくべき「FCS（Frame Check Sequence）」という、イーサネットフレーム末尾に潜む4バイトの守護神について、その実体とデバッグの極意を紐解いていきましょう。

1. FCSとは何か：32ビットの「嘘を見抜く眼」

イーサネットフレーム（IEEE 802.3）の末尾には、必ず4バイトのフィールドが存在します。これが FCS です。

FCSは、送信側のNIC（ネットワーク・インターフェース・カード）が計算した「巡回冗長検査（CRC）」の値を格納しています。仕組みはシンプルですが、極めて強力です。
1. 送信側：フレームのデータ部分に対して多項式除算を行い、その「余り」をFCSとして付与する。
2. 受信側：受信したデータから再度計算を行い、届いたFCSと比較する。
3. 一致しなければ？：そのフレームはハードウェアレベルで即座に破棄される。

ここが重要です。OSやアプリケーションに届く前に、不正なパケットはスイッチやNICのゲートで「なかったこと」にされるのです。つまり、皆さんが curl や Fetch API でタイムアウトを経験している裏側で、ネットワーク機器は血の滲むようなチェックを毎秒何億回と繰り返しているわけです。

2. 実務で遭遇する「FCSエラー」の正体

実務において FCS Error や CRC Error がカウンタにカウントされ始めたら、それはネットワーク機器からの「助けてくれ、物理層が悲鳴を上げている」というサインです。

主な原因は以下の通りです。

物理的な劣化: 劣化したLANケーブル、不適切な曲げによる減衰。
電気的ノイズ: 近くを通る高圧ケーブルからの電磁干渉（EMI）。
コネクタの接触不良: SFPモジュールと光ファイバーの接続不良。
デュプレックス・ミスマッチ: 片側が全二重、片側が半二重でコリジョンが多発しているケース。

デバッグの第一歩：CLIでの確認

シスコやジュニパーのスイッチを触る際、まずはインターフェースの統計情報を確認しましょう。

# Cisco IOSでの確認コマンド
# FCSやCRCのエラーがカウントされていないかチェックする
show interfaces GigabitEthernet 0/1 | include CRC

もしここで CRC や Input errors が増え続けているなら、それはパケットロスの主犯です。いくら HTTP 5xx をアプリケーションでハンドリングしても、物理層が壊れていれば解決策になりません。

3. アプリケーション層から見た「パケットのゆらぎ」

Web APIエンジニアにとって、FCSエラーは「予測不能なレイテンシ」や「TCP再送の増加」として現れます。Pythonで簡易的にパケットの到達を確認する際、あまりにエラーが多いとTCPのハンドシェイクがタイムアウトすることも珍しくありません。

以下は、ネットワークの不安定さを調査するための簡易的な監視スクリプトの例です。

import subprocess
import time

def check_network_latency(target_ip="8.8.8.8"):
    """
    pingを使用してパケット損失の有無を簡易チェック
    物理層のFCSエラーが多発すると、ここでパケットロスが顕著になる
    """
    try:
        # pingを1回送信し、応答を待つ
        result = subprocess.run(
            ["ping", "-c", "1", "-W", "1", target_ip],
            capture_output=True,
            text=True
        )
        if result.returncode == 0:
            print(f"Success: {target_ip} is reachable.")
        else:
            print("Warning: Packet loss detected. Check physical layer or FCS counters.")
    except Exception as e:
        print(f"Error: {e}")

# 10秒おきにネットワークの状態を監視
while True:
    check_network_latency()
    time.sleep(10)

4. 最後に：エンジニアとしての心構え

FCSは、ネットワークという広大な海を航海するパケットたちが、「自分たちは壊れていないか」を常に確認し合うための羅針盤です。

もし皆さんの運用する環境で、原因不明のパケットロスに悩まされたら、まずは上位レイヤーのログを追う手を一度止め、スイッチの show interface や、ケーブルの物理的な取り回しを確認してみてください。「プロトコルは嘘をつかない」。これが、数々のトラブルを乗り越えてきた私の確信です。

次回の記事では、このFCSをすり抜けてしまった微小なエラーが、TCPのチェックサムでどう処理されるのか、あるいはどう検知不能になるのかについて深掘りしていこうと思います。インフラの深淵は、まだまだ奥が深いですよ。