こんにちは、シニアネットワークエンジニアの私だ。日頃からWeb APIのパフォーマンスチューニングやインフラの自動化に奔走している君たちなら、「L2ループを阻止する最後の砦」としてSTP（Spanning Tree Protocol）の名前を聞いたことがあるはずだ。
しかし、現代のデータセンターやアクセスレイヤーの設計において、すべてのポートで教科書通りのSTPを無邪気に動かすのは、時として百害あって一利なしの状況を生む。特に、Cisco CatalystやNexus、あるいはAristaのEOSといったモダンなスイッチング機器を触る現場では、「端末（ホスト）が接続されるポートで、なぜ無駄なBPDUが流れているのか？」という疑問に直面する。
今回は、STPの拡張機能の中でも、エッジポートの無駄な通信を断ち切り、エッジの挙動をクリーンにする「BPDU Filter（BPDUフィルター）」の深淵へと君たちを案内しよう。
—
渋滞するL2ネットワーク：なぜBPDU Filterが必要なのか？
通常、STPが有効なスイッチポート（Ciscoでいう PortFast が有効なポートなど）は、接続された端末がL2ループを作らないことを前提に、リスニングやラーニングの遅延をスキップして即座にフォワード状態へ移行する。
しかし、デフォルトの状態では、そのポートからも相変わらず数秒おきにBPDU（Bridge Protocol Data Unit）という制御フレームが送信され続けている。
[スイッチ (BPDU送信)] ===(BPDUフレーム)===> [Linuxサーバー / Hypervisor]ここで考えてみてほしい。
1. 無駄な帯域の消費: 接続されているのは純粋なL2/L3ホスト（LinuxサーバーやKubernetesのノードなど）であり、背後にスイッチは存在しない。ホストにとってSTPのBPDUは「ゴミ」でしかない。
2. セキュリティリスク: ホスト側が何らかのパケット解析ツール（tcpdump やWireshark）を動かしている場合、不要なSTPトポロジ情報が丸見えになる。
3. 予期せぬ挙動: 一部の仮想化ハイパーバイザーやセキュリティアプライアンスは、受信したBPDUを異常トラフィックと誤検知したり、CPUに負荷をかけたりすることがある。
こうした背景から、「ホスト側とはBPDUのやり取りを完全に遮断したい」という強いニーズに応えるために生まれたのが BPDU Filter である。
—
BPDU Filterの動作原理：送信と受信のコントロール
BPDU Filterの挙動を深く理解するためには、それが「どこで」「どのように」パケットを止めるのかを把握しなければならない。ベンダー（主にCisco等）によって多少の差異はあるが、基本理念は共通している。
BPDU Filterには大きく分けて「グローバル有効（ポート単位のPortFast連動）」と「インターフェース個別設定」の2つのアプローチが存在し、それぞれ送受信の制御が異なる。
1. インターフェース個別設定（完全な送受信停止）
特定のポートにハードコードでBPDU Filterを設定した場合、そのポートはBPDUを一切送信せず、仮に受信してもすべて破棄（またはSTPを無効化）する。
- 送信側（Tx）: BPDUを一切送出しない。
- 受信側（Rx）: 外部からBPDUを受信した場合、BPDU Filterの効果が外れて通常のSTPポートに戻る（PortFast無効化）か、ポートがErr-disabledになるなどの保護動作に移行する（※実装による）。
2. グローバル設定（PortFast連動型）
Ciscoの spanning-room portfast bpdufilter default コマンドに代表される挙動だ。
PortFastが有効化されているポートに対して、「普段はBPDUを送信しないが、万が一向こうからBPDUが飛んできた場合は、BPDU Filterを即座に解除して通常のSTPに参加する」という非常にスマートな動作をする。
[スイッチ] --(BPDU送信ストップ)-- X [L2ホスト]
[スイッチ] <--(BPDUを受信)-- [誤って接続された下流スイッチ] -> (即座にBPDU Filter解除 & STP有効化でループ防止)この「普段は黙り、敵（BPDU）が来たら目を覚ます」という柔軟性こそが、実運用における安全網（セーフティネット）となる。
—
実務で使える設定例：Cisco IOS / Catalystスイッチの場合
それでは、実際のネットワーク機器における設定の作法を見ていこう。ラボや本番環境で検証する際の参考にしてほしい。
パターンA: グローバル設定で全エッジポートに適用（推奨）
アクセスポート（サーバーやPCが直結するポート）に対して一括でBPDU Filterを適用しつつ、万が一のループ耐性を残す最もポピュラーな手法だ。
! グローバルコンフィギュレーションモード
configure terminal
! PortFastが有効なポートに対して、デフォルトでBPDU Filterを有効化
spanning-tree portfast bpdufilter default
! ついでに、BPDUを受信した際にポートを安全にシャットダウン（Err-disabled）させる保護もセットで入れる
spanning-tree portfast bpduguard default
endパターンB: 特定のインターフェースで強制的に送受信を無効化
仮想化基盤のアップリンクや、BPDUを受け付けるとトラブルになる特殊な機器が直結するポートなど、ピンポイントで制御したい場合の設定だ。
configure terminal
interface GigabitEthernet0/1
description === Connection to Virtualization Hypervisor ===
switchport mode access
spanning-tree portfast
! このポートではBPDUの送受信を強制的に無効化する
spanning-tree bpdufilter enable
end> ⚠️ 現場のシニアからの警告（Trap）
> spanning-tree bpdufilter enable をインターフェースレベルで「強制」設定した場合、その先にうっかり別のL2スイッチやHUBが接続されてループを形成しても、スイッチはBPDUを送信しないためループを検知できません。 結果として、ネットワーク全体がブロードキャストストームで即死します。個別設定を使う場合は、接続される機器が100%単一のホストであることを物理的・論理的に担保してください。
—
動作確認とデバッグの手順：パケットが流れていないことを証明する
設定を投入したら、本当にBPDUが止まっているかを確認するのがエンジニアの流儀だ。祈るな、測定しろ。
Cisco IOSであれば、以下のコマンドでポートごとのSTPステータスとBPDUの送受信カウンタを観測する。
# 特定のインターフェースのSTP詳細情報を確認
show spanning-tree interface GigabitEthernet0/1 detail出力結果の注目すべきポイントはここだ：
Port 25 (GigabitEthernet0/1) of the default STP is forwarding
Port path cost: 4, Port priority: 128, Port identifier: 128.25.
Designated root has priority 32768, address 0011.2233.4455
Designated bridge has priority 32768, address 0011.2233.4455
Designated port id is 128.25, designated path cost 0
Timers: message age 0, forward delay 0, hold 0
Number of transitions to forwarding state: 1
BPDU: sent 0, received 0 <--- ★ここが重要！BPDU: sent 0 となっており、かつ正常にフォワード状態であれば、意図通りにBPDUの送信が抑制されていることが証明される。
もしLinux側のホストで実際にパケットキャプチャを行い、スパニングツリーのマルチキャストアドレス（01:80:c2:00:00:00）宛てのフレームが消えていることを確認したい場合は、お馴染みの tcpdump を使えば一目瞭然だ。
# Linux端末側で、STPのマルチキャストフレームが来ていないことを確認する
sudo tcpdump -i eth0 -nn "ether host 01:80:c2:00:00:00"BPDU Filterが正しく動作していれば、このコマンドを実行しても数分間パケットは一切キャプチャされないはずだ。
—
まとめ
BPDU Filterは、一見すると地味なL2のチューニング機能に思えるかもしれない。しかし、大規模なデータセンターや仮想化基盤、あるいはコンテナノードが密集するモダンなインフラにおいて、「不要な制御トラフィックを排除し、エッジの挙動をクリーンにする」というアプローチは、障害の芽を摘む上で極めて重要な意味を持つ。
ネットワークの本質は「無駄を削ぎ落とし、必要なデータを確実に運ぶこと」にある。今回の解説を参考に、ぜひ君たちのインフラ環境でもエッジポートの最適化を見直してみてほしい。それではまた、次の深淵でお会いしよう。
コメント