スパニングツリープロトコルのトラブルシューティングと設計上の考慮事項

ライター翻訳版 - March 19, 2003

Document ID: 10556

ダウンロード: PDF

概要

Spanning-Tree Algorithm（STA; スパニングツリーアルゴリズム）の主な機能は、ブリッジネットワーク内の冗長リンクによって生み出されたループを取り除くことです。Spanning-Tree Protocol（STP; スパニングツリープロトコル）は、OSI モデルのレイヤ 2 で動作し、ブリッジ間で交換される Bridge Protocol Data Unit（BPDU; ブリッジプロトコルデータユニット）を使用して、最終的にトラフィックを転送またはブロックするポートを選択します。このプロトコルは特定の条件で失敗する場合があり、その結果生じた状況のトラブルシューティングは、ネットワークの設計によっては非常に困難になる場合があります。この領域に関するトラブルシューティングの最も重要な部分は、問題が発生する前に行われるとさえ言えます。

この文書では、STP の基本的な動作については説明しません。STP の動作については、次の文書を参照してください。

Catalyst スイッチのスパニングツリープロトコル（STP）の理解と設定

この文書は LAN 設計の完全なガイドではなく、ブリッジ処理の側面から見た、安全なネットワークの実装に役立つ推奨事項のリストです。プロトコル自体に関する知識を前提とした上で、ここでは次の事項を取り上げます。

STP が失敗する原因として考えられる理由
問題の根源を突き止めるために必要な情報
スパニングツリーのリスクを最小化し、トラブルシューティングを容易にするための設計

スパニングツリープロトコルの障害

一般に STA における障害は、ブリッジループに起因します（ループの形成に STP は不要であるため、スパニングツリーループには起因しません）。スパニングツリーの問題で TAC にサポートを求めるお客様のほとんどがバグを疑われますが、これまでの経験上、そのようなケースはほとんどありません。たとえソフトウェアが疑われる場合でも、STP 環境でブリッジループが発生する原因は常に、トラフィックをブロックすべきポートがトラフィックを転送している点にあります。

スパニングツリーコンバージェンス

Flash スパニングツリー Flash アニメーションに進み、例を見ます。この例では、スパニングツリーが最初に収束するしくみと、BPDU が過度に失なわれることによりブロックされたポートがフォワーディングモードに移行して、スパニングツリーアルゴリズムが失敗する理由を説明しています。この文書に戻るには、ブラウザの Back ボタンをクリックします。

これ以降、STA の障害につながるさまざまな状況について説明します。実際、これらの障害のほとんどは、大量の BPDU が失われたために、ブロックされたポートがフォワーディングモードに移行したことに関連しています。

二重モードのミスマッチ

ポイントツーポイントリンクにおける二重モードのミスマッチは、非常によく見られるコンフィギュレーションエラーです。これは、特にリンクの一方の側が全二重にハードコードされている場合に発生します。もう一方の側をオートネゴシエーションモードのままにしておくと、最終的に半二重になります（二重モードがハードコードされたポートがネゴシエートしなくなります）。

最悪のケースは、BPDU を送信しているブリッジがリンク上で半二重に設定されていて、そのピアが全二重に設定されている場合です。上記の例では、ブリッジ A と B を結ぶリンク上での二重モードのミスマッチから、容易にブリッジループが発生します。B は全二重に設定されているため、リンクにアクセスする際にキャリア検知を実行しません。続いて B は、A がすでにそのリンクを使用していても、フレームの送信を開始します。A は衝突を検出してバックオフアルゴリズムを実行してから次のフレームの転送を試みるため、A にとってこれは問題です。結果として、B から A への十分なトラフィックがある場合は、A によって送信されるすべてのパケット（BPDU を含む）が遅延または衝突し、最終的に廃棄されます。STP の観点から見ると、A からの BPDU が受信されなくなるため、ブリッジ B がルートを失います。これにより B は C へのポートのブロックを解除するため、ループが発生します。

