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

Rapid Spanning Tree Protocol(802.1w)の概要

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

目次

概要
Catalyst スイッチにおける RSTP のサポート
新しいポート状態およびポートの役割
      ポートの状態
      ポートの役割
新しい BPDU のフォーマット
新しい BPDU の処理
      ハロータイムごとの BPDU の送信
      情報エージングの高速化
      不良 BPDU の受け入れ
Forwarding 状態への急速な遷移
      エッジ ポート
      リンク タイプ
      802.1D でのコンバージェンス
      802.1w でのコンバージェンス
      プロポーザル/アグリーメントのシーケンス
      UplinkFast
新しいトポロジ変更メカニズム
      トポロジ変更の検出
      トポロジ変更の伝搬
802.1D との互換性
結論
関連するシスコ サポート コミュニティ ディスカッション
関連情報

概要

802.1D Spanning-Tree Protocol(STP; スパニングツリー プロトコル)標準は、接続が切れた後 1 分ほどで接続を回復すれば、十分な性能を持つと思われた時代に設計されました。 LAN 環境でレイヤ 3 スイッチングが普及するとともに、現在、ブリッジングは、短時間で代替パスの提供が可能な Open Shortest Path First(OSPF)や Enhanced Interior Gateway Routing Protocol(EIGRP)のようなプロトコルによるルーテッド ソリューションと競合しています。

シスコは、オリジナルの 802.1D の仕様を、アップリンク ファーストバックボーン ファーストポート ファーストなどの機能で拡張して、ブリッジ ネットワークのコンバージェンス時間を高速化しました。 難点は、これらのメカニズムはシスコ独自の開発であり、設定の追加が必要になることです。

Rapid Spanning Tree Protocol(RSTP; IEEE 802.1w)は、画期的なものというよりも、802.1D 標準を発展進化させたものと言えます。 802.1D の用語はほとんど元のまま残っています。 パラメータはほとんど変化していないので、802.1D に慣れているユーザならすぐに新しいプロトコルを設定できるようになります。 大半のケースで、追加設定をしなくても、RSTP はシスコ社製の拡張機能よりすぐれたパフォーマンスを示します。 また、ポートごとにレガシー ブリッジと併用できるように、802.1w を 802.1D に戻すことも可能です。 ただし、新しく導入された利点は利用できなくなります。

802.1D 標準の新しい版である IEEE 802.1D-2004 は、IEEE 802.1t-2001 標準と IEEE 802.1w 標準を包含しています。.

このドキュメントでは、以前の 802.1D 標準から RSTP で強化された点に関して説明します。

Catalyst スイッチにおける RSTP のサポート

次の表に、Catalyst スイッチにおける RSTP のサポートと、サポートに必要な最低限のソフトウェアを示します。

Catalyst プラットフォーム RSTP を実装した MST RPVST+(別名 PVRST+)

Catalyst 2900 XL / 3500 XL

該当なし

該当なし

Catalyst 2940

12.1(20)EA2

12.1(20)EA2

Catalyst 2950/2955/3550

12.1(9)EA1

12.1(13)EA1

Catalyst 2970/3750

12.1(14)EA1

12.1(14)EA1

Catalyst 3560

12.1(19)EA1

12.1(19)EA1

Catalyst 3750 Metro

12.1(14)AX

12.1(14)AX

Catalyst 2948G-L3/4908G-L3

該当なし

該当なし

Catalyst 4000/2948G/2980G(CatOS)

7.1

7.5

Catalyst 4000/4500(IOS)

12.1(12c)EW

12.1(19)EW

Catalyst 5000/5500

該当なし

該当なし

Catalyst 6000/6500

7.1

7.5

Catalyst 6000/6500(IOS)

12.1(11b)EX、12.1(13)E、12.2(14)SX

12.1(13)E

Catalyst 8500

該当なし

該当なし


新しいポート状態およびポートの役割

