L2の深淵を覗く：I/Gビットが支配するMACアドレスの「素性」とパケットの運命
ネットワークエンジニアとして数多のパケットキャプチャを眺めてきた者にとって、イーサネットフレームのヘッダーは単なる「配送伝票」ではない。そこには、スイッチングファブリックがどう動き、NICがどう割り込みを処理し、セキュリティがどこで防壁を築くかという、プロトコルの美学が凝縮されている。
特に、MACアドレスの先頭バイト、その最初のビットに隠された「I/Gビット（Individual/Group bit）」の扱いは、L2ネットワークの挙動を理解する上での踏み絵だ。今日は、このビットが引き起こすパケットの運命と、それがいかにして高負荷な環境のパフォーマンスやセキュリティに影響を及ぼすのか、その深層を紐解いていく。
—
1. I/Gビットの正体：パケットの「社会的地位」を決める1ビット
MACアドレスは48ビットの識別子だが、最初のバイト（OUIの先頭）の最下位ビット（LSB）がI/Gビットだ。
- I/Gビット = 0 (Individual): ユニキャスト。特定のNICへ向けられた「1対1」の通信。
- I/Gビット = 1 (Group): マルチキャストまたはブロードキャスト。グループへ向けて放たれる「1対多」の通信。
この1ビットが「0」か「1」かだけで、スイッチはASIC内部の転送ロジックを劇的に切り替える。ユニキャストであれば、MACアドレステーブル（CAMテーブル）をルックアップして特定のポートへ「ピンポイント転送（Unicast Forwarding）」を行うが、グループアドレスであれば「フラッディング」あるいは「マルチキャストグループ管理（IGMP Snooping）」の対象として処理される。
もしこのビットの判定ロジックが脆弱であれば、ネットワーク全体を巻き込む悲劇（ブロードキャストストームやDoS攻撃）に直結する。
—
2. 実践的パフォーマンス：RTT削減とカーネルの最適化
インフラアーキテクトとして意識すべきは、このL2の挙動が、実は上位層であるTCPハンドシェイクやRTT（Round Trip Time）にも影を落としている点だ。
例えば、頻繁にマルチキャストを利用する環境で、スイッチのIGMPスヌーピングが適切に設定されていないと、不必要なマルチキャストフレームが全ポートへフラッディングされる。これにより、エッジデバイスのNICはCPU割り込みが急増し、処理能力が枯渇する。結果、TCPのACK応答が遅延し、クライアント側のTCPスタックで再送タイマーが起動してRTTが跳ね上がる。
Linuxカーネルにおける受信パケット処理の最適化例
高負荷なL2環境において、不要なパケットの処理をNICドライバ層で可能な限り遮断するには、ethtoolを用いたハードウェアフィルタリングが有効だ。
# 特定のマルチキャスト通信が不要な場合、ハードウェアオフロードで破棄する設定例
# ソフトウェア割り込みまで到達させず、NICのチップセットレベルでドロップさせる
sudo ethtool -N <インターフェース名> flow-type ether dst 01:00:5e:00:00:01 m 00:00:00:00:00:00 action -1※ -1 はドロップを意味する。このレベルでL2の選別を行うことで、カーネルスタックのメモリコピーやコンテキストスイッチを最小化できる。
—
3. セキュリティの防壁：MACアドレスフィルタリングの死角
「MACアドレスで制御すれば安全」という幻想を抱いているなら、それは今すぐ捨てるべきだ。I/Gビットの仕様を悪用した攻撃は、セキュリティ専門家にとって古典的だが極めて強力な手法である。
攻撃者は、宛先MACアドレスにブロードキャスト（FF:FF:FF:FF:FF:FF）を指定し、かつ送信元MACアドレスを偽装することで、スイッチのCAMテーブルをフラッディング攻撃（CAM表溢れ）に追い込むことがある。CAM表が溢れると、スイッチは「Hub」として動作し、全てのポートに全パケットを転送し始める。これが「パケットスニッフィング」の入り口だ。
対策：ポートセキュリティによる「I/Gビット」の監視
現代のスイッチングファブリックでは、単なるMAC学習制限だけでなく、以下のポリシーを厳格に適用すべきである。
# Cisco IOSでのポートセキュリティ設定の指針
interface GigabitEthernet0/1
switchport port-security
# 学習できる最大MAC数を制限し、CAM表の枯渇を防止
switchport port-security maximum 2
# 不正なMACの動きを検知したら即座にポートを遮断（shutdown）
switchport port-security violation shutdown
# マルチキャストトラフィックのレート制限（ストーム制御）
storm-control multicast level 1.0—
4. アーキテクトへの問い：TLSハンドシェイクとL2の相関
最後に、上位層への影響について触れておこう。TLS 1.3のハンドシェイクでは「0-RTT」がサポートされ、RTTの削減が飛躍的に進んだ。しかし、この0-RTTのパフォーマンスを享受するには、往復のネットワークが安定していることが前提だ。
もしL2レベルでブロードキャストストームが発生していたり、スパニングツリー（STP）の再計算が頻発していたりすれば、TLSのセッション再開要求パケットはロスし、結局はフルハンドシェイク（1.5RTT）が必要になる。
結論:
「L2は単なる土管」と考えるのは、アーキテクトとしては怠慢だ。I/Gビットという小さなフラグが、実はインフラ全体のトラフィックフローを支配し、上位層のプロトコル効率を左右している。
パケットがNICに到達したその瞬間、I/Gビットを判定するハードウェアロジックの裏側で、どんな最適化がなされているか。それを想像し、設計に落とし込める者だけが、真に「遅延のない」ネットワークを構築できるのである。
次回の考察では、このL2スイッチングと、カーネルのXDP (eXpress Data Path)を組み合わせた超高速パケット処理の世界に切り込んでいこう。
コメント