二重モードのミスマッチが存在する場合は、CatOS が動作している Catalyst スイッチのスイッチコンソールに次のエラーメッセージが表示されます。二重モードの設定状況を調べて、その設定が一致していなければ、正しく設定してください。

   CDP-4-DUPLEXMISMATCH: Full/half duplex mismatch detected on port [mod]/[port]

単方向リンク

これは、ブリッジループの原因として最も頻度の高いものです。単方向リンクは多くの場合、ファイバリンクなどで検出されない障害や、トランシーバの問題によって発生します。単方向コミュニケーションの提供中にリンクがアップしたままになると、STP にとっては非常に危険です。次に単純化した例を示します。

ここでは、A と B の間のリンクが単方向で、B から A へのトラフィックは伝送されるものの、A から B へのトラフィックは廃棄されると仮定します。B はブロックされるものとします。すでに説明したように、ポートがブロックされているためには、プライオリティの高いブリッジから BPDU を受信する必要があります。このケースでは、A から送信される BPDU がすべて失われ、結果的にブリッジ B がトラフィックを転送するため、ループが形成されます。このケースでは、この障害が起動時に存在すると、STP が正しくコンバージしない点に注意してください。これは、ブリッジをリブートしてもまったく効果がないことを意味します（これに対して、前のケースではリブートが一時的に効果がある可能性があります）。

シスコでは、ハイエンドスイッチに Uni-Directional Link Detection（UDLD）プロトコルを導入しています。この機能では、不適切なケーブル接続またはレイヤ 2 上の単方向リンクを検出し、いくつかのポートを使用禁止にすることで、形成されたループを自動的に除去できます。これは、ブリッジ環境で単方向リンクが起こる可能性がある場合に非常に役立つ機能です。

パケットの破損

同種の障害は、パケットの破損によっても発生する場合があります。リンクに高い割合で物理的なエラーが発生した場合、一定数の BPDU が連続して失われ、ブロッキングポートがフォワーディングモードに移行する可能性があります。ただし、STP のデフォルトパラメータは堅実な値に設定されているため、こうしたケースはまれです。ブロッキングポートは、BPDU が 50 秒間失われない限りフォワーディングモードに移行しません。また、BPDU が 1 つでも伝送されればループは除去されます。こうしたケースが発生するのは、STP パラメータが不用意に変更された場合に限られます（最大経過時間を減らした場合など）。

パケットの破損の原因になるのは、二重モードのミスマッチ、ケーブル不良、不適切なケーブル長などです。

リソースエラー

スイッチング機能の大部分を専用の ASIC を使用してハードウェアで実行するハイエンドスイッチでも、STP はソフトウェアに実装されます。これは、なんらかの理由でブリッジの CPU の使用率が過大になった場合、BPDU を送信するリソースが不足する可能性があることを意味します。一般に、STA はプロセッサに過大な負荷をかけず、また他の処理より優先されます。後述の「リソースエラーの調査」の項で、特定のプラットフォームが処理できる STP インスタンスの数に関するガイドラインを示します。

PortFast の設定エラー

PortFast 機能は通常、ホストに接続されたポートに対して有効にします。このポートでリンクがアップされると、STA の最初の各ステージがスキップされ、ポートが直接フォワーディングモードに移行します。これは適切に使用しないと危険な機能です。ケーブルの移動時にはループが発生しますが、これは一時的なもので、通常はすぐに解消されます。

この例のブリッジ A では、ポート p1 はすでにフォワーディングモードで、ポート p2 は PortFast に設定されています。B はハブです。2 番目のケーブルが A に接続されると、ポート p2 はただちにフォワーディングモードに移行し、p1 と p2 の間にループが形成されます。p1 または p2 が BPDU を受信してブロッキングモードになると、このループはただちに解消されます。このような一時的なループでは、ループしているトラフィックが過大な場合、ループを停止する BPDU の送信にブリッジが失敗することがあります。これにより、コンバージェンスが著しく遅れる可能性があります。最新のハイエンド Catalyst ソフトウェアは BPDU ガードと呼ばれる機能を実装しており、PortFast に設定されたポートが BPDU を受信すると、そのポートを使用不可にします。

