【実務・中級編】 MACアドレスの構造とOUI（Organizationally Unique Identifier） – インフラ・物理＆L2/L3ネットワーク基礎実践ガイド

こんにちは、シニアネットワークエンジニアの私だ。日々のインフラ運用やWeb APIの設計で、パケットの海に潜り込んでいる君なら、一度はARPテーブルやブリッジングテーブルの羅列を眺めて「このMACアドレス、どこのベンダー製だ？」と頭を抱えたことがあるはずだ。

障害対応の現場では、L2スイッチのログに残った不審なMACアドレスから物理的な接続元を特定したり、クラウド上の仮想NIC（vNIC）の挙動を追ったりと、48ビットの識別子を読み解くスキルは、まさにエンジニアの「勘所」を左右する。

今回は、このMACアドレスの構造、特に前半24ビットの主であるOUI（Organizationally Unique Identifier）にスポットを当て、実務でどう活用し、どうコードに落とし込むべきかを徹底的に解説しよう。教科書の丸写しではない、現場の泥臭い知見と共にお届けする。

—

1. MACアドレスの構造：48ビットの「身元証明書」

イーサネットの世界において、物理デバイスを特定するための基本単位がMACアドレス（Media Access Control Address）だ。長さは48ビット（6オクテット）、通常は16進数で XX:XX:XX:XX:XX:XX のように表現される。

この48ビットは、単なるランダムな数値の羅列ではない。厳密に世界的なルールで分割されている。

0               7               15              23
+---------------+---------------+---------------+
|           OUI (24bit)                         |
|      (ベンダー識別子 / IEEE担当)              |
+---------------+---------------+---------------+
 24              31              39              47
+---------------+---------------+---------------+
|       ベンダー管理番号 (24bit)                |
|      (製造元が自由に割り当て)                 |
+---------------+---------------+---------------+

前半24ビット：OUI（Organizationally Unique Identifier）

IEEE（Institute of Electrical and Electronics Engineers）の登録局が、世界中のハードウェアベンダーに一意に割り当てる識別子だ。例えば、Cisco、Intel、Appleといった企業はそれぞれ独自のOUIを持っている。
パッケージやデバイスの筐体を開かなくても、この前半部分を見るだけで「あ、これは〇〇製のNICだな」と即座に判別できる。

ここで、ネットワークエンジニアとして知っておくべき極めて重要な「ビットの秘密」がある。最初期のオクテット（左端の8ビット）の特定のビットには、特別な意味が込められている。

  • I/Gビット（Individual/Group, 最下位ビットから2番目）:
  • 0 ならばユニキャスト（単一の端末宛て）。
  • 1 ならばマルチキャスト / ブロードキャスト（複数端末宛て）。
  • U/Lビット（Universal/Local, 最下位ビットから1番目）:
  • 0 ならばグローバル一意（IEEEが管理・保証する通常のMACアドレス）。
  • 1 ならばローカル管理（LAA: Locally Administered Address）。仮想マシンのNICやコンテナの仮想インターフェースなどで、管理者が手動または動的に割り当てたもの。

もし君がログで fa:16:3e:xx:xx:xx のようなアドレスを見かけたら、U/Lビットが立っている（ローカル管理）ことにお気づきだろうか。これはOpenStackなどのクラウド基盤でよく自動生成される仮想MACアドレスの典型例だ。こうした背景を知っているだけで、障害切り分けのスピードが段違いに変わる。

後半24ビット：ベンダー管理番号

OUIを保有する各メーカーが、自社の工場ラインや製品ごとに自由に割り当てる領域だ。これにより、同じベンダーの製品であっても、世界中で一意の48ビットMACアドレスが担保される仕組みになっている。

—

2. 実務での活用：Web APIとPythonを使ったOUI自動ルックアップ

インフラの自動化やセキュリティ監視ツール（SIEMなど）を構築していると、「ログから抽出したMACアドレスのベンダー名を動的に引き当てたい」という要件に必ず直面する。IEEEは公式のOUIデータベース（テキスト形式やCSV）を公開しているが、これを毎回パースするのは面倒だ。

そこで、オープンソースのOUIデータベースを検索できるWeb API（例: macvendors.com など）を叩く、あるいはローカルで高速にルックアップするPythonスクリプトの実装例を紹介しよう。実務のスクリプトにそのまま組み込めるよう、エラーハンドリングも含めて記述している。

PythonによるMACアドレス・ベンダー名自動取得スクリプト

import urllib.request
import json
import sys

