ネットワークの勉強をしていると、必ず出てくるのがSTP（スパニングツリープロトコル）です。CCNAでも出題されますし、現場でも当たり前に動いています。
ただ、教科書を読んでも「ルートブリッジを選出して、ルートポートと指定ポートを決めて、残ったポートをブロッキングする」という説明が続くだけで、結局それが現場で何の役に立つのかが見えにくい技術でもあります。
この記事では、STPの仕組みを押さえたうえで、実際にループが起きたときに現場で何が見えるのか、なぜブロッキングポートが意図しない場所に出てしまうのかを、現役10年の視点で解説します。
ループって、起きたらすぐ分かるものなんですか？
それが分かりにくいんです。完全に止まるんじゃなくて、「なんか変だな」から始まることが多いですね。
STPとは？ループを防ぐために、あえて通信を止める仕組み
STP（Spanning Tree Protocol、スパニングツリープロトコル）は、レイヤ2のループを防ぐためのプロトコルです。IEEE 802.1Dとして標準化されています。
やっていることは単純で、ループになる経路を見つけて、その一部を強制的に塞ぎます。塞がれたポートは通信を転送しません。
「せっかく繋いだ線を使わないのか」と思うかもしれません。そのとおりです。STPは帯域を増やす技術ではなく、事故を防ぐための技術です。冗長化のために2本繋いでも、平常時に使えるのは1本だけになります。
ただし塞いだポートは、生きているリンクが切れたときに自動で開きます。だから冗長性は確保されている。ここがSTPの本質です。
ループが起きると何が困るのか
そもそも、なぜループがそんなに危険なのでしょうか。
問題はブロードキャストの扱いにあります。スイッチはブロードキャストフレームを受け取ると、受信したポート以外の全ポートに転送します。これ自体は正常な動作です。
ところが経路がループしていると、転送されたフレームがぐるっと回って戻ってきます。スイッチはそれを再びブロードキャストする。また戻ってくる。また転送する。
ここで決定的なのが、レイヤ2のフレームには生存期間の仕組みがないという点です。IPパケットにはTTLがあり、一定回数ルータを通ると破棄されます。ところがイーサネットフレームにはそれがありません。誰も止めないので、無限に回り続けます。
結果、フレームが指数関数的に増えます。これがブロードキャストストームです。帯域が埋まるだけでなく、スイッチのCPUも処理に追われます。
さらにMACアドレステーブルも壊れます。同じ送信元MACのフレームが複数のポートから届くため、スイッチは「この機器はどのポートの先にいるのか」を判断できなくなり、学習内容が書き換わり続けます。
【現場の実感】ループしているときは「変な雰囲気」がある
ここからが、教科書に書いていない話です。
実際にループが起きているとき、現場で最初に感じるのは「ブロードキャストストームが発生している」という明確な認識ではありません。もっと曖昧な、変な雰囲気です。
具体的には、こういう感覚です。
- 管理系のプロトコルの反応が遅い
- 機器の管理画面が開かない、開いても表示が途中で止まる
- SSHやTelnetのレスポンスがもたつく
- 全体的に「あれ？」という違和感がある
完全に通信が止まるわけではないのが、かえって厄介なところです。「なんとなく調子が悪い」という状態が続きます。
この症状には理由があります。ブロードキャストの洪水はスイッチのCPUを圧迫しますが、管理系の通信はCPUが処理するためです。データの転送はハードウェアが担当するので影響が出にくい一方、SSHやSNMP、管理画面といったCPU依存の処理から先に悪化します。
つまり「管理画面が重い」は、単なる機器の不調ではなく、L2で何かが起きているサインかもしれない。この感覚を持っているかどうかで、原因にたどり着く速さが変わります。
管理画面が重いだけだと、機器の不調かと思ってしまいそうです。
そこでL2を疑えるかどうかが分かれ目です。データ転送はハードウェア処理なので、症状が出るのが遅いんですよ。
とりあえずケーブルを抜く、は絶対にやってはいけない
ループが疑われたとき、つい手が出そうになるのが「怪しいケーブルを抜く」です。
これはやってはいけません。
抜けば症状は収まるかもしれません。でもそれは、原因が分からなくなるということです。何が起きていたのか、どこがループしていたのか、なぜそうなったのか。すべて闇の中に消えます。
そして原因が分からなければ、同じことがまた起きます。次に起きたときも同じように場当たり的に抜くしかない。これは解決ではありません。
私が最初にやるのはログの確認です。
STPのトポロジ変更、ポートの状態遷移、MACアドレスのフラッピングといった事象は、ログに残ります。ここを見れば、いつ何が起きたのか、どのポートが関係しているのかが分かります。まず状況を記録してから、対処に移る。順番が逆になると、後で何も説明できなくなります。
STPの動作：ルートブリッジを決めて、遠いところを塞ぐ
仕組みを整理します。STPは3つのステップで動きます。
ステップ1：ルートブリッジを選出する
まず、ネットワーク内の全スイッチから中心となる1台を決めます。これがルートブリッジです。
選ばれる基準はブリッジIDが最も小さいスイッチ。ブリッジIDは「プライオリティ値＋MACアドレス」で構成されます。
ここが重要です。プライオリティのデフォルト値は全機器で同じ（32768）なので、何も設定しなければMACアドレスが小さい機器が自動的にルートブリッジになります。
MACアドレスは製造時に決まるものです。つまり設計とは何の関係もない基準で、ネットワークの中心が決まってしまいます。
ステップ2：各スイッチでルートポートを決める
ルートブリッジ以外の各スイッチは、ルートブリッジに最も近いポートを1つ選びます。これがルートポートです。
「近い」の基準はパスコストで、帯域が広いリンクほどコストが小さくなります。コストが同じ場合はブリッジIDの小さい方が優先されます。
ステップ3：残ったポートをブロッキングする
各リンクには指定ポートが1つ決まります。そして、ルートポートでも指定ポートでもないポートがブロッキング状態になります。
ここで通信が遮断され、ループが解消されます。ざっくり言えば、ルートブリッジから最も遠いところが塞がれるということです。
【落とし穴】意図しないポートがブロッキングになる
ここが実務で一番ハマるところです。
STPは正しく動いています。ループも防げています。でも、塞がれている場所が想定と違う。
原因は、先ほどのステップ1です。プライオリティを設定していなければ、MACアドレスが小さい機器がルートブリッジになります。そしてルートブリッジの位置が変われば、「最も遠い場所」も変わる。結果としてブロッキングされるポートが動きます。
何が問題かというと、塞がれたポートは通信を通さないということです。設計上メインで使うつもりだった経路が塞がれ、本来バックアップだった細い回線に通信が流れる。こういう状態が起こり得ます。
しかも通信自体は成立しているので、障害としては上がってきません。「なんとなく遅い」で放置されることもあります。
古い機器を残したまま新しい機器を追加したときも要注意です。MACアドレスは製造時期と無関係なので、アクセススイッチがルートブリッジになっているという構成が普通に発生します。
だからルートブリッジはプライオリティで意図的に決める
対策はシンプルです。ルートブリッジを自分で決めます。
私の現場でも、基本的にはプライオリティを明示的に設定しています。自動選出に任せることはあまりありません。
設定方法は2つあります。
spanning-tree vlan [VLAN番号] root primaryでルートブリッジに指定するspanning-tree vlan [VLAN番号] priority [値]でプライオリティ値を直接指定する
どちらでも構いません。プライオリティ値は4096の倍数で指定します。
置く場所は、トラフィックが集まる中心のスイッチです。コアやディストリビューションに置くのが基本で、末端のアクセススイッチに置くことはまずありません。
セカンダリ（ルートブリッジが落ちたときの次点）も設定できますが、正直に言うと私はそこまで細かく設定しないことの方が多いです。設計の要件次第だと思います。
ブロッキングポートの確認方法
意図した場所が塞がれているかを確認するコマンドを紹介します。
| コマンド | 分かること |
|---|---|
show spanning-tree | 各ポートの役割と状態、ルートブリッジ情報 |
show spanning-tree blockedports | ブロックされているポートの一覧 |
show spanning-tree root | ルートブリッジがどれか |
show spanning-tree summary | 状態別のポート数の集計 |
手っ取り早いのは show spanning-tree blockedports です。塞がれているポートだけが並ぶので、想定と違えばすぐ分かります。
「Blockingが0だから大丈夫」は間違い
ここで初心者が必ず引っかかる罠があります。
show spanning-tree summary を実行して、Blockingの欄が0だったとします。これを見て「ブロックされているポートがない＝ループしていない」と判断するのは間違いです。
そのコマンドが教えてくれるのは、そのスイッチにブロックポートがないという事実だけです。ネットワーク全体のことは何も分かりません。
特に紛らわしいのが、自分がルートブリッジだった場合です。ルートブリッジは全ポートがフォワーディングになるので、当然Blockingは0になります。正常な状態でも0、というわけです。
ブロックポートは、ルートブリッジから遠い側のスイッチに現れます。確認するなら、そちら側で見てください。
PortFastとBPDUガード
STPには収束までの待ち時間があります。ポートがリンクアップしてから通信できるようになるまで、状態遷移のために数十秒かかります。
スイッチ同士なら必要な時間ですが、PCを繋いだポートでこれをやられると困ります。起動してもネットワークに繋がらない、という状態が発生するからです。
そこで使うのがPortFastです。設定したポートは、リンクアップ後すぐにフォワーディング状態になります。待ち時間がなくなります。
ただし、PortFastは端末を繋ぐポートにだけ設定してください。スイッチを繋ぐポートに入れると、ループが検知される前に通信が始まってしまいます。事故のもとです。
この事故を防ぐのがBPDUガードです。PortFastを設定したポートでBPDU（STPの制御フレーム）を受信したら、そのポートを強制的に停止します。
BPDUが届くということは、その先にスイッチがいるということ。端末用のポートにスイッチが繋がれた、つまり想定外の接続が起きたと判断して遮断する仕組みです。
PortFastとBPDUガードはセットで設定する。これが基本です。
現場で使われているSTPの種類
STPにはいくつか種類があります。
| 種類 | 特徴 |
|---|---|
| STP（802.1D） | 元祖。収束が遅い |
| RSTP（802.1w） | 収束を高速化したもの |
| PVST+ | VLANごとにSTPを動かすCisco独自方式 |
| Rapid PVST+ | PVST+をRSTPベースにしたもの |
| MST（802.1s） | 複数VLANをグループ化して負荷を抑える |
Cisco環境で私が使っているのはPVST系です。VLANごとにツリーを持てるので、VLANによってブロッキング位置を変えられます。負荷分散という意味では理にかなっています。
MSTはVLAN数が多い大規模環境で効いてきますが、設定が複雑になります。CCNAの学習段階では、PVST系とRSTPの考え方を押さえておけば十分です。
EtherChannelを組んだ区間にSTPは必要か
最後に、実務でよく議論になる話を。
EtherChannelで複数リンクを束ねると、STPからは1本の論理リンクに見えます。ループが存在しないのでブロッキングも発生しません。実際、EtherChannel区間では show spanning-tree blockedports に何も出てきません。
では、STPは要らないのか。
私の現場では、EtherChannelで組んだ区間には基本的にSTPを入れていません。ループが構造的に存在しないので、動かす意味が薄いからです。
ただし「絶対に入れない」ではありません。入れることもあります。
判断が分かれるのは、想定外の接続に対する保険をどこまでかけるかです。設計上ループがなくても、誰かが余ったケーブルをスイッチ同士に挿せばループは生まれます。STPを動かしておけば、そのとき自動で止まります。
設計どおりに運用される前提で組むか、人が間違える前提で組むか。ここは環境と運用体制によって答えが変わる部分です。
まとめ
STPについて押さえておきたいポイントをまとめます。
- STPはループを防ぐために、あえてポートを塞ぐ仕組み
- L2にはTTLがないため、ループするとフレームが無限に増える
- ループの初期症状は「管理画面が重い」など、CPU依存の処理から現れる
- 疑わしくてもケーブルを抜かない。まずログを見る
- プライオリティ未設定だとMACアドレスでルートブリッジが決まる
- 意図しない場所が塞がれると、通信は成立するのに遅い状態になる
show spanning-tree summaryのBlockingが0でも安心はできない- PortFastは端末ポートだけ。BPDUガードとセットで設定する
試験対策としては、ルートブリッジの選出基準とポートの役割を覚えれば得点できます。ただ現場で効いてくるのは、ブロッキングがどこに出るかを設計で決めておくという視点の方です。
STPは正しく動いていても、設計者の意図どおりとは限りません。そこを意識できると、構成を見る目が変わります。
コメント