STP パラメータの不適切なチューニングと直径の問題

すでに見たように、最大経過時間パラメータおよび転送遅延を無理のある値に設定すると、STP が非常に不安定になることがあります。このような場合は、いくつかの BPDU が失われただけでループが発生します。この他に、あまり知られていない問題として、ブリッジネットワークの直径に関する問題があります。STP の保守的なデフォルト値では、最大ネットワーク直径は 7 に設定されています。これは、ネットワーク内のブリッジ同士の間隔が、7 ホップを超えてはならないことを意味します。この制約が課された一因は、BPDU の経過時間フィールドにあります。BPDU がルートブリッジからツリーのリーフに向けて伝搬されるとき、ブリッジを通過するたびに経過時間フィールドの値が増加します。最終的に BPDU の経過時間フィールドが最大経過時間を超えると、その BPDU は廃棄されます。これは通常、ネットワーク内の一部のブリッジがルートから遠すぎる場合に発生します。この問題は、スパニングツリーのコンバージェンスに影響を与えます。

ソフトウェアエラー

概要でも述べたように、STP はシスコ製品の最も初期の段階から実装されている機能です。この機能には非常に高い安定性を期待できます。ここまで見たいくつかの非常に特殊なケースにおける STP の障害は、EtherChanneling などの新機能とのインタラクションによってのみ発生しています。ソフトウェアのバグは予想できないため、発生する問題を詳細に説明することはできません。ここでは、最も危険な状況が生み出されるのは、BDPU の一部が無視される場合、つまり一般的に言えば、ブロッキングポートがフォワーディングモードに移行する場合であることを繰り返すにとどめます。

障害のトラブルシューティング

残念ながら、STP の問題を解決するための体系的な手順はありません。この項では、実行可能なアクションの要点をチェックリストのような形で示します。ここで示す事項のほとんどは、ブリッジループのトラブルシューティングに適用されます。接続損失の原因となるその他の STP の障害は、より一般的な方法で識別できます（問題が発生しているトラフィックが通ったパスの探索など）。

これらのトラブルシューティング手順のほとんどは、ブリッジネットワークの各種デバイスに接続できることを前提としています。これは、コンソールアクセスが可能であることを意味します。たとえば、おそらくブリッジループの際には Telnet の実行は不可能です。

今後予想される障害や修正の表示には、アウトプットインタープリタがご利用になれます。アウトプットインタープリタを使用するためには、CCO 登録ユーザとしてログインしており、 JavaScript を有効化している必要があります。

ネットワークダイアグラムの使用

ブリッジループのトラブルシューティングを行うには、ネットワークに関する基本的な情報を得る必要があります。

少なくとも次の情報が必要です。

ブリッジネットワークのトポロジ

ルートブリッジの位置

ブロックされたポート（および冗長リンク）の位置

この情報は、少なくとも次の 2 つの理由で不可欠です。

ネットワークが正常に稼働しているときの状態がわからなければ、ネットワークの中で修正すべき箇所がわかりません。

トラブルシューティングの手順の大部分は、show コマンドを使用してのエラー状況の識別です。ネットワークについての情報は、キーデバイスのクリティカルポートを特定する上で役立ちます。

ブリッジループの識別

かつては、ブロードキャストストームもネットワークに同じ影響を与える可能性がありました。現在は、ハードウェアレベルのスイッチングを提供する高速リンクおよびデバイスにより、たとえば単一のサーバからのブロードキャストによってネットワークがダウンするなどの可能性は、ほぼなくなりました。ブリッジループをほんとうに確実に識別するには、飽和状態のリンク上のトラフィックを取得し、同様のパケットが複数回見られるかどうかをチェックする必要があります。

