30秒の沈黙が生むビジネス損失：STPの呪縛とRSTPの解法
ネットワークエンジニアなら誰もが一度は経験する、あの冷や汗をかく瞬間がある。冗長化されたL2スイッチの配線変更、あるいは不意のリンクフラップ。その瞬間からネットワーク全体が凍りつき、主要なサーバー群への疎通がパタリと途絶える。
「……あぁ、STPが再計算を始めている」
従来のIEEE 802.1D Spanning Tree Protocol（STP）は、ループフリーなトポロジを維持するためには偉大なプロトコルだった。しかし、最大で50秒ものコンバージェンスタイム（収束遅延）を要求するその挙動は、ミリ秒単位の応答速度が求められる現代のデータセンターや、ゼロトラストを掲げる企業ネットワークにおいては、もはや致命傷になり得る。
この「30秒の沈黙」という呪縛を解き放つために生み出されたのが、IEEE 802.1w Rapid Spanning Tree Protocol（RSTP）だ。今回は、パケットの内部挙動とステートマシンの深淵に潜り込み、なぜRSTPが数秒ではなく「数秒未満（通常1秒以内）」でトポロジを再収束させられるのか、そのメカニズムを骨の髄まで解き明かしていく。
—
IEEE 802.1Dの限界：なぜSTPは遅かったのか
RSTPの凄みを理解するためには、まず先祖である802.1Dがなぜあそこまで遅かったのか、その構造的な欠陥を直視しなければならない。
802.1DのSTPは、「タイマー駆動型（Timer-driven）」のプロトコルである。
ポートがリンクアップしてから、リスニング（Listening）ステートでフォワーディングパスを計算し、ラーニング（Learning）ステートでMACアドレステーブルを温め、ようやくフォワーディング（Forwarding）に至る。この各ステートの遷移には、デフォルトで Forward Delay タイマー（15秒）が2回分（合計30秒）、さらにトポロジ変化検出前のマックスエイジ（Max Age: 20秒）を加えると、最悪の場合は50秒ものブラックアウトが発生する。
さらに絶望的なのは、802.1Dのトポロジ変更（TCN: Topology Change Notification）の伝播方法だ。
トポロジ変化を検知した非根スイッチは、親スイッチに向けて信頼性の低いTCN BPDUをアップストリーム方向に送り続ける。根スイッチ（Root Bridge）がこれを受信して初めて、全ネットワークに向けて「MACアドレステーブルのエイジング時間を短縮しろ（TCフラグ付きBPDU）」という指示がダウンストリームへ流れる。つまり、情報伝達が他力本願であり、中央集権的で、かつタイマーの満了をひたすら待つ設計になっていたのだ。
—
RSTPの核心：プロポーザル・アグリーメント機構（P/Aメカニズム）
RSTP（IEEE 802.1w）が802.1Dと決定的に異なるのは、タイマー待ちを完全に排除し、「ハンドシェイク（対話型）」のトポロジ制御へと舵を切った点にある。これを実現するのが Proposal / Agreement（P/A）メカニズム だ。
パケットレベルで何が起きているのか、2台のスイッチ（SW1がRoot、SW2がダウンストリーム）の間に焦点を当てて追ってみよう。
1. リンクの確立とポートロールの再定義
RSTPでは、ポートの役割（Port Role）が従来のRoot/Designated/Blockedに加えて、以下のように細分化・明確化される。
Root Port (RP): 根スイッチへの最短パスを提供するポートDesignated Port (DP): 下流に向けてBPDUを送出するポートAlternate Port (AP): Root Portのバックアップ（即座にRPに昇格可能）Backup Port (BP): Designated Portのバックアップ（共有メディア向け）
2. P/Aハンドシェイクのシーケンス
SW1とSW2の間で新しいリンクが物理的にアップした瞬間、以下のドラマが数ミリ秒の間に展開される。
1. 提案（Proposal）の送信:
SW1のDesignated Portが、Proposal フラグが立ったRSTP BPDUをSW2へ送信する。
2. 同期（Sync）の実行:
SW2は、受信したBPDUが自身のRoot Portからのものであることを確認すると、「お、上流が新しいパスを用意してくれたな」と認識する。ここでSW2は、ネットワーク全体のループを防ぐため、エッジポートやすでにブロックされているポートを除き、自身が持つ他のすべてのポートを一時的に「同期中（Sync）」のステート（実質的なDiscarding）にする。
3. 合意（Agreement）の返送:
SW2のすべての非エッジポートが同期を完了した瞬間、SW2はSW1のProposalに対する Agreement フラグを立てたRSTP BPDUを押し返す。
4. 即座のフォワーディング移行:
SW1はこの Agreement を受信した瞬間、タイマーを一切待つことなく、該当ポートを即座に Forwarding ステートへ昇格させる。
この一連のハンドシェイクは、リンクの両端がポイント・トゥ・ポイント（Point-to-Point）で接続されていることを前提に、ツリーの末端から根に向かって波及するように瞬時に完了する。これが、RSTPが「爆速」と呼ばれる所以である。
—
現場で役立つ：Cisco Catalyst / NX-OSにおけるRSTP（Rapid-PVST+）設定実例
理論を理解したところで、実際のエンタープライズ環境における設定を見てみよう。Cisco環境では、標準の802.1wをVLANごとに拡張した Rapid-PVST+ (Rapid Per-VLAN Spanning Tree Plus) がデファクトスタンダードとして広く使われている。
以下に、実運用で最低限押さえておくべきベストプラクティスとしての設定例を示す。
! ==========================================
! スパニングツリーモードを Rapid-PVST に変更
! ==========================================
spanning-tree mode rapid-pvst
! ==========================================
! ルートブリッジのプライオリティを明示的に固定
! (意図しないスイッチがRootになるのを防ぐ)
! ==========================================
spanning-tree vlan 10,20 root primary
spanning-tree vlan 10,20 priority 24576
! ==========================================
! エッジポート（サーバやPCが接続するポート）の設定
! P/Aメカニズムのハンドシェイクをスキップし、
! リンクアップと同時に即座にForwardingにする
! ==========================================
interface range GigabitEthernet 0/1 - 24
description === Access Ports for End-Hosts ===
switchport mode access
switchport access vlan 10
spanning-tree portfast
spanning-tree bpduguard enable
! ==========================================
! アップリンクポート（スイッチ間接続）の明示的な設定
! ポイント・トゥ・ポイントの判定を確実にし、
! RSTPの高速収束ハンドシェイクを有効化する
! ==========================================
interface range TenGigabitEthernet 0/1 - 2
description === Uplink to Core Switches ===
switchport mode trunk
spanning-tree link-type point-to-point設定の勘所とプロトコルの罠
ここで設定している spanning-tree portfast（Cisco用語。標準規格では Edge Port）は、RSTP環境において極めて重要だ。端点デバイス（サーバーやクライアントPC）が接続されるポートに対してこれを有効化しておくと、ポートがリンクアップした瞬間にP/Aメカニズムやリスニング/ラーニングのステップを完全にバイパスし、即座にフォワーディングステートに入る。
もしこの設定を忘れると、サーバのNICがリンクアップするたびにスイッチ側が「お、新しいデバイスだ。もしかしてスイッチか？ BPDUを送ってみよう……」と余計なハンドシェイクを試み、無駄な遅延やトポロジ再計算のトリガーを引いてしまう原因になる。さらに bpduguard enable を組み合わせることで、万が一ユーザーが勝手に小型スイッチを持ち込んで接続した際も、即座にポートを err-disabled に落とし、L2ループの発生を物理的・論理的に根絶やしにできる。
—
ディープなトラブルシューティング：RSTPが「遅い」と感じたら見るべきポイント
「RSTPを有効にしたのに、なぜかリンク障害時に数秒〜数十秒の途絶が発生する」
そんな現場の修羅場に直面したとき、インフラアーキテクトが真っ先に確認すべきチェックリストを伝授しよう。
1. リンクタイプの誤認（Shared Mediaの罠）
RSTPのP/Aメカニズムが機能するための最大の前提条件は、そのリンクが 「Point-to-Point」 であることだ。もし途中に古いハブが挟まっていたり、半二重（Half-Duplex）で動作していたり、あるいは一部の無線LANブリッジや特殊なレイヤー2クラウドを挟んでいる場合、スイッチは自動的にそのリンクを Shared（共有メディア）と判定する。
Sharedメディアと判定されたポートでは、古典的な802.1D互換の動作にフォールバックするため、P/Aメカニズムが封印され、高速収束の恩恵を一切受けられなくなる。
*確認コマンド例（Cisco）:*
SW-CORE# show spanning-tree interface GigabitEthernet 0/1
VLAN120 is executing the rstp compatible Spanning Tree protocol
Bridge ID has priority 24576, sysid 120, address cc38.ee11.2233
Interface descriptor is 1000000 kb/s, per peer type is administrative edge
Configured as edge by admin
Loop guard is disabled by default
Timers: message age 0, forward delay 0, hold 0
BPDUs sent 1204, received 15この出力の中で、P2p（Point-to-Point）または Shrd（Shared）のステータスを必ず確認してほしい。意図せず Shrd になっている場合は、物理層のオートネゴシエーションの不整合や、デュプレックスのミスマッチを疑うべきだ。
2. ディープなパケット解析：WiresharkでBPDUを覗く
もし挙動に納得がいかないなら、迷わずポートミラーリング（SPAN）を設定し、WiresharkでBPDUをキャプチャしてバイナリレベルで観察しよう。
RSTP（IEEE 802.1w）のBPDUは、802.1Dのバージョン1（Protocol ID: 0x0000, Version: 0x00）に対し、Version 2（Protocol ID: 0x0000, Version: 0x02） として流れる。さらに、BPDU Typeも従来のTopology Changeだけでなく、フラグバイト（Flags byte）のビット割り当てが大きく拡張されている。
- Bit 7: Proposal
- Bits 5-6: Port Role (01=Root, 10=Alternate/Backup, 11=Designated)
- Bit 4: Learning
- Bit 3: Forwarding
- Bit 1: Agreement
Wiresharkのフィルターで stp.flags.proposal == 1 や stp.flags.agreement == 1 を指定し、パケットが期待通りのタイミングで往来しているかを追跡する。パケットは嘘をつかない。ハンドシェイクのどこでAck（Agreement）が途絶えているのか一目瞭然になる。
—
結びにかえて：L2の足元を固める美学
クラウドやコンテナ、マイクロサービスが全盛の現代においても、その足元を支えているのは間違いなく堅牢なレイヤー2/3の物理・仮想ネットワークである。どれほどアプリケーション層でTLSのハンドシェイク最適化やHTTP/3のQUICチューニングを施そうとも、その下を流れるイーサネットフレームの足元（L2トポロジ）が不安定であれば、システム全体の信頼性は砂上の楼閣にすぎない。
RSTPのメカニズムを深く理解し、パケットの挙動を脳内で完全にトレースできるようになること。それは、インフラエンジニアとしての技量を示すだけでなく、予測不能な障害の荒波からシステムを守り抜くための、最も確実で強力な武器となるはずだ。
コメント