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

ライター翻訳版 - December 31, 2004

Document ID: 12013

ダウンロード: PDF

目次

概要
前提条件
      要件
      使用するコンポーネント
      表記法
トポロジ変更メカニズムの目的
動作の原理
      ルート ブリッジへの通知
      ネットワークへのイベントのブロードキャスト
ネットワークで多数のトポロジ変更がある場合の対応
      トラフィックのフラッド
      ATM LANE ブリッジ環境での問題
      portfast コマンドの使用による TCN 生成の回避
      TCN の発信元の追跡
結論
NetPro ディスカッション フォーラム - 特集対話
関連情報

概要

スパニングツリー プロトコル（STP）の動作を監視していると、統計ログのトポロジ変更カウンタが増分することに懸念を持つことがあります。 STP では、トポロジの変更は通常の動作です。 ただし、回数が多すぎると、ネットワークのパフォーマンスに悪影響を及ぼすことがあります。 この文書では、このトポロジの次の目的について説明します。

• per-VLAN spanning tree（PVST; VLAN 単位のスパニング ツリー）環境と PVST+ 環境でのメカニズムの変更。

• トポロジ変更イベントを発生させる原因の特定。

• トポロジ変更メカニズムに関連する問題の説明。

前提条件

要件

この文書に関する特別な要件はありません。

使用するコンポーネント

この文書は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

この文書の情報は、特定のラボ環境にあるデバイスに基づいて作成されています。この文書内で使用されているデバイスはすべて、クリアな状態（デフォルト）から設定作業を始めています。対象のネットワークが実稼動中である場合には、すべてのコマンドによる潜在的な影響について確実に理解しておく必要があります。

表記法

文書表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

トポロジ変更メカニズムの目的

ブリッジは、受信したフレームからホストの Media Access Control（MAC; メディア アクセス制御）アドレスを学習し、このホストに到達するために経由するポートと関連付けたテーブルを作成します。 このテーブルは、フレームの宛先ポートに直接フレームを転送するために使用されます。 これにより、フラッディングを回避できます。

このテーブルのデフォルトのエージング タイムは、300 秒（5 分）です。 ホストからの受信がないまま 5 分が経過すると、ブリッジのテーブルからそのホストのエントリが消えます。 この例で、エージングをより早くできる理由を示します。

このネットワークでは、ブリッジ B1 が B4 へのリンクをブロックしていると仮定します。 A と B は、接続が確立している 2 台の端末です。 A から B へのトラフィックは、B1、B2、B3 を経て B4 に到達します。 次の構造は、この状況の 4 台のブリッジから学習した MAC アドレスのテーブルを示しています。

ここで、B2 と B3 の間のリンクに障害が発生したと仮定します。 A と B の間のコミュニケーションは、B1 から B4 にフォワーディング モードでポートが設定されるまで中断されます（デフォルトのパラメータでは最大 50 秒間）。 しかし、A が B にフレームを送信しようとしても、まだ B1 には B2 へのエントリがあるため、パケットはブラック ホールに送信されてしまいます。 B が A に到達しようとする場合にも、同様のことが起きます。A と B の MAC アドレスのエントリがエージング アウトするまでの 5 分間、コミュニケーションは中断します。

ブリッジに実装された転送データベースは、安定したネットワークでは、非常に効果的です。 しかし、ネットワークのトポロジが変更された場合は、5 分間のエージング タイムが問題になる状況が多数あります。 トポロジ変更メカニズムは、そのような問題の回避策です。 ネットワークのトポロジが変更されたことをブリッジが検出すると（リンクのダウンや、転送モードへの移行など）、ブリッジ ネットワーク全体にイベントをアドバタイズします。

これが実際に実装されるしくみについては、「動作の原理」セクションに説明があります。 各ブリッジでは、通知後の一定時間（max_age + forward_delay）、経過時間が forward_delay（デフォルト値は 15 秒）に短縮されます。 テーブルをクリアするより、エージング タイムを短くするほうが、より有益です。これは、現在アクティブで効率よくトラフィックを伝送しているホストがテーブルからクリアされないからです。

