【実務・中級編】スパニングツリープロトコル（STP：IEEE 802.1D）の基本アルゴリズムとコンバージェンスの遅延課題 – インフラ・物理＆L2/L3ネットワーク基礎実践ガイド

なぜネットワークは「沈黙」するのか？——STPの呪縛と802.1Dの現実

インフラエンジニアの端くれなら、一度は経験があるはずだ。深夜のメンテナンス中、冗長化のためにケーブルを一本挿した瞬間、社内の通信が完全にストップし、監視ツールが真っ赤に染まる。ログを確認すれば、そこには無慈悲な %SW_MATM-4-MACFLAP_NOTIF の嵐。

そう、すべての元凶は STP（Spanning Tree Protocol / IEEE 802.1D） だ。

Web APIの設計やモダンなクラウドインフラに慣れ親しんだエンジニアほど、「L2ループ？スイッチ側で勝手に止めてくれるんでしょ？」と楽観視しがちだが、その「勝手に止めてくれる」裏側で何が起きているかを知らなければ、本番環境での障害は避けられない。

今回は、現代ネットワークにおいても無視できない「STPの教養」について、現場の視点から掘り下げていこう。

—

1. なぜ「ループ」がパケットを殺すのか

イーサネットのヘッダーには、IPのような TTL（Time To Live）フィールドが存在しない。つまり、一度ループに迷い込んだフレームは、ネットワーク機器のバッファが溢れるまで、あるいはリンクが物理的に切断されるまで、永遠に転送され続ける。

結果、ブロードキャストストームが発生し、スイッチのCPUは100%に張り付き、最終的にネットワーク全体が「沈黙」する。STPはこの悲劇を防ぐための「治安維持部隊」だ。

ルートブリッジ選出のアルゴリズム

STPは、ネットワーク内に「木構造（Tree）」を形成することでループを論理的に排除する。その頂点に立つのが ルートブリッジ（Root Bridge） だ。

選出ロジックは極めてシンプルだ。
1. ブリッジプライオリティ（デフォルトは32768）: 小さい値が優先。
2. MACアドレス: プライオリティが同じなら、小さい値が優先。

実務上のTipsだが、「ルートブリッジは必ずコアスイッチに固定する」こと。これを怠ると、貧弱なアクセススイッチがネットワークの頂点に立ってしまい、予期せぬ通信ボトルネックを生むことになる。

—

2. BPDU：沈黙を破るための「生存確認」

STPの主役は、2秒おきに交換される BPDU（Bridge Protocol Data Unit）という小さな制御パケットだ。この中には、ルートブリッジの識別子やパスコストといった情報が詰め込まれている。

BPDUの重要なパラメーター

Root ID: 誰がルートブリッジか。
Root Path Cost: ルートブリッジまでの累積コスト。帯域が広ければコストは下がる（10Gbpsなら2、100Mbpsなら19など）。
Bridge ID: 自分自身の識別子。

もし、STPが稼働しているポートでBPDUを受け取らなくなったらどうなるか？スイッチは「相手とのリンクが断たれた」と判断し、ブロックしていたポートを解放しようと動く。ここに、STP最大の弱点である「収束時間の遅さ」がある。

—

3. なぜコンバージェンスに「30秒」かかるのか

IEEE 802.1Dの仕様では、ポートが Blocking から Forwarding に切り替わるまでに、Listening（15秒）と Learning（15秒）の計30秒を要する。

Blocking (データ転送停止)
  ↓ (20秒: Max Age経過)
Listening (BPDU待機)
  ↓ (15秒)
Learning (MACアドレス学習)
  ↓ (15秒)
Forwarding (通常通信開始)

この「合計30秒〜50秒の通信断」は、現代のWebサービスでは致命的だ。APIのリクエストタイムアウト設定が5秒であれば、その間にシステムは崩壊する。

実務での回避策：PortFast

サーバーを接続するエッジポートには、STPの計算プロセスをバイパスさせる PortFast（Cisco用語、他ベンダーでは Edge Port）を設定するのが鉄則だ。

Cisco Catalystでの設定例:

interface GigabitEthernet0/1
 description Server_Node_01
 # STPの計算を待たずに即座にForwardingへ移行させる
 spanning-tree portfast
 # BPDUを受け取ったら即座にポートをシャットダウンしてループを防ぐ
 spanning-tree bpduguard enable

※ bpduguard を忘れてはいけない。誤ってスイッチが接続された瞬間にループが発生するのを物理的に防ぐ保険だ。

—

4. インフラの挙動を「観測」する

最後に、スイッチの背後で何が起きているかを確認する方法を紹介する。PythonやCLIを使って、ネットワークの状態を監視する際の一助にしてほしい。

スイッチの設定確認（CLI）

# ルートブリッジの確認
show spanning-tree vlan 10

# どのポートがブロックされているか、コストはどうなっているかを確認
show spanning-tree interface gi0/1 detail

Pythonで簡易的な監視を行う（Netmiko活用例）

ネットワーク運用で自動化を導入する際、Netmiko を使って各スイッチのSTPステータスを定期的に取得し、Blocking 状態のポートが増えていないか監視するスクリプトを書くのは定石だ。

from netmiko import ConnectHandler

# 接続情報
device = {
    'device_type': 'cisco_ios',
    'host': '192.168.1.1',
    'username': 'admin',
    'password': 'password123',
}

# 状態取得
with ConnectHandler(**device) as net_connect:
    output = net_connect.send_command("show spanning-tree vlan 10")
    if "BLK" in output:
        # 実際にはここでSlack通知等を飛ばす
        print("警告: STP Blocking状態のポートが検出されました")

—

結びに代えて：STPは「終わった技術」ではない

STPは古いプロトコルだが、その思想（冗長性とループ回避のトレードオフ）は現代のデータセンターネットワークにも形を変えて受け継がれている。最近では MSTP や RSTP、あるいはVXLANなどのオーバーレイ技術が主流だが、物理レイヤーの根幹で何が起きているかを知らなければ、どんなに高度なAPI設計も、ネットワークの「一瞬の沈黙」の前では無力だ。

トラブルシュートの際、コマンドの結果だけで判断せず、その背景にある「なぜこのポートはブロックされたのか？」という問いを常に持ち続けてほしい。それが、シニアエンジニアへの第一歩だ。