Counting to Infinity問題の続きです。どんな問題かわからなくなったらこちらに戻ってください。
【勉強】Counting to Infinity問題を解説してみた - 大学院生のネットワークなブログ
Counting to Infinity問題のため、ディスタンスベクター型では距離が基準値以上に大きくなったリンクがあると、そこを途切れているとみなします。
基準値を小さくするとネットワークの規模が制限されるので問題外として、基準値を大きくするとディスタンスベクター表が収束するのが遅くなってしまうのがネックでした。
収束を早めるための方策がいろいろと考えられています。
スプリットホライズン・ポイズンリバース
今日はその1つを紹介します。スプリットホライズン・ポイズンリバースと呼ばれる方法です。
スプリットホライズンとは「ある宛先に関して自分の次ホップとなるルータには、その宛先に関するディスタンスベクターを通知しない」というものです。
ポイズンリバースは「ある宛先に関して自分の次ホップとなるルータには、その宛先に関するディスタンスベクターを無限大の距離として通知する」というものです。
どのような方法か
これが実際にどのように働くのか見てみます。
Counting to Infinityのときと同じ場合を考えます。AB間が途切れてしまったときに、Cがディスタンスベクターを通知することによって問題が発生したわけです。
だからここを改善します。
スプリットホライズンではAという宛先に関してCの次ホップとなるルータBに、Aに関するディスタンスベクターを送りません。
ポイズンリバースではAという宛先に関してCの次ホップとなるルータBに、Aに関するディスタンスベクターを無限大の距離として通知します。
どちらも次のタイミングではBからCへディスタンスベクターが送られます。
B本人がAまでは無限大かかると言っているのでCは書き換えますね。
一件落着でしょうか?
これだけではダメだった・・・
一件落着と言いたいところなんですが、これらを使ってもまだCounting to Infinityに繋がってしまう場合があるのです。それを説明します。
下の図を見てください。Dを追加しただけです。あとは今までと同じです。AB間が切れたとき、宛先Aに関してディスタンスベクター表がどうなっていくのかを追っていきます。
Aまでのリンクが切れてしまったのでBは(Inf,A)を隣接ノードに通知します。
この(Inf,A)が先にCに来たときどうなるかを考えます。当然、Dもディスタンスベクターを通知しています。(矢印が多くなると見ずらいので関係ある矢印しか書いていません。)
距離が短い方を採用するのがディスタンスベクター表の更新のルールですからCはDから来た方を採用します。Aまで行くときはC→D→B→Aが最短ルートだと思ってしまうわけです。
つぎの更新タイミングがきます。CはスプリットホライズンによってDにAに関するディスタンスベクターを送りません。なのでDはBから来た方を採用して、Aまでは無限大とします。(ポイズンリバースでも同じ結果ですね。)
さらに次はBが更新されます。
Cから受け取った(3,D)によってBはB→C→D→B→Aが最短ルートだと思ってしまいます。
どんどん行きます。次はDが更新されます。この段階でもAに関してCの次ノードはDです。スプリットホライズンが効いていますので、CからDへは送られません。
Dが更新されました。次はCです。スプリットホライズンでBからは送られないのでDからのディスタンスベクターを採用です。
ここからは同じパターンの無限ループですね。距離が一番小さいところが順次更新されていきます。
けっきょくCounting to Infinityになってしまうので、別の方法と合わせて対策をしなきゃいけないということです。
その別の方法についてはあまりおもしろいテーマではないらしいので、教えてもらえませんでした。