IEEE 802.1s MSTPの深淵：VLANマッピングとリージョン設計によるL2トポロジの極限最適化
ネットワークの歴史を振り返るとき、我々は常に「冗長性とループフリー」という二律背反のジレンマと戦ってきた。1台のスイッチの故障が全体のブラックアウトを招かないよう物理リンクを冗長化すれば、そこには必ずブロードキャストストームの魔物が巣食う。
IEEE 802.1D（STP）の遅い収束に現場が泣き、IEEE 802.1W（RSTP）で数秒単位の高速化を手に入れたものの、現代の大規模データセンターやキャンパスネットワークにおいて、RSTPは新たな矛盾に直面した。「VLANごとにインスタンスを立てる（IEEE 802.1Q – PVST+ / Rapid-PVST+）」というアプローチは、数百のVLANが存在する環境において、CPUと制御プレーンの帯域を容赦なく食い潰す。BPDUの嵐がCPUを窒息させ、トポロジ変更のたびに全域でフラッディングが発生する。
この地獄絵図をスマートに解決する究極の解こそが、IEEE 802.1s、現在ではIEEE 802.1Qに統合された Multiple Spanning Tree Protocol (MSTP) である。
今回は、パケットの挙動、内部ステートマシンの哲学、そして実務で即座に使えるCisco IOS / Cisco NX-OSおよびLinuxブリッジにおけるリージョン設計の極意を、ネットワークプロトコルの深淵を愛する者たちの視点から紐解いていこう。
—
1. なぜRSTPの「VLAN毎インスタンス」は破綻するのか？
大規模なL2ドメインを構築する際、エンジニアはしばしば次のような設計ミスを犯す。「VLAN 10からVLAN 200まで、すべてのVLANで独立したスパニングツリーを動かせば、トラフィックのロードバランスができるはずだ」と。
理論上はその通りだ。しかし、物理的・制御的なコストを計算したことがあるだろうか？
- 制御プレーンのCPU負荷: スイッチが処理しなければならないBPDUの総数は、
（スイッチあたりのVLAN数） × （接続ポート数）に比例して爆発的に増加する。 - マルチキャスト/ブロードキャストの帯域消費: 数百のインスタンスがそれぞれ独自のHello BPDUをネイティブまたはタグ付きで流し続ける。リンクの帯域のごく一部とはいえ、低スペックなアクセス層のスイッチにとっては無視できない負荷だ。
ここでMSTPの登場である。MSTPは、「複数のVLANを一つのスパニングツリーインスタンス（MSTI）にグループ化（VLAN Mapping）」することで、数千のVLANが存在しようとも、制御するツリーの数を数個（例えばデフォルトのCISTを含めて数本）に圧縮する。
—
2. MSTPの内部構造：CISTとMSTI、そしてリージョンの境界
MSTPの動作原理を理解するには、その二層構造のアーキテクチャを正確に把握する必要がある。
1. CIST (Common and Internal Spanning Tree):
- リージョン内を統合する内部ツリー（IST）と、すべてのリージョンおよびレガシーSTP/RSTPスイッチを接続する共通の外部ツリー（CIST External）が融合した概念。
- インスタンス0（
Instance 0またはIST）がこれに該当し、すべてのVLANが明示的にマッピングされない場合のデフォルトの帰れ場所となる。
2. MSTI (Multiple Spanning Tree Instance):
- リージョン内で独立して計算される個別のスパニングツリー（
Instance 1からInstance 4094まで定義可能だが、実運用ではハードウェアの制限もあり通常は16個程度に抑える）。
リージョン（Region）の一致条件
複数のスイッチが同一の「MSTリージョン」に属し、同一のトポロジを共有しているとみなされるためには、以下の4つのパラメーター（MST Configuration Identifier）が完全に一致していなければならない。
- フォーマットセレクター: 通常は
0 - コンフィギュレーションネーム（Name）: 32文字以内の文字列（大文字小文字を区別）
- リビジョン番号（Revision）: 設定の世代管理用整数値（
0〜65535） - VLANとMSTIのマッピングテーブル: 4094個のVLANがどのMSTIに所属しているかの4096バイトのダイジェスト（実際にはMD5ハッシュとしてBPDUに格納される）
このうち1文字でも、1つの数字でも異なれば、スイッチ間は異なるリージョンとみなされ、お互いの境界でMSTIの情報は遮断され、CISTのレベルで単一のリンクとして扱われる（リージョン境界の形成）。この挙動が、L2ドメインのセグメンテーションにおいて極めて重要なセキュリティと障害隔離の境界線となる。
—
3. パケット解析：MSTP BPDUの構造とダイジェストの秘密
IEEE 802.1w（RSTP）のBPDUタイプ（Version 2）を拡張したのが、MSTPのBPDU（Version 3）である。Wireshark等でキャプチャすると、その中身の緻密さに感嘆するはずだ。
RSTPのBPDUフィールドに加え、MSTP特有の「MSTI Configuration Message」が複数連結されている。
[IEEE 802.3 Ethernet Header]
Dst: 01:80:c2:00:00:00 (Bridge_Group_Address)
Src: Switch System MAC
Length: 107+
[LLC / IEEE 802.2 Logical Link Control]
DSAP: 0x42 (STP) / SSAP: 0x42 / Control: 0x03
[RSTP / MSTP BPDU (Protocol Version 3)]
Protocol ID: 0x0000 (Spanning Tree)
Protocol Version ID: 0x03 (MSTP)
BPDU Type: 0x02 (RST/MST BPDU)
Flags: Agreement, Forwarding, Learning, Role (Master/Alternate etc.)
Root Identifier / Cost / Bridge Identifier / Port ID
--- MST Extension ---
Configuration Identifier
Format Selector: 0
Configuration Name: "DC-CORE-REGION"
Revision Number: 1
Configuration Digest: 0x8f3c... (MD5 hash of VLAN-to-Instance mapping)
CIST Internal Root Path Cost / CIST Bridge Identifier / Port ID
MSTI Configuration Messages (Instance 1, Instance 2...)ここで注目すべきは Configuration Digest だ。隣接するスイッチ間で「俺たちのVLANマッピング設定は完全に一致しているか？」を確認するため、設定全体をMD5ハッシュにしてやり取りしている。
もし、片方のスイッチで vlan 100 mapping instance 1 を追加し忘れ、ダイジェスト値が一致しなくなると、そのリンクはリージョン境界とみなされ、MSTIのトラフィック制御が意図通りに機能しなくなる。現場での「なぜか特定のVLANだけループする／通信できない」というトラブルの9割は、このダイジェスト不一致（Configuration Mismatch）に起因する。
—
4. 実務で直面する設計の罠とベストプラクティス
インフラアーキテクトとして数多くの現場を渡り歩いてきた中で、MSTPの設計・実装において絶対に外せない鉄則をいくつか共有しよう。
罠1: すべてのVLANをInstance 0（IST）に放置する愚
MSTPを設定した際、明示的にマッピングを行わないVLANはすべて Instance 0 (CIST) に所属する。もし、デフォルトのまま全VLANを放置すると、RSTPと同じように単一の巨大なツリーに負荷が集中し、MSTPを導入した意味が完全に失われる。
必ず、トラフィックの方向性（ロードバランス）を考慮して、奇数VLANはMSTI 1、偶数VLANはMSTI 2といったように明確にマッピングを分割すべきである。
罠2: ルートブリッジとプライマリ/セカンダリの非対称設計
コアスイッチが2台ある環境では、CISTのルートと、各MSTIのルートを意図的に分散させ、アクティブ・スタンバイ（あるいはデュアルアクティブ）な負荷分散経路を構築する。
—
5. 実設定例：Cisco IOS / NX-OS による堅牢なMSTP設計
では、実際のコマンドラインを通じて、堅牢なMSTPリージョンを構築してみよう。以下の構成では、コアスイッチAとコアスイッチBの間でリージョンを統一し、VLAN 10-50をMSTI 1、VLAN 60-100をMSTI 2に割り当て、トラフィックを美しく分散させる。
Cisco IOS (Catalyst 9000シリーズ等) の設定
! --- グローバルコンフィギュレーションモード ---
! スパニングツリーのプロトコルとしてMSTを指定
spanning-tree mode mst
! --- MSTリージョンの定義（全スイッチで完全に一致させること） ---
spanning-tree mst configuration
! リージョン名の定義（大文字小文字も厳密に一致させる）
name DC-CORE-REGION
! リビジョン番号（設定変更のたびにインクリメントすると安全）
revision 1
! VLANマッピングの定義: VLAN 10から50をMSTI 1へ割り当て
instance 1 vlan 10-50
! VLANマッピングの定義: VLAN 60から100をMSTI 2へ割り当て
instance 2 vlan 60-100
! 設定を反映させる（抜けがちなポイント）
exit
! --- ルートブリッジの配置設計（コアスイッチAをMSTI 1のプライマリ、MSTI 2のセカンダリに） ---
spanning-tree mst 0 priority 4096
spanning-tree mst 1 priority 4096
spanning-tree mst 2 priority 8192
! --- リンク障害時の収束を加速するポートファストとガード機構 ---
interface range GigabitEthernet1/0/1-24
description Access-Ports-Connected-to-End-Devices
spanning-tree portfast edge
spanning-tree bpduguard enable
exit
interface range GigabitEthernet1/0/25-26
description Uplink-Trunks-to-Core-Switches
spanning-tree link-type point-to-point
exitもし対向のコアスイッチB側であれば、MSTI 2のプライマリを 4096 に、MSTI 1のプライマリを 8192 に落とし込むことで、見事なアクティブ・アクティブのL2ロードバランス環境が完成する。
—
6. Linuxカーネル（Bridge）におけるMSTPの現在地
「ベアメタルサーバーやコンテナホストを直接L2網の端点として接続し、Linuxカーネル上でブリッジングを行いたい」というモダンなインフラエンジニアのために、LinuxにおけるMSTPの立ち位置についても触れておかねばならない。
伝統的に、Linuxのブリッジング (bridge モジュール) はRSTP（IEEE 802.1w）のサポートに留まることが多く、単一のブリッジに対して複数の独立したツリー（MSTP / MSTI）をネイティブに構成するのはカーネルの制約上困難であった。
しかし、ユーザースペースのデーモンである mstpd や mstpd と連携する bridge 制御ツール（iproute2 の bridge コマンドなど）を用いることで、Linuxを本格的なMSTPリージョンのノードとして参加させることが可能となっている。
# Linuxカーネル上でブリッジデバイスを作成し、RSTP/MSTPの挙動を有効化する例
ip link add name br0 type bridge
ip link set dev br0 up
# ポートをブリッジに参加させ、スパニングツリーのパラメータを調整
ip link set dev eth0 master br0
ip link set dev eth1 master br0
# 注意: Linuxネイティブのブリッジで厳密なVLANマッピングを伴うMSTIを運用する場合は、
# 専用のユーザー空間デーモン（mstpdなど）の導入と、適切なドキュメントに基づいたビルドが必要となる。ハイパースバイザーやコンテナ基盤の足元でL2冗長化を設計する場合、Linux側で中途半端なSTPを動かすよりも、サーバー側はポートファスト相当（spanning-tree portfast / hairpin 等の適切な制御）で受けておき、L2のループ防止は上流の物理スイッチ（MSTPリージョン）に完全に委譲するのが、実務上の「大人の選択」であると言える。
—
7. おわりに：パケットの流れに思いを馳せて
ネットワークプロトコルは、決して冷徹なバイナリの羅列ではない。そこには、限られた帯域とCPU資源の中で「いかにして通信の連続性を担保するか」という先人たちの知恵とドラマが詰まっている。
RSTPのVLAN毎の暴力的なBPDUの応酬から、MSTPがもたらす洗練されたリージョンとインスタンスの調和へ。この概念をマスターしたインフラエンジニアであれば、何千VLANを抱える巨大なデータセンターの設計図を目の前にしても、微動だにせず、美しく安定したレイヤー2トポロジを描ききることができるはずだ。
さあ、あなたのネットワークのダイジェスト値は、今、美しく一致しているか？ ぜひ検証コマンドを叩いて、パケットの鼓動を確認してみてほしい。
コメント