この例では、ブリッジ B2 または B3 は、ダウンしているリンクを検出すると、ただちにトポロジ変更通知を送信します。 すべてのブリッジはイベントを認識し、それぞれのエージング タイムを 15 秒に短縮します。 B1 がそのポート上で 15 秒以内に B2 へのパケットを B から受信しない場合は、このポート上での B のエントリはエージング アウトされます。 B3 または B4 へのポート上にある A のエントリについても同じことが起きます。 後で、B1 と B4 の間のリンクが転送モードに移行すると、このリンクですぐにトラフィックがフラッドし、再学習されます。

動作の原理

このセクションでは、Bridge Protocol Data Unit（BPDU; ブリッジ プロトコル データ ユニット）レベルで、どのようにブリッジがトポロジ変更をアドバタイズするかを説明します。 .

ブリッジが、いつトポロジ変更を検出したと認識するかについては、すでに簡単に説明しました。 正確には、次のように定義されます。

• フォワーディングしていたポートが使用不能になった場合（ブロッキングなど）。

• ポートがフォワーディングに移行して、ブリッジに代表ポートを設定している場合 （これは、ブリッジがスタンドアロンではないことを意味します）。

ネットワーク内のすべてのブリッジに通知を送信するプロセスは、次の 2 つのステップで行われます。

• ブリッジからルート ブリッジにスパニング ツリーが通知されます。

• ルート ブリッジからネットワーク全体に情報が「ブロードキャスト」されます。

ルート ブリッジへの通知

通常の STP の動作では、ブリッジはそのルート ポート上のルート ブリッジからコンフィギュレーション BPDU を継続して受信します。 しかし、ルート ブリッジに BPDU を送出することはありません。 これを実行するために、トポロジ変更通知（TCN）BPDU という特別な BPDU が導入されました。 これによりブリッジは、トポロジ変更を知らせる必要が生じると、そのルート ポートに TCN の送信を開始します。 代表ブリッジでは、TCN が受信されると、受信確認が返送され、ルート ポートに別の TCN が生成されます。 このプロセスは、TCN がルート ブリッジに到達するまで続けられます。

TCN は、何の情報も含まない単純な BPDU で、ブリッジによって hello_time 秒ごとに送信されます（この hello_time はローカルに設定されたもので、コンフィギュレーション BPDU に指定されている hello_time ではありません）。 代表ブリッジでは、TCN の受信確認として、Topology Change Acknowledgement（TCA）ビット セットを含む、通常のコンフィギュレーション BPDU がすぐに返送されます。 トポロジ変更を通知しているブリッジは、代表ブリッジによって通知が確認されるまで TCN の送信を停止しません。 したがって、代表ブリッジは、ルート ブリッジからコンフィギュレーション BPDU を受信していない場合でも、TCN に対して応答します。

ネットワークへのイベントのブロードキャスト

ルート ブリッジは、ネットワーク内でトポロジ変更イベントが発生したことを認識すると、トポロジ変更（TC）ビットをセットして、自身のコンフィギュレーション BPDU の送出を開始します。 これらの BPDU は、このビットがセットされた状態で、ネットワーク内の各ブリッジによってリレーされます。 その結果、すべてのブリッジがトポロジ変更の状況を認識し、エージング タイムを forward_delay まで短縮できます。 ブリッジは、トポロジ変更 BPDU をフォワーディング ポートとブロッキング ポートの両方で受信します。

TC ビットは、ルート ブリッジにより max_age + forward_delay 秒の間、セットされます。これは、デフォルトでは 20+15=35 秒になります。

ネットワークで多数のトポロジ変更がある場合の対応

ここでは、TCN によって起こされる可能性のある問題について説明します。 その後で、トポロジ変更を制限する方法と、それらがどこから来たかを見つける方法について説明します。

一部ツールについては、ゲスト登録の お客様にはアクセスできない場合がありますことを、ご了承ください。

トラフィックのフラッド

ネットワーク内に存在するホストの数が多ければ多いほど、トポロジ変更が発生する可能性が高くなります。 たとえば、直接接続されているホストでは、電源をオフ/オンするとトポロジ変更がトリガされます。 非常に大規模な（およびフラットな）ネットワークでは、ネットワークが絶え間なくトポロジ変更される状態になることがあります。 これは、エージング タイムが 15 秒に設定されているのと同様であるため、高レベルのフラッディングが発生します。 なんらかのサーバ バックアップを行っている場合などに、このような最悪のシナリオになります。

