スパニング・ツリーを実際のネットワークで使っていると，不満を感じることが出てくる。例えば，経路の切り替えが発生すると一時的とはいえネットワークが使えなくなったり，ブロッキング・ポートを柔軟に設定できなかったりする。

　スパニング・ツリーには強化された改良版があり，多くのLANスイッチがこうした改良版スパニング・ツリーを搭載している。これらの新しい技術を使えば，より便利にスパニング・ツリーを使える。そこでPart3では，強化された最新のスパニング・ツリーを見てみよう。

切り替え時間を短くするRSTP

　スパニング・ツリーを使っていて最も気になるのが，経路が切り替わるための時間である。構成によっては，経路が完全に切り替わるまでに最大50秒間待たねばならない（図3-1）。

図3-1●スパニング・ツリーは経路の切り替えが遅い
図3-1●スパニング・ツリーは経路の切り替えが遅い
最大で50秒間待たないと経路が切り替わらない。

ネットワークが最大50秒も停止する

　スパニング・ツリーで経路の切り替えが遅いのは，経路切り替え時におけるLANスイッチの作業がタイマーによって決まっているからである。ネットワークの構成に変更があると，ツリー構成に変更があったと判断したLANスイッチは，タイマーに沿って順に切り替え作業を実行する。この切り替え作業をしている間，対象となるすべてのLANスイッチの通信が止まってしまう。

　具体的には，Part2の図2-6にあるように，ネットワークの構成に変更があったと判断するのに20秒（マックス・エージ）かかり，さらに構成の再計算に15秒（フォワード・ディレイ），その後MACアドレスの学習に15秒（フォワード・ディレイ）――と，経路を切り替えるまでにこうした決められた時間を経る必要がある。

　こうなると，実際のネットワークにおいてさまざまな不都合が出てくる。例えば，IP電話なら50秒間丸々音声が途切れてしまって，通話にならないだろう。また，そのときに起動したパソコンがあったとすると，DHCPサーバー＊1にアクセスできず，IPアドレスを取得できない状態に陥る可能性もある。

タイマーを使わずに高速切り替え

　こうしたスパニング・ツリーの経路切り替えを高速化するために作られたのが，ラピッド・スパニング・ツリー・プロトコル（RSTP＊2）である。

　RSTPが通常のスパニング・ツリーと大きく違うのは，経路の切り替えに関係するLANスイッチで情報を直接やりとりして，切り替え後のポートの状態を判断する点である。このとき，スパニング・ツリーで使われる各種タイマーは使わない。そのため，高速に切り替え作業が終了する。

　RSTPで切り替え情報をやりとりするときの例を，図3-2のネットワークで見てみよう。

図3-2●スパニング・ツリーを高速化したRSTP（rapid spanning tree protocol）
図3-2●スパニング・ツリーを高速化したRSTP（rapid spanning tree protocol）
スパニング・ツリーの改良版。あらかじめ代替ポートを決めておくことで切り替え時間を短縮。また，タイマーを使う従来の方法ではなく，BPDUに各種情報を入れてやりとりすることによって経路を切り替える。

　LANスイッチAとLANスイッチBの間のケーブルが切れたとする（同(1)）。するとLANスイッチBは「ルート・ブリッジへの道がなくなりました」とスイッチCに通知する（同(2)）。するとスイッチCはスイッチBにつながるブロッキング・ポートを有効にした方がいいと判断し，「それでは私のブロッキング・ポートを有効にしていいですか？」とLANスイッチBに提案する。この提案を受け取ったスイッチBは，「OKです」と同意のメッセージを返す（同(3)）。この返事を受け取ったLANスイッチCは，即座にブロッキング・ポートをフォワーディングに移行してデータの転送を開始するのである。

　以上のやりとりを実現するにあたってRSTPでは，BPDUの内容に改良を加えた。具体的には，BPDUの「フラグ」の部分に，提案（プロポーザル）や合意（アグリーメント）を示す情報や，自分の現在のポート状態などを示す情報を入れるフィールドを設けている。

切り替え候補のポートを決めておく

