STPの「待ち時間」にサヨナラを。RSTP（802.1w）が現場のネットワークを救う理由
ネットワークエンジニアとして現場に立つと、避けて通れないのが「ループ」の恐怖と、それを防ぐための Spanning Tree Protocol (STP) です。しかし、レガシーな 802.1D STP を使っている現場では、リンクダウンから復旧まで「数珠つなぎのスイッチで最大50秒」なんていう、現代のWebサービスでは致命的なダウンタイムが発生します。
今回は、その悪夢を終わらせる RSTP (IEEE 802.1w) の高速収束メカニズムを、現場のリアリティを交えて深掘りしていきましょう。
なぜSTPは「遅い」のか？ そしてRSTPは何をしたのか
従来のSTPは、スイッチ同士が「お互いに隣接しているか」を、タイマー（Forward Delay）に頼って確認していました。この「待つ」という行為が、ネットワークの可用性を殺していたのです。
RSTPが革命的だったのは、「タイマーに依存せず、スイッチ同士が能動的に会話を始めた（Proposal/Agreementハンドシェイク）」点にあります。
高速収束を支える「ポートロール」の刷新
RSTPでは、ポートの役割を細分化することで、ルートスイッチが落ちた際の切り替え速度を劇的に向上させました。
- Root Port (RP): ルートブリッジへ向かう最短パス。
- Designated Port (DP): 各セグメントの代表ポート。
- Alternate Port: ルートポートの「バックアップ」。RPがダウンした瞬間、即座に昇格する（これが
UplinkFast的な役割を果たす）。 - Backup Port: 同じスイッチ内の別セグメントへの冗長パス。
特に Alternate Port の存在が重要です。STPでは「もしもの時のためにスタンバイさせておく」という概念が希薄でしたが、RSTPでは常に「次の一手」を計算してキャッシュしているため、切り替えが瞬時（サブセカンド）に行われます。
現場で使える設定：Cisco CatalystにおけるRSTP（Rapid-PVST+）
実務でCatalystスイッチを扱う際、単なる spanning-tree vlan 1 ではなく、必ず rapid-pvst を明示的に指定します。
! ネットワーク全体の収束を高速化する設定
spanning-tree mode rapid-pvst
! 特定のアクセスポートをエッジポート（PC接続等）として指定
! これにより、ポートアップ直後に転送状態へ移行させる
interface GigabitEthernet0/1
description Workstation_Port
spanning-tree portfast
spanning-tree bpduguard enable ! 誤接続によるループを防ぐ保険この spanning-tree portfast は、RSTP環境下では「エッジポート」として機能します。エッジポートはトポロジー変化の影響を受けないため、リンクアップと同時に通信を開始できるのです。
監視と運用の知見：PythonでSTPの健全性をチェックする
インフラ運用において、どのポートが現在 Forwarding で、どれが Discarding なのかをスクリプトで把握しておくことは、大規模なL2環境を管理する上で必須です。Netmiko を使えば、スイッチのステータスをAPI感覚で取得できます。
from netmiko import ConnectHandler
# スイッチへの接続定義
switch = {
'device_type': 'cisco_ios',
'host': '192.168.1.10',
'username': 'admin',
'password': 'secret_password',
}
def check_stp_status():
with ConnectHandler(**switch) as net_connect:
# STPのステータスを確認するコマンド
output = net_connect.send_command("show spanning-tree vlan 10")
# 簡易的なパース処理
if "Forwarding" in output:
print("STP Status: Normal - Port is Forwarding")
else:
print("STP Status: ALERT - Potential blocking or down state")
# 実行
if __name__ == "__main__":
check_stp_status()運用上の注意点：RSTPを導入する際の「落とし穴」
どんなに優れたRSTPでも、設計を間違えればネットワークは崩壊します。以下の3点は、現場で必ず確認してください。
1. BPDUの遮断: WebサービスのAPIゲートウェイやロードバランサーを繋ぐポートで、意図せず BPDU を送出するような設定（または誤ったL2ループ）がないか。bpduguard を徹底すること。
2. トポロジー変化（TCN）の連鎖: エッジポートの設定を忘れると、PCの電源を入れるたびにネットワーク全体で「トポロジー変更」の通知が飛び、MACアドレステーブルがフラッシュされて通信が一瞬途切れます。
3. 異機種混在: 802.1w は標準規格ですが、メーカーやベンダーによって「PVST（VLANごとのインスタンス）」の挙動に微妙な差異があります。特に Cisco と Juniper を混ぜる際は、MSTP (802.1s) への統一を検討すべきです。
最後に：プロトコルを「信じすぎない」勇気
RSTPは非常に賢いプロトコルですが、ネットワークの安定性はプロトコルの力だけでは作れません。私が現場で一番大切にしているのは、「何が起きてもおかしくないという前提で、物理的なセグメンテーション（VLAN分離）と論理的な制限（BPDU Filter/Guard）を掛け合わせること」です。
パケットがどのポートを通り、どのポートが Alternate として待機しているのか。show spanning-tree の結果が、頭の中でリアルタイムにイメージできれば、あなたはもう一人前のインフラエンジニアです。
次回の運用保守時には、ぜひ debug spanning-tree events を眺めながら、Proposal/Agreement のやり取りが瞬時に終わる様を目撃してください。ネットワークが「生きている」ことを実感できるはずです。
コメント