■ UpLinkFast

STPの話がまだつづいているわけだが。
ネット君、STPが有効になっている場合、再計算にはどれだけ時間がかかるのだったかね？

はい？ え～っと、blockからListeningに20秒、ListeningからLearningが15秒、LearningからFoward（Block）が15秒で、計50秒です。

そうだったな。で、だが50秒は長すぎるというのがSTPについてまわる宿命なのだよ。

宿命ですか。

うむ、宿命と書いて「さだめ」と読む。
まぁ、ともかくだ。さすがに50秒は長い。

確かにそうですが。PortFastなんか使うと早くなりますよね。

PortFastはあくまでそのスイッチ内でのワークステーションの接続のみだ。
他のスイッチとの接続にはどうしても時間がかかってしまう。

う～ん。

なので、コレを早くしようといくつかの技術が導入されている。そのうち２つを今回説明しよう。
まず、UpLinkFast。

あっぷりんくふぁすと？
アップなリンクが早い？

いや、アップリンクが早い、だな。
この技術は、アクセスレイヤスイッチで使用される。アクセスレイヤ、覚えているよな？

え～っと、なんでしたっけ？ 3層構造？

そうだ。アクセス、ディストリビューション、コアの3層構造だったな。
そのうち、エンドユーザと接続する層がアクセスレイヤだ。

で、そのアクセスレイヤのスイッチで使われるのが、UpLinkFastだ、と。

そういうことだな。理由はあとで説明する。
さて、UpLinkFastの動作だが、こうだ。

はい？速やかに？

速やかにだ。

…………。
これが許されるのなら、なんで普通のSTPには転送遅延タイマだの、最大タイマだのがあるんだって話になりません？

まぁ、確かにそう言われればそうかもしれんな。
なので、このUpLinkFastにはいくつかの前提条件が必要だ。

この場合、ブロックポートのうち最小のコストを持つものが即座にルートポートになる。
ただし、セルフループポートは除くが。

セルフループポートってなんです？

あぁ、こういうループになっているものだ。

つまり、自分で送信したBPDUを受け取ることにより、ブロッキングされるポートのことだな。

あぁ、なるほど。

UpLinkFastのポイントは2つ。まず、ルートポート以外の障害では機能しないというところ。

ふむふむ。

そして、基本的にSTPツリーのリーフ(葉)にあるアクセスレイヤのスイッチでしか機能しないところだ。

なぜです？

たとえば、以下のようなSTPツリーがあるとする。

先ほども言ったように、UpLinkFastは「ブロックポートを新たなルートポートとしてフォワーディング」だ。SW-AやSW-Bのようなディストリビューションレイヤのスイッチにブロックポートはあるか？

……ないですね。

SW-Cのようなアクセスレイヤのスイッチでなら意味があるが、SW-AやSW-Bのような位置ならば意味がない。だから、基本的にアクセスレイヤのスイッチで使うものなのだ。

でも、でもでもでもでも。
こうならば？ SW-Bでも意味ありますよね？

む、確かに意味があるな。まぁ、つまりだ。トポロジ状態を把握した上で使用するものなのだ、ということだよ。
なんでもかんでも闇雲にUpLinkFastで高速コンバージェンス、とかやっては駄目だ、ということだな。

う～ん。

つまり、ルートポートの代替となるブロックポートが存在するときに限り、UpLinkFastは有効なのだ。
そしてそれは、多くの場合アクセスレイヤスイッチはブロックポートを持つことが多い。だからアクセスレイヤで使用する、と。

う～ん。わかったようなわからないような。

あぁ、そうそう。１つ注意点を忘れていた。
UpLinkFastはVLAN単位には使用できない。VLANごとに状態が違うPVST+などではあまり有効ではないかもな。

■ CAMテーブルの問題

ネット君。STPのコンバージェンスの際、STPの計算とCAMテーブルの更新にはタイムラグがあって、それが問題になったな。

あ～、STPが50秒なのに、CAMテーブルのリフレッシュが5分ってところが問題だったんですよね。

今回説明した、UpLinkFastはさらにSTPの再計算速度を上昇させるものだ。
つまり、CAMテーブルとはますますズレが発生する。

そうですね。UpLinkFastは即座に再計算されますもんね。

さて、復習だ。通常のSTPではこのズレをどうしていた？

え～っと、ん～。再計算をしたブリッジは、「CAMテーブルのクリア」の要求を出すんでしたよね。

そうだ。要求を受け取った側は15秒にリフレッシュ期間を短縮させるのだが……。
ネット君。UpLinkFastはほんの数秒だぞ？ 15秒でも長くないか？ 無駄じゃないか？

だんだん博士の決め台詞と化してますね。「無駄じゃないか？」
確かにもったいないですよね。ほんの数秒で再計算が終わるUpLinkFastとしては。

だろう？
なので、こうする。

ダミーフレームによりCAMテーブルを更新させるというわけだ。

は～。ダミーフレームをマルチキャストすることにより、強制的にCAMテーブルを更新させる、というわけですか。

そういうことだ。確かにトラフィックは増えるが、この方法ならCAMテーブルがはやく正常化するので、ネットワークの停止時間が短くなるという利点がある。

はわ～。上手いこと考えてますねぇ。

■ BackboneFast

さて、ネット君。次の話をしよう。
ちょっと復習だ。これを見たまえ。

はぁ、STPの再計算ですよね。

うむ、ポイントはココだ。

「受け取ったBPDUがおかしいので」といっているが、正確に言うと、「受け取ったBPDUがおかしいのでそのBPDUは無視。結果、BPDUが届かないという扱いになり、最大タイマ経過後再計算」だ。

おかしいBPDUなので、無視して。そうするとBPDUが届いていないから再計算……。
つまり、最大タイマの20秒後に再計算ってことですね。

うむ。だがネット君、あきらかにおかしいBPDUが送られてきているのに、20秒も待つなんて、無駄じゃないか？

本日2発目ですね。
そのうち博士ったら、「無駄じゃないか」しか言わなくなっちゃったりして。

…。
想像力が豊かなのは結構だが、もうちょっと現実を見つめなおしたまえ。

はぅっ。

ともかくだ。ルートポートもしくは、ブロックされているポートにおかしいBPDUが届くということは、どこかで障害が発生した証拠なわけだ。
なので、できるだけ早く再計算にもっていきたい。

はい。

なので、ここでRLQ BPDUという特殊なBPDUを使う。

あーるえるきゅー？

そうだ。つまり、こう。

この方式をBackboneFastという。

ばっくぼーんふぁすと。

UpLinkFastと違い、直接接続していないリンクの障害を検出し、STP再計算を高速化する技術だ。

ははぁ。
そういえば、RLQ応答が返ってこない場合もあるんですよね？

うむ。こういう場合だな。

上の図だと、SW-CとSW-D。下の図だとSW-DはRLQ応答が返ってこない・送れないことになる。
こういう場合、ルートブリッジとの接続は失われたので、自身をルートブリッジとみなして再計算する。

は～。

ちょっとまとめよう。

さっきもいったが、直接接続していないリンクの障害を検出し、STP再計算を高速化するためにつかう、ということだな。

ばっくぼーんふぁすと。

そうだ。そのセグメントのルートブリッジへの接続（バックボーン）を高速に復旧させるからBackboneFastと呼ばれるわけだな。

なるほどです。

さて、今回はこれぐらいにしておこう。

はい。

今回で一応STPの話は終了だ。RSTPの話とかもあることはあるが、それはまたいずれだな。
次回からはまた別のことを話そう。

了解ッス。
30分間ネットワーキングでした～♪