スパニングツリー－スパニングツリー拡張機能－

今回はスパニングツリーの拡張機能についていくつか書いてみます。

PortFast

以下のようなスパニングツリーが動作しているネットワーク上で、スイッチにパソコンを繋げたとします。
すると、そのポートでスパニングツリーの計算が実行され、その計算が終了するまでポートはブロッキングの状態になってしまいます。

スパニングツリーは４段階の状態遷移を行い、最終的にForwarding状態に移行して初めて収束、すなわちデータの送受信が可能になります。

（最大エージタイマ：20秒）＋（転送遅延タイマ：15秒）＋（転送遅延タイマ：15秒）＝　50秒

つまり最大で50秒間、ポートのリンクがアップしないわけですね。
これって、使用者の側からみても非常に使いづらいですよねぇ。

そこで、この状態を回避するためにCiscoは考えましたよ。えぇ。

パソコンを接続するポートは、当然スパニングツリーを動作させる必要はありませんので、何も４段階の状態遷移を行う必要も無く、いきなりフォワーディング（データの送受信が可能な状態）にしちゃっても良いわけですね。
この機能をPortFastといいまして、スイッチなどのBPDUを発生させない機器（パソコンとか）しか繋げないポートに対して設定することによって、接続すると同時にフォワーディング状態にさせる機能です。

じゃあPortFastを設定したポートにスパニングツリーが動作するスイッチを接続してしまったらどうなるでしょう？
新しく接続したスイッチもスパニングツリーが動作していますので、BPDUを送信します。もし仮に、現在のルートブリッジよりも低いブリッジIDだったりした日には、トポロジが変更されてしまう危険性もあります。

この危険性を回避するために、PortFastにはBPDUガード機能といわれる機能があります。
BPDUガード機能とは、もしPortFastを設定したポートがBPDUを受信した場合、そのポートをブロッキング状態にしてしまうことによって、ネットワーク全体を守る機能です。
ただし、デフォルトでこの機能は無効になっていますので、明示的に有効にしないと動作しません。
コマンドは、

Switch(config)#spanning-tree portfast bpduguard

と設定すればOKです。
また、一度でもBPDUガード機能が動作してしまったポートは、手動で解除してあげない限りブロッキング状態を維持しますので注意しましょう。

Uplink Fast

以下のようにスパニングツリーが動作しているネットワーク上で、SWCのSWB向けのポートがブロッキング状態だったとします。

ここで、SWA～SWC間に障害が発生したとしましょう。
すると、スパニングツリーの再計算が発生し、LISTENING -> LEARNING -> FORWARDINGという状態遷移を辿りますので、最大で30秒の時間を要してしまいます。

でもこの構成をよく見てみてください。
SWA～SWC間が切れたら、SWA～SWB間を使うしかないわけで、それなら「30秒も待っていないでさっさと切り替わっちゃいなっ」てなもんですよ。

そこで、この状態を回避するためにCiscoは考えましたよ。えぇ。

んで、Uplink Fastが考えられました。

Uplink Fastは、SWCのようにコアスイッチ（エッジスイッチ）から上位のスイッチにプライマリ、セカンダリの２本のリンクで接続されている場合に使える機能で、LISTENING -> LEARNING -> FORWARDINGと遷移する時間をすっ飛ばし、一気にFORWARDING状態に移行することで、数秒レベルの通信断で切り替わることが可能な機能です。

当然SWA～SWC間のリンクが切れてセカンダリリンクに切り替わったことを、ほかのスイッチ（SWA,SWB）に知らせる必要がありますね。
そのためにSWCはCisco独自のマルチキャストパケットを送ることで上位スイッチに切り替わりが発生したことを知らせるわけです。

Backbone Fast

以下のようにスパニングツリーが動作しているネットワーク上で、SWCのSWB向けのポートがブロッキング状態だったとします。

ここで、SWA～SWB間に障害が発生したとしましょう。
すると、スパニングツリーの再計算が発生し、BLOCKING -> LISTENING -> LEARNING -> FORWARDINGという状態遷移を辿りますので、SWCのSWB向けポートがFORWARDINGになるまでに最大で50秒の時間を要してしまいます。