MACアドレスの深淵：U/Lビットが支配する「グローバル」と「ローカル」の境界線
ネットワークエンジニアとしてキャリアを積んでいると、必ず一度は「なぜこのMACアドレスはIEEEのOUI（Organizationally Unique Identifier）データベースに存在しないのか？」という壁に突き当たる。
大抵の場合、それはWiresharkのパケットキャプチャで見慣れた 00:00:5e:... のようなVRRP用仮想MAC、あるいはハイパーバイザが自動生成した 52:54:00:... といった類のものだ。しかし、この「なぜ」を深く掘り下げると、イーサネットフレームのヘッダー先頭バイトに隠された、わずか1ビットの静かなる支配者に辿り着く。それが U/Lビット（Universal/Local bit） だ。
1. U/Lビット：アドレスの出自を定義する1ビットの正体
MACアドレス（EUI-48）の最初のオクテット、その下位から2番目のビットがU/Lビットである。このビットが 0 ならばIEEEが管理する「グローバル（Universal）」なアドレス、1 ならば管理者が独自に定義可能な「ローカル（Local）」なアドレスとなる。
- U/L = 0 (Global): IEEEから割り当てられたOUIに基づき、世界中で一意であることが保証される。
- U/L = 1 (Local): 管理者が環境内で任意に設定できる。当然、ネットワーク境界を越えれば衝突のリスクがあるが、仮想化環境や高可用性クラスター（HA）においては、この柔軟性が不可欠だ。
現場でLAA（Locally Administered Address）を扱う際、最も注意すべきはMACアドレスの先頭バイトが「奇数」になるという点だ。なぜなら、先頭バイトのLSB（最下位ビット）はI/Gビット（Individual/Group bit）であり、U/Lビットはそれに続く2ビット目だからだ。
2. パケットレベルの挙動とフィルタリングの罠
インフラアーキテクトとして意識すべきは、LAAがスイッチのCAM（Content Addressable Memory）テーブルやTCAMに与える影響だ。多くの高機能スイッチは、LAAを通常のユニキャストアドレスとして学習するが、一部のセキュリティアプライアンスやIDS/IPSは、U/Lビットが 1 であるアドレスを「異常」や「偽装（Spoofing）」としてフラグを立てる設定になっていることがある。
特に、KubernetesのCNIプラグインやOpenStackの仮想スイッチ（OVS）でLAAを多用する場合、ARPテーブルのタイムアウト値や、Linuxカーネル側の neighbor キャッシュの設定（gc_thresh 等）と整合性を取らないと、大規模環境ではフラッピングを誘発する。
# LinuxカーネルのARPキャッシュ設定をチューニング
# 大規模仮想化環境ではエントリが溢れやすいため、閾値を引き上げる
sysctl -w net.ipv4.neigh.default.gc_thresh1=1024
sysctl -w net.ipv4.neigh.default.gc_thresh2=2048
sysctl -w net.ipv4.neigh.default.gc_thresh3=40963. 高性能ネットワークにおけるLAAの戦略的活用
LAAは単なる「仮想化の都合」ではない。パフォーマンスを追求する環境では、LAAを戦略的に設計することで、フローの局所性を高めることが可能だ。
例えば、DPDK（Data Plane Development Kit）を用いた高速パケット処理環境では、NICのMACアドレスを意図的にLAAへ変更し、トラフィックを特定のCPUコアへ誘導するハードウェアフィルタリング（RSS: Receive Side Scaling）と組み合わせる手法がある。
PythonによるLAA生成のベストプラクティス
もしスクリプトでLAAを生成するなら、以下の点に注意してほしい。
import random
def generate_laa():
# 最初のオクテットのU/Lビットを1にする
# 0x02 = 0000 0010 (U/Lビット=1, I/Gビット=0)
mac = [0x02, 0x00, 0x00, 0x00, 0x00, 0x00]
# 残りのバイトをランダムに埋める
for i in range(1, 6):
mac[i] = random.randint(0x00, 0xff)
return ":".join(map(lambda x: "%02x" % x, mac))
print(f"生成されたローカル管理アドレス: {generate_laa()}")4. 脆弱性回避とセキュリティの観点から
最後に、セキュリティスペシャリストとして警告したい。LAAは「なりすまし」の温床になりやすい。特にクラウド環境において、インスタンス間でIPアドレスを引き継ぐ際、LAAを動的に変更する設計は、ARPスプーフィング攻撃に対して脆弱になる可能性がある。
これを防ぐには、L2レベルでのDAI (Dynamic ARP Inspection)や、ポートセキュリティ機能（MACの学習数を制限し、静的バインドを強制する）を併用するのが鉄則だ。
- RTT削減のヒント: LAAを使用する環境では、スイッチのMAC学習を待たずに通信が発生するケースが多い。静的ARPエントリを投入し、L2学習プロセスをスキップさせることで、特にTCP 3-way handshakeの遅延（RTT）をマイクロ秒単位で削減できる。
結論：プロトコルの深淵へ
ネットワークは、たかが1ビットのフラグにさえ壮大な設計思想が宿る。LAAを使いこなすということは、IEEEの管理するグローバルな秩序と、自分たちが構築するローカルな秩序の境界をコントロールすることに他ならない。
この記事を読んだ皆さんが、次にWiresharkを開いたとき、02:... で始まるMACアドレスを見て「ああ、これはシステムが意志を持って生成したアドレスだな」とニヤリとしてくれることを願う。インフラ構築とは、そうした「通信の意志」を設計することなのだから。
コメント