イーサネットフレームと CRC による誤り検出

誤り検出はなぜ必要か

伝送路では電気的ノイズ・クロストーク・減衰によってビットが反転します。1ビットでも化けたフレームを上位層に渡せば、誤ったデータがそのまま処理されてしまう。これを防ぐのがデータリンク層の 誤り検出（error detection） で、イーサネットでは末尾4バイトの FCS（Frame Check Sequence） がその役割を担います。FCSの中身は CRC-32（32ビット巡回冗長検査） で、単純なパリティやチェックサムよりはるかに強力な検出能力を、ハードウェアで安価に実現します。フレーム構造とスイッチングの全体像は /network/ethernet-switching-internals/ を、層構造の位置づけは /network/osi/ を参照してください。

フレーム構造とFCSの位置

L2で運ばれる1単位がフレームです。FCSが「何を対象に計算されるか」を正確に押さえます。

重要なのは、プリアンブルとSFDはCRCの計算対象に含まれない 点です。これらは受信側のクロック同期とフレーム開始位置の検出に使われる「枠外」の信号で、保護対象は宛先MACからペイロード末尾までです。FCSはその範囲を入力としたCRC-32の値を格納し、受信側は同じ範囲を再計算して照合します。

CRCの数理：GF(2)上の多項式除算

CRCの本質は 2を法とする多項式の除算（GF(2)上の除算） です。ビット列を多項式の係数とみなします。たとえばビット列 1101 は次の多項式に対応します。

1·x^3 + 1·x^2 + 0·x^1 + 1·x^0  =  x^3 + x^2 + 1

GF(2)では係数が0か1だけで、加算も減算も繰り上がりのない XOR になります（1+1=0）。CRC-32の手順は次の通りです。

1. 送信データの多項式を M(x) とする
2. M(x) を 32ビットぶん左シフト（x^32 を掛ける）= M(x)·x^32
3. それを生成多項式 G(x)（33ビット、最高次 x^32）でGF(2)除算
4. 余り R(x)（32ビット）がCRC値 = FCS
5. 送る列は M(x)·x^32 + R(x) … つまり末尾にFCSを付けた形

ポイントは、M(x)·x^32 + R(x) が G(x)で割り切れる（剰余0） ように設計されている点です。引き算がXORなので、M(x)·x^32 を割った余り R(x) を末尾に足すと、その合成多項式は必ずG(x)の倍数になります。受信側は受け取った列全体をG(x)で割り、余りが0なら誤りなし、0以外なら誤りあり と判定します。FCSを別に取り出して比較する必要すらありません。

イーサネットのCRC-32が使う生成多項式は次の固定値です（IEEE 802.3、最高次から並べた係数の指数）。

G(x) = x^32 + x^26 + x^23 + x^22 + x^16 + x^12 + x^11
       + x^10 + x^8 + x^7 + x^5 + x^4 + x^2 + x + 1
（32ビット表現で 0x04C11DB7。実装では反転表記 0xEDB88320 も使う）

実際の計算はビット単位のシフトとXORの繰り返しで、CPUを使わずとも論理回路（シフトレジスタ＋XORゲート）で1クロックずつ処理できます。これがCRCをハードウェアで高速・安価に実装できる理由です。

// 多項式除算（最上位ビットが1なら G とXOR）の骨子
remainder = 0
各ビット b について:
    remainder = (remainder << 1) | b
    if remainder の最上位(33ビット目)が 1:
        remainder = remainder XOR G
最終 remainder の下位32ビット = CRC

検出能力と限界

CRC-32がパリティより強いのは、どの誤りパターンを必ず検出できるか が数学的に保証されるからです。

最も実用的に効くのが バーストエラー耐性 です。ノイズは連続したビットをまとめて壊す傾向があり、CRC-32は 連続32ビット以下の誤りを100%検出 します。連続長がG(x)の次数（32）以下なら、誤りパターンを表す多項式の次数が32未満となり、33ビットのG(x)では割り切れないからです。33ビットを超えるバーストや無作為な多点誤りでは見逃しが起こりえますが、その確率は約 2^-32（およそ43億分の1）まで抑えられます。なお「CRCは奇数個の誤りを必ず検出する」という説明をよく見かけますが、これは生成多項式が (x + 1) を因数に持つ場合の話です。IEEE 802.3 の CRC-32（0x04C11DB7）は項数が15個（奇数）で (x + 1) を因数に持たないため、奇数個誤りの検出は保証されません。多くの16ビットCRCが (x + 1) を因数に含むのと対照的で、CRC-32の強みはむしろ実用フレーム長における大きなハミング距離とバースト耐性にあります。

壊れたフレームのたどる末路

受信時にFCS照合が失敗したフレームは破棄され、インターフェースの誤りカウンタが増えます。ここを読むと物理層の不調を切り分けられます。

スイッチの転送方式によってCRCを検証するタイミングが変わる点も実務上重要です。フレーム全体を受け切ってからFCSを検証する ストアアンドフォワード は壊れたフレームを次段に流しませんが、宛先MACだけ読んで即転送する カットスルー はFCS検証前に転送するため、誤りフレームを下流に拡散させえます。tcpdump などでフレームを観察する手法は /network/packet-capture/ を参照してください。

ジャンボフレームとCRCの関係

標準のイーサネットペイロード上限は1500バイトですが、これを超える ジャンボフレーム（一般に最大9000バイト前後のMTU）を使うと、1フレームで運べるデータが増え、フレーム数あたりのヘッダ・FCS・割り込み処理のオーバーヘッドが相対的に下がります。大容量転送やストレージ・仮想化のバックエンドで採用されます。MTUとフラグメンテーションの全体像は /network/mtu/ にあります。

まとめ

イーサネットのFCSは、宛先MACからペイロード末尾までをCRC-32で守る4バイトです。CRCの正体はGF(2)上の多項式除算で、送信側はデータを生成多項式で割った剰余を末尾に付け、受信側は同じ除算の剰余が0かどうかだけで誤りを判定します。XORシフトで構成できるため論理回路で高速に動き、32ビット以下のバーストと奇数個誤りを確実に捕えます。一方で訂正も改ざん検知もできず、ジャンボフレームでは長さに比例して見逃し機会が増える——この「強力だが検出専用」という性質を押さえれば、L2の誤り検出が回路の単純さと数学的保証の両立として読み解けます。