しかし実際には、あるブリッジドメインのすべてのユーザに同時に接続の問題が発生した場合は、ブリッジループを疑うことができます。

デバイス上のポートの使用状況をチェックし、異常な値がないかを確認します。後述の「ポートの使用状況のチェック」の項を参照してください。

CatOS が動作している Catalyst スイッチでは、show system コマンドによってバックプレーン全体の使用状況を容易にチェックできます。このコマンドは、スイッチバックプレーンの現在の使用状況だけでなく、使用率のピーク（およびその日付）も特定できるため、非常に有用です。使用率のピークの異状を調べることにより、そのデバイスにブリッジループがあったかどうかががわかります。

接続の迅速な復旧と今後のための準備

ポートの使用禁止によるループの除去

ブリッジループは、ブリッジネットワークにきわめて深刻な結果をもたらします。管理者は通常、ループの発生理由を調べる時間がないため、できるだけ迅速に接続を復旧することを優先します。このようなケースでは、ネットワーク内で冗長性を提供しているポートすべてを手動で使用禁止にする方法が容易です。ネットワーク内で比較的影響の大きい部分がわかっている場合は、その領域のポートから使用禁止にしていきます。可能であれば、本来ブロッキングモードであるべきポートを最初に使用禁止にします。ポートを 1 つ使用禁止にするたびに、ネットワークの接続が復旧したかどうかをチェックします。ブリッジループに当たった場合は、ループが除去されればただちにその影響が消えます。どのポートを使用禁止にしたときにループが解消するかがわかれば、そのポートが位置する冗長パスに障害が存在していたことがわかります。そのポートが本来ブロッキングモードであるべきポートだった場合は、おそらくそこが障害の発生したリンクです。

ブロックされたポートをホストするデバイス上での STP イベントのロギング

問題の発生源を正確に特定できない場合や、問題が一時的にしか発生しない場合には、障害が発生しているネットワークのブリッジおよびスイッチで、STP イベントのロギングを有効にします。設定するデバイスの数を制限したい場合は、少なくともブロックされたポートをホストするデバイス上でこのロギングを有効にします。これは、ループは必ずブロックされたポートの移行によって発生するためです。

IOS：exec コマンド debug spantree events を入力して、STP デバッグ情報の生成を有効にします。一般の設定モードコマンド logging buffered を使用して、デバイスのバッファ内でこのデバッグ情報を取得します。

CatOS：コマンド set logging level spantree 7 default は、デバッグに関連する STP イベントのデフォルトレベルを増加させます。 set logging buffer 500 コマンドを使用して、スイッチのバッファ内で最大量のメッセージがロギングされていることを確認します。

syslog デバイスにこれらの出力の送信を試みることもできます。残念ながら、ブリッジループが発生した場合は、syslog サーバへの接続を維持できることはまれです。

ポートのチェック

すでに述べたように、最初に調査すべきクリティカルポートはブロッキングポートです。次に示すのは、各種ポートにおける調査項目のリストです。あわせて、IOS ベースのマシンと CatOS ベースのスイッチの両方について、入力すべきコマンドの簡単な説明も示します。

ブロックされたポートが BPDU を受信しているかどうかのチェック

特にブロックされたポートとルートポートで、定期的に BPDU を受信しているかどうかをチェックします。パケット/BPDU を受信していないポートには、複数の問題が発生している可能性があります。

IOS： IOS リリース 12.0 以降を使用している場合は、コマンド show spanning-tree <bridge-group #> を実行すると、BPDU というフィールドに各インターフェイスで受信した BPDU の数が表示されます。このコマンドを 1～2 回発行することにより、デバイスが BPDU を受信しているかどうかをすばやくチェックできます。
show spanning-tree コマンドの出力にフィールド BPDU がない場合は、debug spantree tree コマンドによって STP デバッグを有効にすることが、BPDU を受信しているかどうかを確認する最も容易な方法です。