def get_vendor_by_mac(mac_address: str) -> str:
    """
    指定されたMACアドレスのOUIからベンダー名をAPI経由で取得する関数
    
    Parameters:
        mac_address (str): 調査したいMACアドレス (例: "00:50:56:C0:00:01")
        
    Returns:
        str: ベンダー名（取得失敗時はエラーメッセージ）
    """
    # APIのエンドポイント（macvendors.comのパブリックAPIを使用）
    api_url = f"https://api.macvendors.com/{urllib.parse.quote(mac_address)}"
    
    # HTTPリクエストヘッダー（User-Agentを明記するのがマナー）
    headers = {'User-Agent': 'NetworkAutomationScript/1.0'}
    
    try:
        req = urllib.request.Request(api_url, headers=headers)
        with urllib.request.urlopen(req, timeout=5) as response:
            if response.status == 200:
                vendor_name = response.read().decode('utf-8')
                return vendor_name
            else:
                return f"Unexpected status code: {response.status}"
                
    except urllib.error.HTTPError as e:
        if e.code == 404:
            return "Vendor not found (Unknown OUI)"
        return f"HTTP Error occurred: {e.code}"
    except urllib.error.URLError as e:
        return f"Network Connection Error: {e.reason}"

if __name__ == "__main__":
    # テスト用のMACアドレス（例: VMwareのOUIを持つアドレス）
    target_mac = "00:50:56:FF:FE:B8"
    
    print(f"[*] Analyzing MAC Address: {target_mac}")
    vendor = get_vendor_by_mac(target_mac)
    print(f"[+] Identified Vendor: {vendor}")

このようなスクリプトを、Syslog転送サーバーやNetFlow/IPFIXの解析パイプラインに組み込んでおけば、「社内ネットワークに謎の未知のデバイスが接続された瞬間、そのベンダー名（例: Raspberry Pi FoundationやIntelなど）をSlackに通知する」といった自動化が容易に実現できる。

—

3. 現場で役立つトラブルシューティングTips

最後に、OUIやMACアドレス構造にまつわる、現場で本当にあったトラブルと解決の知見をいくつか共有しよう。

トラブル事例1: MACアドレスフラッピングとLAA（ローカル管理アドレス）の罠

ある日、コアスイッチのログに「Port 0/1 と Port 0/2の間でMACアドレスが高速にフラッピングしている（MAC Flapping）」というアラートが大量発生した。
調査を進めると、物理的なループ配線ではなく、仮想化基盤（KVM/Proxmoxなど）上でライブマイグレーションやブリッジ設定のミスにより、同じLAA（ローカル管理アドレス）を持つ仮想NICが異なる物理ポートの配下に同時に存在してしまっていたことが原因だった。

教訓:
「U/Lビット」が立っているMACアドレスを見つけたら、それは物理的なハードウェアベンダーの固有値ではなく、ソフトウェアや管理者が動的に生成したものであることを疑え。クラウドやコンテナ環境では、MACアドレスの重複がレイヤー2のルーティングやブリッジングを容易に破壊する。

トラブル事例2: スプーフィング（なりすまし）の検知

セキュリティインシデントの調査において、不正アクセスの踏み台となった端末のログを洗ったところ、OUIが存在しない、あるいは不自然なベンダー名が表示されるケースがあった。攻撃者がMACアドレス偽装（MAC Spoofing）を行う際、適当な16進数を並べた結果、IEEEに割り当てられていない不正なOUI（あるいはマルチキャストビットが不適切に立ったもの）になっていることが多々ある。

対策:
スイッチのポートセキュリティ設定やDAI（Dynamic ARP Inspection）を導入する際、単にMACアドレスを学習させるだけでなく、OUIの正当性やU/Lビットの整合性をチェックするポリシーをEDRやNAC（Network Access Control）製品で組み合わせるのが、堅牢なインフラ設計の定石だ。

—

まとめ

たかが48ビット、されど48ビット。MACアドレスの構造とOUIの概念は、L2スイッチングの基礎であると同時に、ネットワークの自動化、セキュリティ監視、仮想化基盤のトラブルシューティングに至るまで、あらゆるレイヤーで私たちの羅針盤となる。

教科書の定義を覚えるだけでなく、「このビットが立っている意味は何か？」「このOUIの裏にはどんなハードウェアや仮想化技術があるのか？」という視点を持つことこそが、一流のインフラエンジニアへの道だ。

次のパケット解析の際には、ぜひアドレスの最初の6桁（OUI）に目を向けてみてほしい。そこには、デバイスの「素性」を物語る面白いストーリーが隠されているはずだ。

スポンサーリンク

コメント

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