802.1D には、次の 4 つのポートの状態が定義されています。

  • listening

  • learning

  • blocking

  • forwarding

詳細については、このドキュメントの「ポートの状態」のセクションを参照してください。

これは、トラフィックをブロックするか転送するかというポートの状態と、アクティブなトポロジでポートが果たす役割(ルート ポート、指定ポートなど)を区別していないため、やや混乱を招きます。 たとえば、動作の観点からは blocking 状態にあるポートと listening 状態にあるポートに違いはありません。 どちらもフレームを廃棄し、MAC アドレスを学習することはありません。 実際の違いは、スパニングツリーがポートに割り当てる役割にあるのです。 listening 状態にあるポートは、指定ポートかルート ポートのいずれかで、forwarding 状態への途上にあると推論してほぼ間違いありません。 残念ながら、いったん forwarding 状態になると、ポートの状態から、ポートがルートなのか指定なのか区別する方法はありません。これは、このような状態に基づいた用語自体に限界があることを示しています。 RSTP は、ポートの役割と状態を区別することでこの問題に対処しています。

ポートの状態

RSTP では、考えられる動作上の状態に合わせて、ポートの状態は 3 つだけになっています。 802.1D での disabled、blocking、listening の各状態は、802.1w 独自の discarding 状態に統合されています。

STP(802.1D)のポートの状態 RSTP(802.1w)のポートの状態 ポートはアクティブなトポロジに含まれるか ポートは MAC アドレスを学習するか

disabled

discarding

いいえ

いいえ

blocking

discarding

いいえ

いいえ

listening

discarding

はい

いいえ

learning

learning

はい

はい

forwarding

forwarding

はい

はい


ポートの役割

今回から役割は任意のポートに割り当てられる変数になりました。 ルート ポートおよび指定ポートの役割は変わりませんが、ブロッキング ポートの役割はバックアップと代替ポートの役割に分割されています。 Spanning-Tree Algorithm(STA; スパニングツリー アルゴリズム)が、Bridge Protocol Data Unit(BPDU; ブリッジ プロトコル データ ユニット)に基づいてポートの役割を決定します。 簡単に言うと、BPDU に関しては、任意の 2 つを比較して、どちらの方が有用かを決定する方法が常に存在することを覚えておいてください。 BPDU に保存された値、および BPDU を受け取るポートが基準になる場合もあります。 これを踏まえて、次のセクションでは、実用的なアプローチでポートの役割を説明しています。

ルート ポートの役割

  • ブリッジ上で最良の BPDU を受け取るポートがルート ポートになります。 つまり、パス コストの点からルート ブリッジに最も近いポートです。 STA は、ブリッジ ネットワーク全体から(VLAN ごとに)単一のルート ブリッジを選択します。 ルート ブリッジが送信する BPDU は、他のブリッジが送信するものより有用です。 ネットワーク中で、ルート ポートを持たないブリッジはルート ブリッジだけです。 他のブリッジはすべて、少なくとも 1 つのポートから BPDU を受信します。

146-b.gif

ルート ポートの役割

指定ポートの役割

  • 接続されたセグメントに最高の BPDU を送信できるポートは、指定ポートになります。 802.1D のブリッジでは、別々のセグメント(イーサネット セグメントなど)をリンクすることで、ブリッジ ドメインが作成されます。 いずれのセグメント上でも、ルート ブリッジに向かうパスは 1 つしか置けません。 2 つある場合は、ネットワークにブリッジ ループができています。 任意のセグメントに接続しているブリッジはすべて相互に BPDU をリスニングし、最良の BPDU を送信しているブリッジをそのセグメントの指定ブリッジとして認識します。 そのブリッジ上にある対応するポートが指定ポートです。

146-c.gif

指定ポートの役割