CatOS： show mac <module/port> コマンドを実行すると、特定のポートで受信されているマルチキャストパケットの数がわかります。しかし最も簡単な方法は、show spantree statistic <module#/port#> <vlan#> を使用することです。このコマンドを実行すると、指定した VLAN 上の指定したポートで受信されたコンフィギュレーション BPDU の正確な数が表示されます（トランキングによって 1 つのポートが複数の VLAN に所属する場合もあります）。後述の「もう 1 つの CatOS コマンド」の項を参照してください。

二重モードのミスマッチのチェック

二重モードのミスマッチを調べるためには、当然、ポイントツーポイントリンクの両側をチェックする必要があります。

IOS： show interface コマンドを使用して、指定されたポートのスピードと二重モードのステータスをチェックします。

CatOS： show port <module#/port#> の出力の最初の行に、ポートのスピードと二重モードの設定状況が表示されます。

ポートの使用状況のチェック

すでに見たように、インターフェイスへの過大な負荷は BPDU の致命的な伝送失敗の原因になります。リンクへの過大な負荷も、ブリッジループの兆候を示します。

IOS：コマンド show interface を使用して、インターフェイスの使用状況を判別します。ここでは、load、packets input/output などのフィールドが役立ちます。

CatOS：ポート上で受信または送信されたパケットに関する統計情報を表示するコマンドは、show mac <module#/port#> です。コマンド show top では、ポートの 30 秒間の使用状況が自動的に評価され、結果が帯域利用率ごとに分類されて表示されます（その他のオプションもあります）。また、show system コマンドでは、個々のポートまでは特定されませんが、バックプレーンの使用状況を把握できます。

パケットの破損のチェック

IOS： show interface コマンドの input errors フィールドで増加している数字がないかを確認します。

CatOS：コマンド show port <module#/port#> の Aling-Err、FCS-Err、Xmit-Err、Rcv-Err、および Undersize フィールドから詳細情報が得られます。さらに詳細な統計情報が必要な場合は、show counters <module#/port#> コマンドを使用します。

もう 1 つの CatOS コマンド

STP のトラブルシューティングに関しては、Catalyst 用ソフトウェアの方が IOS よりも機能が豊富です。コマンド show spantree statistics <module#/port#> <vlan#> を使用すると、特定のポートに関する非常に正確な情報を入手できます。疑わしいポートにはこのコマンドを実行し、特に次のフィールドに注意を払ってください。

Forward trans count：このカウンタには、あるポートのラーニングからフォワーディングへの移行回数が記録されます。安定したトポロジでは、このカウンタは常に 1 を示しています。対応するポートがダウンしてアップすると、このカウンタが 0 にリセットされます。したがってこの値が 1 より大きい場合は、このポートの移行が、直接的なリンク障害の結果ではなく、STP 再計算の結果であることを意味します。

Max age expiry count：このカウンタは、このリンクにおける最大経過時間の超過回数を追跡します。基本的に、BPDU の到着を待っているポートで最大経過時間（デフォルトで 20 秒）が経過すると、代表ブリッジが失われたと見なされます。このイベントが発生するたびに、このカウンタは増加します。値が 0 でないときは、この LAN の代表ブリッジがなんらかの理由で BPDU を伝送できないか、または BPDU の伝送自体に問題があります。

リソースエラーの調査

すでに見たように、CPU 高使用率は STA が動作しているシステムにとって危険です。次に、デバイスの CPU リソースが不足していないかどうかをチェックする方法を示します。

IOS： show processes cpu コマンドを使用します。CPU 使用率が 100 % に近づいていないかどうかをチェックしてください。

CatOS： show inband の出力からフィールド RsrcErrors（リソースエラー）を探します（一部のスーパーバイザでは、このコマンドは show biga という名前になっています）。基本的にこのカウンタは、プロセッサの過負荷によってタスクの一部が実行できなかったときに増加します。1 つのスーパーバイザエンジンが処理できる STP インスタンスの数には限界があります。これについては、実行しているソフトウェアのリリースノートをチェックしてください。

