【テクニカル・上級編】ループガード（Loop Guard）による単方向リンク障害の検知 – インフラ・物理＆L2/L3ネットワーク基礎実践ガイド

ループガード（Loop Guard）の深淵：単方向リンク障害が引き起こすL2崩壊と、パケットレベルの防衛策

ネットワークエンジニアとしてキャリアを積んでいくと、教科書通りにいかない「物理層とデータリンク層の幽霊」に出会うことがある。その最たるものが、単方向リンク障害（Unidirectional Link Failure）だ。

光ファイバーの片側（Tx/Rx）の汚染やトランシーバーのレーザーダイオードの片肺不良、あるいはメディアコンバーターの密かな沈黙。これらは、リンクアップのステータス（Carrier Detect）を両端のスイッチに維持させながら、データプレーンのトラフィック、そして何より制御プレーンの生命線であるBPDU（Bridge Protocol Data Unit）の片方向通行、あるいは完全な断絶を引き起こす。

STP（Spanning Tree Protocol）の歴史において、この「見えない断絶」は幾度となくデータセンターやキャンパスネットワークを全滅させてきた。本稿では、この悪夢を防ぐためにCisco CatalystをはじめとするモダンなスイッチングOSに実装されているループガード（Loop Guard）のパケットレベルの挙動、そして実務における設計・運用のベストプラクティスを、プロトコルの深淵を覗く視点から徹底的に解剖する。

—

1. なぜSTPは単方向リンクに無力なのか？

スパニングツリーの根底にある哲学は、「お互いの声（BPDU）が聞こえていれば、トポロジーは安全である」という極めて性善説に基づいたものだ。

正常な状態では、非指定ポート（Non-Designated Port / Alternate or Backup Port）は、指定ブリッジ（Designated Bridge）から定期的に送出されるBPDUを受信し続けることで、「あぁ、向こうの世界は健在だ。私はおとなしくBlocking（Discarding）状態で待機していよう」と判断する。

ここで、厄介な物理障害が発生したとする。

[Switch A (Designated)] ---(Tx: 正常 / Rx: 異常)---> [Switch B (Alternate)]

Switch AからSwitch Bへの方向（Tx）のファイバーが破損したとしよう。この瞬間、何が起きるか。
1. Switch Aの送信したBPDUは、Switch Bに届かない。
2. Switch Bは、自身が保持している「直近で受信したBPDU（Max Ageタイマー）」の有効期限が切れるのを待つ。
3. Max Age（デフォルト20秒）が経過すると、Switch Bは「指定ブリッジからの声が途絶えた＝向こうのリンク、あるいはSwitch Aが死んだに違いない」と誤認する。
4. Switch Bは、自分がルートへのパスを引き継ぐべきだと勝手に判断し、ポートの状態を Blocking から Listening -> Learning -> Forwarding へと遷移させる。

この瞬間、Switch AとSwitch Bの間には、互いに「自分が指定ポートだ」と信じ込んだままトラフィックを送り合うレイヤ2の無限ループ（ブリッジループ）が完成する。数秒のうちにブロードキャストストームが発生し、CPU使用率は100%に張り付き、管理用SSHすら応答しなくなる。これが単方向リンク障害の恐怖である。

—

2. ループガードのパケットレベルでの内部挙動

この致命的な設計上の弱点を補うために設計されたのがループガードだ。

ループガードは、STPの非指定ポート（Alternate または Rootポート）に対してのみ有効化される機能である。その本質は極めてシンプルかつ強烈だ。

> 「私はこのポートで指定ブリッジからのBPDUを『聴く』立場にいる。もし、このポートで突然BPDUが来なくなったら、リンク障害とみなして絶対にフォワーディング状態にしてはならない。ポートを『ループインコンシステント（Loop-Inconsistent）』状態に幽閉せよ」

状態遷移のメカニズム

ループガードが有効なポートが、本来届くべきBPDUの受信を停止した場合、内部ステートマシンは以下のように動作する。

1. BPDUロストの検知: 定期的なHelloタイマー（通常2秒）の間にBPDUを受信しなくなる。
2. 不整合（Inconsistency）の宣言: Max Ageの満了を待つことなく、直ちにポートを Loop-Inconsistent 状態に落とし込む。
3. データプレーンの遮断: この状態になったポートは、事実上の Blocking 状態と同等となり、ユーザートラフィックの転送（Forwarding）を完全に停止する。同時に、自分自身からのBPDUの送出も停止、あるいは適切に制御される。
4. 自動復旧の仕組み: 障害が物理的に修復され、再び対向から正常なBPDUの受信が再開されると、管理者の介入なしに自動的にポートは通常の状態（Listening -> Learning -> Forwarding）へと復旧する。この「自動復旧」の特性は、後述するUDLDとの決定的な違いを生む。

—

