web-dev-qa-db-ja.com

ベルマンフォードアルゴリズムで無限に数える原因となる正確な原因

私が理解できることから、無限にカウントすることは、あるルーターが別の古い情報をフィードするときに発生し、それはネットワークを介して無限に向かって伝播し続けます。私が読んだところによると、これはリンクが削除されたときに間違いなく発生する可能性があります。

enter image description here

したがって、この例では、ベルマンフォードアルゴリズムがルーターごとに収束し、ルーターごとにエントリがあります。 R2は、1のコストでR3に到達できることを認識し、R1は、2のコストでR2を介してR3に到達できることを認識します。

R2とR3の間のリンクが切断されている場合、R2は、そのリンクを介してR3にアクセスできなくなったことを認識し、テーブルから削除します。更新を送信する前に、R1から更新を受信する可能性があります。これは2のコストでR3に到達できることをアドバタイズします。R2は1のコストでR1に到達できるため、ルートを更新します。 R3はR1経由で3のコストでR1は後でR2から更新を受け取り、そのコストを4に更新します。その後、彼らはお互いに悪い情報を無限に送り続けます。

私がいくつかの場所で言及したことの1つは、リンクのコストの変更など、リンクがオフラインになるだけでなく、無限にカウントされる他の原因が存在する可能性があることです。私はこれについて考えるようになりました、そして私が言うことができることから、おそらくリンクのコストが増加することが問題を引き起こす可能性があるように思われます。しかし、コストを下げることで問題が発生する可能性はないと思います。

たとえば、上記の例では、アルゴリズムが収束し、R2が1のコストでR3へのルートを持ち、R1が2のコストでR2を経由してR3へのルートを持っている場合、R2とR3の間のコストが5.次に、これにより同じ問題が発生します。R2はR1から更新を取得してコスト2をアドバタイズし、R1を介してコストを3に変更し、次にR2を介してルートを4に変更します。ただし、コンバージドルートでコストが減少した場合、変更は発生しません。これは正しいです?問題を引き起こす可能性があるのはリンク間のコストの増加であり、コストの減少ではありませんか?他に考えられる原因はありますか?ルーターをオフラインにすることは、リンクが切れることと同じでしょうか?

14
Cory Gross

この例を見てください:

enter image description here

ルーティングテーブルは次のようになります。

_    R1   R2    R3
R1  0    1     2
R2  1    0     1
R3  2    1     0
_

ここで、R2とR3の間の接続が失われたと仮定します(回線が切断されたか、それらの間の中間ルーターが切断された可能性があります)。

情報の送信を1回繰り返すと、次のルーティングテーブルが表示されます。

_    R1   R2    R3
R1  0    1     2
R2  1    0     3
R3  2    3     0
_

これは、R2、R3が接続されなくなったために発生します。そのため、R2は、パスが2のR1を介してパッケージをR3にリダイレクトできると「考え」ます。したがって、重み3のパスを取得します。

追加の反復の後、R1はR2が以前よりも高価であると「認識」するため、ルーティングテーブルを変更します。

_    R1   R2    R3
R1  0    1     4
R2  1    0     3
R3  4    3     0
_

など、正しい値に収束するまで続きますが、特に(R1、R3)が高価な場合は、時間がかかる可能性があります。
これは「無限カウント」と呼ばれます(w(R1,R3)=infinityが唯一のパスである場合、永久にカウントを続けます)。


2つのルーター間のコストが上がると、同じ問題が発生することに注意してください(上記の例ではw(R2,R3)が50になると想定しています)。同じことが起こります-_R2_は、_R3_にも依存することを「認識」せずに、_R1_経由で_(R2,R3)_にルーティングしようとします。同じ最初のステップが得られます。正しいコストを見つけたら収束します。
ただし、コストが下がった場合(新しいコストが現在よりも優れているため発生しません)、ルーター_R2_は同じルーティングを維持し、コストを削減します。 _R1_を経由します。

26
amit

ウィキペディアによると:

RIPは、スプリットホライズンとポイズンリバーステクニックを使用してループを形成する可能性を減らし、最大数のホップを使用して「無限カウント」の問題に対処します。これらの対策により、すべてではありませんが、一部のケースでルーティングループの形成が回避されます。ホールドタイムの​​追加(ルート撤回後の数分間のルート更新の拒否)は、事実上すべての場合にループ形成を回避しますが、収束時間の大幅な増加を引き起こします。

最近では、ループのないディスタンスベクタープロトコルが数多く開発されています。注目すべき例は、EIGRP、DSDV、Babelです。これらはすべての場合にループ形成を回避しますが、複雑さが増し、OSPFなどのリンク状態ルーティングプロトコルの成功により展開が遅くなります。

http://en.wikipedia.org/wiki/Distance-vector_routing_protocol#Workarounds_and_solutions

2

これは質問のベルマンフォードアルゴリズムの部分を認めていませんが、これは単純化された答えです。ここに行きます。

元のポスターの画像に注目してください。 R1、R2、およびR3があります。それぞれルーター1、2、および3を表します。

各リンクのコストは1、各ホップのコストは1です。2つのルーター(例:R1からR3)をホップするには、2のコストが必要です。

各ルーターはコストを追跡し、情報を更新します。ただし、値が欠落している場合(たとえば、ルーター間のリンクが欠落している場合)、ホップカウントは削除され、ルーティングテーブルが更新されると、別のルーターによって埋められます。

例:

ルータ3のルータ2へのリンクがダウンすると、ルータ2はそのルートをテーブルから削除します。ルーター1は、ルーター3に到達するのに2ホップかかると考えています。これは、ルーター2に複製され、両方のルーターは、ルーター3に到達するのに2ホップかかると考えています。

ルーター1は、「ルーター2に到達するのに1ホップかかり、ルーター2がルーター3に到達するのに2ホップかかる場合、ルーター3に到達するのに3ホップかかるはずです」という簡単な計算を行います。ルーター2も同様の計算を行い、ルートに1ホップを追加します。

これがループの仕組みです。

1

ホールドダウン:

  • メトリックが増加すると、情報の伝播が遅れます

制限:

  • 収束ループ回避を遅らせる
  • ルートアドバタイズメントのフルパス情報
  • ループの明示的なクエリ(例:DUAL)スプリットホライズン
  • ネクストホップを介して宛先をアドバタイズしないでください
    • AはCをBにアドバタイズしません
  • ポイズンリバース:ネクストホップを介して目的地を宣伝するときに否定的な情報を送信する
  • Aは、∞のメトリックでCをBにアドバタイズします。
    • 制限:サイズ2の「ループ」でのみ機能します
0
kosai