次に、Catalyst 4000/5000/6000 シリーズに適用される制限事項の要約を示します。

各種 VLAN の STP インスタンス全体にわたる論理ポートの総数が、スーパーバイザエンジンの各タイプおよびメモリコンフィギュレーションでサポートされている最大数を超えないようにしてください。スイッチ上の論理ポートの総数は、show spantree summary コマンドと次の公式を使用して計算できます。

（非 ATM トランクの数 x そのトランク上でアクティブな VLAN の数）

+ 2 x（ATM トランクの数 x そのトランク上でアクティブな VLAN の数）

+ 非トランキングポートの数

上記の公式から求められる論理ポートの総数が、次の値以下である必要があります。

Catalyst 4000 シリーズ：

Catalyst 4000 ファミリスーパーバイザエンジン I および II については、1500

Catalyst 5000 シリーズ：

スーパーバイザエンジン I（8 MB DRAM）については、200

スーパーバイザエンジン I（20 MB DRAM）については、400

スーパーバイザエンジン II および III F については、1500

スーパーバイザエンジン II G および III G については、1800

スーパーバイザエンジン III については、4000

Catalyst 6000 シリーズ：

スーパーバイザについては、4000

不要な機能の無効化

トラブルシューティングは、現在のネットワーク内で問題になっている箇所を特定することです。この観点から見ると、できるだけ多くの機能を無効にすれば、ネットワーク構造が簡素化されるため、問題の特定が容易になります。たとえば EtherChanneling は、STP を使用して複数の異なるリンクを論理的に 1 つのリンクに束ねる高度な機能です。トラブルシューティング中は、この機能を無効にします。これは 1 つの例に過ぎませんが、一般に設定をできるだけシンプルにすることは、トラブルシューティングの労力軽減につながります。

役に立つコマンド

Catalyst IOS のコマンド

Catalyst OS のコマンド

トラブルを回避するための STP の設計

ルートブリッジの特定

小さなことのようですが、トラブルシューティングの際にこの情報が得られないことは少なくありません。ルートになるブリッジが STP によって決定されることは避ける必要があります。ネットワークの設計に応じて、VLAN ごとにルートとして適したスイッチを特定できる必要があります。通常は、ネットワークの中心に位置する強力なブリッジを選択することをお勧めします。ルートブリッジをネットワークの中心に置き、サーバおよびルータに直接接続すると、ほとんどの場合、クライアントからサーバおよびルータまでの平均距離が短縮されます。

このシンプルな図では、次のことが明らかです。

ブリッジ B がルートである場合、A または C で AC 間のリンクがブロックされます。このケースでは、スイッチ B に接続されたホストはサーバとルータに 2 ホップでアクセスでき、ブリッジ C に接続されたホストは 3 ホップでアクセスできます。したがって、平均ホップ数は 2.5 になります。

ブリッジ A がルートの場合は、B と C のどちらに接続されたホストも 2 ホップでルータおよびサーバにアクセスでき、これらの平均距離は 2 ホップになります。

この例では明白ですが、より複雑なトポロジで必要となるしくみと同種のものです。

重要：各 VLAN について、STP プライオリティパラメータの値を小さくすることにより（または set spantree root マクロを使用して）、ルートブリッジおよびバックアップルートブリッジをハードコードしてください。

冗長箇所の特定

冗長リンクの構成方法について計画します。ここでも、STP のプラグアンドプレイ機能のことは忘れてください。STP のコストパラメータを変更することで、ブロックされるポートを決定します。設計が階層的で、ルートブリッジの位置が適切な場合は、これが不要な場合もあります。

重要： 各 VLAN について、安定したネットワークでどのポートがブロックされるべきかを把握してください。ネットワーク内の各物理ループの位置と、ループを除去するためにブロックすべきポートを明確に示すネットワークダイアグラムを用意してください。

冗長リンクの箇所が正確にわかっていれば、ブリッジループが発生した場合にループおよび原因を特定する上で役立ちます。また、ブロックされるポートの位置がわかっていれば、簡単な比較によってエラーの発生箇所を発見できます。

