STPの「待ち時間」にサヨナラを。RSTPで実現する瞬時の収束と、現場で語り継ぐべきポートの真実
ネットワークエンジニアとして現場を歩いていると、いまだに「STP（Spanning Tree Protocol）は遅い」という言葉を耳にします。確かに、オリジナルの802.1Dは、リンク障害時に最大50秒ものコンバージェンス（収束）時間を要しました。しかし、現代のインフラでその猶予は許されません。
今回は、IEEE 802.1w、すなわちRSTP（Rapid Spanning Tree Protocol）の深淵に潜り込みます。なぜRSTPは「即座に」切り替わることができるのか？その仕組みと、実務で絶対に押さえておくべきポートの作法について、泥臭い知見を交えて解説しましょう。
—
1. 概念の破壊：ポートロールと状態の再定義
従来のSTPが「待つ」ことでループを防いでいたのに対し、RSTPは「握手（プロポーズ）」をすることで即座に通信を開始します。まずは、混乱しがちなポートロール（役割）とステートを整理しましょう。
ポートロール（役割）
RSTPでは、役割が明確に分担されています。
- Root Port: ルートブリッジまでの最短パスとなるポート（各非ルートブリッジに1つ）。
- Designated Port: セグメントごとに選出された、転送を担当するポート。
- Alternate Port: Root Portのバックアップ。ルートブリッジへの代替パスを提供します。
- Backup Port: 同一スイッチ内の冗長パス（ハブ接続などで発生する特殊なケース）。
状態（ステート）の統合
802.1Dにあった「Disabled」「Blocking」「Listening」は、すべて 「Discarding」 という一つの状態に統合されました。つまり、フレームを転送しない状態はすべて「Discarding」です。これにより、状態遷移が劇的にシンプルになりました。
—
2. なぜ「即座」に切り替わるのか：提案と合意（Proposal/Agreement）
RSTPの真骨頂は、隣接スイッチ間で行われるProposal/Agreementハンドシェイクにあります。
1. スイッチAが、自身がDesignated Portであることを主張して「Proposal」を送信。
2. スイッチBは、自身のポートがRoot Portになれるかを判断。
3. 問題なければ、下位のポートを一時的にDiscarding（同期）し、相手に「Agreement」を返す。
このやり取りにより、タイマーを待たずに即座に「Forwarding」へと移行します。これは、Web APIの接続確立においてTCP 3-way handshakeで接続性を確認するのと似た、非常に理にかなった通信フローです。
—
3. 実務での設定と確認：Cisco IOSを例に
現場でRSTP（Ciscoではrapid-pvstと呼称）を導入する際の設定例です。単純なコマンドですが、ここでのミスが全断を招きます。
# グローバル設定でRSTPを有効化
switch(config)# spanning-tree mode rapid-pvst
# 特定のVLANでの優先度設定（ルートブリッジを意図的に決定する）
switch(config)# spanning-tree vlan 10 priority 4096
# エッジポート（PCやサーバー接続用）の設定
# これを忘れると、エッジポートのリンクアップ時にSTP計算が走り、通信断が発生します
switch(config-if)# interface GigabitEthernet 0/1
switch(config-if)# spanning-tree portfast # エッジポートとして即座にForwardingへ
switch(config-if)# spanning-tree bpduguard enable # 誤接続防止の保険—
4. Pythonでネットワーク状態を監視する
インフラの自動化が進む現代では、手動でshowコマンドを叩くのは卒業です。Netmikoを使って、ポートの状態がForwardingになっているかを定期的にチェックするスクリプトを書いてみましょう。
from netmiko import ConnectHandler
# 接続デバイス定義
device = {
'device_type': 'cisco_ios',
'host': '192.168.1.1',
'username': 'admin',
'password': 'password'
}
def check_stp_status():
with ConnectHandler(**device) as net_connect:
# STPのステータスを取得
output = net_connect.send_command("show spanning-tree vlan 10")
# 簡易的なバリデーション：全ポートがForwardingか確認
if "BLK" in output or "DIS" in output:
print("警告: 意図しないDiscardingポートを検知しました！")
else:
print("正常: 全ポートがForwarding状態です。")
if __name__ == "__main__":
check_stp_status()—
5. シニアエンジニアからのTips：現場の落とし穴
最後に、RFCの仕様書には載っていない「現場の教訓」を一つ。
「エッジポート設定（PortFast）を疎かにするな」
サーバーを接続するポートにspanning-tree portfastを設定し忘れると、NICがリンクアップした瞬間、スイッチはそのポートでSTP計算を開始します。サーバーのOSがIPアドレスを取得しようとしても、スイッチ側がまだListeningやLearningで止まっていれば、DHCPリクエストやAPIの初期疎通はタイムアウトします。
Webサービスの構築において、この数秒のロスは致命的です。インフラを設計する際は、物理層の接続が整った後の「論理的な接続待ち時間」をいかにゼロにするか。それが、真のネットワークスペシャリストの腕の見せ所です。
RSTPは単なるプロトコルではなく、現代のクラウドネイティブな環境においても安定した足場を提供する重要なバックボーンです。ぜひ、今日の構成図をもう一度見直し、不要な「待ち時間」が潜んでいないか確認してみてください。
コメント