ルーティングプロトコルで特に問題となるのが「ルーティングループ」です。ループが発生すると,パケットの正しいルーティングが行われなくなり,あて先にパケットが届かなくなります。ディスタンスベクタ型ルーティングプロトコルのRIPで発生するルーティングループの仕組みと解決法を学びましょう。
ルーティングループ
RIPのようなディスタンスベクタ型ルーティングプロトコルで最大の問題点と言っても過言ではないものがルーティングループです。ルーティングループはアップデートのタイミングなどにより発生し,ルーティングテーブルが誤った情報を載せてしまい,その結果正しいルーティングが行われなくなります。
ルーティングループは再配布などを除けばディスタンスベクタ型以外のルーティングプロトコルでは発生しないか,もしくは発生しにくくなっています。一方のリンクステート型やハイブリッド型のルーティングプロトコルでは,元々ルーティングループの防止を組み込んで作られています。
では,RIPでルーティングループが発生する仕組みを見てみましょう(図1)。

ルーティングループが発生すると,パケットはルータ間でやりとりされ,あて先まで届かなくなります。そしてパケットのTTLが0になって時点で破棄されることになります。もともとTTLはこのような事態が発生した場合にパケットを破棄するために存在します。つまり,「あて先までパケットが届かない」,「メトリックが増え続ける」という二つの「異常事態」が発生することになります。
特に「あて先までパケットが届かない」というのは問題です。そのため,ルーティングループの発生は絶対に防がなければなりません。
ルーティングループの防止(その1)
ルーティングループの発生要因として「コンバージェンス速度」の問題があります。例えば図1でルータAで1.0.0.0がダウンした直後に,その情報がすぐルータBに伝わっていたとしたら,ルーティングループは発生しません。つまり,ディスタンスベクタ型のコンバージェンス速度自体がルーティングループの要因になります。
また,アップデートの観点から見ればルーティングループが発生する要因は「自分が通知した情報を受信してルーティングテーブルに載せる」ことであると言えます。図1ではルータAは自分がルータBに通知した1.0.0.0の情報が,ルータA自身に戻ってきてしまい,それをルーティングテーブルに載せています。これによりルーティングループが発生しています。
つまりルーティングループを防止するためには,「コンバージェンス速度を速める」と「自身が通知した情報を受け取らない」という2点が必要になります。RIPではこの2点を考え,ルーティングループを防ぐため以下の技術が使われています。
- メトリックの上限値の設定
- スプリットホライズン
- ポイズンリバース付きスプリットホライズン
- トリガアップデート
- ルートポイゾニング
- ホールドダウンタイム
まず,「メトリックの上限値の設定」です。RIPではメトリックが16の経路は「到達不能」として扱います。これを利用してルーティングループを防止します(図2)。

これによりルーティングループは防止されますが,この方法はどちらかと言えば受動的な対策といえます。少なくともメトリックが上限値に達するまではルーティングループが発生していることになります。
よって次の防止策である「スプリットホライズン(Split-Horazon)」が使われます。スプリットホライズンは「経路情報を受信したインタフェースから送信されるアップデートにはその経路情報を含めない」というルールです(図3)。