バックアップを受信するデバイスのエントリのエージング アウトは厄介です。これは、すべてのユーザに悪影響を与えるようなトラフィックの輻輳を引き起こします。 TCN 生成を回避する方法については、「portfast コマンドの使用による TCN 生成の回避」セクションを参照してください。

ATM LANE ブリッジ環境での問題

このケースは、クイック エージングに伴う通常のトラフィック フラッディングよりも深刻です。 VLAN のトポロジ変更を受信すると、Catalyst スイッチは LAN エミュレーション（LANE）ブレードに対して、それらの LE-arp テーブルで対応するエミュレート LAN（ELAN）を再確認するように指示します。 ELAN のすべての LANE ブレードは、同時に同じ要求を発行するため、再確認する必要のあるエントリが大量にある場合は、LAN エミュレーション サーバ（LES）に高い負荷が加わります。 このシナリオには、接続性の問題があります。 ネットワークがトポロジ変更の影響を受けやすい場合、本当の問題はトポロジ変更そのものではなく、ネットワークの設計にあります。 できる限り TCN 生成を制限して、LES の CPU を節約することを推奨します。 TCN 生成を制限する方法については、「portfast コマンドの使用による TCN 生成の回避」セクションを参照してください。

portfast コマンドの使用による TCN 生成の回避

portfast 機能は、STP 実装をシスコ独自に変更したものです。 Portfast コマンドは、特定のポートに適用されると 2 つ結果が得られます。

• アップしたポートは、ラーニング プロセスおよびリスニング プロセスを経過せずに、直接、転送 STP モードに置かれます。 portfast では、引き続きポート上で STP が実行されています。

• portfast が設定されたポートがアップまたはダウンしても、スイッチでは TCN が生成されません。

接続されているホストがリンクをアップまたはダウンさせる可能性の高いポート（通常は、ユーザが頻繁に電源をオフ/オンする端末）で、portfast を有効にします。 この機能は、サーバ ポートでは必要ありません。 ハブまたは他のブリッジなどに接続されているポートでは、絶対に使用しないでください。 冗長リンク上で直接に転送状態に移行するポートでは、一時的なブリッジ ループを引き起こす可能性があります。

トポロジ変更は有用なので、リンクのアップまたはダウンがネットワークの重要なイベントになるポートでは、portfast を有効にしないでください。

TCN の発信元の追跡

トポロジ変更通知は、それ自体では悪いことではありませんが、ネットワーク管理者としては、それらが本当の問題に関係がないことを確認するために、発信元を知っておく必要があります。 トポロジ変更を発行したブリッジを識別することは、容易な作業ではありません。 しかし、複雑な技術は必要ありません。

ほとんどのブリッジでは、自ら発行した TCN または受信した TCN の数を数えるだけです。 Catalyst 4500/4000、5500/5000、および 6500/6000 では、最後に受信したトポロジ変更を送信したブリッジのポートと ID を表示する機能があります。 ルートからスタートして、発信元のブリッジに下りていきます。 詳細については、show spantree statistics コマンドを参照してください。

一部ツールについては、ゲスト登録の お客様にはアクセスできない場合がありますことを、ご了承ください。

結論

ここで考慮すべき重要な点は、TCN では STP 再計算は開始されないということです。 TCN は、通常、不安定な STP 環境に関連していますが、不安定な環境の結果であって原因ではありません。 TCN による影響があるのは、エージング タイムだけです。 これにより、トポロジが変更されたり、ループが発生することはありません。

トポロジ変更の数や発生率自体は問題ではありません。 トポロジ変更が何を意味するのかを知ることが重要です。 正常なネットワークでも、トポロジの変更が高い比率で発生する場合があります。 しかしトポロジ変更は、理論的にはサーバのアップまたはダウンや、リンクの遷移など、ネットワーク内の重要なイベントに関連しているはずです。 アップ/ダウンを繰り返すポートでは、通常の操作の一部として portfast を有効にすることで、これが達成できます。

NetPro ディスカッション フォーラム - 特集対話

関連情報