【テクニカル・上級編】 RSTP（Rapid Spanning Tree Protocol/IEEE 802.1w）の高速収束メカニズム – インフラ・物理＆L2/L3ネットワーク基礎実践ガイド

RSTP（802.1w）の深淵：なぜ「待つこと」はネットワークの罪なのか

ネットワークエンジニアにとって、STP（802.1D）の30秒から50秒にも及ぶ「あの沈黙」は、まさに悪夢だ。L2ループを防ぐという崇高な目的のためとはいえ、収束を待つ間にTCPセッションはタイムアウトし、上位レイヤーのアプリケーションは再接続の地獄に叩き込まれる。

現代のインフラに求められるのは「即時性」だ。RSTP（802.1w）がもたらした「Proposal/Agreement」ハンドシェイクは、単なるプロトコルのアップデートではない。それは、ネットワークが自身のトポロジーを「能動的」に握手しに行く、知的なプロトコルへの進化である。

1. Proposal/Agreement：握手による即時収束の魔法

従来のSTPが、タイマー（Forward Delay）という名の「神の見えざる手」を盲目的に待っていたのに対し、RSTPは隣接スイッチと直接交渉する。

RSTPの高速収束の核となるのは、P2P（Point-to-Point）リンクでのProposal/Agreementハンドシェイクだ。

1. Proposalの送出: 新たにリンクが確立されると、スイッチは自身のBPDUで「Proposal」フラグを立てて送信する。
2. 同期（Sync）: 受け取った側は、自身の非エッジポートを一時的にブロックし、自身のトポロジー情報が整合していることを確認する。
3. Agreementの返信: 準備が整えば、相手に対して「Agreement」フラグを立てたBPDUを即座に送り返す。
4. 即時転送: この交換が終わった瞬間、双方はフォワーディング状態へ移行する。

このプロセスは、RTT（Round Trip Time）が数ミリ秒であれば、物理的なリンクアップとほぼ同時に完了する。タイマー待ちなどという無駄な時間は、このプロトコルには存在しないのだ。

2. パフォーマンスとセキュリティの裏側

RSTPの恩恵は、単なる収束速度の向上だけではない。この高速性を維持しつつ、堅牢なネットワークを構築するためには、いくつかのアプローチが必須となる。

TCPバッファと再送制御の最適化

RSTPによる収束がミリ秒単位で完了すれば、上位のTCPスタックが「リンクダウン」を検知してウィンドウサイズを縮小させる前に、パスが復旧する可能性がある。しかし、万が一のパケットロスに備え、Linuxカーネルレベルでのチューニングは欠かせない。

# sysctlでのTCP設定例：ネットワークの揺らぎに対する耐性を強化する
# TCPの再送タイムアウトの下限を調整し、短い瞬断からの復帰を高速化
sysctl -w net.ipv4.tcp_retries2=5
# 輻輳制御アルゴリズムをBBRに設定し、パケットロス時のスループット低下を抑制
sysctl -w net.ipv4.tcp_congestion_control=bbr

セキュリティ：BPDU GuardとRoot Guardの鉄則

高速な収束は、裏を返せば「異常なBPDUに対する反応も速い」ことを意味する。悪意あるデバイスが接続され、偽のBPDUを流せば、瞬時にトポロジーが書き換えられる危険がある。

# Cisco IOSでのエッジポート設定（PortFast + BPDU Guard）
interface GigabitEthernet0/1
 description User_Access_Port
 switchport mode access
 spanning-tree portfast          # エッジポートとして即時転送
 spanning-tree bpduguard enable  # BPDUが来たら即座にポートを閉じる

3. トランスポート層の視点：TLSハンドシェイクへの影響

ネットワークが高速に切り替わると、TLSセッションへの影響を最小限に抑えることができる。もし収束に時間がかかれば、TLSのハンドシェイク中にACKが戻らず、クライアントはTCP再送待ち（RTO）の罠にハマる。

TLS 1.3では 0-RTT データが導入されたが、これにはリプレイアタックのリスクが伴う。RSTPでネットワークの安定性を担保し、レイヤー2からレイヤー4までの「最短経路」を維持することは、現代の暗号化通信の安定性そのものに直結しているのだ。

4. 現場の教訓：なぜRSTPは「期待通り」に動かないことがあるのか

現場でRSTPを設計する際、最大の落とし穴は「共有メディア（ハブなど）」の存在である。

半二重リンクの罠: RSTPの高速ハンドシェイクは、フル二重（Full-Duplex）かつP2P接続であることが前提だ。もし間にハブが入っていると、RSTPは従来のSTP互換モードにフォールバックし、高速性は霧散する。
トポロジー変更の伝播: Topology Change フラグが頻繁に発生すると、各スイッチはMACアドレス学習テーブルをフラッシュする。これにより一時的なフラッディングが発生し、CPU負荷が跳ね上がる。エッジポートには必ず PortFast を設定し、末端のリンクアップダウンをトポロジー変更として伝播させないことが、大規模ネットワークでの鉄則だ。

結論：プロトコルと対話するということ

RSTPは、ネットワーク機器同士が「お前はルートブリッジか？」「いや、私がルートへの最短パスを持っている」と短い言葉で交わす、究極の対話である。

我々インフラエンジニアの仕事は、単にコマンドを叩くことではない。パケットがスイッチのASICを通過し、BPDUが隣接ノードに届き、ハンドシェイクが完了するまでの「ネットワークの呼吸」を感じ取ることだ。その呼吸が止まる瞬間を最小化する——それが、RSTPという技術を深く愛する者の矜持である。