MACアドレスの深淵：I/Gビットが語る「誰に届くか」の真実
ネットワークエンジニアとして現場に立っていると、上位レイヤー（L7）のAPI設計やクラウドのインフラ構築に没頭するあまり、L2の足元をすくわれる場面に何度も遭遇します。「なぜかパケットが届かない」「特定の端末でだけ通信が重い」。その原因の多くは、イーサネットフレームの宛先MACアドレスという、最も基本的かつ最も重要なビットに隠されています。
今日は、IEEE 802.3の仕様書を開く前に、現場のエンジニアが知っておくべき「MACアドレスの識別ルール」と、その挙動がネットワーク全体に与える影響について深く掘り下げていきましょう。
MACアドレスの「顔」を決めるI/Gビット
MACアドレスは48ビット（6バイト）の識別子ですが、単なる「ラベル」ではありません。その先頭バイトの最下位ビット（Least Significant Bit）こそが、そのフレームの運命を決めるI/Gビット（Individual/Group bit）です。
- I/Gビット = 0（Individual）: ユニキャスト。特定の1台のNIC（Network Interface Card）へ向かう通信。
- I/Gビット = 1（Group）: グループ（マルチキャストまたはブロードキャスト）。複数の端末へ向かう通信。
この1ビットが0か1かによって、スイッチ（L2スイッチ）のASICがパケットをどう扱うか、運命が変わるのです。
ユニキャスト、マルチキャスト、ブロードキャストの判定基準
MACアドレスの最初の1バイト（16進数表記）を2進数に展開してみましょう。
1. ユニキャスト (Unicast)
I/Gビットが 0 です。宛先が特定のデバイス1台のみを指します。
- 例:
00:50:56:xx:xx:xx（VMwareのMACアドレスなど） - 先頭バイトが偶数（
00,02,04…）であれば、それは間違いなくユニキャストです。
2. マルチキャスト (Multicast)
I/Gビットが 1 です。特定のグループに参加している端末すべてにパケットを届けます。
- 例:
01:00:5E:xx:xx:xx（IPv4マルチキャスト用） - 先頭バイトが奇数（
01,03,05…）であれば、それはグループ通信です。
3. ブロードキャスト (Broadcast)
I/Gビットが 1 であることに加え、すべてのビットが 1（FF:FF:FF:FF:FF:FF）である特殊なケースです。セグメント内の「全員」が受信対象となります。
—
現場で役立つPythonによるアドレス判別
API設計やネットワークツール開発で、送信先MACアドレスがどのような性質を持つか、パケットキャプチャの解析時にコードで弾きたい場面があるはずです。以下に、Scapyライブラリ等を使わずに純粋なバイナリ操作で判別するロジックを示します。
def check_mac_type(mac_str):
"""
MACアドレス文字列から通信種別を判定する
"""
# ':' を取り除き、最初の2文字（1バイト分）を取り出す
first_byte_hex = mac_str.split(':')[0]
first_byte_int = int(first_byte_hex, 16)
# 0xFF:FF:FF:FF:FF:FF はブロードキャスト
if mac_str.upper() == "FF:FF:FF:FF:FF:FF":
return "Broadcast"
# I/Gビットの判定 (最下位ビットが1ならGroup)
if (first_byte_int & 0x01):
return "Multicast"
else:
return "Unicast"
# テスト実行
print(check_mac_type("00:0C:29:4F:8B:3C")) # ユニキャスト
print(check_mac_type("01:00:5E:00:00:01")) # マルチキャストスイッチングの挙動：なぜL2スイッチは「バラ撒く」のか
インフラエンジニアが知るべきは、このMACアドレスがスイッチの「MACアドレステーブル」とどう関わるかです。
1. ユニキャスト: スイッチは学習したポートへ転送（Forwarding）します。学習していない場合は、全ポートへフラッディングしますが、これは「例外」です。
2. マルチキャスト/ブロードキャスト: スイッチはMACアドレステーブルの学習に関係なく、受信ポート以外の全ポートへ転送（Flood）します。
特に、Web APIのバックエンドで高頻度なマルチキャストトラフィックを流すと、L2スイッチの背後にいる全ポートのNICに負荷がかかります。「マルチキャストだから特定の相手にだけ届く」というのは誤解です。L2レベルでは、グループ参加に関係なく、そのセグメント内のすべての機器がフレームを受信し、CPUで「自分宛てかどうか」を判断しなければならないのです。
トラブルシューティングの極意：デバッグ手順
現場で「通信が遅い」「ARPが解決しない」という事象に遭遇したら、以下の手順でパケットの挙動を疑ってください。
1. tcpdump で確認:
tcpdump -i eth0 -e を実行し、MACアドレスの先頭バイトを凝視します。もし想定外のマルチキャストが大量に流れていたら、それが帯域を圧迫し、CPU負荷を上げている主犯かもしれません。
2. スイッチの統計情報:
show interface counters 等のCLIコマンドで、broadcast や multicast のフレームカウンタが異常に増えていないか確認してください。
3. L3ルーティングの境界を意識:
MACアドレスの挙動はL2スイッチまでです。ルーター（L3）を超えると、MACアドレスは宛先ゲートウェイのものに書き換わります。エンドツーエンドで見ているつもりが、実はL2セグメントごとに「宛先MAC」が付け替えられていることを忘れないでください。
最後に：ネットワークを俯瞰する視点
技術者がL2のビットレベルまで理解していると、上位層のトラブルシューティングの際、パケットが「どこで、なぜ止まったのか」が手に取るように見えてきます。
「なんとなく動いている」から「理屈で制御できる」へ。この一歩を踏み出すために、今日から tcpdump や Wireshark を開いたとき、一番最初の6バイトを眺める癖をつけてみてください。そこには、ネットワークの深淵に触れるための確かな鍵が記されています。
コメント