ブロックされるポートの数の最小化

STP によって行われる唯一の重要なアクションは、ポートをブロックすることです。エラーによって 1 つのポートがブロッキングからフォワーディングに移行するだけで、ネットワークの多くの部分がダウンする可能性があります。STP の使用に伴うリスクを最小化する最善の方法は、ブロックされるポートの数をできるだけ少なくすることです。

使用されない VLAN のプルーニング

ブリッジネットワーク内の 2 つのノード間には、3 つ以上の冗長リンクは不要です。しかし、このような設定はしばしば見受けられます。

これは非常によく見られる設計です。2 つのコアスイッチに、ディストリビューションスイッチが二重接続されています。ディストリビューションスイッチには、ネットワーク内で利用可能な VLAN のサブセット内のユーザのみが接続します（ここでは、Dist2 には VLAN 2 内のユーザのみが接続し、Dist3 には VLAN 3 内のユーザのみが接続します）。デフォルトでは、トランクは VTP ドメインで定義されたすべての VLAN を伝送します。ここでは Dist2 のみが VLAN3 の不要なブロードキャストとマルチキャストのトラフィックを受信していますが、VLAN3 へのポートの 1 つもブロックされています。この結果、コア AB 間には 3 つの冗長パスが存在することになります。つまり、さらに多くのポートがブロックされ、ループの可能性が増大することになります。

重要： 不要な VLAN はすべてトランクからプルーニングしてください。

VTP プルーニングを利用すればこれを実現できますが、このようなプラグアンドプレイ機能はネットワークのコア部分ではほんとうに必要なものではありません。

前の例をもう一度使用します。今回は、コアへのディストリビューションスイッチにアクセス VLAN のみを使用して接続します。

この設計では、ブロックされるポートは VLAN ごとに 1 つのみです。また、この設計では、Core A または Core B をシャットダウンすることにより、すべての冗長リンクを 1 ステップで除去できます。

レイヤ 3 スイッチングの使用

レイヤ 3 スイッチングとは、ほぼスイッチングスピードでのルーティングを意味します。ルータは主に次の 2 つの機能を担います。

一般にルーティングプロトコルを使用したピアとの情報交換により、転送テーブルを作成します。
パケットを受信し、宛先アドレスに基づいて正しいインターフェイスに転送します。

現在ハイエンドの Cisco レイヤ 3 スイッチでは、この 2 番目の機能をレイヤ 2 スイッチング機能と同じスピードで実行できます。ルーティングホップの導入やネットワークセグメンテーションの追加によるスピードペナルティはありません。次に、もう一度同じダイアグラムを使用します。

この例では、Core A と Core B はレイヤ 3 スイッチです。Core A と Core B の間で VLAN 2 および VLAN 3 をブリッジ処理していないため、STP によって除去されるループがなくなっています。

冗長性はまだ存在しますが、レイヤ 3 ルーティングプロトコルに依存しています（また、STP の場合よりも再コンバージェンスははるかに高速になります）。

STP によってブロックされるポートはもはや存在しません。このため、ブリッジループが発生する可能性が完全に排除されます。

レイヤ 3 スイッチングによって VLAN を通過するスピードは、VLAN 内部のブリッジ処理と同等のため、スピードペナルティはありません。

唯一の欠点は、このような設計に移行するには一般にアドレッシング方式を変更する必要がある点です。

使用しない STP の維持

ブロックされるポートをネットワークから完全に除去できた場合でも、また物理的な冗長がない場合でも、STP は有効にしておくのが安全です。一般に STP はプロセッサへの負荷が小さく（さらに、ほとんどの Cisco スイッチではパケット変換に CPU を使用しません）、各リンクで送信されるわずかな BPDU によって、使用可能な帯域幅が著しく減少することはありません。これに対して、STP が有効になっていないブリッジネットワークは、オペレータによるパッチパネル上のエラーなどによって瞬時にダウンする可能性があります。ブリッジネットワークで STP を無効にすることは、ほとんどの場合、リスクに見合う価値がありません。

