こんにちは。ネットワークの深淵を愛するインフラアーキテクトの私だ。
Web APIの設計やモダンなクラウドインフラの構築に日々奔走するエンジニアの君たちなら、L3（IP）層のルーティングやロードバланシングの仕組みについては語り尽くしていることだろう。だが、ふと足元を見下ろしてほしい。その下を支えるL2（イーサネット）の世界では、静かに、しかし強烈なプレッシャーを放ちながらパケットの海を律する「古の守護神」が稼働していることをご存じだろうか。
そう、スパニングツリープロトコル（STP / IEEE 802.1D）だ。
「いまどき物理スイッチなんて触らないよ、全部クラウドの仮想VPCだろ？」と思ったそこの君。ちょっと待ってほしい。クラウドのアンダーレイでも、オンプレミスのデータセンターでも、工場やオフィスのフロアスイッチでも、冗長化された物理・論理レイヤー2トポロジが存在する限り、ブロードキャストストームという悪夢を防ぐためにSTP（あるいはその進化系であるRSTPやMSTP）が必ず裏で動いている。
今回は、数々のL2障害現場で血を流してきたシニアエンジニアの視点から、STPの基本原理、パケットの動き、そして現場で役立つ実務的なコンフィグとデバッグのノウハウを余すところなく伝授しよう。
—
なぜL2ループは「死」を意味するのか？
レイヤー3のIPパケットには、お馴染みの TTL（Time to Live） フィールドが存在する。ルーティングループに陥っても、TTLが0になった瞬間にパケットはパージされ、ネットワーク全体の崩壊は免れる。
しかし、レイヤー2のイーサネットフレームには、このような「寿命」の概念が存在しない。
もしスイッチ間に冗長パス（ループ）が存在し、その状態でブロードキャストフレーム（ARPリクエストやDHCPdiscoverなど）が流れるとどうなるか。スイッチは受信したポート以外のすべてのポートへフレームを転送（フラッディング）するため、フレームは永遠にネットワーク内を回り続ける。
[スイッチA] <---- (リンク1) ----> [スイッチB]
^ ^
| |
(リンク2) (リンク3)
| |
+-----------> [スイッチC] <-------+
（無限ループの発生源）この現象をブロードキャストストームと呼ぶ。数秒のうちにリンクの帯域は100%枯渇し、スイッチのCPU使用率は跳ね上がり、マネジメントプレーンへのアクセスすら奪われて、現場は完全な「ブラックアウト」に陥る。
この恐怖のループを、パケットの転送を止めずに「論理的なツリー構造」を作り出すことでスマートに解決するのが、STPの真髄なのだ。
—
STPの基本原理と三種の神器
IEEE 802.1Dで規定されたSTPは、ネットワーク全体を1つの「全域木（Spanning Tree）」に形作ることでループを排除する。そのためにスイッチ同士が会話をし、以下の3つの役割を決定する。
1. ルートブリッジ（Root Bridge）：
ネットワーク全体の「根」となる頂点スイッチ。すべてのパス計算はこのスイッチを基準に行われる。
2. ルートポート（Root Port / RP）：
非ルートブリッジが「最もコスト的・論理的にルートブリッジに近い」と判断した自身のポート。各非ルートブリッジに必ず1つ存在する。
3. 指定ポート（Designated Port / DP）：
セグメント（リンク）ごとに、ルートブリッジに向かって最も良質なBPDUを送出する側のポート。
そして、これらから漏れた「不要な冗長パス」のポートは、フレームの送受信を停止するブロッキング状態（Discarding）に置かれる。
STPの頭脳：BPDU（Bridge Protocol Data Unit）
スイッチ同士は、BPDU と呼ばれる制御フレームをマルチキャスト（01:80:c2:00:00:00）で常時（デフォルトでは2秒おきに）交信し合っている。BPDUの中身には、主に以下のパラメータが含まれている。
- ブリッジID（Bridge ID）：
プライオリティ（通常4096単位、デフォルト32768）＋ MACアドレス。この値が「若い（小さい）」ほど偉い。
- ルートID（Root ID）：
現在、そのスイッチが認識している「ルートブリッジのブリッジID」。
- パスコスト（Root Path Cost）：
ルートブリッジまでの累積コスト。リンクの速度に応じて決まる（100Mbpsなら19、1Gbpsなら4、10Gbpsなら2など）。
スイッチの起動時、すべてのスイッチは「自分がルートブリッジだ」と勘違いした状態でBPDUをばら撒く。その後、お互いのBPDUを比較し合い、「最もプライオリティとMACアドレスが若い奴」を全会一致でルートブリッジとして戴冠する。これがSTPの収束（Convergence）のプロセスだ。
—
通信フローとポートステートの遷移
STPが有効なポートは、単に「ON/OFF」するわけではない。ループを確実に防ぐため、ポートが有効化されてから実際にトラフィックを流し始めるまでに、慎重なステート遷移を行う。
従来の802.1Dでは、以下のステップを踏む。
[ポート有効化]
↓
[Blocking（ブロッキング）] : データ送受信不可、BPDU受信のみ
↓ (Max Ageタイマー満了: 通常20秒)
[Listening（リスニング）] : MACアドレステーブルの学習なし、BPDU送受信
↓ (Forward Delayタイマー: 通常15秒)
[Learning（ラーニング）] : MACアドレステーブルの学習開始、データ転送はまだ不可
↓ (Forward Delayタイマー: 通常15秒)
[Forwarding（フォワーディング）] : 完全なデータ送受信が可能お気づきだろうか。従来のSTPは、トポロジに変化があった際、安全のために最大で約50秒ものコンバージョンタイム（収束時間）を要する。この間、通信は完全にブラックアウトする。本番環境のWeb APIやデータベース通信において、50秒の無通信断は致命傷になりかねない。
そのため、現在のモダンなインフラでは、これを数秒（数秒以内）に短縮した RSTP（Rapid Spanning Tree Protocol / IEEE 802.1w） の利用がデファクトスタンダードとなっている。
—
実務で使える設定例と現場のノウハウ
ここからは、Cisco Catalyst / IOS-XE環境を想定した実務的なコンフィグと、現場で踏みがちな「地雷」を回避するためのTipsを解説する。
1. 冗長スイッチの基本コンフィグ例
ネットワークの心臓部となるコア・ディストリビューション層のスイッチでは、意図しないスイッチがルートブリッジに選ばれないよう、プライオリティを明示的に固定するのが鉄則だ。
! --- プライマリルートブリッジ（最優先）の指定 ---
Switch-A(config)# spanning-vlan 10,20 root primary
! （内部的にプライオリティが 24576 などに自動調整される）
! --- セカンダリルートブリッジ（バックアップ）の指定 ---
Switch-B(config)# spanning-vlan 10,20 root secondary
! （内部的にプライオリティが 28672 などに自動調整される）
! --- 収束を高速化するため、モードを RSTP (Rapid-PVST+) に変更 ---
Switch-A(config)# spanning-tree mode rapid-pvst
Switch-B(config)# spanning-tree mode rapid-pvst2. エンドユーザー接続ポートへの必須設定（PortFast / BPDU Guard）
これが実務で最も重要だ。サーバーのNICや仮想化基盤（ESXi等）のアップリンク、あるいはルーターが接続されるアクセスポートに対して、デフォルトのSTP計算を適用させてはならない。
もしサーバー側のポートでSTPが動作していると、ケーブルを挿した瞬間にListening/Learningステートを挟むため、リンクアップ直後のDHCPやARPがドロップし、起動失敗の原因になる。さらに、ユーザーが誤ってスイッチを持ち込んでループを作った際に、ネットワーク全体が巻き込まれるリスクもある。
! --- アクセスポートの定義 ---
Switch-A(config)# interface GigabitEthernet 0/1
Switch-A(config-if)# switchport mode access
Switch-A(config-if)# switchport access vlan 10
! --- PortFastの有効化（Listening/Learningをスキップし即座にForwardingへ） ---
Switch-A(config-if)# spanning-tree portfast
! --- BPDU Guardの有効化（万が一、このポートからBPDUを受信したらポートをerr-disabledにする） ---
Switch-A(config-if)# spanning-tree bpduguard enableもし、bpduguard が有効なポートにユーザーが勝手にスイッチを接続してBPDUを送信してきた場合、スイッチは即座にそのポートを err-disabled（エラー無効状態）にしてネットワークの崩壊を未然に防ぐ。インフラエンジニアの夜間呼び出しを防ぐための必須の防衛策だ。
—
トラブルシューティング：障害発生時のデバッグ手順
「突然、社内ネットワークの特定セグメントの通信が途絶えた」「ログに不穏なメッセージが出ている」
そんな修羅場で使える、CLIでの実務的な確認コマンドの流れを記そう。
① ルートブリッジと現在のトポロジの把握
まず、どのスイッチがルートブリッジになっているかを確認する。意図しない安物のスイッチがルートになっていないか？
Switch# show spanning-tree vlan 10
VLAN0010
Spanning tree enabled protocol ieee
Root ID Priority 24586
Address aabb.cc00.1100
This bridge is the root <-- 自機がルートならこう出る
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 24586 (priority 24576 sys-id-ext 10)
Address aabb.cc00.1100
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec② ポートのステートとロールを確認する
通信できない端末が接続されているポートや、アップリンクのポートがどのステートにあるかをチェックする。
Switch# show spanning-tree interface GigabitEthernet 0/24
Interfaceprot Role Sts Cost Prio.Nbr Type
----------------------------------------------------------------
Gi0/24 Desg FWD 4 128.24 P2p- Role:
Root（ルートポート）,Desg（指定ポート）,Altn（代替ポート/ブロック中） - Sts:
FWD（Forwarding）,LIS（Listening）,LRN（Learning）,BLK（Blocking/Discarding）
もし、ステートがいつまで経っても LIS や LRN から動かない（Listening/LearningループやTCNの嵐）場合、物理レイヤーのフラッピング（リンクダウン・アップのチャタリング）が疑われる。
③ ログの確認
システムログに以下のようなメッセージが頻発していないか確認せよ。
%SPANTREE-5-TOPOTCHANGE: Topology change received on port Gi0/1 - VLAN0010
%PM-4-ERR_DISABLE: bpduguard error detected on Gi0/2, putting Gi0/2 in err-disable stateTOPOTCHANGE が高頻度で発生している場合、どこかの物理ケーブルが不良を起こしているか、ループ障害の発生・復旧が繰り返されているサインだ。
—
まとめ
スパニングツリープロトコルは、一見すると「遅い」「面倒くさい」レガシーなプロトコルに見えるかもしれない。しかし、イーサネットの根本である「ブロードキャスト・フラッド」という宿命をコントロールし、L2ネットワークの信頼性を担保してきた偉大な仕組みであることに変わりはない。
モダンなインフラを設計・運用する私たちであっても、物理・論理の境界線にあるSTPの挙動を正しく理解し、適切なプライオリティ設計や PortFast / BPDU Guard などのセキュリティ対策を施すこと。それこそが、真にレジリエントなシステムを作り上げるためのプロフェッショナルとしての嗜みである。
さあ、今日のデプロイが終わったら、スイッチのコンソールを開いて show spanning-tree を叩いてみよう。そこには、静かにトポロジを守り続ける美しい木の姿があるはずだ。
コメント