ルートポイズニングとホールドダウンタイマ
ディスタンスベクタ型のルーティングプロトコルでは、コンバージェンスが遅いのでルーティングループが発生しやすいという問題点があります。
トリガードアップデートを行うことで、コンバージェンスを高速化する仕組みがありますが、ルータが複数あるネットワークの場合、アップデートがバケツリレーで送られてくるため、誤ったアップデートを完全に防ぐことはできません。
下図は、RIPで構築されたネットワークにおいて、ルーティングループが発生している図です。
ルーティングループが発生してしまった原因は、Router_A が、Router_B からの定期更新で、「10.0.0.0 メトリック2」という情報を信じてしまったからです。
クラスフルルーティングの問題点
Router_Aは、直接接続している「10.0.0.0/8」のネットワークのダウンを検出すると、Router_B にメトリックが無限大であるというメトリック16の「10.0.0.0 , 16」というエントリーをRIPのアップデートで通知します。
※RIPでは、最大メトリックが15、メトリック16は、到達不能を意味します。
つまり、
メトリック無限大 ＝ ポイズン(毒)
というアップデートをRouter_B に送信します。
Router_B は、メトリックが無限大のルート情報を受け取るとルーティングテーブル上に、既にそのルートのエントリがあるかを調べます。
もし、あれば、「Possibly down」（恐らくダウン）と判断して、そのエントリをホールドダウン状態に置きます。ホールドダウン期間中は、ルーティングテーブルに「Possibly down」と表示されます。
この状態は、ホールドダウンタイマが切れるまで続き、その間は、ホールドダウン状態に置かれたルートを更新しません。それは、ホールドダウン期間中は、間違ったアップデートがやってくる可能性があるからです。
このように。ホールドダウンタイマは、ルートポイズニングによって起動するようになっています。
このホールドダウンタイマは、以下のタイミングで解除します。ホールドダウンタイマの制限時間が切れるまで、指をくわえて待っているというようなことはしないようになっています。
- ホールドダウンタイマーの時間が経過した時
- 別のルータから元のメトリックより小さいメトリックのアップデートを受信した時
- フラッシュタイマーよってルーティングテーブルから削除された時
トリガードアップデート
せっかくルートポイズニングによってホールドダウン状態にできても、このルートポイズニングが他のルータに早く届かなくては、意味がありません。定期的なアップデートで、この情報を通知していたのでは時間がかかりすぎてしまいます。
そこで、ネットワークの状態に変化が起こった時に、すぐにアップデートを送信するトリガードアップデートという仕組みが用意されています。