【実務・中級編】 イーサネットフレーム構造（DIX規格 / Ethernet II） – インフラ・物理＆L2/L3ネットワーク基礎実践ガイド

パケットの息遣いを感じろ！Ethernet II（DIX規格）フレーム構造の深淵と実務的解釈

こんにちは。ネットワークの配管工からキャリアをスタートさせ、数々のL2ループや謎のパケットロスという名の「魔物」と夜な夜な格闘してきたシニアインフラエンジニアです。

普段、Web APIの設計やモダンなクラウドインフラの構築に携わっているエンジニアの皆さんは、アプリケーション層の美しさに目を奪われがちです。「JSONのスキーマがどうこう」「RESTfulなエンドポイントの設計が〜」と議論しているその瞬間も、あなたの書いたリクエストは、すべて泥臭い物理世界、すなわちイーサネットフレームという極めてプリミティブなカプセル化の箱に詰め込まれて、光や電気のパルスとしてネットワークを駆け巡っています。

今回は、現代のLANおよびデータセンターネットワークの土台である Ethernet II（DIX規格）フレーム構造 に焦点を当て、その各フィールドが持つ意味、そして実務の現場でトラブルシューティングを行う際に、なぜこの構造を知っておく必要があるのかを、徹底的に解説していきましょう。

—

1. なぜ「Ethernet II」なのか？（歴史的背景と現代の立ち位置）

私たちが普段何気なく使っているIPパケットは、そのままではNIC（Network Interface Card）の上を流れることはできません。それを物理的な媒体に載せるための共通語がイーサネットです。

歴史を振り返ると、IEEE 802.3委員会が策定したオリジナルの規格と、DEC・インテル・ゼロックス（DIX）の3社が共同で策定した「Ethernet II（DIX規格）」の間には、フレームの識別方法を巡るちょっとした歴史的摩擦がありました。しかし、結果として「高速化と効率性」を求める潮流の中で、シンプルかつ高速に処理できるEthernet IIが勝ち残り、現在のインターネットや企業内LANのデファクトスタンダードとなりました。

現代のネットワークにおいて、私たちが目にするトラフィックのほぼ100%（IPv4、IPv6、ARP、さらにはVLANタグがついたIEEE 802.1Qフレームであっても）は、このEthernet IIの構造をベースに流れています。

—

2. Ethernet IIフレームの全体像とフィールド構造

それでは、パケットキャプチャツール（Wiresharkなど）を覗いたときに目にする、Ethernet IIフレームの全貌を解剖していきましょう。

フレームの全体像は、以下のようなバイト列の並びになっています。

+------------------+------------------+------------------+------------------+------------------+----------------+
| プリアンブル     | 宛先MACアドレス  | 送信元MACアドレス| タイプ（EtherType）| ペイロード       | FCS            |
| (7 Bytes)        | (6 Bytes)        | (6 Bytes)        | (2 Bytes)        | (46 - 1500 Bytes)| (4 Bytes)      |
+------------------+------------------+------------------+------------------+------------------+----------------+

総バイト数は最小で64バイト（プリアンブルとFCSを除く実データ部が46バイトの場合）、最大で1500バイト（MTUの制限内。ジャンボフレームの場合はこれを超える）となります。それぞれのフィールドを、現場の視点を交えて詳しく見ていきましょう。

① プリアンブル（Preamble）とSFD

  • サイズ: 7バイト（プリアンブル） + 1バイト（SFD: Start Frame Delimiter） = 計8バイト
  • 役割: 受信側のNICのクロックを送信側のクロックに同期させ、「これからパケットが来るぞ」という合図を送るためのビット列です。
  • 現場のTips: 通常、OSやアプリケーション層からは見えません。Wiresharkのパケット詳細でも省略されることが多いですが、ハードウェアレベルのパケットキャプチャ（SPANポートやタップ装置）を行うと必ず現れます。物理層の不整合（ケーブルの不良など）でパケットが破損する場合、このプリアンブルの段階で受信側が同期できず、CRCエラー（FCSエラー）としてドロップされます。

