L2（レイヤ2）ネットワークを管理・運用するエンジニアにとって、最も恐ろしい障害の一つが「L2ループ」と、それに伴う「ブロードキャストストーム」です。
「スパニングツリー（STP）を設定しているから大丈夫」と過信していませんか？ 実務においては、対向（接続先）の機器が何かによってSTPの設定や周辺のセキュリティ設計を適切に変えなければ、冗長切り替え時の通信断や、STPそのものがストームで機能不全を起こして他拠点まで巻き込む全断大障害に発展することがあります。

本記事では、Cisco Catalystスイッチ（デフォルト：Rapid-PVST+）をベースに、接続先別の推奨設定から、ストーム制御、CoPP（CPU保護）、さらには「島ハブ」でのループ検知メカニズムの裏側まで、技術ブログとして体系的にまとめました。

1. 【保存版】接続先別・STP＆ポートセキュリティ設計ポリシー一覧

まずは、本番ネットワークの構築においてそのまま使える、対向デバイス別の設計マトリクスです。

接続対象

ポートモード

STP・周辺の推奨設定

設定コマンド例

設計根拠と実務上の注意点

① スイッチ（SW）間

トランク (trunk)

追加のSTP機能は適用しない
（Allowed VLANで制限）

（追加設定なし）

基幹ループフリーの形成：
動的なSTP計算を行わせるため、過渡状態をスキップする機能は適用しません。MEC（マルチシャーシイーサチャネル）による論理1台化が推奨です。

② FW / サーバー
(LACPポート)

アクセス / トランク

PortFast ＋ BPDUガード
(★Port-Channel論理ポートに設定)

spanning-tree portfast [trunk]
spanning-tree bpduguard enable

冗長切替時の通信断をゼロにする：
物理フラップやActive/Standby切り替え時に、RSTPのタイマー遅延（15秒）をスキップします。LACP構成時は、物理ではなくPort-channelインターフェースに対して設定を投入します。

③ 閉域網 / ルーター

トランク (trunk)

BPDUフィルター
(※推奨は物理L3ポート化)

spanning-tree bpdufilter enable
(または no switchport)

STPドメインの完全分離：
キャリア網などを跨ぐ場合、他社ドメインからBPDUが流入してerrdisableになるのを防ぐため、BPDUを完全に無視（送受信停止）させます。

④ フロアLAN（端末）

アクセス (access)

PortFast ＋ BPDUガード
(自動復旧の併用)

spanning-tree portfast
spanning-tree bpduguard enable

一般エッジのループ・不正SW対策：
PC等の瞬時リンクアップを可能にしつつ、勝手なハブ接続やループ時にポートを瞬時に閉塞します。管理者負担を減らすため自動復旧を併用します。

⑤ 無線AP

トランク (trunk)

PortFast trunk ＋ BPDUガード
(ポートセキュリティは競合NG)

spanning-tree portfast trunk
spanning-tree bpduguard enable

起動高速化＆ローミング対策：
AP起動時の通信復旧を高速化しつつ、露出したポートでの悪意ある接続をガードします。ローミングによるMACフラップで閉塞しないよう、ポートセキュリティ等は無効化します。

2. 対向デバイス別の詳細設定と実装のポイント

① スイッチ（SW）間接続（Trunkポート）

スイッチ同士をトランクリンクで接続する場合、DTP（Dynamic Trunking Protocol）による動的交渉は無効化し、静的にトランクを設定したうえで、 Allowed VLAN を設定して不要なVLANをトランクから除外するのが鉄則です。

! 【SW間接続の設定例】
interface GigabitEthernet1/0/1
 description === Uplink to Inter-SW Trunk ===
 switchport mode trunk
 switchport trunk allowed vlan 10,20,30   <-- 必要なVLANのみに絞り、不要なSTPインスタンスを排除
 switchport nonegotiate                   <-- DTPを無効化（切替時のポート不整合を予防）

💡 トラブルシューティング：ポート不整合「PVID Inconsistency」はなぜ起きる？

アクセスポートからトランクポートへの移行中など、片方のスイッチの設定がトランクになり、もう片方のスイッチのポートがアクセスポート（またはネイティブVLAN設定が異なる）のままになった場合、対向スイッチで以下のポート不整合ログが出力されてポートがブロックされます。