3. ループガードとUDLDの決定的な違いと使い分け

単方向リンクを検知する機能として、しばしばUDLD（UniDirectional Link Detection）が引き合いに出される。両者は混同されやすいが、レイヤとアプローチが根本的に異なる。

アーキテクトの視点：どちらを使うべきか？

ループガードは、STPトポロジーの計算ミスに起因するループを防ぐための「最後の安全弁」である。CPU負荷が低く、STPが稼働している環境であれば、すべての非指定ポート（root および alternate）にグローバル、あるいはインターフェース単位で有効化しておくべきである。
UDLD（特にアグレッシブモード）は、STPが動いていないポート（EtherChannelのメンバーポートなど）を含め、物理リンクレベルの片方向障害を早期に検知してポートをシャットダウンするために用いる。

理想的なモダンデータセンター設計では、両者を組み合わせて多重防御（Defense in Depth）を構築するのが正解となる。

—

4. 実務における設定と運用のベストプラクティス

ここからは、Cisco IOS / IOS-XE環境をベースにした実用的な設定例を見ていこう。

グローバル設定による一括有効化

ヒューマンエラーを防ぐため、可能な限りグローバルコンフィギュレーションでデフォルト有効化することを推奨する。

! すべてのポイントツーポイントリンクの非指定ポートでループガードをデフォルト有効化
spanning-tree loopguard default

! 注意: ループガードはポートタイプ（アクセス/トランク）に関わらず、
! STPの非指定ポート（Root / Alternate）として動作するポートに自動適用されます。

インスタンス（個別インターフェース）単位での設定

特定のアップリンクや、特に冗長性がクリティカルなパスに対して明示的に指定する場合の設定だ。

interface GigabitEthernet0/1
 description === Uplink to Core Switch A ===
 switchport mode trunk
 switchport trunk allowed vlan 10,20,30
 ! このポートでループガードを明示的に強制する
 spanning-tree guard loop

> Warning（注意点）
> spanning-tree guard root（ルートガード）と spanning-tree guard loop（ループガード）は排他関係にある。ルートガードは「指定ポート」を保護し、自分がルートブリッジであることを死守する機能であるため、同じポートに両方を設定することはできない。トポロジーの役割を正確に把握して使い分ける必要がある。

—

5. 障害発生時のトラブルシューティングとログの読み方

ループガードが発動した瞬間、スイッチのログ（syslog）には以下のようなメッセージが記録される。実運用において、このログを見落とさないことが迅速な復旧の鍵となる。

%SPANTREE-2-LOOP_GUARD_BLOCK: 
Loop guard blocking port GigabitEthernet0/1 on VLAN0010.

このログが出力された場合、ネットワーク管理者は以下の手順で即座に状況を把握し、インシデントに対処しなければならない。

1. 状態の確認コマンド

対象のポートが実際にどのようなステートに落ちているかを確認する。

# show spanning-tree interface GigabitEthernet0/1

Vim/CLI Output Example:
------------------------------------
Interface Role Sts Cost      Prio.Nbr Type
------------------------------------
Gi0/1     Alt  <b>BKN*</b> 4       128.1    P2p 
                                    
*<b>BKN</b> = Broken / Loop-Inconsistent 状態を示しています。

ステータスが BKN*（Loop-Inconsistent）になっていることが確認できれば、ループガードが正常に働き、データプレーンのループを未然に阻止している証拠だ。

2. 根本原因の特定（チェックスクリプト的思考）

ループガードが発動するということは、「対向機器からのBPDUが止まった」という厳然たる事実がある。以下の要因を疑う。

物理レイヤの確認: SFPトランシーバーの光パワーメーター測定（Rx/Txの減衰量確認）。
ケーブルの健全性: パッチコードの折れ曲がり、あるいは片側だけの抜け・緩み。
対向装置の健全性: 指定ブリッジ側（対向スイッチ）の極端なCPU高負荷によるBPDU送出停止、あるいはリブート中。

—

6. まとめ：パケットの奔流を守る静かなる番人

ループガードは、派手な機能ではない。平時には一切のトラフィックを生み出さず、ただ静かにBPDUの鼓動を聞き続けているだけの地味なプロトコル拡張にすぎない。

しかし、ひとたび物理的な闇（単方向リンク障害）が訪れたとき、ネットワーク全体がブロードキャストストームの炎に包まれるのを防ぎ、たった一人で踏みとどまる「最後の防壁」となる。

インフラアーキテクトやテックリードに求められるのは、単に「動く設定」を投入することではなく、「何が起きたときに、プロトコルがどう振る舞うべきか」というパケットレベルのストーリーを脳内で完全にシミュレーションできることだ。

ループガードの挙動を深く理解し適切に配置することで、あなたのネットワークは、物理層の気まぐれな断絶に対しても揺るぎないレジリエンスを手に入れることになるだろう。