代替ポートとバックアップ ポートの役割

  • この 2 つのポートの役割は、802.1D の blocking 状態に対応します。 ブロッキング ポートとは、指定ポートでもルート ポートでもないと定義されます。 ブロッキング ポートは、セグメント上で、そのポートから送信される BPDU よりも有用な BPDU を受信しています。 ポートがブロックされた状態を維持するには、BPDU の受信が必須であることに注意してください。 RSTP は、それを目的としてこの 2 つの役割を導入しました。

  • 代替ポートとは、他のブリッジよりも有用な BPDU を受信していて、さらに、ブロックされているポートです。 次の図に例を示します。

146-d.gif

代替ポートの役割

  • バックアップ ポートとは、自ブリッジからさらに有用度の高い BPDU を受信していて、さらに、ブロックされているポートです。 次の図に例を示します。

146-e.gif

バックアップ ポートの役割

802.1D では内部的にすでにこの区別はされていました。 基本的に、それがシスコの UplinkFast 機能の仕組みです。 代替ポートはルート ブリッジに代替パスを提供することにより、ルート ポートに障害が発生した場合、代替できるという論理です。 バックアップ ポートは同じセグメントに冗長接続を提供するので、ルート ブリッジへの代替接続は保証できません。 そのため、アップリンク グループからは除外されています。

その結果、RSTP は、802.1D と同じ基準でスパニングツリーの最終トポロジを計算します。 別なブリッジやポートの優先順位が使用される方法にはいっさい変更がありません。 シスコのインプリメンテーションでは、discarding 状態を表すために blocking という名称を使用しています。 CatOS リリース 7.1 以降では、listening 状態と learning 状態が引き続き表示されます。 そのため、ポートに関して、IEEE 標準で義務付けられている以上の情報が得られるようになっています。 しかし、新しい機能では、プロトコルがポートに割り当てた役割と現在の状態は別なものになっています。 たとえば、ポートが指定ポートでありながら、同時に blocking 状態になることが今では完全に有効です。 通常このようなことが起きるのはごく短時間の間で、このポートが指定 forwarding 状態に移行段階にあることを意味していることになります。

新しい BPDU のフォーマット

RSTP により BPDU フォーマットにいくつかの変更が行われました。 802.1D では、Topology Change(TC; トポロジの変化)および TC Acknowledgement(TCA; TC 承認)という 2 つのフラグだけが定義されていましたが、RSTP ではフラグ バイトの残りの 6 ビットすべてを使用して次のことを行っています。

  • BPDU 発信ポートの役割と状態のエンコード

  • プロポーザルおよびアグリーメント メカニズムの処理

146-f.gif

新しい BPDU のフォーマット

もう一つの重要な変更は、RSTP BPDU が現在タイプ 2、バージョン 2 になっていることです。 つまり、レガシー ブリッジではこの新しい BPDU は必ず破棄されることになります。 この特性によって、802.1w ブリッジは、接続されたレガシー ブリッジを容易に検出できます。

新しい BPDU の処理

ハロータイムごとの BPDU の送信

BPDU は(単にリレーされるのではなく)ハロータイムごとに送信されます。 802.1D では、ルート ポート上で BPDU を受信すると、ノンルート ブリッジでは BPDU の作成だけが行われます。 実際には、ブリッジでは、BPDU を生成しているというよりも、リレーしていることになります。 802.1w では、これは当てはまりません。 ブリッジは、ルート ブリッジから BPDU を受信しなくても、<ハロータイム>にかかる秒数ごとに(デフォルトでは 2 秒)現在の情報が入っている BPDU を送信します。

情報エージングの高速化

どのポートでも、ハロー メッセージが 3 回続けて受信されないと(または、max_age が時間切れになった場合)、プロトコル情報はただちに期限切れとなります。 前述のプロトコル変更により、BPDU はブリッジ間でキープアライブ メカニズムとして使用されます。 ブリッジは、3 回連続で BPDU を受信ミスすると、直接隣接しているルートまたは指定ブリッジへの接続が失われたものとみなします。 このように情報が急速にエージングすることで、障害が速やかに検出されます。 ブリッジが隣接ブリッジから BPDU を受信しなかった場合、その場所との接続が失われているのは確かです。この点が、ルートへのパスのどこで問題が起きたか分からない 802.1D とは異なります。