%SPANTREE-2-RECV_PVID: Rx Spanning Tree Parameter Inconsistency on GigabitEthernet0/8 vlan 20
%SPANTREE-2-PORT_BLOCK: Port GigabitEthernet0/8 blocking due to PVID inconsistency

これは、トランク側から送信されたPVST+用のタグ付きBPDU（SSTP BPDU）をアクセスポート側で受信した際、ポートが属するアクセスVLAN（PVID / Native VLAN）とBPDU内のVLAN情報（VLAN 20）との決定的な矛盾を検知したためです。
この状態のまま放置すると、VLAN間でスパニングツリーの計算が狂い、深刻なL2ループを引き起こす可能性があるため、STPは安全装置として対象ポートを自動的にブロック状態（*broken や BKN）にします。

② FW / サーバー接続（LACP / Port-Channel）

本番環境では、ファイアウォール（FW）やサーバーとの間をLACP（IEEE 802.3ad）のポートチャネル（EtherChannel）で冗長化することが一般的です。

! 【Port-Channel側の設定例】
interface Port-channel1
 description === Link to FW (LACP Group) ===
 switchport mode trunk
 switchport trunk allowed vlan 10,20
 switchport nonegotiate
 spanning-tree portfast trunk             <-- ★物理ではなくPoインターフェース側に設定する
 spanning-tree bpduguard enable           <-- ★物理ではなくPoインターフェース側に設定する
!
interface GigabitEthernet1/0/1
 description === Member of Po1 ===
 switchport mode trunk
 switchport trunk allowed vlan 10,20
 channel-group 1 mode active              <-- LACP(Active)の設定
!
interface GigabitEthernet2/0/1
 description === Member of Po1 (Cross-Stack) ===
 switchport mode trunk
 switchport trunk allowed vlan 10,20
 channel-group 1 mode active

⚠️ 設定の超重要ルール

LACP構成を組む場合、RSTPの設定コマンド（PortFast、BPDUガードなど）は、物理ポートではなく、自動生成されるポートチャネルインターフェース（Port-channel）に対して投入してください。
物理ポートと論理ポート間で Allowed-VLAN や STPパラメータにズレが生じると、ポートがグループから自動的に除外（サスペンド）される原因になります。

💡 なぜFWにPortFastが必要なのか？

対向がFW（Active/Standby冗長）の場合、FWのフェイルオーバーが走ると、スイッチ側では物理リンクのフラップやMACアドレスの学習元の切り替えが発生します。
この時、トランクポートに spanning-tree portfast trunk が入っていないと、ポートが通信可能（Forwarding）状態になるまでにRSTPのタイマー遅延（後述する約15秒の待機）が発生してしまい、FW自体の切り替えは一瞬でも、L2スイッチの待機によって数秒〜15秒の通信断が発生してしまいます。これを防ぐために、FW向けポートにはPortFastが必須です。

3. 【深掘り】ループとストームを防ぐ多層防御の仕組み

① RSTP（Rapid-PVST+）の15秒遷移の正体

「アクセスポートにはデフォルトでPortFastの設定は入っている？」
答えは 「いいえ、デフォルトですべてのインターフェースで無効（Disabled）」 です。そのため、設定を入れ忘れたアクセスポートは通常のSTP計算が走ります。

ただし、レガシーSTP（IEEE 802.1D）の時代は、ポートが通信可能（Forwarding）になるまでに 最大で30秒（Listening 15秒 ＋ Learning 15秒）かかっていましたが、Ciscoのデフォルトである RSTP（Rapid-PVST+）環境であれば、PortFastを設定していなくても約15秒で通信が可能になります。

RSTPのタイマー遷移（なぜ15秒なのか？）

RSTPでは、レガシーSTPにあった「Listening」という状態が完全に廃止（Discardingに統合）されました。

  1. Discarding（Cisco CLI表示は BLK）[0秒/瞬時]：リンクアップ後、RSTPはListeningで15秒待つことなく、瞬時にMAC学習の準備として「Learning（LRN）」状態に移行します。
  2. Learning（Cisco CLI表示は LRN）[15秒]：安全装置として、フォワードディレイタイマー（デフォルト15秒）を1回だけ消化し、MACアドレスを学習します。
  3. Forwarding（Cisco CLI表示は FWD）：15秒満了後、そのまま通信可能となります。

