【実務・中級編】 IEEE 802.1w Rapid Spanning Tree Protocol (RSTP) の仕組みと高速収束 – インフラ・物理＆L2/L3ネットワーク基礎実践ガイド

ネットワークの「沈黙」を許すな：RSTP (IEEE 802.1w) が実現する真の高速収束メカニズム

ネットワークエンジニアの皆さん、こんにちは。現場で「STPが収束するまでコーヒーを飲みに行く」なんていう余裕をかましていた時代は、もう過去の話です。現代のミッションクリティカルな環境において、リンクダウンから30秒〜50秒もトラフィックが流れないなんて事態は、そのままビジネスの致命傷になりかねません。

今回は、STPの「遅すぎる」という呪縛を解き放った IEEE 802.1w (RSTP: Rapid Spanning Tree Protocol) について、その神髄を掘り下げていきます。

STPという「先代」の限界

オリジナルの 802.1D STP は、慎重すぎました。すべてのノードが「本当にループしていないか？」を確認するために Listening や Learning といったタイマーを律儀に待つ。これが、トポロジ変更時にネットワークが一時的に「ブラックホール」化する原因です。

これに対し、RSTPは「待つ」のではなく「握手（ハンドシェイク）」をするという発想の転換を行いました。

RSTPの高速収束を支える「3つの柱」

RSTPがなぜ速いのか。それは、単にタイマーを短縮したからではありません。以下の構造的な進化が鍵を握っています。

1. ポートロールの拡張と進化

802.1Dでは Root と Designated だけでしたが、RSTPは以下の2つを定義しました。

Alternate Port: Root Portのバックアップ。Root Bridgeへの別のパス。
Backup Port: 同じセグメント内で、自分がDesignated Portであるにもかかわらず、別のポートがより良いパスを提供している状態（ハブを使った古い構成などで発生）。

これらが定義されていることで、もしメインのリンクが切れても、すぐに Alternate Port が Root Port に昇格できます。計算のやり直しを待つ必要がないのです。

2. Proposal / Agreement プロセス（同期ハンドシェイク）

これがRSTPの真骨頂です。対向するスイッチ間で「俺がこっちのパスを使うから、お前はブロックしてくれ」というネゴシエーションを即座に行います。

スイッチAが Proposal を送る。
スイッチBがそれを承諾し、自身の下位ポートを一旦ブロック（Sync）した上で Agreement を返す。
これが瞬時に連鎖することで、全網でトポロジが確定します。

3. Edge Port の概念

エンドデバイス（サーバーやAPなど）が接続されるポートに対し、最初から Forwarding 状態を許可する機能です（Ciscoでいう PortFast）。STP計算の対象外とすることで、リンクアップと同時に通信を開始させます。

—

実践：現場で役立つ設定と確認の勘所

実務において、RSTPを有効にする設定は非常にシンプルですが、注意点があります。まずはCisco Catalystを想定した設定例を見てみましょう。

# スパニングツリーモードをRSTPへ変更（Ciscoでは rapid-pvst）
Switch(config)# spanning-tree mode rapid-pvst

# エンドデバイス接続ポートの設定（重要：Edge Port化）
Switch(config)# interface GigabitEthernet0/1
Switch(config-if)# description "Server_Uplink"
Switch(config-if)# spanning-tree portfast  # これがEdge Portとして機能させる
Switch(config-if)# spanning-tree bpduguard enable # 誤接続防止のためBPDUが来たら即シャットダウン

現場のトラブルシューティングTips

ネットワークが期待通りに収束しない場合、あるいは「なぜかトポロジが不安定」な場合、まずは show spanning-tree コマンドで P2P (Point-to-Point) リンクとして認識されているかを確認してください。

# 状態確認コマンド
Switch# show spanning-tree vlan 10

# 確認すべきポイント:
# 1. Port Role が Alternate になっているか？
# 2. Link Type が P2P になっているか？
# ※もし Shared と表示されていたら、それはハブを介しているか、
#   全二重通信が正しく認識されていない可能性があります。

自動化時代における「ネットワークの状態」の把握

最近では、Web APIやPythonを用いてインフラの状態を監視・制御する機会も増えています。例えば、スクリプトからスイッチのトポロジ情報を取得し、異常があれば通知を飛ばすようなロジックを組むことも可能です。

以下のPythonの例は、Netmiko を使ってRSTPのステータスをチェックする際のイメージです。

from netmiko import ConnectHandler

# スイッチへの接続情報
device = {
    'device_type': 'cisco_ios',
    'host': '192.168.1.1',
    'username': 'admin',
    'password': 'password123',
}

def check_stp_status():
    with ConnectHandler(**device) as net_connect:
        output = net_connect.send_command("show spanning-tree vlan 10 detail")
        # ここで "Alternate" という文字列が含まれているかチェックし、
        # 冗長構成が正常に待機しているか監視するロジックを組む
        if "Alternate" in output:
            print("冗長パスは正常に確保されています。")
        else:
            print("警告：代替パスが見当たりません！")

check_stp_status()

最後に：ネットワークを「止まらないもの」にするために

RSTPは非常に強力ですが、あくまで「レイヤー2のループ防止策」に過ぎません。昨今のデータセンターや大規模キャンパスネットワークでは、MLAG (Multi-Chassis LAG) や EVPN-VXLAN といった技術に主役が移りつつあります。

しかし、足元のL2トポロジが正しく理解できていないエンジニアは、どれほど高尚な技術を導入しても、どこかで必ず「謎の通信断」に泣くことになります。まずはこのRSTPの挙動をパケットレベルで想像できるまで叩き込んでください。

現場からは以上です。次のトラブルシューティングも、落ち着いてパケットを追っていきましょう。