管理 VLAN からのトラフィックの分離と、単一 VLAN によるネットワーク全体のスパニングの回避

次の 2 点が関連します。

Cisco スイッチは通常、ある VLAN（「管理 VLAN」とも呼ばれる）にバインドされた単一の IP アドレスを持ちます。この VLAN では、スイッチは汎用 IP ホストのように機能します。特に、ブロードキャストパケットおよびマルチキャストパケットはすべて CPU に転送されます。管理 VLAN で大量のブロードキャストまたはマルチキャストが行われると、CPU に過大な負荷がかかり、BPDU の処理能力に致命的な影響が出る場合があります。したがって、管理 VLAN からは常にユーザトラフィックを分離しておくことをお勧めします。

最近まで、シスコの実装では、VLAN 1 をトランクから除去する方法はありませんでした。この VLAN は一般に管理 VLAN として使用されており、すべてのスイッチに同一の IP サブネットでアクセスできます。これは便利である半面、VLAN 1 上のブリッジループがすべてのトランクに影響を与え、ネットワーク全体をダウンさせるおそれがあります。もちろん、同じ問題は VLAN の種類を問わず存在します。可能であれば、高速レイヤ 3 スイッチを使用したブリッジングドメインのセグメント化を試してください。

CatOS ソフトウェアバージョン 5.4 以降では、トランク上の VLAN 1 をクリアできます（実際には VLAN 1 が存在しますが、トラフィックがブロックされるため、ループが発生する可能性が排除されます）。

STP パラメータのチューニングの回避

特に注意を払う必要があるのは、STP タイマーをデフォルト値から変更しようとする場合です。（他のオプションとしては、CatOS マクロの使用があります。）これによって再コンバージェンスの高速化などを試みることは、非常に危険です。これにより、ネットワークの直径や STP の安定性に影響が出る可能性があります。変更してもよいパラメータは、ブリッジプライオリティ（ルートブリッジの選択のため）とポートコストまたはポートプライオリティ（冗長性とロードバランシングの制御のため）のみです。

Cisco Catalyst ソフトウェアでは、重要な STP パラメータを細かくチューニングできるマクロが用意されています。

set spantree root [secondary] コマンド：これは、ブリッジプライオリティを小さくしてルート（または代替ルート）にするマクロです。その他に、ネットワークの直径を指定して STP タイマーをチューニングするオプションもあります。タイマーのチューニングは、正しく行った場合でもコンバージェンス時間の大幅な短縮にはつながりません（Uplink Fast や Backbone Fast などの機能や、適切に設計されたレイヤ 3 スイッチングなどと比較しても、特にコンバージェンス時間は変わりません）。また、ネットワークが不安定になるリスクもあります。このようなチューニングは、ネットワークにデバイスを追加するたびに更新する必要があります。ネットワークエンジニアが見慣れた、保守的なデフォルト値をそのまま使用することをお勧めします。

set spantree uplinkfast コマンドにより、スイッチプライオリティを上げて、ルートにはならないようにすることができます。通常、このコマンドは、複数のコアスイッチに多重接続されたディストリビューションスイッチで使用するはずです。このコマンドの影響についての詳細は uplink fast 機能についての文書をお読みください。

UDLD の設定（可能な場合）

ブロックされたポートを持つリンクで単方向リンクが発生した場合は、50 % の確率でブリッジループが発生します。STP のアルゴリズムはこの状況にまったく対処できません。したがってこれは、STP の障害が発生する危険性がきわめて高い状況です。最新の Catalyst ソフトウェアには、この危険の検出に役立つ Uni-Directional Link Detection（UDLD）機能が実装されています。この機能は、Cisco デバイス間のポイントツーポイントリンクでのみ有効です。

Hierarchical Navigation

LAN スイッチング : スパニング ツリー プロトコル