STPポート状態遷移の深淵:物理・L2レイヤーの静けさと、その裏で鼓動するBPDUの生態系
ネットワークエンジニアのキャリアにおいて、最も美しく、そして最も歯痒いプロトコルの一つがSpanning Tree Protocol(STP:IEEE 802.1D)である。現代のハイパースケールなデータセンターでは、TRILLやSPB、あるいはEVPN-VXLANといったルーテッドアクセス/ファブリックアーキテクチャが主流となり、クラシックなSTPは「悪者」扱いされることも少なくない。
しかし、エッジスイッチや小規模拠点、あるいは予期せぬレイヤー2のループポイントにおいて、STPは今なお無言の守護神として私たちのインフラストラクチャを支えている。
「なぜスパニングツリーの収束にはあんなにも時間がかかるのか?」
「トポロジー変更(TCN)が起きた際、データプレーンの裏側では何が起きているのか?」
教科書的な4つの状態遷移(Blocking $\rightarrow$ Listening $\rightarrow$ Learning $\rightarrow$ Forwarding)をただ暗記しているだけでは、実環境で発生するマイクロバースト、パケットロス、あるいはマルチキャストストームの真の原因にたどり着くことはできない。今回は、パケットレベルの内部挙動とLinuxブリッジカーネルの挙動をも視野に入れ、STPのポート状態遷移の深淵へと迫る。
—
1. ループ防止の代償:なぜSTPのポート遷移には「時間」が必要なのか
イーサネットのデータプレーンには、IPレイヤーのような「TTL(Time-to-Live)」が存在しない。つまり、スイッチ間に物理的な環状結線(ループ)が存在する場合、一度ブロードキャストされたフレームは永久にL2空間を回り続け、瞬時にリンクの帯域を飽和させ、最終的にはCPUの過負荷によるスイッチのダウン(ハンギング)を引き起こす。
この致命的な現象を防ぐため、STPはネットワーク全体で単一の論理的ツリー(Spanning Tree)を構築する。この過程において、各ポートは段階的に権限と役割を与えられ、データフレームの転送可否を制御する。それが以下の4つの状態遷移である。
1. Blocking(ブロッキング)
2. Listening(リスニング)
3. Learning(ラーニング)
4. Forwarding(フォワーディング)
これらに、初期状態である Disabled(ディスエーブルド) を加えた5つのフェーズが、Classic STP(802.1D)の基本構造となる。各状態における挙動の差異を以下のマトリクスに整理する。
| ポート状態 | BPDUの送受信 | MACアドレス学習 | データフレーム転送 | 存続期間(タイマー) |
| :— | :— | :— | :— | :— |
| Disabled | 不可 | 不変 | 不可 | 管理者依存 |
| Blocking | 受信のみ(送信不可) | 不可 | 不可 | 最大 Max Age (20秒) |
| Listening| 可 | 不可 | 不可 | Forward Delay (15秒) |
| Learning | 可 | 可(テーブル構築)| 不可 | Forward Delay (15秒) |
| Forwarding| 可 | 可 | 可 | 永久(トポロジー変化まで)|
なぜ、即座にForwardingに移行せず、このような冗長なステップを踏むのか。最大の理由は「一時的なL2ループ(過渡期ループ)の完全排除」と「MACアドレステーブルの汚染防壁」にある。
ネットワークトポロジーが変化した瞬間、全スイッチが同時に新しいツリーの形状を理解できるわけではない。情報伝播のタイムラグ(プロパゲーション遅延)が存在するため、もし末端のポートが即座に転送を開始すれば、古いトポロジーの情報に基づいたフレームが逆流し、致命的なブロードキャストストームが発生する。このタイムラグを安全に吸収するためのバッファが、Forward Delay(デフォルト15秒)という時間なのだ。
—
2. 4つの状態におけるパケットレベルの内部挙動
ここからは、各状態をパケットおよびスイッチのASIC/カーネルの視点から解剖する。
2.1 Blocking 状態:静寂のオブザーバー
ポートが物理的にリンクアップした直後、あるいはルートブリッジからの選定により「不要なパス」と判定されたポートは、まずBlocking状態に入る。
- データプレーンの挙動: すべてのユーザートラフィック(ユニキャスト、マルチキャスト、ブロードキャスト)の送受信を完全に破棄(Drop)する。ASICのハードウェアレベルで、入力ポートのL2パケットパーサーが該当ポートからの入力を無視するようにマスクされる。
- コントロールプレーンの挙動: ルートブリッジから送出される配置確認用BPDU(Configuration BPDU)の「受信」のみを行う。自身からBPDUを送信することは原則としてない(トポロジー変更時にTCN BPDUを上流へ流す例外を除く)。
- タイマー: デフォルトで20秒の
Max Ageタイマーが満期を迎えるか、上流からのBPDUロスト検知によって次の状態へ遷移する。
2.2 Listening 状態:コンセンサスの形成
Blockingを抜けたポート、あるいはトポロジー変化の兆候を捉えたポートはListeningに昇格する。
- データプレーンの挙動: 引き続き、ユーザートラフィックの転送およびMACアドレスの学習は一切行わない。データプレーンはまだ「沈黙」を保っている。
- コントロールプレーンの挙動: ここから自らもBPDUの送受信に参加する。自身が計算したツリー構造の正当性を周囲のスイッチとアサート(主張)し合い、ポートの役割(Root Portか Designated Portか)を最終確定させる。
- タイマー: この状態の継続時間は
Forward Delay(デフォルト15秒)に縛られる。
2.3 Learning 状態:記憶の蓄積と防壁の構築
Listeningタイマーが満期(15秒経過)になると、ポートはLearning状態に移行する。ここが実務上、非常に重要なポイントとなる。
- データプレーンの挙動: ユーザートラフィックの転送はまだ行わない。しかし、入力されてくるフレームのソースMACアドレス(SA)を抽出し、MACアドレステーブルへの動的学習(Aging Tableの更新)を開始する。
- なぜ転送しないのに学習するのか?:
もし転送しながら学習を行おうとすると、ポートがForwardingになった瞬間にアドレステーブルが空っぽであり、初期フラッディング(Flooding)が大量発生してネットワークが一時的に麻痺する。あらかじめデータプレーンに流れるトラフィックからMACアドレスを「予習(Learning)」しておくことで、Forwarding移行直後から精度の高いユニキャスト転送を実現し、フラッディングによる無駄な帯域消費を防ぐのだ。
- タイマー: 再び
Forward Delay(15秒)の間、この状態を維持する。
2.4 Forwarding 状態:完全開放
Listeningから15秒、Learningから15秒、合計で最低でも30秒(Blockingからだと最大50秒)の厳格な検証期間を経て、ポートはようやくForwarding状態に到達する。
- データプレーンの挙動: すべての制約が解除される。受信したフレームはMACアドレステーブルを元にスイッチングされ、宛先ポートへワイヤレートで転送(Forward)される。
- コントロールプレーンの挙動: 定期的なHello BPDU(通常2秒ごと)の送受信を継続し、トポロジーの健全性を監視し続ける。
—
3. 実務インフラにおけるリスクとパフォーマンス最適化
古典的な802.1D STPの「最大50秒かかる収束時間」は、現代の高可用性システム(Webアプリケーションのロードバランスや金融系トランザクション)においては許容しがたい遅延である。この課題を解決するため、そして実運用でハマりがちな罠を回避するための知見を整理する。
3.1 802.1w (RSTP) への移行と「PST / Proposal-Agreement」のメカニズム
現代のネットワークでは、IEEE 802.1Dは事実上レガシーであり、後継であるRSTP(Rapid Spanning Tree Protocol – IEEE 802.1w)が標準である。
RSTPでは、従来の複雑な状態遷移を以下の3つに簡素化し、収束時間を秒単位(数秒〜サブセコンド)に短縮している。
- Discarding(Blocking / Listening / Disabledを統合)
- Learning
- Forwarding
この高速化の鍵が、Proposal / Agreement(提案と合意)ハンドシェイクである。
ポイントツーポイント(全二重)リンクにおいて、スイッチは下流のスイッチに対して「私が新しいルートポートになる(Proposal)」と宣言し、下流が即座に他のすべてのポートをエッジ/ブロッキング化して「合意する(Agreement)」ことで、タイマー待ちを一切バイパスして即座にForwardingへ移行する。
3.2 Linuxカーネル(ブリッジ)におけるSTP設定とチューニング
仮想化基盤(KVM/QEMU)やコンテナホスト、あるいはLinuxルーターにおいて、ソフトウェアブリッジ(br0)を構築する際、STPがデフォルトで無効化されているか、あるいは適切に設定されていないと思わぬL2ループを引き起こす。
以下に、Linux環境(iproute2およびbridgeユーティリティ)で安全かつ高速なブリッジ環境を構築するための設定例を示す。
#!/bin/bash
# ==============================================================================
# Linux ソフトウェアブリッジにおけるRSTP/STP最適化スクリプト
# 対象OS: Ubuntu 22.04 LTS / RHEL 9 等の近代Linuxディストリビューション
# ==============================================================================
BRIDGE_NAME="br0"
INTERFACES=("eth0" "eth1")
echo "[*] ブリッジデバイス ${BRIDGE_NAME} を作成します..."
ip link add name ${BRIDGE_NAME} type bridge
echo "[*] 物理インターフェースをブリッジにアタッチします..."
for iface in "${INTERFACES[@]}"; do
ip link set dev ${iface} master ${BRIDGE_NAME}
ip link set dev ${iface} up
done
echo "[*] STP (Spanning Tree Protocol) を有効化し、RSTP(802.1w)モードに設定します..."
# 0を渡すとSTP有効(プレースホルダー)、1(rstp)を指定して高速収束を有効化
ip link set dev ${BRIDGE_NAME} type bridge stp_state 1
ip link set dev ${BRIDGE_NAME} type bridge protocol rstp
echo "[*] フォワードディレイ(Forward Delay)を安全な最小値(例: 4秒)にチューニング..."
# デフォルトの15秒は仮想環境のコンバージェンスには長すぎるため短縮
ip link set dev ${BRIDGE_NAME} type bridge forward_delay 400
echo "[*] ブリッジインターフェースを起動します..."
ip link set dev ${BRIDGE_NAME} up
echo "[+] 設定が完了しました。現在のブリッジ状態を確認します:"
bridge link show
3.3 セキュリティ上の脅威:Rogue Root Bridge Attack (不正ルートブリッジ攻撃)
STPには、OSI参照モデルのL2レイヤーで動作するという特性上、認証機構が標準ではほとんど存在しない(BPDU Guard等の機能に依存する)。
もし、攻撃者が悪意ある端末をアクセスポートに接続し、自らを最高優先度(例: Priority 0)に設定したConfiguration BPDUを大量に送り込んだ場合、ネットワーク全体のトポロジーが強制的に書き換わり、すべてのトラフィックがその不正な端末経由(中間者攻撃:MitM)にルーティングされてしまう。
対策:BPDU Guard と Root Guard の実装
Cisco Catalystや現代のエンタープライズスイッチでは、エンドデバイスが接続されるポートに対して以下の防御策を講じるのが「インフラの常識」である。
- BPDU Guard: エンドユーザー向けポート(Access Port)でBPDUを受信した瞬間、ポートを
ErrDisabled(エラーディスエーブル)状態に落とし、不正なトポロジー変更を防ぐ。 - Root Guard: アップリンクではないダウングレード可能なポートにおいて、外部からより優先度の高いBPDUを受信した場合に、そのポートを
Root-Inconsistent(ブロッキング)状態に固定し、ルートブリッジの座を守り抜く。
[正常なネットワーク]
(Core Switch: Priority 4096) <--- [Root Guard] --- (Access Switch: Priority 32768)
[攻撃者の介入]
(Attacker: Priority 0) ===[悪意あるBPDU]===X---> [Root Guardによりポート遮断!] (Access Switch)
—
4. 結びにかえて
STPのポート状態遷移(Blocking $\rightarrow$ Listening $\rightarrow$ Learning $\rightarrow$ Forwarding)は、一見すると泥臭く、非効率な「足踏み時間」に見えるかもしれない。しかし、その裏側では、目に見えないパケットの奔流とトポロジーの整合性を保つための精緻なステートマシンが駆動している。
インフラエンジニアとしての真価が問われるのは、「動いているシステムをただ眺める時」ではなく、「予期せぬL2ループによる障害が起きた時」、あるいは「クラウドネイティブなオーバーレイネットワークの基盤となる物理L2を設計する時」である。
パケットがたどる物理と論理の境界線を脳内に描き出しながら、確実でレジリエントなネットワークを構築してほしい。プロトコルの深淵を愛する者にとって、そこには常に美しく合理的な答えが隠されているのだから。
コメント