パケットの鼓動を聞け：GVRPとMVRPが織りなすダイナミックVLANの深淵
ネットワークエンジニアとしてキャリアを積んでいくと、いつかは「レイ2の全自動化」という甘美な罠、あるいは巧妙に仕掛けられたパケットの迷宮に直面する。静的なトランキング設定の手間を省き、スイッチ間でのVLANデータベース同期を自動化する――その理想郷を目指してIEEEが策定したプロトコルが、GARPを基盤とする GVRP (GARP VLAN Registration Protocol) であり、その現代的な後継である MVRP (Multiple VLAN Registration Protocol) だ。
教科書を開けば「VLANの動的な伝播により管理コストを削減します」といったお決まりの美辞麗句が並ぶ。だが、現場のインフラアーキテクトやテックリードが知りたいのはそんなことではない。マルチキャストMACアドレスの海を漂う制御パケットが、CPUの割り込みをどれだけスパイクさせるのか。そして、トポロジ変更の嵐の中で、なぜレイ2ループや予期せぬVLANの消失（ブラックホール化）が引き起こされるのか。その「パケットレベルのリアルな挙動」にこそ、プロトコルの本質が隠されている。
今回は、L2/L3ネットワークの深淵を愛する者たちへ向けて、GVRPからMVRPへの進化の歴史、イベント駆動型の動的登録メカニズム、そして現場で血を流さないための実践的な設計論を徹底的に紐解いていこう。
—
1. GARP/GVRPの構造的限界：なぜ私たちはGVRPを封印すべきなのか
まずはすべての元凶であり、いまや「レガシーの遺物」として扱われるべき GVRP（IEEE 802.1Q Annex G）の挙動から振り返る。
GVRP は、GARP (Generic Attribute Registration Protocol) という汎用プロトコルの枠組みの上で動作する。GARPの仕事は極めてシンプルだ。「私はこの属性（VLAN ID）を持っている」「誰かこの属性を必要としているか？」という情報を、レイ2のマルチキャスト空間を通じて近隣のスイッチとキャッチボールすることである。
マルチキャストの嵐とGARPタイマーの悪夢
GVRPが使用する宛先MACアドレスは、イーサネットマルチキャストアドレスである 01-80-C2-00-00-21 だ。このアドレス宛てのフレームは、802.1D Spanning TreeのBPDUsと同様に、通常のフォワーディングデータベース（FDB）の学習対象外となり、基本的にはすべてのポート（VLANに属するポート）へフラッディングされるか、CPUへと吸い上げられる。
ここで発生するのが、大規模ネットワークにおけるブロードキャスト・ストームならぬ「GARPメッセージの洪水」である。
ネットワーク内に数台のスイッチを接続し、数百のVLANを一斉に定義した瞬間を想像してほしい。GVRPは以下のイベント駆動型メッセージを無限に吐き出し始める。
JoinEmpty: 「このVLANを知っているか？（まだ誰もリスナーはいない）」JoinIn: 「このVLANを知っており、我がポートでも必要としている」LeaveEmpty: 「このVLANの必要性がなくなった」LeaveAll: 「すべてのVLAN登録をリセットする。維持したいなら再登録しろ」
これらがタイマー駆動（Joinタイマー、Leaveタイマー、LeaveAllタイマー）で網の目のように飛び交う。結果として、スイッチのコントロールプレーン（CPU）はGARPパケットの処理に追われ、CPU使用率が跳ね上がる。極端なトポロジ変更が発生した際には、LeaveAllタイマーの期限切れに伴う一斉再登録（リフレッシュ・ストーム）が引き金となり、正常なデータトラフィックすらも巻き込んでネットワーク全体が沈黙するという惨劇が幾度となく報告されてきた。
—
2. MVRPの登場：IEEE 802.1akによる近代化とMRPの洗練
GVRPの抱えた致命的なスケーラビリティの欠如とコンバージェンスの遅さを解決するため、IEEEは2007年に IEEE 802.1ak を承認し、MMRP (Multiple Mac Registration Protocol) とともに MVRP (Multiple VLAN Registration Protocol) を世に送り出した。
MVRPの基盤にあるのは、GARPを完全に刷新した MRP (Multiple Registration Protocol) だ。MRPは、GARPが持っていた冗長で非効率なステートマシンを見直し、より洗練されたイベント駆動型のパケット構造へと生まれ変わった。
MVRPパケット構造とイーサネットタイプ
MVRPは、EtherTypeに 0x88F6 を使用し、宛先MACアドレスには同じくブリッジ用のマルチキャストアドレス 01-80-C2-00-00-21 を使用する。しかし、その内部のTLV（Type-Length-Value）構造は非常に効率的だ。
+-----------------------------------+-----------------------------------+
| Destination MAC: 01-80-C2-00-00-21| Source MAC: Switch Base MAC |
+-----------------------------------+-----------------------------------+
| TPID: 0x88F6 (MVRP EtherType) | Protocol Version: 0x00 |
+-----------------------------------+-----------------------------------+
| Attribute Type: VLAN (0x01) | Attribute Length: 2 Bytes |
+-----------------------------------+-----------------------------------+
| Attribute List (Vector Header / Packed Values) |
| - VLAN ID 10: JoinIn / Leave / Empty |
| - VLAN ID 20: Empty |
+-----------------------------------+-----------------------------------+MVRPの最大の改良点は、複数の属性（VLAN ID）を1つのプロトコルデータユニット（PDU）に効率よくパックして送信できる点（Vector Attributeの導入）にある。これにより、数百のVLANが存在する環境であっても、パケットの総数を劇的に削減し、コントロールプレーンへの負荷を最小限に抑えることに成功している。
—
3. 状態遷移のメカニズム：MRP State Machineの深層
MVRPの挙動を完全に理解するためには、MRPが各ポートのVLANごとに保持する状態マシン（State Machine）を読み解く必要がある。
各ポートの属性インスタンスは、以下のような状態を行き来する。
1. MT (Member and Translator / Empty): 属性が登録されておらず、参加者もいない初期状態。
2. VO (Very Often / Joining): 自ら属性を登録しようとしている状態（Join メッセージ送信中）。
3. VP (Very Poor / In): 近隣スイッチから Join を受信し、そのVLANがアクティブであることを認識している状態。
4. LA (Leave): 属性の削除タイマーが作動している状態。
ネットワークエンジニアがトラブルシューティングの際に必ず直面するのが、「なぜかVLANが自動生成されない、または勝手に消える」という現象だ。これは大抵、LeaveAllタイマー（デフォルトで通常10秒〜数秒）のインタラクションのミスマッチや、スパニングツリー（STP/RSTP/MSTP）のトポロジ変更（TCN）とMVRPのステート同期のタイミングがずれることに起因する。
実務上、リンクフラップが発生した瞬間、MVRPは一斉に LeaveAll をブロードキャストし、数ミリ秒の間に全ての動的VLANデータベースを破棄・再構築する。この過渡期において、レイ3のSVI（Switch Virtual Interface）にトラフィックが流れ込むと、ブラックホール化やパケットロスが盛大に発生する。これが、プロダクション環境のコア・ディストリビューション層でダイナミックVLANが敬遠される最大の理由である。
—
4. 実務的インフラ設計：なぜプロダクション環境でGVRP/MVRPは嫌われるのか？
インフラアーキテクトとしての冷徹な視点を持つならば、現代のエンタープライズ・データセンターや大規模キャンパスネットワークにおいて、GVRPやMVRPを有効化することは「百害あって一利なし」と断言せざるを得ない。
その理由は明確だ。
1. セキュリティリスク（VLANインジェクション・不正拡張）
もしアクセスポートや未信頼のアップリンク側でMVRPが有効になっていれば、悪意ある攻撃者が不正なMVRPフレームを流し込むことで、スイッチ上に任意のVLANを動的に強制生成させ、本来アクセスできないセグメントへの足がかり（VLANホッピングの変種）を与えてしまうリスクが生じる。
2. 障害時の影響範囲の予測不能性（Blast Radius）
静的なVLAN設計（vlan 100, name PRODUCTION を手動で各スイッチに流し込む、あるいはAnsibleなどの構成管理ツールで担保する）であれば、障害発生時の挙動は完全に予測可能である。しかし、動的プロトコルに依存した場合、「どのスイッチがどのVLANを現在保持しているか」の真実（Single Source of Truth）が刻一刻と変化し、障害時の切り分けが極めて困難になる。
3. SDN / ネットワーク自動化の台頭
そもそもGVRP/MVRPが解決しようとした「VLAN設定の手間」は、現代においてはNETCONF/YANG、RESTCONF、あるいはAnsibleやTerraformといったInfrastructure as Code（IaC）ツール、さらにはEVPN-VXLANのようなモダンなオーバーレイ技術によって完全に克服されている。L2の制御プレーンに複雑な自律分散プロトコルを走らせる必要性は、もはや過去のものとなった。
—
5. LinuxカーネルおよびスイッチOSにおける実装と設定の作法
とはいえ、検証環境や特定の閉じたレガシー環境、あるいはCCIE等の試験対策として、MVRPの挙動を確認・設定しなければならないシチュエーションは存在する。ここでは、Cisco IOS-XEおよびLinux（bridge設定）における実際の構文と注意点を見ておこう。
CiscoスイッチにおけるMVRP設定例（Cisco IOS-XE）
Cisco機でMVRPを有効にする場合、大前提としてVTP（VLAN Trunking Protocol）のモードが適切に設定されているか、あるいはVTPが無効化されている必要がある（VTPとMVRPの競合を避けるため）。
! グローバルコンフィギュレーションモードでMRPおよびMVRPを有効化
feature mvrp
! トランクポート上でMVRPを有効化する
interface GigabitEthernet0/1
description === Uplink to Core Switch with MVRP ===
switchport mode trunk
switchport trunk allowed vlan 10,20,30
mvrp
!
! 注意: MVRPを動作させるためには、グローバルでMSTIやRSTPが稼働しており、
! トポロジが安定していることが絶対条件となる。Linuxブリッジ（iproute2 / bridgeコマンド）における設定
もしLinuxをソフトウェアルータや仮想スイッチ（KVMのブリッジ等）として運用し、MVRPの挙動をテストしたい場合、Linuxカーネル（bridge モジュール）はGARP/MVRPのフル実装をネイティブでは持たないことが多いが、IEEE 802.1Qの基本属性やGARPデーモン（garpd やサードパーティ製プロトコルスタック）を組み合わせて実験を行う。
実務的なLinuxのL2ブリッジ作成およびVLANフィルタリングの基本設定（静的アプローチ）は以下の通り。MVRPのような動的プロトコルに頼らず、明示的にVLANをコントロールするための標準的なコマンドである。
#!/bin/bash
# =====================================================================
# Linux ブリッジインターフェースの構築とVLANフィルタリング設定
# 動的プロトコルを使わず、安全かつ確実にL2セグメントを構築する例
# =====================================================================
BRIDGE_NAME="br0"
PHYS_INTF="eth0"
# 1. ブリッジデバイスの作成
ip link add name ${BRIDGE_NAME} type bridge
# 2. ブリッジでVLANフィルタリングを有効化（セキュアな設計の基本）
ip link set dev ${BRIDGE_NAME} type bridge vlan_filtering 1
# 3. 物理インターフェースをブリッジに参加させる
ip link set dev ${PHYS_INTF} master ${BRIDGE_NAME}
# 4. ブリッジインターフェース自体にVLAN 100 (管理用等) を割り当てる
ip link add link ${BRIDGE_NAME} name ${BRIDGE_NAME}.100 type vlan id 100
ip addr add 192.168.100.10/24 dev ${BRIDGE_NAME}.100
# 5. インターフェースの有効化
ip link set dev ${PHYS_INTF} up
ip link set dev ${BRIDGE_NAME} up
ip link set dev ${BRIDGE_NAME}.100 up
echo "Linux L2 Bridge with VLAN Filtering successfully initialized."Linux環境でダイナミックなVLAN登録を行いたいシチュエーションに出会ったとしても、カーネルレベルの自律プロトコルに身を委ねるのではなく、上位のオーケストレーションツールからNetlinkソケットを叩いて動的にVLANインターフェースを生やすアプローチをとる方が、圧倒的にモダンであり、トラブルシューティングの容易性も段違いに高い。
—
6. 結びにかえて：プロトコルの美しさとエンジニアの選択
GVRPからMVRPへの進化は、IEEEのエンジニアたちが「いかにコントロールプレーンの負荷を減らし、効率的なパケットやり取りを行うか」という課題に挑んだ歴史の結晶である。TLVの最適化やステートマシンの洗練は、ネットワークプロトコルとしての美しさを十分に湛えている。
しかし、プロトコルの美しさと、現場のインフラとしての堅牢性は、必ずしも一致しない。
パケットがネットワークを駆け抜ける裏側で何が起きているのかを深く理解した上で、「あえて使わない」という決断を下すこと。それこそが、数千台のデバイスを預かるインフラアーキテクトやテックリードに求められる、真のプロフェッショナリズムなのである。
コメント