注:物理的なリンク障害の場合はさらに迅速に障害が検出されます。

不良 BPDU の受け入れ

この概念は、BackboneFast エンジンの中核を形成するものです。 IEEE 802.1w 委員会は、RSTP に同様のメカニズムを取り入れることを決定しました。 ブリッジが、指定ブリッジやルートブリッジから不良情報を受信すると、ただちに受け入れ、それ以前に記憶した情報と入れ替えます。

146-g.gif

不良 BPDU の受け入れ

ブリッジ C は、ルートが問題なく動作していることがわかっているので、ただちにブリッジ B にルート ブリッジに関する情報を収めた BPDU を送信します。 その結果、ブリッジ B は自身の BPDU を送信せず、ブリッジ C につながるポートを新しいルート ポートとして受け入れます。

Forwarding 状態への急速な遷移

802.1w が導入した最も重要な機能は急速な遷移です。 レガシー STA では、ネットワークのコンバージェンスを何もせずに待ってから、ポートを forwarding 状態にしていました。 コンバージェンスを速めるには、控えめに設定されたデフォルトのパラメータ(転送遅延および max_age タイマー)をチューニングするしかなく、ネットワークの安定性が脅かされる場合もありました。 新しい高速 STP では、ポートが forwarding 状態に安全に遷移できることをアクティブに確認でき、タイマーの設定にはまったく依存していません。 これは、RSTP 準拠ブリッジ間で作用する実際のフィードバック メカニズムです。 ポート上でファースト コンバージェンスを実現するために、プロトコルではエッジ ポートとリンク タイプという 2 つの新しい変数を利用します。

エッジ ポート

エッジ ポートのコンセプトは、基本的にポート ファースト機能に対応しているので、シスコのスパニングツリー ユーザにはすでにおなじみです。 直接エンド ステーションと接続しているすべてのポートで、ネットワーク内にブリッジング ループが形成される可能性はありません。 そのため、エッジ ポートは listening 状態と learning 状態を飛ばして、直接 forwarding 状態に遷移します。 エッジ ポートでも、PortFast 対応のポートでも、リンクが切り替わった際にトポロジの変更は生成されません。 PortFast と異なり、BPDU を受信したエッジ ポートは、ただちにエッジ ポートの状態ではなくなり、通常のスパニングツリー ポートになります。 この時点では、ユーザ設定の値とエッジ ポート状態の動作値が存在しています。 シスコの実装では、エッジ ポートの設定で、PortFast のキーワードが使用できる状態は維持されており、RSTP への移行が容易になっています。

リンク タイプ

RSTP が、forwarding 状態への迅速な遷移を実現できるのは、エッジ ポート上かポイントツーポイント リンク上に限られます。 リンク タイプはポートのデュプレックス モードから自動的に導出されます。 デフォルトでは、全二重で動作しているポートはポイントツーポイントと見なされ、半二重のポートは共有ポートと見なされます。 明示的に設定すると、この自動リンク タイプ設定を無効にできます。 今日のスイッチド ネットワークでは、ほぼすべてのリンクは全二重モードで動作しているため、RSTP ではポイントツーポイントとして扱われます。 そのため、forwarding 状態へ急速に遷移する可能性が高くなっています。

802.1D でのコンバージェンス

次の図は、ブリッジ型ネットワークに追加された新しいリンクを 802.1D が処理する方法を示しています。

146-h.gif

802.1D でのコンバージェンス

