待ったなしの再収束：RSTP (IEEE 802.1w) が実現する「瞬殺」のレイヤ2トポロジー
ネットワークエンジニアにとって、STP（802.1D）の「30秒〜50秒」という収束時間は、もはや悪夢以外の何物でもない。クラウドネイティブな時代、物理層やデータリンク層で数十秒のブラックアウトが発生すれば、TCPの再送タイマーはタイムアウトし、アプリケーション層のTLSハンドシェイクは分断され、ユーザー体験は地に堕ちる。
本稿では、レガシーなSTPを過去のものにしたRSTP（IEEE 802.1w）の深淵に潜り、なぜ彼らが「高速」であり得るのか、そのパケットレベルの挙動を解剖する。
—
1. 概念の転換：ステートマシンから「提案と同意」へ
従来のSTPが「タイマー頼み」の受動的なプロトコルであるのに対し、RSTPは「P2P（Point-to-Point）リンク」を前提とした能動的な合意形成プロトコルだ。
Proposal/Agreement (P/A) ハンドシェイクの正体
RSTPの高速収束の核は、BPDUの交換による即時交渉にある。
1. Proposal: 指定ポート（Designated Port）が隣接スイッチへ「私をルートパスにしてほしい」と要求を投げる。
2. Sync: 隣接スイッチは、自身の他のポートを一時的にブロッキング状態に追い込み、トポロジーの整合性を保つ「同期」を行う。
3. Agreement: 同期が完了したことを確認し、即座にフォワーディング状態へ移行する。
このプロセスにより、従来の Listening や Learning といった冗長な待ち時間をバイパスし、パケット転送をミリ秒単位で再開させるのだ。
—
2. 現場で生きるチューニング：エッジポートの重要性
RSTPを語る上で避けて通れないのが Edge Port（Cisco用語でいう PortFast）の設定だ。これを怠れば、末端のPCが接続されるたびにトポロジー変更（TC）が走り、ネットワーク全体が揺らぐことになる。
# Cisco IOSでの設定例
interface GigabitEthernet0/1
description Access_Port_To_Workstation
# エッジポートとして定義し、接続時に即座にForwardingへ移行させる
spanning-tree portfast
# BPDUガードを併用し、予期せぬスイッチ接続を物理層でブロックする
spanning-tree bpduguard enableここで重要なのは、BPDU Guard の併用だ。エッジポートにスイッチが接続されると、本来ならRSTPの計算が走り、ネットワークが不安定化する。これを検知してポートを即座にシャットダウンさせるのは、インフラ防衛の基本である。
—
3. パフォーマンスの深淵：TCPバッファとRSTPの相関
もしあなたが「L2の収束が速ければ全て解決」と考えているなら、それは少し甘い。収束中にバッファリングされていたパケットが、再開と同時に一気にフラッドされる（バーストトラフィック）ことで、スイッチのASICバッファを枯渇させることがある。
特に、高スループットなTLS通信を行っている場合、ネットワークの瞬断はTCPウィンドウサイズの縮小を招き、再送制御によるスループット低下を引き起こす。
- パケット解析の視点: RSTPの収束直後、
TCP Retransmissionが多発していないかを確認せよ。 - カーネルチューニング: Linuxサーバー側で
net.ipv4.tcp_slow_start_after_idleをオフにすることで、再接続後のスループット回復を早めるチューニングも検討すべきだ。
# TCPのアイドル後のスロースタートを無効化し、再接続後の性能低下を防ぐ
sysctl -w net.ipv4.tcp_slow_start_after_idle=0—
4. セキュリティ：BPDUを巡る攻防
RSTPの脆弱性は、悪意のあるBPDUが注入されることにある。攻撃者が高い優先度（Bridge Priority 0）を持つBPDUを流せば、トポロジーを意図的に変更し、トラフィックを傍受（MITM攻撃）することが可能だ。
これを回避するための「鉄則」は以下の通りである。
1. Root Guard: 許可していないポートから、ルートブリッジのBPDUを受け取らないようにする。
2. BPDU Filter: 信頼できないエッジに対して、BPDUの送受信を一切遮断する。
# ルートブリッジの座を死守するためのガード設定
interface GigabitEthernet0/24
description Uplink_To_Untrusted_Segment
spanning-tree guard root—
結論：プロトコルを「制御」するということ
RSTPは、単なる802.1wの仕様書に留まらない。それは、ネットワークの「可用性」という抽象的な概念を、パケットのハンドシェイクという「物理的現実」に落とし込むための工学的な回答だ。
大規模なL2ドメインを維持するインフラアーキテクトにとって、RSTPの挙動をパケットキャプチャ（tcpdump や Wireshark）で追い、各ポートのステート遷移をOSI参照モデルの観点から理解することは、トラブルシューティングの最後の砦となる。
次にネットワークが「瞬断」したとき、それはプロトコルの不備ではなく、あなたの設計の甘さかもしれない。常にパケットの流れる先を想像し、ビットの揺らぎを制すること。それが、ネットワークスペシャリストの矜持だ。
コメント