RIP/OSPF間再配送におけるAD値変更時の動作について
- フォーラムは新サイトへ移行しました。
- このフォーラムではゲスト投稿が禁止されています
honor7833
投稿数: 2
投稿数: 2
【前提条件】
・あるルータで、ripとospfを有効にし、双方向の再配送を行っている。
・AD値はデフォルトのまま。
・ある同じ経路を、ripとospfで受け取る時、OSPF側の経路が有効になっている。
【検証手順】
1.ripの方の経路を有効にするため、distanceコマンドで、ripを105にする。すると、ルーティングテーブルにおける該当経路が O E2→R に変更された。タイミングは即座ではなく、数十秒後だった。（これはルーティングアップデートのタイミング？）
2.次に、再度OSPF側の経路を有効にするため、distanceコマンドで、ripを120に変更した。しかし、ルーティングテーブルは即座に更新されなかった。show ip route と debug コマンドで確認したところ、以下の遷移だった模様。
============================================================
インバリッドタイマ(180秒程度)経過→possibily down→フラッシュタイマ経過(60秒程度)→RIPの経路情報削除(metric16でアドバタイズ）→ルーティングテーブルにOSPFの経路情報が乗る。
上記の間も、debugコマンドで確認する限り、隣接のRIPルータから、該当の経路情報（ルーティングアップデート）は受信していた。ただ、何故か、ルーティングテーブル上の経過時間は増え続けていた。
============================================================
AD値を変更しても、即座にルーティングテーブルが切り替わらないのは仕様でしょうか。上記1、2のいずれも、切り替わりのタイミングがいまいち理解できていないです。
仔細説明いただける方、お願いできれば助かります。
・あるルータで、ripとospfを有効にし、双方向の再配送を行っている。
・AD値はデフォルトのまま。
・ある同じ経路を、ripとospfで受け取る時、OSPF側の経路が有効になっている。
【検証手順】
1.ripの方の経路を有効にするため、distanceコマンドで、ripを105にする。すると、ルーティングテーブルにおける該当経路が O E2→R に変更された。タイミングは即座ではなく、数十秒後だった。（これはルーティングアップデートのタイミング？）
2.次に、再度OSPF側の経路を有効にするため、distanceコマンドで、ripを120に変更した。しかし、ルーティングテーブルは即座に更新されなかった。show ip route と debug コマンドで確認したところ、以下の遷移だった模様。
============================================================
インバリッドタイマ(180秒程度)経過→possibily down→フラッシュタイマ経過(60秒程度)→RIPの経路情報削除(metric16でアドバタイズ）→ルーティングテーブルにOSPFの経路情報が乗る。
上記の間も、debugコマンドで確認する限り、隣接のRIPルータから、該当の経路情報（ルーティングアップデート）は受信していた。ただ、何故か、ルーティングテーブル上の経過時間は増え続けていた。
============================================================
AD値を変更しても、即座にルーティングテーブルが切り替わらないのは仕様でしょうか。上記1、2のいずれも、切り替わりのタイミングがいまいち理解できていないです。
仔細説明いただける方、お願いできれば助かります。
arashi1977
居住地: 広島
投稿数: 1715
居住地: 広島
投稿数: 1715
honor7833 さん＞
構成がわからないので適当に環境を作って試してみましたが、確かにそうなりますね。
この構成で即座にルーティングテーブルを更新したい場合は
をやると更新されます。
※ドキュメントを探してみたのですが見つからなかったため、ここから先の記述は私の推測が多分に含まれています。
ルーティングテーブルは、各種ルーティングプロトコル（スタティック、connected含む）から入手した情報をもとに、最適なものをピックアップして構成されるものです。
※ここから先、show processをした結果のプロセス名を使用します。
AD値は、IP RIB Updateプロセスが利用する値であり、動的ルーティングの場合は各ルーティングプロセス（RIP Router、OSPF-1 Router）が付加して渡します。
各ルーティングプロセスが自身のタイマ、あるいはイベントトリガによって、アップデート情報をIP RIB Updateプロセスに渡し、そのタイミングでルーティングテーブルの更新が行われます。
今回の場合
・OSPFはリンクステートに変更がなければアップデートが走らない
・RIPは各種タイマでの更新タイミングまで、変更情報をIP RIB Updateプロセスに送らない
と考えられるため、即座に切替らなかったものと思います。
clear ip route * を実行することで、強制的にRIB更新を実行させ、更新したAD値でのルーティング情報をRIP Router/OSPF-1 Routerプロセスから入手でき、期待通りのルーティングテーブルに書き換えられたと考えます。
※たぶんEIGRPだったら何らかの情報変更をつかんでアップデートを行うはず
動作からの推測ですが、たぶんこんな感じかと
構成がわからないので適当に環境を作って試してみましたが、確かにそうなりますね。
この構成で即座にルーティングテーブルを更新したい場合は
clear ip route *
※ドキュメントを探してみたのですが見つからなかったため、ここから先の記述は私の推測が多分に含まれています。
ルーティングテーブルは、各種ルーティングプロトコル（スタティック、connected含む）から入手した情報をもとに、最適なものをピックアップして構成されるものです。
※ここから先、show processをした結果のプロセス名を使用します。
AD値は、IP RIB Updateプロセスが利用する値であり、動的ルーティングの場合は各ルーティングプロセス（RIP Router、OSPF-1 Router）が付加して渡します。
各ルーティングプロセスが自身のタイマ、あるいはイベントトリガによって、アップデート情報をIP RIB Updateプロセスに渡し、そのタイミングでルーティングテーブルの更新が行われます。
今回の場合
・OSPFはリンクステートに変更がなければアップデートが走らない
・RIPは各種タイマでの更新タイミングまで、変更情報をIP RIB Updateプロセスに送らない
と考えられるため、即座に切替らなかったものと思います。
clear ip route * を実行することで、強制的にRIB更新を実行させ、更新したAD値でのルーティング情報をRIP Router/OSPF-1 Routerプロセスから入手でき、期待通りのルーティングテーブルに書き換えられたと考えます。
※たぶんEIGRPだったら何らかの情報変更をつかんでアップデートを行うはず
動作からの推測ですが、たぶんこんな感じかと
honor7833
投稿数: 2
投稿数: 2
arashi1977 さん
早速返信頂き、ありがとうございます！
挙動の方も、筋が通ったご説明で、理解できました。
ただ、1と2で挙動が変わるのが、やはり個人的に気持ち悪いところですね。。
「AD値を変更した場合、優先される方のルーティングプロトコルで、何らかのトリガーが走らないと、ルーティングテーブルが更新されない。」だとしたら、2のパターンで、clear ip ospf process を試したら、即座に切り替わるのかな。。
早速返信頂き、ありがとうございます！
挙動の方も、筋が通ったご説明で、理解できました。
ただ、1と2で挙動が変わるのが、やはり個人的に気持ち悪いところですね。。
「AD値を変更した場合、優先される方のルーティングプロトコルで、何らかのトリガーが走らないと、ルーティングテーブルが更新されない。」だとしたら、2のパターンで、clear ip ospf process を試したら、即座に切り替わるのかな。。