この例では、ルート ブリッジとブリッジ A 間のリンクが追加されています。 ブリッジ A とルート ブリッジの間には、すでに間接的な接続(図中の C-D 経由)があると仮定します。 STA は、ポートをブロックしてブリッジング ループを無効にします。 まず、発生と同時に、ルートとブリッジ A の間のリンク上にあるポートは両方が listening 状態になります。 ブリッジ A は直接ルートから受信できるようになり、ただちに指定ポート上でツリーのリーフに向けて BPDU を伝搬します。 ブリッジ B および C は、A からこの新しい上位情報を受信すると、リーフに向けてリレーします。 ほんの数秒で、ブリッジ D がルートから BPDU を受信して、即座にポート P1 をブロックします。

146-i.gif

新しいトポロジを効率よく算定できるが、転送遅延の 2 倍の時間がかかる

スパニングツリーでは、非常に効率よくネットワークの新しいトポロジを算定できます。 唯一の問題は、ルートとブリッジ A の間のリンクが forwarding 状態になるまでに、転送遅延の 2 倍の時間がかかることです。 つまり、8021.D のアルゴリズムにはネットワークでのファースト コンバージェンスを秒単位で明確にアドバタイズするフィードバック メカニズムがないため、トラフィックが 30 秒間途絶えてしまう(ネットワークの A、B、C の全体が孤立する)ことになります。

802.1w でのコンバージェンス

今度は、RSTP が同様の状況をどう処理するかを見て行きます。 最終的なトポロジは、802.1D が算定するものとまったく同じであることに注意してください。(つまり、以前と同一の場所にブロックされたポートが 1 つあります)。 このトポロジに到達するステップが変化しただけです。

ブリッジ A とルート間にあるリンク上のポートは、発生後ただちに指定ブロッキングに置かれます。 ここまでは、すべての動作が純粋な 802.1D 環境と同じです。 しかし、この段階では、スイッチ A とルート間でネゴシエーションが行われます。 A がルートの BPDU を受信すると、即座に、非エッジ指定ポートをブロックします。 この操作は同期と呼びます。 この操作終了後、ブリッジ A はルート ブリッジがポートを forwarding 状態にするよう、明示的に権限を与えます。 下の図は、ネットワーク上でこのプロセスがどのような結果になるかを示しています。 スイッチ A とルート ブリッジ間のリンクはブロックされ、両方のブリッジが BPDU を交換します。

146-j.gif

802.1w でのコンバージェンス

スイッチ A が非エッジ指定ポートをブロックしてしまうと、スイッチ A とルート間のリンクは forwarding 状態になり、次のような状況になります。

146-k.gif

スイッチ A の下をブロック

まだループの発生はありません。 ネットワークが、スイッチ A のをブロックする代わりに、スイッチ A の下をブロックしています。ただし、発生する可能性のあるブリッジ ループは別の場所で切断されています。 スイッチ A へのルートで生成された新しい BPDU とともに、この切断箇所はツリーを下っていきます。 この段階で、スイッチ A 上で新しくブロックされたポートも、同期操作を開始するスイッチ B およびスイッチ C 上の両方の近隣ポートとの、forwarding 状態への急速な遷移のネゴシエーションを行います。 A に対するルート ポート以外には、スイッチ B にはエッジ指定ポートしかありません。 そのため、スイッチ A に forwarding 状態に移行する権限を与えるためにブロックできるポートがありません。 同様に、D に対する指定ポートをブロックする必要があるのはスイッチ C だけです。 この時点で、次の図に示す状態になります。

146-l.gif

最終的なトポロジは同じだが、転送遅延の 2 倍の時間がかかる listening と learning のステージが回避される

