はじめに
物理的なケーブル接続作業にて、接続ポートを誤りループが発生するネットワーク環境を構築した経験はありませんか。
重大なNW障害の一つとして、L2ループが存在します。
このL2ループはL2スイッチの誤接続や設定ミスにより発生し、ネットワーク全体が瞬時に麻痺する障害を引き起こします。
本記事では、実機を用いて実際にL2ループを再現し、そのとき実機とその内部のステータスにどのような変化があるのかを観察します。
また、以下の理由についても踏み込んで行きたいと思います。
- なぜ STP（Spanning Tree Protocol） という技術が存在してデフォルトで有効なのか
- どのようなアンチパターンがネットワーク構築作業で起きやすいのか
- どう防ぐべきか
本記事の目的は以下の通りです。
- L2ループが発生した際の挙動を実機で観察する
- CPU負荷・CLI応答遅延の有無を確認する
- STPがなぜ存在するのか、なぜデフォルトで有効なのかを理解する
概要
本記事では、実機環境にて意図的にSTPを無効化し、L2ループによるブロードキャストストームを発生させる検証を行います。
また、今回の構成ではL3SW間および監視・管理用の経路においてOSPFを稼働させています。
L2ループによるブロードキャストストーム発生時には帯域が圧迫されることにより、Helloパケットなどのドロップや到達遅延が発生します。
これにより、「OSPFネイバーがDead Timer切れによりDOWNし、帯域が一時的に空くと再びFULLに復帰する」というネイバーのUp/Downが発生することが想定されます。
具体的には、以下の手順で実機の挙動を追跡し、L2ループによるブロードキャストストームが及ぼす影響と適切な防御策を検証します。
- 通常状態におけるCPU使用率やLED・SYSLOG等のステータスを確認する
- STPおよびKeepaliveを無効化した上でARPキャッシュをクリアし、ブロードキャストストームを発生させる
- CPU高負荷、OSPFネイバーのUp/Down、MACフラッピング、LEDの高速点滅等の変化を観察する
- ループ経路のケーブルを抜線し、各ステータスが即座に正常化することを確認する
- 安全装置であるBPDU Guardを設定し、ループ発生時に自動でポートが閉塞（errdisable）される挙動を確認する
観察するポイントは以下の通りです。
- L3SWのインターフェースの物理的な挙動
- CPU負荷
ARP：ネットワーク上でIPアドレスから機器固有のMACアドレスを調べるためのプロトコル
OSPF：ルータ間で経路情報を交換するプロトコル。Helloパケットが届かないと隣接関係がダウンする
検証に使用する機材は以下の通りです。
- Layer3スイッチ（Cisco IOS）× 2
- 使用機器（Catalyst 3750）はL3SWですが、内部にはL2ドメインが存在しており、VLAN単位でSTPが動作するため、ループを作成するとブロードキャストストームが発生します。
- VLAN1（管理用）とVLAN10（検証用）を使用し、両スイッチ間のインターフェース（Fa1/0/13, Fa1/0/15）はトランクリンクで接続しています。
- 監視用端末（Zabbix）× 1
- コンソール接続用端末 × 1
VLAN：物理的な配線や位置に関係なく、1台または複数のスイッチ内部でネットワークを仮想的に分割・グループ化する技術
構成図
今回のネットワーク構成は以下のようになります。
L3SW2台を接続したシンプルな構成を使用します。L3SWを直接接続し、意図的にループを作成します。
実機での配線は以下のようになります。
検証手順
今回の検証では、以下の順序で実施します。
- 事前確認
- STP無効化
- 実機含む挙動観察
- ケーブル抜線時観察
- 防御策確認
事前確認
L2ループによるブロードキャストストームを発生させる前に各機器の状態を確認していきます。
L3SW1 CPU使用率
L3SW1のCPU使用率は0〜10%程で安定していることが確認できました。
L3SW1# show processes cpu history
L3SW2 CPU使用率
L3SW2のCPU使用率もL3SW1と同様に0〜10%程で安定していることが確認できました。
L3SW2# show processes cpu history
実機LED点灯状況
実機のインターフェースも緑点滅しており、特段フラッピングが発生していない状態です。
監視端末（Zabbix）CPU使用率確認
監視端末にて各機器のCPU使用率を確認しましたが0〜10%ほどで安定していました。
STP無効化
Catalystシリーズには Ethernet Keepalive という、自身が送信したフレームが同一ポートに戻ってきた場合に自己ループと判断し、ポートをdown/err状態にする仕組みがあります。
今回は、L2ループの挙動を純粋に観察するため、Ethernet Keepaliveも無効化し、概要の構成の通りトランクリンクを設定しています。
また、Catalystシリーズでは標準でPVST+が動作しており、L2ループが発生しないため、今回は意図的にVLAN単位でSTPを無効化します。
PVST+：VLANごとに個別のSTPインスタンスを持つCisco独自のプロトコル
以下の設定は検証環境専用です。本番環境では絶対に実施しないでください。
STP無効化（L3SW1）
L3SW1(config)# no spanning-tree vlan 1,10
インターフェース設定（L3SW1）
L3SW1(config)# interface Fa1/0/13
L3SW1(config-if)# no keepalive
L3SW1(config-if)# exit
L3SW1(config)# interface Fa1/0/15
L3SW1(config-if)# no keepalive
L3SW1(config-if)# exit
STP無効化（L3SW2）
L3SW2(config)# no spanning-tree vlan 1,10
インターフェース設定（L3SW2）
L3SW2(config)# interface Fa1/0/13
L3SW2(config-if)# no keepalive
L3SW2(config-if)# exit
L3SW2(config)# interface Fa1/0/15
L3SW2(config-if)# no keepalive
L3SW2(config-if)# exit
挙動観察
今回の検証では、既に存在するループ上でARPリクエストを発生させるためにARPテーブルのキャッシュを削除してブロードキャストストームを発生させたいと思います。
L3SW2# clear arp-cache
コマンドを投入したタイミングから以下のような事象が発生するようになりました。
- 機器内にて SYSLOGが頻繁に出力される
- 帯域消費とCPU負荷により、Helloパケットがドロップされるため OSPFのネイバーがUp/Downを繰り返す
- フラッピングのSYSLOGがL3SW1に出力される
- インターフェースにて送受信している ブロードキャストのパケット数が急激に増加する
SYSLOG出力内容
L3SW1
*Mar 1 08:54:36.182: %OSPF-5-ADJCHG: Process 10, Nbr 10.10.10.1 on FastEthernet1/0/3 from FULL to DOWN, Neighbor Down: Dead timer expired
L3SW1#
*Mar 1 08:54:38.505: %SW_MATM-4-MACFLAP_NOTIF: Host 0011.9363.5bc0 in vlan 1 is flapping between port Fa1/0/13 and port Fa1/0/15
L3SW1#
*Mar 1 08:55:14.224: %OSPF-5-ADJCHG: Process 10, Nbr 10.10.10.1 on FastEthernet1/0/3 from LOADING to FULL, Loading Done
%SW_MATM-4-MACFLAP_NOTIF は、同一MACアドレスが複数ポートで交互検出されている状態を表しているSYSLOGであり、ループの典型的な兆候として出力されます。
L3SW2
*Mar 1 08:43:25.999: %OSPF-5-ADJCHG: Process 10, Nbr 20.20.20.1 on FastEthernet1/0/3 from FULL to DOWN, Neighbor Down: Dead timer expired
L3SW2#
*Mar 1 08:45:10.202: %OSPF-5-ADJCHG: Process 10, Nbr 20.20.20.1 on FastEthernet1/0/3 from LOADING to FULL, Loading Done
パケットカウント確認
ブロードキャストのパケットが実施前と比較して 急激に増加 していることが確認できました。
L3SW1
L3SW2
CPU負荷観察
コマンドを使用して実際のCPU負荷を観察してみたいと思います。
L3SW2# show processes cpu history
コマンドの結果から両機器ともCPU使用率が 60%ほど に張り付くことが確認できました。
L3SW1
L3SW2
監視端末（Zabbix）確認
実機LED点灯状態確認
L2ループによるブロードキャストストーム発生時の実機状態を確認したところ、L3SW1とL3SW2のFa1/0/13とFa1/0/15のLEDが 高速で点滅 していることが確認できました。
実機LED点灯状態確認（ケーブル抜線後）
それでは、ここでL2ループの原因となっているL3SW1のFa1/0/15に差さっているケーブルを抜線します。
高速で緑点滅していたインターフェースの点滅速度が緩やかになりました。
ケーブル抜線後に改めてCPUや機器内部を確認したところ、CPU使用率は0〜10%ほどに落ち着き、OSPFのネイバーダウンなども発生しなくなりました。
L3SW1
L3SW2
Zabbix
防御策（BPDU Guard）
以下のような、企業のネットワーク構築において起こりうる原因例や今回検証したL2ループを防ぐ仕組みとして、BPDU Guard という機能が存在します。
- ハブや小型スイッチの誤接続による意図しないSTP参加
- Wi-Fiルータでのブリッジモード時の誤接続によるループの発生
- PortFastの誤設定によるSTP検知までの一時的なループの発生
- BPDU Filterの誤設定によるSTPのループ検知無効化
BPDU Guardは、BPDUを受信した際に即座にインターフェースをerrdisable状態にして閉塞する安全装置の機能を果たし、ループ発生を未然に防ぐための有効な安全対策として存在しています。
実運用では、PortFast機能と併用してBPDU Guardをアクセス/エッジポートに適用しますが、今回の検証では挙動の確認のみを行うためFa1/0/13のみに設定を投入します。
抜線していたケーブルを再接続し、ループが再発生する状態に戻した上でL3SW2に対してBPDU Guardを設定し、STPを有効化して確認します。
BPDU Guardの設定例
L3SW2(config)# interface Fa1/0/13
L3SW2(config-if)# spanning-tree bpduguard enable
L3SW2(config-if)# exit
L3SW2(config)# spanning-tree vlan 1,10
STPを有効化したところ、以下のようなSYSLOGが出力され、インターフェースがリンクダウンすることを確認できました。
*Mar 1 00:04:53.106: %SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port Fa1/0/13 with BPDU Guard enabled. Disabling port.
*Mar 1 00:04:53.106: %PM-4-ERR_DISABLE: bpduguard error detected on Fa1/0/13, putting Fa1/0/13 in err-disable state
BPDU Guardの他にも Root Guard / Loop Guard など類似の保護機能がありますが、今回は誤接続を即遮断するBPDU Guardを検証対象としました。
BPDU：ネットワークのループを防ぐSTPにおいて、スイッチ同士が状態を共有するために定期的にやり取りする制御用のフレーム
BPDU Guard実装時の注意点
今回の検証では動作確認のためにトランクリンクへBPDU Guardを適用しましたが、本来BPDU Guardはアクセス／エッジポート限定で実装すべき機能である点に注意が必要です。
BPDU Guardは「BPDUを受信したら即座にポートをerrdisableにする」安全装置であり、上位スイッチとの接続（トランク／アップリンク）では必ずBPDUを受信します。
そのため、誤ってトランクやアップリンクにBPDU Guardを設定すると、以下のようなリスクがあります。
- 正常なBPDUを受信しただけで即errdisable状態となる
- サービス断が発生する
- 上位スイッチとの接続が突然遮断する恐れがある
- VLAN全体の通信断が発生する
- OSPFなどのネイバーが一斉にDownする
復旧の際には、以下のいずれかが必要になります。
-
errdisable recovery cause bpduguardによる自動復旧の設定 - 該当インターフェースの
shutdown→no shutdownによる手動復旧 - BPDU Guardの設定削除
アップリンクで発生した場合、BPDU GuardがL2ループより先にネットワークを止めてしまうため、注意が必要です。
所感
今回の検証を通して、ネットワーク全体を麻痺させる障害の一つであるL2ループによるブロードキャストストームを体験することができました。
STPがない環境ではCPU高負荷、OSPF等のパケットロス、ブロードキャストストームが即座に発生することに加えて、実機特有の以下挙動が確認できました。
CPU使用率が60%に張り付く
今回の検証にて使用したCatalyst 3750には、ハードウェアスイッチングによりデータプレーンはCPUを経由せず、制御プレーンへのトラフィックにはレートリミットがかかるため、CPUが100%になることはありませんでしたが、使用率0〜10%ほどから急激に増加することが確認できました。
CLI応答の遅延は未発生
今回の検証で使用したCatalystシリーズには、CLI処理はデータプレーンとは別でも同一CPU上で制御プレーントラフィックと共に処理され、優先度制御（レートリミット等）によって遅延が抑えられているため、CLI応答が遅延しませんでした。
体感的にも遅延を感じませんでしたが、詳細な定量計測については実施していません。
LEDが高速点滅する
フラッピング発生により、実機のインターフェースLEDが高速で緑点滅することが確認できました。
ケーブル抜線で即時復旧する
フラッピング発生時にループしているケーブルの一部を抜線すると解消することも確認できました。
BPDU Guardでループを未然に遮断できる
BPDU Guardは、誤接続による意図しないSTP参加を即座に検知し、ポートをerrdisableで遮断することで、L2ループによるブロードキャストストームを発生前に防ぐ有効な安全装置です。
ネットワーク構築作業で頻発する人為的ミスを技術的にカバーし、ネットワーク全体の安定性を大幅に高めるため、アクセスポートにおける有効な安全対策として広く導入されています。
実際の商用環境でこのような設定誤りや配線ミスが発生した場合、重大な障害につながるリスクがあります。
本検証を通じて、障害発生時の具体的な挙動を把握できただけでなく、ネットワーク機器にはSTP以外にも多様なループ防止機構が用意されており、それらを適切に組み合わせて設計・運用することの重要性を改めて認識できました。
まとめ
L2ループは、ネットワーク全体を瞬時に麻痺させる非常に重大な障害です。
ネットワーク構築作業において、配線ミスや意図しない接続といった人為的ミスが発生する可能性を完全には排除できません。
そのため、ネットワークの可用性を担保する観点から、ネットワーク機器の多くはSTPなどのループ防止機能をデフォルトで有効化する仕様や設計思想が一般的となっています。
本記事の検証を通じて、L2ループの挙動やその危険性、および防御策についての理解を深めるきっかけとなれば幸いです。
We Are Hiring!
FindConsultingでは、ネットワーク・インフラの知見を活かして新しい領域に挑戦したい仲間を募集しています。
資格取得支援や実案件への早期参画など、次のステップへ踏み出すための環境が整っています。
「話を聞きたい」くらいの気持ちで、ぜひ一度 カジュアル面談 でお話しましょう。