STPの呪縛からの解放：RSTP（IEEE 802.1w）Proposal/Agreementハンドシェイクがもたらす極限の収束速度とネットワーク設計の真実
ネットワークエンジニアなら誰もが一度は、L2ループによる全社ネットワークの完全停止という悪夢にうなされた経験があるはずだ。ブロードキャストストームが発生し、スイッチのCPU使用率が100%に張り付いた瞬間、監視画面は赤く染まり、Slackの通知音は止まらなくなる。
我々をその恐怖から守ってきたのが、IEEE 802.1D Spanning Tree Protocol（STP）である。しかし、従来のSTPは「安全だが、あまりにも遅い」。ポートがブロッキング状態からフォワード状態に遷移するまでに、Listening（15秒）とLearning（15秒）のタイマーを律儀に経由し、合計30秒から最悪の場合50秒ものダウンタイムを強要する。これは、ゼロトラストアーキテクチャや高可用性が絶対正義である現代のエンタープライズインフラにおいて、到底許容できる数字ではない。
この「30秒の壁」を打ち破るために登場したのが、IEEE 802.1w Rapid Spanning Tree Protocol（RSTP）だ。今回は、RSTPの真骨頂である Proposal/Agreement（P/A）ハンドシェイク のパケットレベルの挙動を解剖し、なぜこれが瞬時の高速収束を可能にするのか、そして大規模ネットワークにおける実務的なチューニングの勘所を、現場の泥臭い知見とともに深く掘り下げていこう。
—
1. 従来のSTPが抱える構造的欠陥と「タイマー依存」の限界
なぜ従来のSTPはあんなにも遅いのか。その根本原因は、「自分が正しいトポロジにいるかどうかの確信を、タイマーの経過によってしか得られない設計」にある。
従来のSTPでは、ポートがリンクアップした際、まず Listening 状態になり、自ら送出するコンフィグBPDU（Bridge Protocol Data Unit）と対向から来るBPDUを比較してトポロジの計算を行う。ループを防ぐためには、古いトポロジの情報がネットワークから完全に消え去るのを待つ必要があり、これが冒頭の Listening（15秒）と Learning（15秒）という固定タイマーを生み出していた。
[リンクダウン / 変更発生]
↓ (STP)
[Listening (15秒)] : トポロジ計算中。データ転送不可
↓
[Learning (15秒)] : MACアドレス学習中。データ転送不可
↓
[Forwarding] : やっと通信開始（合計 30〜50秒の停止）この「受動的なタイマー待ち」を根本から覆し、「明示的なハンドシェイクによる双方向の合意」によって状態遷移を瞬時（数ミリ秒〜1秒以内）に行う仕組みこそが、RSTPの核心である。
—
2. RSTPの心臓部：Proposal / Agreement（P/A）ハンドシェイクの全貌
RSTPでは、BPDUのフォーマット自体が拡張されている。従来のSTPでは無視されていたBPDUヘッダの「Flags」フィールドの全8ビットが活用され、特に Proposal ビットと Agreement ビットが追加されたことで、スイッチ間の会話が可能になった。
パケットキャプチャの現場でこのハンドシェイクがどのように行われているか、そのシークエンスを紐解こう。
P/Aハンドシェイクのステップ・バイ・ステップ
1. リンクアップとProposalの送信
新しくリンクアップしたポート（例えばRoot Port候補）を持つスイッチAが、対向のスイッチBに向けて Proposal ビットが立ったBPDUを送信する。これは「俺がこのセグメントの新しいRoot指定ポートになる。お前のポートは Discarding（旧Blocking）にしてくれ」という強い要求だ。
2. 同期処理（Sync）の発生
Proposal を受信したスイッチBは、自身が持つ他のすべての指定ポート（Designated Port）を一時的に Discarding 状態へと強制的に落とし、トポロジのループを防ぐ。これを Sync（同期） と呼ぶ。この同期が完了した瞬間、スイッチBの内部でループの可能性が完全に排除される。
3. Agreementの返送
スイッチBは、自身の全ポートの同期が完了したことを確認すると、スイッチAに対して Agreement ビットが立ったBPDUを返送する。「お前のProposalを承認する。これでループの危険は消えた」という合図だ。
4. 即座のForwarding遷移
Agreement を受け取ったスイッチAは、タイマーを待つことなく、そのポートを即座に Forwarding 状態へ遷移させる。
[Switch A (Root)] [Switch B (Non-Root)]
│ │
│── 1. BPDU (Proposal=1) ──────────────────>│ (指定ポートへ昇格要求)
│ │ (※Switch Bは他ポートをSyncしDiscardingへ)
│ │
│<── 2. BPDU (Agreement=1) ─────────────────│ (合意を返答)
│ │
(即座に Forwardingへ) (即座に Forwardingへ)この一連のハンドシェイクは、リンクの両端がポイント・トゥ・ポイント（Point-to-Point）で接続されていることが前提条件となる。ハブを介した共有メディア環境では、この決定論的なハンドシェイクが破綻するため、RSTPは自動的に旧来のレガシーSTP動作へとフォールバックする。
—
3. レガシーSTPとの互換性維持（Backward Compatibility）のメカニズム
現実のネットワーク移行期において、すべてのスイッチを一斉にRSTPへアップグレードすることは不可能だ。既存のレガシーSTP（802.1D）が稼働するスイッチと、最新のRSTP（802.1w）が混在する環境下で、どのように互換性が維持されているのか。
RSTPの各ポートは、内部で RSTP Mode と STP-Compatibility Mode を動的に切り替えるステートマシンを持っている。
- マイグレーションの挙動
RSTPを有効にしたポートが、対向からレガシーなSTPの構成BPDU（Flagsフィールドがクリアされたもの）を受信すると、そのポートは自ら「自分はレガシー環境に接続された」と判断し、送信するBPDUを旧形式にダウングレードする。
- タイマー依存への一時的回帰
ダウングレードされたポートは、P/Aハンドシェイクの利用を停止し、従来の Listening / Learning タイマーに従った動作にフォールバックする。
この互換性維持は非常にスマートに実装されているが、現場のインフラアーキテクトとしては注意が必要である。「一部の古いエッジスイッチが混ざっているだけで、セグメント全体の高速収束の恩恵が失われる」というボトルネックが発生するためだ。段階的移行を行う際は、エッジ部分のスイッチリプレースを優先し、コア・ディストリビューション層は早期に完全なRSTP環境（欲を言えばMultiple Spanning Tree Protocol: MSTP / IEEE 802.1s）へと移行すべきである。
—
4. 現場で役立つ実務的設定とチューニングの勘所
理論を理解したところで、実際のLinuxベースのネットワークOS（Cumulus Linux / SONiC）や、Cisco Catalyst / Nexus環境におけるRSTPの設計・運用のベストプラクティスを見ていこう。
Cisco IOS/IOS-XEにおけるRSTP（Rapid PVST+）の実装例
現代のCisco環境では、単なるRSTPではなく、VLANごとに独立したRSTPインスタンスを走らせる Rapid PVST+ がデファクトスタンダードとなっている。
! グローバルコンフィグレーションモードでスパニングツリーのモードを Rapid-PVST に変更
spanning-tree mode rapid-pvst
! ルートブリッジの優先度を明示的に固定（コアスイッチAをプライマリ、Bをセカンダリに）
spanning-tree vlan 1-4094 root primary
spanning-tree vlan 1-4094 priority 4096
! エッジポート（サーバや端末が接続するポート）には PortFast を有効化
! これによりリンクアップと同時に即座に Forwarding になり、P/Aハンドシェイクの対象外とする
interface range GigabitEthernet0/1 - 24
spanning-tree portfast
spanning-tree portfast bpduguard default
! ※万が一BPDUが飛んできた場合はポートをシャットダウンしてループを物理的に阻止（BPDU Guard）Linuxブリッジ（bridgeコマンド）におけるRSTPの設定例
Kubernetesのノード間接続や仮想化基盤の内部ネットワークでLinuxブリッジを構築し、冗長化のためにSTPを有効化する場合、iproute2パッケージの bridge コマンドを用いる。
#!/bin/bash
# ==============================================================================
# LinuxブリッジにRSTP（IEEE 802.1w）を有効化する設定スクリプト
# ==============================================================================
BRIDGE_NAME="br-enterprise"
# 1. ブリッジインターフェースの作成
ip link add name ${BRIDGE_NAME} type bridge
# 2. STPの有効化 (IEEE 802.1w / RSTP を指定)
# ※ デフォルトのSTPから高速なRSTPへ切り替える
ip link set dev ${BRIDGE_NAME} type bridge stp_state 1
sysctl -w net.bridge.bridge_nf_call_iptables=0
# 3. 物理インターフェースをブリッジに参加させ、リンク特性を設定
for iface in eth1 eth2; do
ip link set dev ${iface} master ${BRIDGE_NAME}
ip link set dev ${iface} up
# ブリッジポートのコスト設定（帯域に応じた適切なパスコスト）
bridge link set dev ${iface} cost 4
# ポイント・トゥ・ポイント接続の強制（RSTPのP/Aハンドシェイクを確実に機能させる）
# ※共有メディア（ハブ等）が存在しないことが確実な場合に有効
bridge link set dev ${iface} hairpin off
done
ip link set dev ${BRIDGE_NAME} up
echo "RSTP-enabled Linux bridge ${BRIDGE_NAME} has been successfully configured."—
5. セキュリティとパフォーマンスの交差点：RSTP運用における潜在的リスク
ネットワークセキュリティスペシャリストの視点から見逃してはならないのが、「STP/RSTPプロトコル自体には認証機構が標準では存在しない」という根本的な脆弱性である。
悪意ある攻撃者が社内ネットワークのアクセスポートに自前のPCや不正なスイッチを接続し、極端に低いプライマリ優先度（例: Priority 0）を設定したRSTPのBPDUを流し込んだ場合、何が起きるか？
ネットワーク全体がその不正なデバイスを「ルートブリッジ」と誤認し、トポロジが強制的に再計算される。結果として、すべてのトラフィックが攻撃者の端末を通過するよう誘導され、Man-in-the-Middle（中間者攻撃）やトラフィックのブラックホール化（DDoS）が瞬時に完成してしまう。
必須のセキュリティハードニング
エンタープライズの境界防御および内部セグメンテーションにおいて、RSTPを安全に運用するためには、以下の機能を必ず実装しなければならない。
1. BPDU Guard（BPDUガード）
端末接続用のアクセスポート（エッジポート）でBPDUを受信した場合、即座にポートを err-disable 状態にし、不正なスイッチの接続を物理的・論理的に遮断する。
2. BPDU Filter（BPDUフィルター）
エッジポートから不要なBPDUの送信を完全に停止し、無駄なトラフィックの抑制と外部へのトポロジ情報の漏洩を防ぐ。
3. Root Guard（ルートガード）
ディストリビューション層やコア層のアップリンクポートに設定し、「このポートからは上位のルートブリッジからのBPDU以外は受け付けない（もし自社より優先度の高いBPDUが来たらポートを Root-Inconsistent 状態にして遮断する）」ことで、外部からのルートハイジャックを物理的に防ぐ。
—
結びに代えて：高速化と堅牢性のバランス
RSTPのProposal/Agreementハンドシェイクは、パケットレベルの細やかな対話によって、従来のSTPの「待ち時間」という最大の足かせを綺麗に消し去った傑作プロトコルである。
しかし、技術がどれほど高速化されようとも、ネットワークを支えるエンジニアの「セキュリティに対する嗅覚」が鈍れば、一瞬にして堅牢なアーキテクチャは崩壊する。P/Aハンドシェイクの裏側で何が行われているのかをパケットのバイナリレベルでイメージし、BPDU GuardやRoot Guardといった適切な防御壁を張り巡らせること。それこそが、真にセキュアでハイパフォーマンスなエンタープライズネットワークを作り上げる唯一の道なのである。
コメント