最終的なトポロジは、802.1D の例とまったく同じであり、D 上のポート P1 は、最後にはブロッキング状態になることに注意してください。 つまり、新しい BPDU がツリー内を移動するのに必要なだけの時間で、最終的なネットワーク トポロジに到達したということになります。 この迅速なコンバージェンスにはタイマーはまったく関与していません。 RSTP によって導入された唯一の新しいメカニズムは、forwarding 状態への即時の遷移の権限を与えるために、スイッチが新しいルート ポート上で送信できる確認応答だけです。これにより、転送遅延の 2 倍の時間がかかる listening および learning のステージが回避されています。 ファースト コンバージェンスの利点を活用するには、管理者は次の点にだけ留意が必要です。

  • ブリッジ間のネゴシエーションは、ポイントツーポイント リンクで接続したブリッジ間だけで可能です(つまり、明示的なポート設定でなければ全二重リンク)。

  • 802.1D のポート上で、PortFast が有効にされているので、エッジ ポートの役割がさらに重要になっています。 ネットワーク管理者が B 上のエッジ ポートを正しく設定していない場合、A とルート間にリンクが発生することで接続に影響が出ます。

プロポーザル/アグリーメントのシーケンス

STA がポートを選択し、指定ポートとなる場合、802.1D では依然として <転送遅延> にかかる秒数の 2 倍(デフォルトでは 2×15 秒)が経過してから、forwarding 状態に遷移します。 RSTP では、この状態は、blocking 状態を除いた指定の役割を持つポートに対応します。 次の図は、迅速な遷移がどのように実現されるかを順を追って説明したものです。 ルートとスイッチ A との間に新しいリンクが作成されていると仮定しています。 このリンク上のポートはどちらも、相手から BPDU を受信するまで指定 blocking 状態にあります。

146-m.gif

迅速な遷移がどのように実現されるか:ステップ 1 〜ステップ 3

指定ポートが discarding または learning 状態にある場合(そしてこの場合だけ)、送信する BPDU 上にプロポーザル ビットを設定します。 前の図のステップ 1 で示されているように、ルート ブリッジのポート p0 はこのような状態になっています。 スイッチ A は上位情報を受信しますから、p1 が新しいルート ポートであることはすぐに分かります。 するとスイッチ A は同期を開始して、スイッチ A 上のポートすべてがこの新しい情報と同期が取れていることを確認します。 次の基準のいずれかが当てはまれば、ポートは同期が取れています。

  • blocking 状態にあること(つまり、安定したトポロジでは、discarding 状態)。

  • エッジ ポートであること。

別種のポート上での同期メカニズムの効果を明らかにするため、スイッチ A 上に、代替ポート p2、指定転送ポート p3、エッジ ポート p4 が存在すると仮定します。 p2 と p4 は、すでに基準の 1 つを満たしていることに注意してください。 同期が取れた状態(前の図のステップ 2)になるには、スイッチ A はポート p3 をブロックして、discarding 状態を割り当てる必要があります。 この時点ですべてのポートの同期が取れたので、スイッチ A は、新しく選択したルート ポート p1 のブロックを解除し、アグリーメント メッセージを送信してルートに応答します。 (ステップ 3 を参照。) このメッセージは、プロポーザル BPDU のコピーで、プロポーザル ビットの代わりにアグリーメント ビットが設定されています。 これにより、ポート p0 は、受信したアグリーメントが、どのプロポーザルに対応するものか、確実に判別できます。

146-n.gif

迅速な遷移がどのように実現されるか:ステップ 4

