ネットワークの現場で最も背筋が凍る瞬間の一つをご存知でしょうか？
それは、セキュリティが担保されているはずのフロアの端っこ（アクセスポート）に、アルバイトの学生や他部署の社員が、自宅から持ち込んだ安物のアンマネージドスイッチをこっそり接続した瞬間です。
「パチッ」とLANケーブルが挿されたその瞬間、L2ネットワークの世界では何が起きているか。新しく接続されたスイッチは「俺がルートブリッジだ！」と言わばかりに、全方向に我先にとBPDU（Bridge Protocol Data Unit）をブロードキャストし始めます。STP（Spanning Tree Protocol）のトポロジー変化が連鎖し、社内ネットワーク全体が数分間にわたって通信不能に陥る――。いわゆる「L2ループ爆弾」の完成です。
こうした悲劇を未然に防ぐために、現代のネットワークエンジニアが必須の武器として持っておかなければならないのが BPDUガード（BPDU Guard） と BPDUフィルタ（BPDU Filter） です。
今回は、これら2つの機能がパケットレベルでどのように働き、実務の現場でどう設定・運用すべきか、私の泥臭い実体験ベースの知見を交えて徹底的に解説します。
—
1. BPDUガードとBPDUフィルタの基本思想：なぜ「エッジ」を守らなければならないのか？
IEEE 802.1Dや802.1W（RSTP）で規定されているスパニングツリープロトコルは、本来、冗長構成を持つスイッチ間のループを防ぐための神聖なプロトコルです。しかし、PCやIP電話が接続される「アクセスポート（エッジポート）」において、スイッチからのBPDUを受け取る必要は一切ありません。
むしろ、アクセスポートは「終端」であるべきです。そこに勝手にスイッチが繋がれることを防ぐ、あるいは繋がれた瞬間にネットワークから物理的に切り離すのが BPDUガード の役割です。
一方の BPDUフィルタ は、エッジポートにおける無駄なBPDUの送受信を停止（または抑制）するための機能です。これら2つは似て非なるものであり、現場のポリシーに合わせて適切に組み合わせる必要があります。
—
2. 内部挙動と通信フロー：BPDUガードが発動する瞬間
では、Cisco CatalystやNexusなどのスイッチ（一般的なエンタープライズL2スイッチ）において、BPDUガードが有効なポートに不正なBPDUが流れ込んだとき、内部で何が起きているのでしょうか。
通信のシーケンスと状態遷移を追ってみましょう。
[不正なスイッチ] [Ciscoスイッチ (アクセスポート + BPDU Guard有効)]
| |
| ---- (1) BPDU (Topology Change / Config) --> |
| | (2) 受信パケットを検知！
| | 「エッジポートにBPDUが来たぞ」
| |
| | (3) ポートをシャットダウン
| | (err-disabled状態へ遷移)
| |
| <--- (4) リンク断 (物理リンクがダウン扱い) ---- |1. 不正なBPDUの流入: ユーザ端末を想定したポートに対し、外部スイッチがBPDUを送信します。
2. トリガー検知: ポートが spanning-tree bpduguard enable または spanning-tree portfast bpduguard default によって保護されている場合、スイッチASIC/CPUはこのBPDUの受信を「ポリシー違反」として即座に検知します。
3. Err-disabled（Error-disabled）への遷移: ポートの状態は即座に err-disabled に落とされ、データプレーンの転送が完全に遮断されます。これにより、L2ループの発生がコンマ数秒の単位で阻止されます。
4. ログの吐き出し: コンソールやSyslogには、お馴染みの以下のようなメッセージが記録されます。
%SPANTREE-2-BLOCK_BPDU_GUARD: Received BPDU on port Gi0/1 with BPDU Guard enabled. Disabling port.
%PM-4-ERR_DISABLE: bpduguard error detected on Gi0/1, putting Gi0/1 in err-disable stateこの「問答無用でポートを殺す」という容赦なさが、大規模ネットワークの可用性を守る最大の盾となります。
—
3. 実務で役立つコンフィギュレーションとパラメータ設計
それでは、実際の機器設定を見ていきましょう。ここでは、実務で最も採用されることが多いCisco IOSをベースに解説します。
パターンA：個別ポートへの明示的なBPDUガード設定
特定のアップリンクや、特に厳重に管理したい重要拠点への接続ポートに対して手動で設定する場合です。
! 1. 対象のインターフェースコンフィギュレーションモードへ移行
interface GigabitEthernet0/1
description === ユーザー端末接続用アクセスポート ===
switchport mode access
switchport access vlan 10
! ポートファスト（STPのリスニング/ラーニング遅延をスキップ）を有効化
spanning-tree portfast
! このポートでBPDUを受信したら即座にシャットダウンする
spanning-tree bpduguard enableパターンB：グローバルでのデフォルト有効化（推奨）
数百ポートあるスイッチで、1つずつ spanning-tree bpduguard enable を書いていくのはヒューマンエラーの元です。「アクセスポート（PortFastが有効なポート）すべてに自動でBPDUガードを効かせる」というベストプラクティス設定がこちらです。
! グローバルコンフィギュレーションモード
! PortFastが有効化されているすべてのポートに対して、一括でBPDUガードを適用する
spanning-tree portfast bpduguard default
! エラーでシャットダウンしたポートを、一定時間後に自動復旧させたい場合（例: 300秒後）
errdisable recovery cause bpduguard
errdisable recovery interval 300> シニアエンジニアの現場Tips:
> errdisable recovery を有効にするのは諸刃の剣です。原因（不正なスイッチの接続）が取り除かれていない場合、ポートが復旧した瞬間に再びBPDUを受信し、err-disabled と復旧を無限に繰り返す「フラッピング地獄」に陥ります。根本的な原因究明を行うまでは、自動復旧はあえて有効にせず、現地スタッフに対応させる運用（マニュアル復旧）を選ぶ現場も非常に多いです。
—
4. BPDUフィルタ（BPDU Filter）の挙動と危険な罠
次に BPDUフィルタ についてです。
BPDUフィルタは、文字通り「BPDUの送受信をフィルタリング（隠蔽・破棄）」する機能です。これには大きく分けて グローバル設定 と インターフェース設定 の2つの顔があり、挙動が全く異なるため注意が必要です。
1. インターフェース単位での設定
指定したポートにおいて、BPDUの送信を一切行わず、受信したBPDUも無視します。
【警告】 これはSTPの計算をそのポート上で完全に無効化すると同義です。もしこの設定をしたポートの先に別のスイッチが接続され、さらにループが構成された場合、STPは完全に機能不全に陥り、ネットワークは確実に死にます。よって、対抗機器が絶対にルーターやPCであることが確実な場合を除き、アクセスポートへの安易な個別設定は厳禁です。
2. グローバル単位での設定 (spanning-tree portfast bpdufilter default)
「PortFastが有効なポートからBPDUの送信を止めるが、もし向こうからBPDUが来たらPortFastとBPDUフィルタを即座に解除し、通常のSTPポートとして動作させる」という、非常にインテリジェントな挙動をします。
! グローバル設定例
spanning-tree portfast bpdufilter defaultこれにより、VoIP機器（IP電話機）などが接続された際、不要なSTPのマルチキャストパケット（BPDU）を端末側に送り出さずにクリーンな通信を維持しつつ、万が一スイッチが接続された際にもSTPの安全網を張ることができます。
—
5. 障害シューティング：現場で「ポートが死んだ！」と言われたら
運用フェーズで、ヘルプデスクから「総務部の〇番のポートに繋いだらネットに繋がらなくなった！」という連絡が入ったときの、プロのデバッグ手順を授けましょう。
Step 1: ステータスの確認
該当スイッチにログインし、ポートの状態を show interfaces および show spanning-tree で確認します。
Router# show interfaces GigabitEthernet0/1 status
Port Name Status Vlan Duplex Speed Type
Gi0/1 総務部PC err-disabled 10 auto auto 10/100/1000BaseTXステータスが err-disabled になっていれば、BPDUガードが仕事をした証拠です。
Step 2: ログと原因の特定
本当にBPDUガードが原因で落ちたのか、Syslogを確認します。
Router# show logging | include BPDU
*Mar 10 10:15:22.123: %SPANTREE-2-BLOCK_BPDU_GUARD: Received BPDU on port Gi0/1 with BPDU Guard enabled. Disabling port.もしここで、接続したはずの端末が通常のWindows PCやMacであるにもかかわらずこのログが出る場合、以下の原因が考えられます。
- 端末の仮想化ソフト（VMware WorkstationやVirtualBox、Docker等）のブリッジネットワーク設定が原因で、OSがBPDUのようなパケットを誤って送出している。
- ユーザーが私物の無線LANルーターの「LAN側ポート」ではなく「WAN側ポート」に間違えて社内LANケーブルを挿し、ルーター機能（STPやSTP互換のスパニングツリー）が暴走している。
Step 3: 手動での復旧作業
原因機器が取り除かれたことを確認した後、ポートを手動で復旧させます。
Router# configure terminal
Router(config)# interface GigabitEthernet0/1
Router(config-if)# shutdown
Router(config-if)# no shutdownシャットダウンを一度挟む（Stateのトグル）ことで、err-disabled 状態がクリアされ、ポートが正常なアップ状態に戻ります。
—
まとめ：ネットワークの境界線を守るために
BPDUガードとBPDUフィルタは、地味ながらも企業のL2ネットワークの平穏を守る「最後の砦」です。
「ウチのフロアには誰も変な機器を繋がないはずだ」という性善説に基づいたインフラ設計は、いつの日か必ず大規模障害という形で牙を剥きます。
アクセスの末端（エッジ）を徹底的に硬化（Harden）させ、不正なトポロジー変動の芽を根元から断つこと。それこそが、信頼性の高いネットワークインフラを支えるエンジニアの矜持です。明日からのコンフィグ見直しに、ぜひ取り入れてみてください。
コメント