■ STPタイマー

さて、ネット君。
ルートブリッジの決定と、それにともなうポートの決定はわかったかな？

ブリッジIDと、ルートポート、指定ポート、ですよね？

うむ、そうだ。STPは、ルートポート、指定ポートをフォワーディング。その他のポートをブロッキングにすることにより、ループのない論理接続構成を作成する。

でした。

さて、わざわざSTPなんてもの持ち出した理由は、冗長構成をとりながら、ループのないループフリー環境を作り出すため、だったよな？

ですよね。
どっかのリンクやブリッジがダメになっても、代替パスがあって大丈夫、でもループはダメだよ、という形にしたいからですよね。

そうだ。なので、障害時にどのような動作をするか、ということを説明しよう。
まず、覚えて欲しいのは、STPで使われるタイマーだ。以下はすべてデフォルト値だ。

？
これ、なんの秒数ですか？

それは今から説明する。まず、スイッチダイアメータは本当はタイマーと違うが、ここでまとめて説明させてもらう。
スイッチダイアメータはスパニングツリーの範囲を示す値だ。

範囲？

そうだ。IEEEが定めるSTPの最大経由スイッチ数だ。任意のスイッチから、任意のスイッチまで、元と宛を含めて7つまでのスイッチの範囲で収まること。

ん〜っと。つまり、数え始めのスイッチを抜いて、6つまでってことですか？
ルータ風に言うと、6ホップまで？

うむ、そういうことだ。

ルートの位置は関係ない？

うむ。ルートブリッジが決定される前も考える必要があるからな。
そして、このダイアメータの値により、他のタイマーを変更するとより効果的なSTPになる。 ▼ link

ははぁ。

次は、最大タイマ。
最大タイマの時間BPDUが届かなければそのリンクはダウンしたと判断する。

障害の検出時間ですね。20秒ってことは、Hello10回？ ずいぶん長いんですね。

まぁ、確かにそうかもな。
最後の転送遅延。これはポートの遷移のところで話そう。ともかく、3つのタイマは必ず覚えておくこと。

Helloタイマ、最大タイマ、転送遅延の3つですね。

■ 障害の検出

さて、STPではそれぞれのスイッチの各ポートはBPDUをHelloタイマ間隔で送信している。

2秒に1回ですね。

うむ。そして、直接接続の障害以外最大タイマの時間BPDUを受け取らなかったら障害が発生した、と考える。

直接接続はいいんですか？

直接接続の場合、障害があったことはすぐわかるからな。

さて、セグメント5の指定ポートであったスイッチCのポートで障害が発生してしまったわけだ。
こうなると、セグメント5に対しフレームが届かなくなってしまう。さてどうする？

どうするって？ こういう時のための冗長構成ですよね。
スイッチDのブロックになってるポートをフォワード（指定ポート）にして、セグメント5に届けるようにします。

確かにそうだ。それにより、セグメント5にフレームが届くようになる。
だが。

だが？
なんか間違ってました？

ネット君が間違うのはよくあることだが、今回はちゃんとあっているぞ。その通り、フォワーディングになる。
だが、ここで問題になるのは、そんなにすぐフォワーディングにしてもいいのか、もし21秒後にスイッチCのポートが復旧したらどうなる、という問題だ。

21秒後に？ そりゃまたずいぶんきまぐれなポートですね。
え〜っと、その場合はスイッチDのポートがまたブロックになるんじゃないかな？

結果的には確かにブロッキングになる。だが、スイッチBのポートが復旧したことに気づくまで、ネットワークでループが発生することになってしまう。

う、う〜ん。確かにそうなってしまいますね。

この例は簡単な形にしてあるので、ループが発生する時間が短いが、トポロジによっては長時間ループが発生する可能性もある。
さて、どうすればいい？

どうすればいいと言われましても。

スイッチがネットワークの正確なトポロジを知るまでの間、時間を稼げばいい。
そうすれば、ループを防ぐことができる。ルーティングループを防ぐのにも似たような方式があったな？

･･････ホールドダウンタイム？

そうだ。それが転送遅延タイマだ。

■ ポート遷移

前回、ポートの状態というのを説明したな。

コレですよね。停止と移行中と転送と無効。
ブロックとフォワーディング、ディゼーブルはわかりますけど、リスニングとラーニングってなんです？ 移行中って？

うむ。先ほどの話がそれには関係ある。
つまり、ネットワークの正確なトポロジを知るまでの間、時間を稼ぐための状態がリスニングとラーニングだ。

ははぁ。トポロジの状態把握中って感じですか？

