■ FDとAD

さて、前々から言葉がでてきていた、DUALを今回は説明する。

でゅある？

Diffusing Update ALgorithm、拡散アップデートアルゴリズムと訳す。
EIGRPのアップデートだな。

ははぁ。
拡張ディスタンスベクタというぐらいなんですから、普通にルーティングテーブルをやりとりはしないんですよね。

うむ。
まず、DUALで使われる用語の説明をしよう。まずFDとADだ。

えふでぃー、えーでぃー。

EIGRPは拡張とはいえ基本はディスタンスベクタだ。
なので、ネイバーが知るパスを教えてくれる。そのメトリックがADだ。

ははぁ。
宛先ネットワークとネイバーとの距離ってことですか？

そう、ネイバーが通知(アドバタイズ)してきた距離、つまりAD(アドバタイズドディスタンス)ってことだな。
そして、もうひとつがFDだ。

こっちは、自身から宛先ネットワークまでの距離ですね。

そういうことだ。宛先ネットワークまでパケットを送ることがフィージブル(実行可能な)距離、FD(フィージブルディスタンス)だ。

ふむふむ。
で、このFDとADは何に使うんですか？

サクセサとフィージブルサクセサを計算するのに使うのだ。

さくせさ？
成功者？

■ サクセサ

成功する[succeed]の名詞形が成功[success]だが、successor は「後任、後継者、後に来るもの」の意味がある。
ともかく、サクセサとはベストパスのことだ。

べすとぱす？ 最適経路ですよね。

うむ、ルーティングテーブルに記載される最適経路だ。
さてネット君。EIGRPのルーティングテーブルはどう作る？

えっと、ネイバーから教えてもらった経路がすべて載ったトポロジテーブルから、ベストパスを抜き出して、作られます。

そうだ、前回出てきた図であったな。

あ〜。ここにFDとADが出てる。

うむ。図を見てわかるように、最小のFDを持つパスがサクセサになり、ルーティングテーブルに記載されるわけだ。

じゃ、ADは何に使うんです？
それと、フィージブルサクセサって何です？

まぁ、まて。一気に言うな。順番に行こう。
フィージブルサクセサは代替パスのことだ。

代替パス？
最適パスに対する、代わりのパスですか？

うむ。バックアップルートのことだな。

はぁ。宛先ネットワークまでの別のパスですね。
サクセサが駄目になった時に使う、と。

そうだ。だが、サクセサと別のパスがあったからといって、なんでもかんでもフィージブルサクセサにはならない。
サクセサ以外の条件を満たしたパスのみがフィージブルサクセサになる。

条件？

うむ、以下のような条件だ。

サクセサの宛先ネットワークまでのメトリックより、フィージブルサクセサ(候補)までのメトリックの方が小さい？

そうだ。ちょっとわかりづらいので図で示そう。

ははぁ。なんでこんな面倒な条件をしてるんでしょうか？
素直に、サクセサ以外のパスはバックアップ、としてしまえばいいのに。

確かにそうだが、実を言うと、これがDUALの「ルーティングループ」を防ぐための手段なのだよ。

そうなんですか？

うむ。それについてはまたいずれ話そう。
さて、この条件でいけば、メトリック的に変な状況にもなりうる。

FDは遠いネイバーCのパスがフィージブルサクセサに選ばれてしまう、このようなこともありえるわけだ。

あ〜、そういえばそうなりますよね。
なんでですかね？

基本的にディスタンスベクタなEIGRPは、ディスタンスベクタの基本概念である「ネイバーからの通知」を重視する。
なので、フィージブルサクセサを選ぶ場合は、通知してきた距離(AD)を使う。

は〜、なんか納得いかないような。

うむ。正直知らんのだ、あまりツッコむな。

ほほ〜。博士の敗北宣言とは珍しい。
じゃ、この話はここまでにしときましょう。

■ ACTIVE

さて、サクセサをルーティングテーブルに記載する。
サクセサのダウン時は、フィージブルサクセサがサクセサに昇格する。この２点はいいな。

はい。サクセサが最適経路、フィージブルサクセサはバックアップのパスですね。

問題は、フィージブルサクセサがない状態で、サクセサがダウンした場合だ。

結局、フィージブルサクセサでなかったパスが、サクセサになっちゃうんですね。

うむ。バックアップのルートとしては遠すぎるなぁ、と感じていたパスだが、結局それしかないから仕方がない。という感じかな。
ポイントはいくつかある。まずQueryとReplyだ。

「問い合わせ」「応答」ですね。

そうだ。DUALはルーティングループが発生しないと以前話したが、理由はこのQueryとReplyだ。
ネット君、ルーティングループは何故発生する？

それは、え〜、トポロジの変更情報が届かないうちに、他のルータへ誤ったトポロジ情報を通知するから。
あとは、変更情報が届かないうちに、パケットを転送するからなかな。

よしよし。だが、EIGRPの場合、トポロジの変更が起きた場合、フィージブルサクセサがあればそちらをすぐ採用して使う。
ループは発生しないな？

そうですね。
違うルートがあるんですから、誤ったルートへは送られないですよね。

フィージブルサクセサがない場合、Qurayを送る。Queryを送るとACTIVEになってルーティングは保留になる。
正確なトポロジ情報が入ってくるまで、つまりコンバージェンスに達するまで行動を控えるわけだな。

は〜。
ということは、誤ったトポロジ情報を使わないってことですよね、なるほど。

そういうことだ。
あと、Query/Replyに関してはポイントが２つある。

確実にコンバージェンスに達するため、すべてのネイバーから通知をもらうまでACTIVEは続くってことだな。

ん〜、確かに正確さを求めるためにはそうでしょうけど。
もしなんらかの原因でReplyが帰ってこなかったらどうなるんです？

例えば、Queryを受け取った直後にダウンしたとかか？
3分以内にReplyが帰ってこなかった場合、そのネイバーはダウンした、と判断する。

なんだ、ちゃんと考えられているんですね。

うむ。そのReply待ちについては先でまた説明する。
もう１つのQuery/Replyのポイントは、以下の通りだ。

サクセサからのQueryもダウンと判断する？

その通り。考えてみれば当然だ。上の例でいえば、ルータBはネイバーのルータAから教えてもらったルートを使っている。
それなのに、その当のルータAから「αへのパスを知りませんか？」ときたら、おかしいなと思うだろ？

あ〜、確かに。
「お前から教えてもらったのに、(αへのパスを)知らんとはどういうこっちゃ？」と思いますね。

そういうことだ。

ディスタンスベクタに似てると言えば、似てるけど。
なんかいろいろ考えられてますねぇ。

拡張ディスタンスベクタだからな。
さて今回はこれぐらいにしておこう。

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