ルーティングループ

ルーティングループの発生

コンバージェンスするために時間がかかってしまうというディスタンスベクタ型ルーティングプロトコルの欠点から、ネットワークの変更を正しくルーティングテーブルに反映することができずに、ルーティングループが発生する可能性があります。

まずは、図のような単純なネットワークを考えます。

※図をクリックすると拡大します

この図では、ルータA、ルータBともにお互いにルーティング情報を交換してコンバージェンス状態となっています。

この状態から、ルータAに直接接続されている10.0.0.0/8のネットワークがダウンしたときを考えます。すると、ルータAのルーティングテーブルから10.0.0.0/8のエントリが削除されます。この間、ルータBは30秒ごとに定期的なアップデートをブロードキャストしています。アップデートには、(10.0.0.0,2) (20.0.0.0,1) (30.0.0.0,1)が含まれています。

※ここではスプリットホライズンを考えていません。

このアップデートを受け取ったルータAは、10.0.0.0のエントリがルーティングテーブル上からすでになくなってしまっているので、ベルマンフォードアルゴリズムに従って、ネクストホップをルータBとしてルーティングテーブルに追加します。しかし、よくよく考えてみると、ルータBの向こう側には10.0.0.0/8のネットワークは存在しませんので、10.0.0.0/8には到達することはできません。それにもかかわらずルータAは、間違った情報をルーティングテーブルに載せてしまうわけです。

※図をクリックすると拡大します

もし、このときルータBにあて先IPアドレスが10.0.0.1というパケットがやってくると、ルータAにルーティングし、ルータAは自身のルーティングルーティングテーブルに従って、ルータBにルーティングします。この戻ってきたパケットをまたルータBはルータAにルーティングし、ルータAはルータBにルーティングする・・・という具合に、パケットはルータAとルータBの間を行ったりきたりしてしまうことになります。これは、パケットのTTLが0になって、廃棄されるまで続くことになります。次々と、10.0.0.0/8あてのパケットがやってくると、さらにループするパケットの数が増え、ルータAとルータBの間の帯域幅を圧迫してしまうことにもなります。

※図をクリックすると拡大します

さらに、ルータAは30秒経つとルーティングテーブルのエントリをブロードキャストします。その内容は、(10.0.0.0,3) (20.0.0.0,1) (30.0.0.0,2) です。実際には、10.0.0.0/8のネットワークはすでに存在しないのに、あたかも自分を経由して到達できるかのような情報を流すわけです。このアップデートを受け取ったルータBは、ルーティングテーブルに追加すべきかどうか判断します。
10.0.0.0のエントリは、もともとルータBから教えてもらったものです。ベルマンフォードアルゴリズムの3番目のパターンで、ルーティングテーブル上のネクストホップアドレスとルーティングアップデートのネクストホップアドレスが同じ場合には、メトリックにかかわらずに受信したルーティングアップデートをルーティングテーブルに採用します。

※図をクリックすると拡大します

そして、ルータBは定期的な間隔でルーティングテーブルをブロードキャストします。今度の内容は、(10.0.0.0,4) (20.0.0.0,1) (30.0.0.0,1) です。実際には存在しない10.0.0.0/8のネットワークへ、ルータBを経由して行けると通知してしまっているわけです。ルータAは、10.0.0.0/8のエントリはルータBから教えてもらったものですから、たとえメトリックが悪くてもさきほどと同じようにルーティングテーブルに採用するわけです。

※図をクリックすると拡大します

そして、またルータAがルータBへ・・・

このような現象がルーティングループと呼ばれるものです。ルーティングループが発生すると、ルータ同士が間違った情報を交換してしまい、正しくルーティングテーブルを作ることができません。ルーティングテーブルが間違っているということは、結局通信ができなくなってしまいます。