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

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

2015 年 11 月 26 日 - 機械翻訳について
その他のバージョン: PDFpdf | ライター翻訳版 (2010 年 3 月 10 日) | 英語版 (2015 年 10 月 7 日) | フィードバック


対話式: この文書では、個別のユーザに合わせたシスコ デバイスの分析を行います。


目次


概要

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 および B MAC アドレスのためのエントリまでの 5 分の間失われる、エージング・アウトする A. Communication に達したいと思うと適用します。

/image/gif/paws/12013/17b.gif

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

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

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

動作原理

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

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

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

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

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

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

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

ルート ブリッジへの通知

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

/image/gif/paws/12013/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 コマンドの出力がある場合、アウトプットインタープリタ登録ユーザ専用)を使用して、可能性のある問題と修正を表示できます。一部ツールについては、ゲスト登録のお客様にはアクセスできない場合がありますことをご了承ください。 Output Interpreter登録ユーザのみ)を使用するためには、登録ユーザとして登録しており、JavaScript を有効にしている必要があります。

結論

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

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

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

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


関連情報


Document ID: 12013