RSTPのポートロールとステート遷移：数秒のコンバージェンスに別れを告げるL2スパニングツリーの極限最適化
ネットワークエンジニアのキャリアにおいて、スパニングツリープロトコル（STP：IEEE 802.1D）のコンバージェンスを待つあの「30秒から50秒」の沈黙は、誰もが一度は冷や汗をかいたトラウマではないだろうか。冗長化構成をとったはずのコアスイッチでリンク障害が発生し、L2のトポロジーが再計算されるまでの間、オフィスフロア全体が静まり返る。あの絶望的な待ち時間を過去のものにしたのが、IEEE 802.1wによって標準化され、のちにIEEE 802.1D-2004に統合されたRSTP（Rapid Spanning Tree Protocol）であるタイマー依存型の旧来モデルを完全に破壊し、プロポーザル／アグリーメント（Proposal/Agreement）という同期メカニズムを導入したRSTPの本質は、その「ポートロール（Port Roles）」と「ポートステート（Port States）」の再定義にある。
今回は、パケットのワイヤフォーマットレベルの挙動から、現代の大規模データセンターやキャンパスネットワークにおけるL2フォワーディングの極限最適化まで、RSTPの深淵を解き明かしていく。
—
1. 従来のSTPの呪縛とRSTPがもたらしたパラダイムシフト
従来の802.1D STPは、コンバージェンスの遅さを「タイマー」に依存していることに起因していた。トポロジーの変化を検知しても、Max Age（最大20秒）やListening、Learningの各ステートにおけるForward Delay（各15秒、計30秒）を律儀に待つ仕様だったため、トータルで最大50秒ものブラックアウトが発生する。
これに対し、RSTPはタイマー待ちの概念をほぼ排除し、「トポロジーの即時合意（Sync）」によってミリ秒単位の切り替えを実現している。この超高速コンバージェンスを支えているのが、新しく定義されたポートの「役割（Role）」と「状態（State）」の分離である。
旧来のポートステートとの対比
| 802.1D (STP) ステート | 802.1w (RSTP) ステート | フォワーディング動作 | 学習動作 (MACアドレス) |
| :— | :— | :— | :— |
| Disabled | Discarding | 停止 | 停止 |
| Blocking | Discarding | 停止 | 停止 |
| Listening | Discarding | 停止 | 停止 |
| Learning | Learning | 停止 | 有効 |
| Forwarding | Forwarding | 有効 | 有効 |
RSTPでは、ステートの数が実質的に Discarding、Learning、Forwarding の3つに整理された。特筆すべきは、従来の「非指定ポート（Blocking）」が、パケットをドロップしつつもMACアドレステーブルのフラッシュを避けるためにトポロジー情報を監視し続けるという、より洗練された役割へと昇華した点だ。
—
2. RSTPの4つのポートロール（Port Roles）
RSTPでは、BPDU（Bridge Protocol Data Unit）のやり取りを通じて、各ポートに厳密な役割が割り当てられる。802.1DのRoot、Designated、Non-Designatedに加え、バックアップと代替の概念が明文化された。
① Root Port (RP)
ブリッジからルートブリッジ（Root Bridge）に至るまでのパスコストが最小となる、最適パスを提供するポート。各ノンルートブリッジにつき必ず1つだけ存在する。
② Designated Port (DP)
セグメント（リンク）単位で、ルートブリッジに向かうBPDUを送信する責任を持つポート。セグメントにおいて最も優れたBPDUを送出するスイッチのポートがこの役割を担う。
③ Alternate Port (AP)
ルートポートの「バックアップ」である。他ブリッジから送出された優れたBPDUを受信するが、自らがルートポートではないため、現在のセグメントにおいてはフォワーディングを行えない。ルートポートがダウンした際、タイマーを待たずに即座に新しいルートポートに昇格できる（これがRoot Guardや UplinkFastの概念をプロトコルレベルで内包している所以だ）。
④ Backup Port (BP)
同一セグメント内に接続された別のスイッチからのBPDUを受信する、デザインテッドポート（DP）の「バックアップ」である。共有メディア（ハブ等）環境や、同一スイッチ間に複数の物理リンクがL2で直結されている誤った冗長構成（ポートチャネル未設定時）などで出現する。
—
3. パケットレベルで見るProposal / Agreementのメカニズム
RSTPが「ラピッド（迅速）」たる所以は、下流のスイッチとの間で交わされる Proposal/Agreement（P/A）ハンドシェイク にある。この挙動をパケットキャプチャの視点で追ってみよう。
1. リンクアップの検知:
新しくリンクが接続されると、双方のポートは一旦 Discarding ステートになり、自身を Designated Port と仮定して BPDU（RSTPフラグフィールドの Proposal ビットが立ったもの）を送出する。
2. 同期（Sync）の連鎖:
下流のスイッチが上流からの Proposal を受信すると、自身の下流にある他のすべてのポートをいったん Discarding ステートに落とし（これが Sync 状態）、トポロジーの整合性を保つ。
3. アグリーメント（Agreement）の返送:
同期が完了した下流スイッチは、上流スイッチに対して Agreement ビットが立った BPDU を送り返す。
4. 即座のフォワーディング遷移:
Agreement を受信した上流スイッチのポートは、タイマーを待つことなく、即座に Forwarding ステートへと遷移する。
このハンドシェイクはツリーの末端から根元に向かって波及するため、ネットワーク全体が数ミリ秒〜数十ミリ秒で収束する。
—
4. 実務における設計・チューニングとコンフィグレーション
Cisco Catalyst / Nexus や Linuxブリッジ環境におけるRSTP（Rapid-PVST+を含む）のベストプラクティスと、実運用のための設定サンプルを見ていこう。
Cisco IOS / IOS-XE における設定例
実運用環境では、エンドホスト（サーバーやPC）が接続されるアクセスポートに対して無駄なP/AハンドシェイクやTCN（Topology Change Notification）の発生を防ぐため、必ず spanning-tree portfast（Ciscoでは portfast はRSTP環境下でもエッジポートとして機能する）を有効化する必要がある。
! グローバルコンフィグレーションでRSTP (Rapid-PVST+) を有効化
spanning-tree mode rapid-pvst
spanning-tree extend system-id
! コア間を結ぶバックボーンポートの明示的設定
interface GigabitEthernet0/1
description === Uplink to Core-SW02 ===
switchport mode trunk
spanning-tree portfast disable
spanning-tree link-type point-to-point ! ポイントツーポイントリンクを強制しP/Aを高速化
! エンドホスト（サーバー・仮想化基盤）が接続されるアクセスポート
interface GigabitEthernet0/24
description === Connection to Hypervisor-Node01 ===
switchport mode access
switchport access vlan 100
spanning-tree portfast edge ! エッジポートとして即座にForwardingへ
spanning-tree bpduguard enable ! 不正なスイッチ接続を防ぐセキュリティ機能Linux (iproute2 / bridge) におけるRSTPの設定
ベアメタルサーバーやLinuxルーター、KVMホスト上でソフトウェアブリッジを構成し、L2の冗長化を行う場合も、カーネルのブリッジモジュールでRSTPを有効化することが可能だ。
#!/bin/bash
# LinuxカーネルブリッジでRSTPを有効化するスクリプト
BRIDGE_NAME="br0"
INTERFACES=("eth0" "eth1")
# ブリッジデバイスの作成
ip link add name $BRIDGE_NAME type bridge
# RSTP (IEEE 802.1w) を有効化 (stp_state 2 がRSTPに相当)
ip link set $BRIDGE_NAME type bridge stp_state 2
ip link set $BRIDGE_NAME type bridge priority 32768
# メンバーインターフェイスをブリッジにアタッチ
for iface in "${INTERFACES[@]}"; do
ip link set $iface master $BRIDGE_NAME
ip link set $iface up
# ホストポートとしてのパスコストやプライオリティの微調整
bridge link set dev $iface cost 4
bridge link set dev $iface hairpin off
done
# ブリッジインターフェイス自体の有効化
ip link set $BRIDGE_NAME up
echo "Linux Bridge $BRIDGE_NAME with RSTP is now active."—
5. 現場のインフラエンジニアが陥る「RSTPの罠」とセキュリティ対策
プロトコルがどれほど洗練されていいても、現場のオペレーションミスや悪意ある攻撃の前には無力化することがある。ここではインフラアーキテクトが絶対に押さえておくべき「落とし穴」を挙げる。
① 共有メディア（Shared Link）とポイントツーポイントの誤認
RSTPの真骨頂である Proposal/Agreement は、リンクが Point-to-Point（全二重通信）であることが前提となっている。もしハブや旧式のL2スイッチ、あるいは設定ミスによって半二重（Half-Duplex）リンクや共有セグメントと判定されると、RSTPは旧来の802.1D互換モードにフォールバックし、コンバージェンス速度が著しく低下する。
- 対策:
spanning-tree link-type point-to-pointを明示的にスタティック設定し、デュプレックスのミスマッチを監視する。
② 不正なBPDUインジェクション（TCNリファレンス攻撃）
悪意あるユーザーがアクセスポートに自前のスイッチを接続し、強力なルートプライオリティを持ったBPDUや、意図的にTCN（Topology Change Notification）を流し続けた場合、ネットワーク全体でMACアドレステーブルのフラッシュが頻発し、CPU使用率のスパイクや深刻なパケットロス（ブラックホール化）を引き起こす。
- 対策:
- BPDU Guard: エッジポートでBPDUを受信した場合、即座にポートを
err-disabledに落とす。 - Root Guard: 不正な上位BPDUを受け入れてルートブリッジの座を奪われるのを防ぐため、指定ポートがルートブリッジを変更するようなBPDUを受信した場合、ポートを
Root-Inconsistent（実質的なDiscarding）状態にロックする。
! Root Guard の適用例（外部接続トランクポートなど）
interface GigabitEthernet0/2
description === Connection to External ISP / Partner L2 ===
switchport mode trunk
spanning-tree guard root—
6. まとめ
RSTPのポートロール（Root, Designated, Alternate, Backup）とステート（Discarding, Learning, Forwarding）の有機的な連携は、単なる「STPの高速化パッチ」ではない。それは、L2ネットワークというフラットな空間において、自律分散システムが極限まで無駄を削ぎ落とし、トポロジーの整合性を保つための数学的・プロトコル的洗練の極みである。
パケットがワイヤー上を駆け抜け、P/Aハンドシェイクがミリ単位の時間で交わされるその裏側には、プロトコル設計者たちの知恵が詰まっている。インフラエンジニアとして、単にコマンドを叩くだけではなく、このステート遷移のダイナミクスを脳内で完全に再現できるようになること――それこそが、障害に強く、美しく堅牢なネットワークを構築するための最大の武器となる。
コメント