STPの悪夢は終わった。MSTP（IEEE 802.1s）で実現する、マルチVLAN時代のモダンL2アーキテクチャの極意
ネットワークエンジニアなら誰もが一度は恐怖したことがあるはずだ。レイヤ2ループによるブロードキャストストーム。そして、それを防ぐためのSTP（Spanning Tree Protocol）を導入したはいいものの、すべてのVLANトラフィックがたった1本のアップリンクに集中し、隣の冗長回線は無慈悲に「Blocking（破棄）」状態として遊んでいる光景を――。
「せっかく10Gbpsの冗長線を2本引いているのに、なぜ帯域の半分が無駄になるのか」
「VLANごとに異なるパスで負荷分散させたいけれど、PVST+はCiscoプロプライエタリだし、VLANの数だけインスタンスを立てたらCPUが悲鳴を上げる……」
そんなインフラエンジニアの長年のジレンマを鮮やかに解決するのが、今回解説する MSTP（Multiple Spanning Tree Protocol：IEEE 802.1s） だ。
数々の現場で泥臭いトラブルシューティングをくぐり抜けてきたシニアエンジニアの視点から、RFC 4541/IEEE 802.1Qに裏打ちされたMSTPの本当の仕組みと、実務で絶対に押さえておかなければならない設計・運用の極意を紐解いていこう。
—
1. なぜMSTPなのか？ STP・RSTPの限界と進化の歴史
そもそも、なぜ私たちはMSTPを必要としているのだろうか。歴史を少しだけ振り返ってみる。
1. STP（IEEE 802.1D）: 収束（Convergence）に数分かかる。「ループは防げるが、障害時のダウンタイムが長すぎる」という致命的な弱点があった。
2. RSTP（IEEE 802.1w）: ステートの再定義やプロポーサル／アグリーメント（Proposal/Agreement）メカニズムにより、数秒（下手すればサブセカンド）での収束を実現した。しかし、「全VLANでたった1つのツリーを共有する」という基本構造は変わらなかった。
3. PVST+ / Rapid-PVST+（Cisco独自）: VLANごとに独立したRSTPインスタンスを走らせることでトラフィックの負荷分散を実現したが、VLANが100個あれば100個のBPDU（Bridge Protocol Data Unit）が飛び交い、スイッチのCPUと帯域を圧迫する。
そこで登場したのが MSTP（IEEE 802.1s、現在はIEEE 802.1Qに統合） である。
MSTPは、複数のVLANを1つの「MSTI（Multiple Spanning Tree Instance）」にマッピングすることで、RSTPの高速収束性を維持しつつ、インスタンスの数を劇的に削減し、マルチパスによるトラフィックエンジニアリングを可能にした。
—
2. MSTPのアーキテクチャと核心概念
MSTPを正しく設計・運用するためには、いくつかの独特な用語と概念を頭に叩き込んでおく必要がある。ここがあやふやだと、障害時にデバッグの方向を大きく誤ることになる。
MST領域（MST Region）の概念
MSTPの最大の特徴は、世界中のスイッチを1つの巨大なツリーにするのではなく、「MST領域（Region）」という論理的なグループに分割する点だ。
同じRegionに属するスイッチ群は、内部的にはVLANごとのグループ（MSTI）でそれぞれの最適パスを計算するが、領域の外（他のRegionや従来のRSTP/STPスイッチ）から見ると、あた単一の仮想的なブリッジ（Common and Internal Spanning Tree: CISTルート）として振る舞う。
この「境界の隠蔽」のおかげで、L2ネットワークの規模が大きくなってもBPDUのスパム爆発を防ぐことができる。
Regionを一致させるための「4つのパラメータ」
複数のスイッチが「自分たちは同じRegionにいる」と認識するためには、以下の4つの設定（BPDUに含まれるパラメータ）が一字一句完全に一致していなければならない。ここが現場で最も多い設定ミスの温床だ。
1. Configuration Name（設定名）: 32文字以内の文字列（例: DC-Core-Region）
2. Revision Level（リビジョン番号）: 設定の世代管理番号（例: 1）
3. VLAN-to-Instance Mapping Table（VLANとMSTIのマッピング）: どのVLANがどのインスタンスに所属するかの対応表（4096個のVLANを最大64個のMSTIに割り当てる）
4. MACアドレス（CIST情報の一部として計算に関与）: （通常はスイッチのベースMACだが、Region判定のハッシュ値生成に寄与する）
※このうち「1つでも」値が異なると、スイッチ同士は「俺たちはお互いに別のRegionにいる」と判断し、そのポートは Boundary Port（境界ポート） として扱われ、CISTインスタンス以外のMSTI情報は外側に伝播しなくなる。
—
3. 実務で役立つ！Cisco IOSおよびLinux(iproute2/bridge)での設定例
では、実際にモダンなネットワーク機器でどのようにMSTPを設定するのか。Cisco Catalyst/Nexusスイッチを想定したCLI設定と、Linuxのブリッジ機能を用いた実務的な設定例を見てみよう。
パターンA：Cisco IOSでのMSTP設定例
コアスイッチ間でVLAN 10-20をインスタンス1に、VLAN 30-40をインスタンス2に割り当て、それぞれのインスタンスでルートブリッジを分散させる（ロードバランシング）構成だ。
! --- グローバルコンフィグレーション ---
spanning-tree mode mst
!
! --- MSTリジョン設定（※全スイッチで完全に一致させること！） ---
spanning-tree mst configuration
name TOKYO-DC-CORE ! リジョン名（32文字以内）
revision 1 ! リジョンリビジョン番号
instance 1 vlan 10, 20 ! インスタンス1にVLAN 10と20をマッピング
instance 2 vlan 30, 40 ! インスタンス2にVLAN 30と40をマッピング
exit
!
! --- 冗長性とプライオリティのチューニング ---
! インスタンス0 (CIST) のルートはスイッチAをプライマリに
spanning-tree mst 0 priority 4096
! インスタンス1のルートはスイッチAをプライマリ、スイッチBをセカンダリに
spanning-tree mst 1 priority 4096
! インスタンス2のルートはスイッチBをプライマリ、スイッチAをセカンダリに
spanning-tree mst 2 priority 8192
!
! --- ポートファストとBPDUガードの有効化（エッジポートのベストプラクティス） ---
interface GigabitEthernet0/1
description === Server Access Port ===
switchport mode access
switchport access vlan 10
spanning-tree portfast edge
spanning-tree bpduguard enableパターンB：Linux (iproute2 + bridge) でのSTP設定
ベアメタルサーバーやKVMハイパーバイザーで複数の仮想ブリッジを束ねる際、あるいはソフトウェアルーターでL2フォールトトレラントを組む際、LinuxカーネルのbridgeドライバでもSTP/RSTPを有効化できる。（※厳密なMSTPのフル実装はiproute2単体では限定的だが、RSTPベースの運用やvlan-aware bridgeの組み合わせが一般的である）
#!/bin/bash
# Linuxブリッジを作成し、RSTPを有効化する実務スクリプト
# 1. ブリッジデバイスの作成
ip link add name br-mstp type bridge
# 2. ブリッジでSTPを有効化（RSTPがデフォルトで動作）
ip link set dev br-mstp type bridge stp_state 1
# 3. 物理インターフェースをブリッジに収容
ip link set dev eth1 master br-mstp
ip link set dev eth2 master br-mstp
# 4. アップ/ダウンの実行
ip link set dev eth1 up
ip link set dev eth2 up
ip link set dev br-mstp up
echo "Linux Bridge br-mstp with RSTP enabled successfully."—
4. トラブルシューティング：現場でハマる「MSTPの罠」とデバッグ手順
インフラ運用において、MSTPを導入した後に「なぜか通信できない」「VLANの一部がブラックホール化している」というトラブルに直面することは少なくない。シニアエンジニアが現場で真っ先に確認するチェックリストを公開しよう。
トラブル1：Region不一致によるトポロジの断絶
- 症状: スイッチ間をトランクで接続しているのに、特定のVLANだけ通信が通らない、あるいはポートが想定外の
BDRY（Boundary）やDISD（Discarding）になっている。 - 原因: 隣接するスイッチ間で
Configuration Name、Revision、あるいはVLAN Mappingのいずれかが1文字、1桁でも違っている。 - 確認コマンド (Cisco IOS):
show spanning-tree mst configuration このコマンドを実行し、出力される Configuration Digest（MD5ハッシュ値）が対向機器と完全に一致しているかをまず確認する。もしDigestが異なっていれば、どこかの文字やマッピングがズレている証拠だ。
トラブル2：ネイティブVLAN（Native VLAN）の不一致によるBPDUドロップ
- 症状: トランクポート上でMSTPのステートが不安定になり、ログにループ検知やTCN（Topology Change Notification）が頻発する。
- 原因: スイッチ間でアクセスVLANやネイティブVLAN（タグなしパケットの所属）が異なると、CIST（Instance 0）のBPDUが正しく解釈されず、プロトコルエラーを引き起こす。
- 確認コマンド:
show spanning-tree mst interface GigabitEthernet0/24ポートごとのステート、送信/受信しているBPDUのカウンターが正しくインクリメントされているかを追跡する。
—
5. クラウド・API時代におけるL2設計の立ち位置
「いまどきベアメタルや物理L2スイッチを触る機会なんて減ったよ」と感じるかもしれない。AWSやGCPなどのパブリッククラウドでは、VPCや仮想ルーターがL2/L3の複雑さを抽象化してくれている。
しかし、オンプレミス環境のデータセンター、ハイブリッドクラウドを繋ぐコロケーション拠点、キャリアグレードの低遅延（Low-Latency）ネットワーク、あるいはローカル5Gやエッジコンピューティングの現場では、依然として高可用なイーサネットスイッチングがインフラの土台を支えている。
APIファーストで仮想インフラを構築する時代であっても、その下を流れる物理・L2レイヤの挙動を熟知しているかどうかが、大規模障害を防ぐ最後の砦となるのだ。
まとめ
- MSTP（IEEE 802.1s） は、RSTPの高速収束性を保ちつつ、VLANグループごとにインスタンスを分けて負荷分散（マルチパス）を可能にする決定版プロトコル。
- 導入のキモは 「Regionを構成する4つのパラメータ（名前、リビジョン、マッピング、MAC）」を完全一致させること。
- トラブル時は慌てずに
show spanning-tree mst configurationでDigestの一致を確認し、ポートごとのステートを追うべし。
プロトコルの深淵を覗くことは、ネットワークという巨大な生命体の呼吸を聞くことに似ている。ぜひ自身の環境でもMSTPを正しく設計・実装し、美しく洗練されたマルチパスL2ネットワークを作り上げてほしい。
コメント