　さらに，あらかじめ切り替え候補になる代替ポートを決めておいて，次にどのポートを有効にすればいいかを瞬時に判断できるようにしている。

　具体的には，ルート・ポートと代表ポートの代替ポートをそれぞれ，「オルタネート・ポート」と「バックアップ・ポート」としてあらかじめ定義しておく。オルタネート・ポートは，優先順位が2番目に高いルート・ポートで，バックアップ・ポートは2番目の代表ポートである。例えば，ある経路がダウンしてルート・ブリッジに行く経路がなくなったことがわかったときは，2番目に優先順位が高いオルタネート・ポートを有効にすることを他のLANスイッチに提案するわけだ。

　これらは言ってみれば，経路に変更があった場合の動作を一足先に決めておくようなもの。オルタネート・ポートは，ルート・ポートがなくなった時点においてそのLANスイッチからルート・ブリッジに最も近いポートである。同様にバックアップ・ポートは，代表ポートが使えなくなった時点においてそのLANセグメントからルート・ブリッジに最も近いポートである。

　RSTPにおいて最適経路の選定に使う情報は，通常のスパニング・ツリーと同じブリッジIDやパス・コストである。そのためRSTPを使っても，切り替え後のネットワーク構成は，通常のスパニング・ツリーの場合とまったく同じになる。

切り替え時間を実験で測定

　では，RSTPを使うと実際どれくらい切り替え時間が速くなるのだろうか。実機を使って確認してみた。

　ネットワークの構成は，3台のLANスイッチ（LANスイッチA，LANスイッチB，LANスイッチC）をトライアングル状に接続し，さらにLANスイッチBにパソコン1をつなぎ，LANスイッチCにパソコン2をつないだ構成である（図3-3）。3台のLANスイッチではすべてRSTPを有効にした。ブロッキング・ポートは，LANスイッチCがLANスイッチBにつながるポート（Fa1/0/11）である。

図3-3●RSTPの経路切り替え時間を測ってみた
図3-3●RSTPの経路切り替え時間を測ってみた
通常のスパニング・ツリーだと切り替えに50秒かかる構成で実験した。RSTPを使ったときの経路の切り替え時間は1秒以内だった。
[画像のクリックで拡大表示]

　この状態で，パソコン1からパソコン2にping＊3パケットを1秒間隔で送り続ける。つまりパケットは，パソコン1→LANスイッチB→LANスイッチA→LANスイッチC→パソコン2と流れることになる。ここで，LANスイッチAとLANスイッチBをつないでいるケーブルを抜く。このとき，LANスイッチCのブロッキング・ポートがフォワーディングになって経路が切り替わり，通信が復旧するまでにどれだけの時間がかかるのかを調べてみた。

pingパケットのロスはほぼゼロに

　実験の結果，ダウン時間はわずか1秒程度だった。何回か実験してみたところ，pingの応答パケットが返って来なかったことを示す「Request timed out.」のメッセージが1個出てすぐに復旧するか，もしくは1個も出ずに通信し続けることができた。つまりRSTPによって，経路の切り替わりが1秒以内で実行されたわけだ。

　通常のスパニング・ツリーで同様の実験をすると，「Request timed out.」のメッセージは約50個出て，切り替えに50秒かかる。比べてみると，RSTPは通常のスパニング・ツリーに比べてはるかに高速なことがわかる。

　なお，RSTPを使う場合，パソコンをつなぐポートには「このポートはLANスイッチがつながっていないエッジ・ポートである」とあらかじめ明示的に設定する必要がある。というのも，RSTPが動作しているLANスイッチは，経路切り替え時にLANスイッチがいる可能性のあるポートすべてに切り替えの提案（プロポーザル）を送って応答を待つ。しかし，RSTP対応のLANスイッチが存在せず応答がないと，タイマーを使った通常のスパニング・ツリーの動作になってしまうのだ。

　例えば図3-3のケースでは，パソコン1がつながるLANスイッチBのポートと，パソコン2がつながるLANスイッチCのポートを「エッジ・ポート」として定義しておく。そうすることで，パソコンだけがつながるポートでRSTPのBPDUをやりとりしないようにする＊4わけだ。