② 宛先MACアドレス（Destination MAC Address）

  • サイズ: 6バイト（48ビット）
  • 役割: フレームを受け取るべき相手のハードウェアアドレスです。ユニキャストだけでなく、すべての機器に宛てるブロードキャスト（FF:FF:FF:FF:FF:FF）や、特定のグループ宛てのマルチキャストアドレスが指定されます。
  • 現場のTips: L2スイッチはこのフィールドを見て、MACアドレステーブル（CAMテーブル）を参照し、どのポートにフレームを転送すべきかを判断します。「通信できない」というトラブルに遭遇した際、ARPテーブルやMACアドレステーブルの不整合を疑う原点がここにあります。

③ 送信元MACアドレス（Source MAC Address）

  • サイズ: 6バイト（48ビット）
  • 役割: このフレームを送り出したデバイスのMACアドレスです。
  • 現場のTips: 原則としてユニキャストアドレスが入ります。仮想化環境やコンテナ、クラウドのVPC内では、ハイパーバイザーや仮想スイッチ（OVSなど）がこのMACアドレスをスプーフィング（偽装）あるいは制御してトラフィックのルーティングを行っています。セキュリティ製品が「MACアドレスフラッディング攻撃」や「ARPスプーフィング」を検知する際も、このフィールドの挙動が監視されています。

④ タイプ / EtherType

  • サイズ: 2バイト（16ビット）
  • 役割: ペイロード（データ部）に格納されている上位プロトコルの種類を示します。
  • 0x0800: IPv4
  • 0x86DD: IPv6
  • 0x0806: ARP
  • 0x8100: IEEE 802.1Q（VLANタギング用。この場合はタイプフィールドが拡張されます）
  • 現場のTips: パケットアナライザで「何のプロトコルが流れているか」を瞬時に判別するための最重要マーカーです。もしここに未知の値や異常な値が入っている場合、それは不正なパケットか、あるいはジャンボフレームや独自プロトコルの通信である可能性があります。

⑤ ペイロード（Payload / Data）

  • サイズ: 46 ～ 1500バイト（標準的なイーサネットの場合）
  • 役割: 上位層のデータ（IPヘッダー＋トランスポート層＋アプリケーションデータ）がそのまま格納されます。イーサネットの最小フレームサイズ（64バイト）を満たすため、データが46バイト未満の場合は、パディング（意味のないパケ詰めのためのデータ）で埋められます。
  • 現場のTips: Web APIを叩く際、HTTPリクエストのペイロードが大きすぎると、L3層でIPフラグメンテーションが発生するか、あるいはL2層のMTU（Maximum Transmission Unit: 通常1500バイト）を超過して「Packet Too Big」やDF（Don’t Fragment）ビットによるドロップを引き起こします。これが、クラウド環境などでよく問題になる「MTUブラックホール問題」のL2的な原因です。

⑥ FCS（Frame Check Sequence）

  • サイズ: 4バイト（32ビット）
  • 役割: フレーム全体のデータエラーを検知するための巡回冗長検査（CRC: Cyclic Redundancy Check）の値が格納されます。
  • 現場のTips: 受信側のNICは、受け取ったフレームのデータから自分でCRCを計算し、FCSの値と一致するか検証します。もし一致しなければ、そのフレームは途中で破損したとみなされ、容赦なくサイレント破棄（Drop）されます。インフラのトラブルシューティングで、L2インターフェイスのエラーカウンター（Interface ErrorsやCRC Errors）が1秒間に何個も増加している場合、物理ケーブルの劣化、SFPモジュールの不具合、あるいはノイズの混入を疑うべき決定的な証拠となります。

—

3. 実務への応用：ネットワークスタックをPythonで覗き見る

「理屈は分かったけれど、実際のところアプリケーションエンジニアの自分にどう関係があるのか？」と思われるかもしれません。

例えば、Pythonを使って低水準のソケットプログラミング（Raw Socket）を行うと、OSがハンドリングする前の「生のイーサネットフレーム」を直接観察・構築することができます。以下のスクリプトは、Linux環境（root権限が必要）で、自分自身のインターフェイスから流れるEthernet IIフレームのヘッダーをダンプする簡単なコードです。

import socket
import struct
import sys