そうだな。リスニング、ラーニング中はトポロジ状態を把握してる最中だから、ループの危険性があるため、データ転送を行わない。

っていうと、さっきの5つの状態のうち、データを転送するのはフォワーディングだけですか。

うむ。

へぇ。で、リスニングとラーニングってどう違うんですか？

それは後で説明するとして。では、STPでどのようにホールドダウンタイムを稼ぐか説明しよう。
まず、障害を検出したり、新たなBPDUを受け取ったりしてSTPの再計算が必要な状態になったとする。

障害を検出した場合、STPの再計算が必要なのはわかりますけど。
新たなBPDUを受け取った場合？

そうだ。新しくスイッチが追加されたり、いままでダウンしていたスイッチ・リンクが復旧したりすると、いままで受け取っていなかったBPDUが届くことになる。その場合、あらたなツリーが必要なるだろ？

そうですね。確かに。

まぁ、つまり障害・障害復旧・追加・削除などによりトポロジに変更が合った場合、STPの再計算が必要、ということだな。
STPの再計算が必要になったスイッチは、すべてのポートをブロックにする。

全部ですか？ 新しくBPDUを受け取ったとか、受け取らなかったポートだけじゃなくて？

全部ブロックだ。トポロジがどういう状態かわからないのに、フォワーディング状態のポートを残しておくとループが発生する可能性があるからな。

なるほど。

その後は…、図にしよう。

ブロックから、リスニング、ラーニング、で。
フォワーディングか、ブロックに戻る？

そうなる。もしそのポートが新しいSTPの結果によりルートポートか指定ポートになるなら、そのポートはフォワーディングに遷移。そうでなければブロックに遷移、ということだな。

あ、なるほど。

つまり、ブロックからフォワーディング状態に移るまで、つまりコンバージェンスに達するまで50秒の時間がかかる、ということだ。

20 + 15 + 15で50秒ッスね。
結構長いんですね。

そうだな。50秒というのはかなりの時間だ。これを短縮する技術の話はまた先の回で話すとして。
リスニングとラーニングの違いを話しておかなければな。

んん？ CAMテーブルに記憶するかしないか？

そうだ。基本的にSTPの計算、というかループを防ぐための時間はリスニング中に終了していると思っていい。ラーニングはその後の転送のためMACアドレスを覚えるための時間だ。

ははぁ。そういうもんなんですか。

そういうものだ。
あぁ、そうそう。ポートの移行中でデータ転送中止といってるが、BPDUは別だからな。

そうなんですか？

もちろんだ。BPDUを受け取らなければ新しいSTPが計算できないし。
BPDUを送らなければ、隣接スイッチはそのスイッチがダウンしたと勘違いするだろう？

そう言われればそうですね。

STPの再計算だが、基本的にスイッチ単位で実行される。
つまり、ダウンしたことが影響しないスイッチでは再計算は実行されない。

影響って直接BPDUの受け渡しをするスイッチだけのことですか？

いや、そういうわけではない。
例えば、下の図だ。

この場合、各スイッチが受け取るルートブリッジへのコストが変わってしまうため、3つのスイッチが影響を受ける。

ははぁ。影響…。

わかったわかった。計算動作を示そう。
前回のポートの決定の図を使うぞ。

なるほどです。確かに他のスイッチに影響してますね。

■ CAMテーブルの問題

さて、どのような結果になるとしても、STPの再計算とCAMテーブルにはズレが生じることになる。

CAMテーブルとズレ？ CAMテーブルってポートとMACアドレスの対応テーブルでしたよね。

うむ。それはCAMテーブルのリフレッシュが5分間隔ということからくる問題だ。

あららら。STPが正しくなったのに、CAMテーブルが正しくなってない？

そういうことだ。
これはCAMテーブルがリフレッシュされるか、PC-Aが新たに送信を行い、それがCAMテーブルの更新を引き起こすまで続けられる。

う〜ん。5分って長いですよね。そんな長時間データが届かなくなったりするんですか〜。

うむ。では、これを防ぐにはどうする？

どうするって…。CAMテーブルのリフレッシュ間隔を短くする？

それでは普通の、なんら問題がない状態でのスイッチの負荷が大きくなってしまう。
なので、再計算が実行されたことを通知し、CAMテーブルの消去をお願いするのだ。

は〜。「CAMテーブルをクリアしてください」って通知を送るんですね。

そういうことだな。

へ〜。

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

はい。

STPはしばらく続くぞ。では、また次回。

はい。
30分間ネットワーキングでした〜♪