p0 がこのアグリーメントを受信したら、ただちに forwarding 状態に遷移できます。 これが、前の図のステップ 4 です。 ポート p3 は、同期後も指定 discarding 状態のままであることに注意してください。 ステップ 4 では、このポートは、ステップ 1 の間のポート p0 とまったく同じ状況です。 その後で、隣接ポートへのプロポーザルを開始して、forwarding 状態に迅速に遷移しようとします。

  • プロポーザル アグリーメント メカニズムは、タイマーにまったく依存しないため、非常に高速です。 このハンドシェイクの波は即座にネットワーク末端にまで伝搬し、トポロジの変更後すぐに接続を回復します。

  • 指定 discarding ポートがプロポーザルを送信してもアグリーメントを受信しない場合、徐々に forwarding 状態へと遷移し、従来の 802.1D listening-learning シーケンスへと戻っていきます。 リモート ブリッジで RSTP BPDU が認識されない場合や、リモート ブリッジのポートがブロッキング状態にある場合に、このような状態が発生します。

  • シスコは、同期を取る際に、ブリッジが以前のルート ポートしか discarding 状態にできないように同期メカニズムを強化しました。 このメカニズムの仕組みを詳述するのは、このドキュメントの範囲ではありません。 しかし、ごく普通の再コンバージェンスのケースでは、ほとんどの場合この機能が呼び出されると考えて間違いありません。 最後にブロックされたポートへのパス上にあるポートだけが一時的に混乱するだけなので、このドキュメントの「802.1w でのコンバージェンス」のセクションで説明した例が非常に有効です。

146-o.gif

有効な例

UplinkFast

RSTP に含まれている、即座に forwarding 状態へ遷移するための別な形式は、シスコ独自の UplinkFast スパニングツリー拡張機能と同じです。 基本的に、ブリッジがルート ポートを失う場合、最良の代替ポートを直接 forwarding モードにすることが可能です(新しいルート ポートの出現も RSTP が処理します)。 代替ポートを新しいルート ポートに選択すると、トポロジの変更が生じます。 802.1w のトポロジ変更メカニズムによって、アップストリームのブリッジにある Content Addressable Memory(CAM)テーブル中の該当するエントリがクリアされます。 この処理により、UplinkFast のダミー マルチキャスト生成プロセスは不要になっています。

このメカニズムは RSTP に元々含まれていて自動的に有効になるので、UplinkFast をそれ以上設定する必要はありません。

新しいトポロジ変更メカニズム

802.1D のブリッジがトポロジ変更を検出すると、信頼できるメカニズムを使用して、まずルート ブリッジに通知します。 次の図に例を示します。

146-p.gif

新しいトポロジ変更メカニズムの例
※ 画像をクリックすると、大きく表示されます。

ルート ブリッジがネットワークのトポロジ変更を認識すると、送信する BPDU 上に TC フラグを設定し、ネットワーク中の全ブリッジにリレーします。 TC フラグ ビットが設定された BPDU をブリッジが受信すると、ブリッジングテーブルのエージング タイムが転送遅延の秒数に減らされます。 この処置により、古くなった情報が比較的迅速に、確実にフラッシュされるようになります。 このプロセスの詳細については、『スパニングツリー プロトコル トポロジの変更』を参照してください。 このトポロジ変更メカニズムは、RSTP では大幅に改造されています。 トポロジ変更の検出も、ネットワークを介した伝搬も、ともに進化しています。

トポロジ変更の検出

RSTP では、トポロジ変更が発生するのは、非エッジ ポートの forwarding 状態への移行だけです。 RSTP では、802.1D とは異なり、接続を失うことはもはやトポロジ変更とはみなされないということです(つまり、ブロッキング状態に移行するポートでは TC を生成しないようになっています)。 RSTP ブリッジでトポロジ変更が検出されると、次のようになります。

  • 必要に応じて、すべての非エッジ指定ポートおよびルート ポートに対してハロータイムの 2 倍に等しい値で TC While タイマーが開始されます。

  • これらのポートすべてに関連した MAC アドレスをフラッシュします。

注:TC While タイマーがポート上で作動している間は、そのポートから送信される BPDU には TC ビットが設定されています。 BPDU は、タイマーがアクティブな間、ルート ポート上でも送信されます。

トポロジ変更の伝搬

ブリッジが近隣から TC ビットが設定された BPDU を受信すると、次のようになります。

  • トポロジ変更を受信したポートを除き、すべてのポート上で学習した MAC アドレスがクリアされます。

  • TC While タイマーを開始し、すべての指定ポートおよびルート ポート上で TC を設定した BPDU を送信します(レガシー ブリッジに通知が必要な場合を除き、RSTP はもう特定の TCN BPDU を使用しません)。

