STPはなぜ「遅い」と言われたのか？RSTP（IEEE 802.1w）がもたらした高速収束の裏側と実務的チューニング
ネットワークエンジニアの皆さん、日々のインフラ運用お疲れ様です。
レイヤ2ループを防ぐための「聖域」として長年君臨してきたSpanning Tree Protocol（STP：IEEE 802d）。しかし、現代のデータセンターや高可用性が求められる企業ネットワークにおいて、障害発生時に従来のSTPが引き起こす「30秒から50秒のブラックアウト」は、もはや許されない致命傷になり得ます。
Webアプリケーションが数秒のダウンタイムですらリトライストームや504 Gateway Timeoutを引き起こす現代において、L2の収束遅延はアプリケーション層の障害に直結します。
今回は、STPの呪縛を解き放ち、リンク断をわずか数秒（数発のHelloパケット間隔）で収束させる RSTP（Rapid Spanning Tree Protocol：IEEE 802.1w） の深淵へと皆さんをご案内します。教科書的な仕様の丸暗記ではなく、パケットがワイヤー上をどう駆け抜け、スイッチのASIC内部で何が起きているのかという「リアルな挙動」を紐解いていきましょう。
—
1. なぜSTPは遅かったのか？ そしてRSTPは何を変えたのか
まずは、私たちが長年苦しめられてきたレガシーSTP（IEEE 802.1d）の罪深さを振り返る必要があります。
レガシーSTPが遅い最大の理由は、「タイマー依存の受動的なメカニズム」にありました。リンクに障害が発生した際、下位スイッチは上位からのBBP（Bridge Protocol Data Unit）の途絶を待ち（Max Age：デフォルト20秒）、その後、トポロジー変更を伝搬させながら、Listening（15秒）とLearning（15秒）という無慈悲な待機ステートを強制されました。合計で最大50秒。この間、ネットワークは沈黙します。
これに対し、RSTP（IEEE 802.1w）は以下のパラダイムシフトを起こしました。
1. 「待つ」から「合意（Agreement）を取る」へ： タイマーによる受動的な待ち時間を廃止し、スイッチ間の双方向ハンドシェイクによる能動的な同期を採用。
2. ポートロール（役割）の細分化： 従来の Blocking という曖昧なステートを解体し、明確な役割を定義。
3. トポロジー変更（TCN）の爆速化： ルートブリッジを起点としたフラッディングではなく、RSTPではエッジ（末端）での変更を即座に全域へ伝搬。
それでは、RSTPの肝となる「ポートロール」と「ポートステート」の進化を実務目線で整理しましょう。
—
2. RSTPの「ポートロール」と「ポートステート」の完全理解
RSTPでは、ポートの「役割（Role）」と「状態（State）」が完全に分離・整理されました。ここを混同すると、Ciscoの show spanning-tree の出力結果を見たときに頭が真っ白になります。
ポートロール（Role：論理的な役割）
- Root Port (RP): ルートブリッジに最も近い、パスコストが最小のポート。
- Designated Port (DP): セグメントにおいてBBPを送信（または担当）する責任を持つポート。
- Alternate Port (AP): ルートポートの「バックアップ」。上位スイッチへの別経路であり、ルートポートが死んだら即座に昇格する（旧Non-DesignatedのBlocked状態に近い）。
- Backup Port (BP): 同一スイッチ内の別ポートがセグメントのDesignatedになっている場合のバックアップ（主にハブ接続などの共有媒体向け。現代ではほぼ見かけません）。
ポートステート（State：パケット転送の可否）
RSTPでは、ポートの状態が以下の3つにシンプル化されました。
| ステート名 | BPDUの送信 | BPDUの受信 | MACアドレステーブルの学習 | データフレームの転送 |
| :— | :—: | :—: | :—: | :—: |
| Discarding | 可 | 可 | 不可 | 不可 |
| Learning | 可 | 可 | 可 | 不可 |
| Forwarding | 可 | 可 | 可 | 可 |
レガシーSTPにあった Listening や Blocking という言葉は消え、実質的に「データを通さない（Discarding）」か「通す（Forwarding）」か、その前の足場固めとしての「学習（Learning）」だけに削ぎ落とされています。
—
3. 瞬速の裏側：P2Pリンク間ハンドシェイク（Proposal / Agreement）の全貌
RSTPの高速収束の核心は、P2P（Point-to-Point）リンク間で行われる「Proposal（提案）とAgreement（合意）」のハンドシェイクにあります。
これがネットワーク上でどのように行われるのか、パケットのシーケンスを見てみましょう。
[Switch A (Root/DP)] [Switch B (Non-Root/AP)]
| |
|--- 1. Proposal (BPDUs) -------------->| (Switch Bはルートポートを選定中)
| | (Switch Bは既存のDPを一時的にDiscardingへ落とし、
| | ループの危険性を排除する = 同期(Sync))
|<-- 2. Agreement ----------------------| (準備完了の合意を返す)
| |
v v
(即座に Forwarding へ移行) (即座に Forwarding へ移行)実際のハンドシェイクのステップ
1. プロポーザルの発射: 新しくリンクアップした、あるいはトポロジーが変化したDesignatedポート（Switch A）は、Proposal フラグが立ったBPDUを対向（Switch B）に送ります。
2. 同期（Sync）の発生: Proposal を受け取ったSwitch Bは、「お、ルートが変わったな」と判断します。この時、ループを防ぐために、Switch Bの他のすべての非エッジポートを一時的に Discarding ステートに落とします（これがSyncのプロセスです）。
3. アグリーメントの返却: 同期が完了し、ループの懸念が完全に払拭されたことを確認したSwitch Bは、Agreement フラグを立てたBPDUをSwitch Aに送り返します。
4. ミリ秒単位のトランジション: Switch Aはこの Agreement を受け取った瞬間、自身のポートを Forwarding に遷移させます。Switch Bも同様に Root Port を Forwarding に引き上げます。
この一連のやり取りはタイマーを一切待ちません。BPDUの往復（通常数ミリ秒〜十数ミリ秒）だけで完了するため、体感ほぼノーディレイでリンクが確立します。
—
4. 実務で必須！Cisco Catalyst / Nexus におけるRSTP設定と現場のTIPS
それでは、実際のネットワーク機器での設定例を見ていきましょう。
Cisco IOS/IOS-XE環境を想定した、実務でそのまま使える構成です。
[Core Switch] ----(Trunk / P2P)---- [Access Switch]コアスイッチ（Root Bridge候補）の設定例
! グローバルコンフィギュレーションモード
configure terminal
! スパニングツリーのモードをRSTP（IEEE 802.1wベースのRapid PVST+）に設定
spanning-tree mode rapid-pvst
! このスイッチを強烈にルートブリッジへ誘導する（プライオリティを 0 に）
spanning-tree vlan 1-4096 root primary
! エンドデバイス（PCやサーバー）が接続されるポートはPortFastを有効化
! ※RSTPではEdge Portとして機能し、ハンドシェイクをバイパスして即座にForwardingになる
interface range GigabitEthernet 0/1 - 24
spanning-tree portfast
spanning-tree portfast bpduguard default
endアクセスイッチ側の設定例と実務Tips
configure terminal
spanning-tree mode rapid-pvst
! アップリンクポート（コアスイッチ側）の物理リンクが確実にP2Pとして動作しているか確認
! 通常、全二重（Full-Duplex）のギガビット以上であれば自動判定される
interface GigabitEthernet 0/24
description === Uplink to Core Switch ===
switchport mode trunk
! 万が一、対向がレガシーSTPやハブの場合に挙動が落ちるのを防ぐため、明示的にP2Pを指定することも可能
spanning-tree link-type point-to-point
end💡 現場のシニアからの実践Tips：トラブルシューティングの勘所
1. 「デュプレックスミスマッチ」はRSTPの天敵
もし片側のポートが何らかの理由で Half-Duplex に落ちたり、メディアコンバーターの不調でリンクタイプが Shared（共有媒体）と誤認識されると、RSTPの強力な Proposal/Agreement 機構が働きません。結果として、レガシーSTP並みの遅延（30秒待ち）に格下げされます。「あれ？RSTPなのに収束が遅いぞ？」と思ったら、まず show spanning-tree interface <interface> で物理リンクのステータス（P2Pか Sharedか、Full-Duplexか）を確認してください。
2. BPDU Guardの常時有効化
エンドユーザーのPCやアクセスポイントが接続されるポート（PortFast / Edge Port）には、必ず bpduguard を有効にしましょう。万が一、ユーザーが勝手に小型スイッチを持ち込んでループを作った場合、そのポートからBPDUを受信した瞬間にポートを err-disabled に落とし、ネットワーク全体の崩壊を防げます。
—
5. まとめ
RSTP（IEEE 802.1w）は、単に「STPのスピードが速くなった上位互換」ではありません。「タイマー依存のパッシブなプロトコルから、メッセージ交換によるアクティブな合意形成プロトコルへの脱皮」です。
インフラエンジニアとして、L2の足元がどのように固まっているかを理解しているか否かは、大規模障害時の切り分けスピードに直結します。「なぜこのポートはDiscardingなんだ？」「なぜProposalが返ってこない？」――パケットの挙動を脳内でトレースできるシニアエンジニアを目指し、今日の検証環境でぜひ show spanning-tree の出力を深く読み込んでみてください。
それでは、次のパケットの旅でお会いしましょう！
コメント