このように、RSTPでは不要な待機時間が削ぎ落とされたため、ポートにPortFastを設定し忘れた一般端末であっても、最長15秒（レガシーの半分）でパケットが通るようになります。

② ストーム制御「pps設定」の推奨値と導入前の確認手順

Ciscoの公式テンプレート（LAP_INTERFACE_TEMPLATE 等）において、エッジ端末向けポートの推奨標準値として、以下のストーム制御値がデフォルト定義されています。

  • ブロードキャスト：1k pps（1秒間に1,000パケット）
  • マルチキャスト：2k pps（1秒間に2,000パケット）
  • アクション：storm-control action trap（SNMPトラップ送信。しきい値を超えたパケットはASICで即自動ドロップされる）

❓ なぜマルチキャストの制限値（2k pps）はブロードキャスト（1k pps）より多いのか？

Ciscoスイッチのストーム制御はASIC（ハードウェア）レベルで動作しますが、「通常のマルチキャストデータパケット」と「OSPFやPIMなどのルーティング・制御通信用マルチキャストパケット」を区別しない仕様になっています。マルチキャストのしきい値を極端に絞りすぎると、ネットワーク起動時などに流れる正常なルーティングパケットもドロップされてしまい、「OSPFのネイバーが切れる」などの二次災害が起きます。そのため、安全マージンとして緩めの設定値になっています。

現代のLAN環境では、デバイスの自動探索プロトコル（mDNS/Bonjour、SSDP、LLMNRなど）がマルチキャストを多用するため、バーストを誤検知させないためにマージンを取っています。

  1. 制御・ルーティング通信への影響を防止するため（最重要）：
  2. マルチキャストをベースとした定常サービス（探索・同期）の保護：

🔍 導入前に確認！本番環境でのトラフィック確認コマンド

本番運用中のポートにストーム制御を導入する際は、現在の正常なパケット量（ベースライン）を把握しておく必要があります。以下のコマンドを使って確認を行います。

! ① 対象物理ポートの5分間平均ppsとパケット数カウントの確認
show interfaces gigabitethernet 1/0/1

! ② リアルタイムなストーム制御の適用シミュレーション
show storm-control gigabitethernet 1/0/1 [broadcast | multicast]

! ③ NBAR（プロトコルディスカバリ）による通過プロトコルの内訳確認
show ip nbar protocol-discovery interface gigabitethernet 1/0/1

③ 停電復旧時（一斉バースト）におけるCiscoスイッチの多層防衛

「端末が1,000台以上あり、停電からの一斉復旧後にARPが一気に流れたら、ストーム制御でポートが止まったり、スイッチがフリーズしたりするのでは？」
実務において非常に鋭い懸念ですが、Catalystスイッチはこうした最悪のシナリオを想定した「多層防御システム」がハードウェアレベルで組み込まれています。

1,000台一斉起動時のバーストARP 停電復旧・一斉電源投入 ① 物理アクセスポート（ストーム制御 1k pps） 各ポートに分散して流入するため ポート単体では しきい値を超えない（セーフ） ② DAI（Dynamic ARP Inspection） 有効時はデフォルト 15 pps の制限に接触する可能性 設計上のレート調整が必要 ③ CoPP（Control Plane Policing）★最後の砦 CPU宛ての最大処理レート（例：約4,000 pps）を ASIC（ハードウェア）上のポリサーで即時スロットリング 超過したARPはASICでドロップ CPUフリーズを防ぎ、端末側の再送で順次収束

  • ポートレベル： ストーム制御は「物理ポート個別」に判定されます。1,000台のARPバーストであっても、それらは各物理ポートに分散して流入（1ポートあたり数パケット）するため、ポート単体で 1k pps を超えてドロップされることはありません。
  • CPUレベル（最後の砦）： 一斉に発生したブロードキャストARPはスイッチのCPU（コントロールプレーン）に処理要求として殺到します。しかし、Catalyst 9000シリーズでは CoPP（system-cpp-policy） が常時ハードウェア（ASIC）レベルで稼働しており、CPU宛てトラフィックを自動的に制限します。CPUが処理限界を超える前に、超過したARPパケットはハードウェアレベルで強制的にドロップ（間引き）されるため、スイッチ自体がフリーズすることは絶対にありません。