def analyze_ethernet_frame():
    # 生ソケット（Raw Socket）を作成し、すべてのEtherTypeのパケットをキャプチャする
    # 注意: Linux環境かつroot権限が必要です
    try:
        # ETH_P_ALL (0x0003) を指定してすべてのプロトコルをキャプチャ
        raw_socket = socket.socket(socket.AF_PACKET, socket.SOCK_RAW, socket.ntohs(0x0003))
    except PermissionError:
        print("エラー: このスクリプトを実行するにはroot権限（sudo）が必要です。", file=sys.stderr)
        sys.exit(1)

    print("イーサネットフレームのキャプチャを開始します... (Ctrl+Cで終了)")

    while True:
        # パケットを生データとして受信（最大65535バイト）
        packet, addr = raw_socket.recvfrom(65535)

        # 最初の14バイトがEthernet IIヘッダー
        # 宛先MAC(6) + 送信元MAC(6) + EtherType(2) = 14 Bytes
        eth_header = packet[:14]
        
        # structモジュールでバイナリデータをアンパック
        # '!6s6sH' -> ネットワークバイトオーダー(Big Endian): 6バイト文字列, 6s, 符号なし短整数(H)
        dest_mac, src_mac, eth_type = struct.unpack('!6s6sH', eth_header)

        # MACアドレスを人間が読みやすい16進数表記（XX:XX:XX:XX:XX:XX）に変換
        dest_mac_str = ':'.join(f'{b:02x}' for b in dest_mac)
        src_mac_str = ':'.join(f'{b:02x}' for b in src_mac)

        print(f"Dst MAC: {dest_mac_str} | Src MAC: {src_mac_str} | EtherType: 0x{eth_type:04x}")

if __name__ == "__main__":
    analyze_ethernet_frame()

このコードから得られる実務的視点

Web APIのバックエンドやマイクロサービスのコンテナ間通信において、もしパケットが意図した宛先に届かない場合、OSのルーティングテーブル（L3）やiptables（L4）を見る前に、そもそも「L2の宛先MACアドレスが正しくARP解決されているか」「正しいインターフェイスから送出されているか」というレイヤーで問題が起きていることがあります。このRaw Socketの発想を持つことで、インフラとアプリの境界線にあるトラブルの解像度が劇的に上がります。

—

4. トラブルシューティングの実践Tips

最後に、インフラ運用の現場でEthernet IIフレームやL2まわりの異常に直面した際、シニアエンジニアがどのような手順で原因を切り分けるのか、実践的なTipsを共有します。

1. インターフェイスのエラーカウンターをまず見る

  • Linuxなら ip -s link や netstat -i、Cisco等のルーター/スイッチなら show interfaces を実行します。
  • CRC/FCS Errors や Frame Errors がカウントアップされている場合、それは上位のTCPやHTTPの問題ではなく、物理層・L2層の物理的な障害（ケーブル、コネクタ、SFP、伝送距離オーバー）です。いくらアプリのコードを修正しても無駄足になります。

2. MTUのミスマッチ（ジャンボフレームの罠）に気を付ける

  • クラウド環境やコンテナネットワーク（Docker、KubernetesのCiliumやCalicoなど）において、VXLANやGeneveといったカプセル化（オーバーレイネットワーク）を使用すると、元のイーサネットフレームの外側にさらにヘッダーが付加されます。
  • これにより通常のMTU（1500バイト）を超過し、途中のルーターやスイッチでパケットがドロップする現象が起きます。TCPのMSSクランプ設定や、インターフェイスのMTUサイズ（例: 9000バイトや、オーバーレイを考慮した減算）が正しく設計されているか、フレーム構造のサイズ制限を意識して確認しましょう。

3. Wiresharkでのフィルター活用法

  • パケットキャプチャを取った際、無数のフレームから目的の通信を探すには、EtherTypeやMACアドレスでフィルタリングします。
  • 例: eth.type == 0x0800 （IPv4フレームのみ抽出）
  • 例: eth.addr == 00:11:22:33:44:55 （特定のMACアドレスが絡むフレームをすべて抽出）

—

まとめ

普段私たちが何気なく叩いている curl や Web API のリクエストは、すべてこの数バイト単位で厳密に定義された Ethernet II のフレーム構造という「封筒」に入れられ、秒速何ギガビットという世界で宛先へと運ばれています。

「動いているからいいや」ではなく、その下のレイヤーで何が起きているのかという「構造」を理解しているエンジニアこそが、不可解なネットワーク障害に直面したときにも、冷静かつ最短で真因に辿り着くことができます。

皆さんのインフラライフが、FCSエラーのないクリーンなパケットに満たされたものでありますように。

スポンサーリンク

コメント

タイトルとURLをコピーしました