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

スパニングツリー プロトコル トポロジの変更

2010 年 3 月 10 日 - ライター翻訳版
その他のバージョン: PDFpdf | 機械翻訳版 (2013 年 8 月 21 日) | 英語版 (2005 年 10 月 10 日) | フィードバック

対話式:このドキュメントでは、ご使用中の Cisco デバイスに応じた解析を行います。


目次

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


概要

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

  • per-VLAN spanning tree(PVST)環境と PVST+ 環境でのメカニズムの変更。

  • トポロジ変更イベントをトリガーする原因の特定。

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



前提条件

要件

このドキュメントに関する特別な要件はありません。



使用するコンポーネント

このドキュメントは、特定のソフトウェアやハードウェアに限定されるものではありません。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。対象のネットワークが実稼働中である場合には、どのような作業についても、その潜在的な影響について確実に理解しておく必要があります。



表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。



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

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

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

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

17a.gif

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

17b.gif

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

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

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



動作の原理

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

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

  • 転送していたポートが使用不能になった場合(ブロッキングなど)。

  • ポートが転送に移行して、ブリッジに指定ポートがある場合(これは、ブリッジがスタンドアロンではないことを意味します)。

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

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

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



ルート ブリッジへの通知

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

17c.gif

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



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

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

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

17d.gif



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

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

Cisco デバイスからの show-tech support コマンドの出力がある場合、アウトプットインタープリタ登録ユーザ専用)を使用して、可能性のある問題と修正を表示できます。一部ツールについては、ゲスト登録のお客様にはアクセスできない場合がありますことをご了承ください。アウトプットインタープリタ登録ユーザ専用)を使用するためには、登録ユーザであり、ログインしていて、さらに JavaScript を有効にしている必要があります。一部ツールについては、ゲスト登録のお客様にはアクセスできない場合がありますことをご了承ください。



トラフィックのフラッド

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

17e.gif

バックアップを受信するデバイスのエントリのエージング アウトは厄介です。すべてのユーザに悪影響を与えるような非常に重いトラフィックを引き起こすからです。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 コマンドを参照してください。

Cisco デバイスからの show spantree statistics コマンドの出力がある場合、アウトプットインタープリタ登録ユーザ専用)を使用して、可能性のある問題と修正を表示できます。一部ツールについては、ゲスト登録のお客様にはアクセスできない場合がありますことをご了承ください。アウトプットインタープリタ登録ユーザ専用)を使用するためには、登録ユーザであり、ログインしていて、さらに JavaScript を有効にしている必要があります。一部ツールについては、ゲスト登録のお客様にはアクセスできない場合がありますことをご了承ください。



結論

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

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



関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


関連情報




Document ID: 12013