4. 【実務の疑問】島ハブ（アンマネージド）のループはBPDUガードで止まる？

「島ハブ（STP未対応の安価な未管理スイッチ）でループ構成を作った場合、自スイッチが送信したBPDUがループして戻ってくるから、BPDUガードでシャットダウンできるのでは？」

多くのエンジニアがそう推測しますが、結論から言うと、デフォルト設定の「BPDUガード」だけでは、島ハブによるセルフパッチ・ループ（1台のハブ内でのループ）を検知してポートを自動シャットダウン（errdisable）させることはできません。

これには、以下の2つの技術的理由があります。

Catalyst スイッチ Gi1/0/1（アクセスポート） loopdetect 有効 島ハブ（アンマネージド） ポート同士を誤ってパッチ（ループ） loop-detectフレーム送出 透過して戻る → errdisable

理由①：STPは「自ポートから戻ってきたBPDU」ではBPDUガードを起動しない

BPDUガードは、本来「自ポートの先に他のスイッチ（異なるBridge IDを持つデバイス）が誤接続されたこと」を検知して閉塞する機能です。
自ポートから送出したBPDUがそのまま自ポートに戻ってきた（Bridge IDとPort IDが自スイッチと一致する）場合、STPエンジンは以下のように判断します。

  • 動作： 「別スイッチが接続された（BPDUガード違反）」とは判定せず、「自ポートの先でループ経路が発生している」と判断。
  • 結果： ポートの役割を「Backupポート」、状態を論理ブロックである「Discarding（CLI上は BLK）」に変更するのみ。ポートの物理シャットダウン（errdisable）には移行しません。

理由②：島ハブがBPDUを「破棄（フィルタ）」してしまうケースが多い

安価な島ハブであっても、IEEE規格で定義されたスパニングツリー用の特別なマルチキャストMACアドレス（01-80-C2-00-00-00 など）を受信した際、ハブの内部仕様としてパケットを透過（フラッディング）させずに静かにドロップする製品が数多く存在します。
この場合、自スイッチから送出したBPDUがループ経路を通って戻ってくることすらありません。

💡 解決策：島ハブのループを完璧にシャットダウンさせる方法

島ハブのセルフパッチ・ループを完璧に防ぎ、ポートを安全に閉塞させるためには、以下の設定を追加投入します。

対策A：Loop Detection Guard（ループディテクションガード）の併用

Cisco Catalystには、「STPを動作させていないアンマネージドハブでのループ」を検知してポートをシャットダウンさせるための専用機能が用意されています。

interface GigabitEthernet1/0/1
 description === Access Port (to Island Hub) ===
 switchport mode access
 switchport access vlan 100
 loopdetect                     <-- ループディテクションを有効化
 loopdetect time 5              <-- 検出パケットの送信周期（5秒）

これにより、スイッチ独自の「ループ検出フレーム（loop-detectフレーム）」が島ハブを透過して自ポートへ戻ってきた瞬間、ポートを即座に errdisable（シャットダウン）状態にし、ストームの発生を未然に防ぎます。

対策B：Keepalive（キープアライブ）による自動閉塞

Ciscoスイッチがポート上で送信するキープアライブフレームが島ハブ経由で自ポートに戻ってきた場合、スイッチはループを検知してポートを自動的に error-disabled に移行させます。

5. まとめ

CiscoスイッチのRSTPおよび周辺プロトコルは、ただ設定を有効化するだけでなく、「対向デバイスが何か」を意識して、パラメータやガード機能を組み合わせた多層防御を設計することが、安定したセキュアなインフラを作るための鍵です。

実務でCatalystの構築に携わる際は、本記事で紹介した設定ポリシー一覧や、島ハブ対策、ストーム制御のしきい値設計を参考に、より堅牢なネットワーク構築を目指してください！