このようにして、TCN は即座にネットワーク全体でフラッディングされます。 TC 伝搬はこれでワン ステップのプロセスになりました。 実際には、ルートだけがフラッディングを起こしていた 802.1D とは異なり、トポロジ変更を起こした場所が、ネットワーク全体にこの情報をフラッディングしています。 このメカニズムは、802.1D の同等機能よりもはるかに高速です。 ルート ブリッジが通知を受けて、ネットワーク全体がトポロジ変更状態を <max_age + 転送遅延> の秒数の間待つ必要がありません。

146-q.gif

TCN は即座にネットワーク全体でフラッディングされる

わずか数秒(ハロータイムの数倍の時間)で、ネットワーク(VLAN)全体で CAM テーブルのエントリはほとんどフラッシュされます。 このアプローチでは、一時的にフラッディングが増える可能性がありますが、一方では速やかな接続回復を妨げる陳腐化する可能性のある情報をクリアします。

802.1D との互換性

RSTP は、レガシー STP プロトコルと相互運用が可能です。 しかし、レガシー ブリッジと双方向で通信すると、802.1w に備わるファースト コンバージェンスの利点が失われることに注意することは大切です。

各ポートは、対応するセグメント上でプロトコルが動作するよう定義した変数を維持しています。 ポートがアップ状態になると、3 秒の移行遅延タイマーも開始します。 このタイマーが作動している間、ポートと関連した現在の STP または RSTP モードはロックされます。 移行遅延の時間が終了すると、ポートは次に受信する BPDU に対応するモードに適応します。 ポートが BPDU を受信した結果、動作モードを変更する場合は、移行遅延が再起動されます。 この動作により、モード変更の頻度が制限されます。

146-r.gif

ブリッジ A および B とレガシー STP ブリッジ C の例

たとえば、前の図のブリッジ A および B が両方とも RSTP を実行していて、スイッチ A がセグメントに指定されていると仮定します。 レガシー STP ブリッジ C がこのリンクに導入されます。 802.1D ブリッジは RSTP BPDU を無視して破棄するので、C はセグメント上に他にブリッジはないと見なして、不良 802.1D フォーマットの BPDU を送信し始めます。 スイッチ A はこれらの BPDU を受信し、最大ハロータイムの 2 倍が経過した後、該当ポート上でだけモードを 802.1D に変更します。 その結果、C はスイッチ A の BPDU を理解できるようになり、セグメントの指定ブリッジとして A を受け入れます。

146-s.gif

ブリッジ C が削除されるとユーザの操作が必要になる

この特定のケースでは、ブリッジ C が削除されると、ブリッジ A は、唯一の隣接ブリッジ B とさらに効率の高い RSTP で動作可能であるにもかかわらず、そのポート上で STP モードを実行します。 これは、セグメントからブリッジ C が削除されたことを A が認識していないからです。 この特定の(まれな)ケースでは、ポートのプロトコル検出を手動で再開するために、ユーザの操作が必要になります。

ポートが 802.1D 互換モードの場合は、Topology Change Notification(TCN; トポロジ変更通知)BPDU、および TC または TCA ビットが設定された BPDU も処理できます。

結論

RSTP(IEEE 802.1w)は、シスコが独自に 802.1D スパニングツリーに加えた、BackboneFast、UplinkFast、PortFast などの強化機能のほとんどをデフォルトで備えています。 RSTP は、適切に設定されたネットワークなら、ときには数百ミリ秒の精度で、はるかに高速なコンバージェンスを実現します。 転送遅延や max_age など 802.1D の定番タイマーは、バックアップとして使用するだけで、ポイントツーポイント リンクおよびエッジ ポートを管理者が適切に識別して設定している場合は必要ありません。 また、レガシー ブリッジとのやり取りがない場合にもタイマーは必要ありません。


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

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


関連情報