広告
広告
https://www.7key.jp/nw/routing/r_protocol/rip.html#whatRIPは代表的なルーティングプロトコルで、インターネットの前進であるARPANETの時代から使用されています。RIPの起源はゼロックスのネットワーク内で使われていたプロトコルで、その後XNS【Xerox Network Systems】で改良されRIPと名付けられました。ただ、この頃のRIPは仕様のないまま使われており、ベンダによって細かな実装に違いがみられていました。その中でも最も有力だったのだUNIX 4.3BSD【4.3 Berkeley Software Distribution】でroutedというプログラムとして配布されたものでした。そもそもTCP/IP自体が4.2BSDに同梱されて、4.2BSDの人気と共にネットワークの世界に受け入れられた経緯もあり、routedも4.3BSDに同梱されることでデファクトスタンダードとしての地位を確立するに至ったのです。1988年になるとroutedを基にRIPの仕様が確定しました。これは現在RIP version1（RFC1058）として知られています。その後、RIP version1の規制を緩和するためにRIPv2（RFC2453）が規定されました。RIPの主な特徴は次の通りです。
RIPはAS内部で利用するIGPsです。アルゴリズムにはディスタンスベクタ型を利用して経路情報を定期的（30秒に1回）に交換し、ダイナミックにルーティングテーブルの作成と維持を行います。
ホップ数とは、目的の宛先に到達するまでに通過するルータの数を指します。RIPではホップの最大数は16までとの制限があります。ただし、ホップ16は到達不可能を表す特別な値となっており、実質の最大数は15となっています。
RIP version1はクラスフルルーティングプロトコルです。クラスフルルーティングプロトコルではサブネットマスクを経路情報と一緒に交換できないため、推測でサブネットマスクを適用します。従って、RIPを使う場合はこの推測を裏切らないようなネットワークの分割をするよう注意しなければなりません。
ディスタンスベクタ型ルーティングプロトコルには、コンバージェンスが遅いという欠点があります。
コンバージェンスに時間がかかることによって、ネットワーク上に意としないルーティングループが発生する可能性が出てきます。
ルーティングテーブルの交換について、RIP version1はIPレベルのブロードキャストを用いて行います。そのためRIPルータ以外のルータやコンピュータもブロードキャストパケットを受信してしまうため、無駄が生じることとなります。
https://www.7key.jp/nw/routing/r_protocol/rip.html#formatRIPはアプリケーション層のプロトコルで、トランスポート層のサービスとしてUDPを使用します。どの更新についても送信と受信両方にUDPポート520が使用されます。このため、通常の定時更新が行われるとき、ポート520はUDPヘッダの送信元兼宛先ポートとなります。更新のほとんどは要求に基づくものではありませんが、RIPは要求に応答する機能もサポートしていますので、ステーションがルータに更新を要求することがきます。この際、要求元ステーションは任意のUDPポートから要求を送信しますが、応答が返ってくるのは必ずそのステーションのUDPポート520です。
RIPパケットのフォーマットは次の通りです（括弧内数値はbit）。
| オペレーション（8） | バージョン（8） | 未使用（16bit全て0） |
| アドレスファミリー識別子（16） | 未使用（16bit全て0） | |
| IPアドレス（32） | ||
| 未使用（32bit全て0） | ||
| 未使用（32bit全て0） | ||
| メトリック | ||
| … | ||
| アドレスファミリー識別子（16） | 未使用（16bit全て0） | |
| IPアドレス（32） | ||
| 未使用（32bit全て0） | ||
| 未使用（32bit全て0） | ||
| メトリック | ||
RIPアップデートメッセージの最大長は512オクテットとなっており、更新情報が多ければ複数のUDPデータグラムが必要となります。1つのルートごとにアドレスファミリ識別子からメトリックまでの20オクテットを使用し、最大で25ルートを1つのUDPデータグラムで送信することができます。
実行されるオペレーションの種類がはいります。オペレーションは5種類ありますが、実際に利用されているのはリクエストとレスポンスだけです。
| コード | 意味 | 説明 |
|---|---|---|
| 1 | Request | ルータが持つルーティングテーブルの全部又は一部の送信をルータに要求する。 |
| 2 | Response | ルーティングテーブルの全て又は一部をいれたメッセージ。要求に応答する場合と通常の定時更新の際に使われる。 |
| 3 | Trace On | 使われなくなった機能で、このオペレーションコードを持つデータグラムは無視される。 |
| 4 | Trace Off | 使われなくなった機能で、このオペレーションコードを持つデータグラムは無視される。 |
| 5 | Reserved | Sun Microsystemsが内部で使用するために確保されているコード。このオペレーションコードを持つデータグラムは他のシステムでは無視される。 |
使用しているRIPのバージョンを入れます。RIP version1では1が入ります。また、バージョン番号が0のデータグラムは全て破棄されます。バージョン番号1のデータグラムは、未使用のフィールドの何れかに0でない値が入っていた場合は破棄されます。バージョン番号が1よりも大きければ破棄されません。
そのエントリがどのプロトコルに由来しているかを示します。RIPはもともとIP以外のプロトコルでも利用できるよう設計されていますが、IP以外での利用はほとんどなされていませんので、IPルーティングを表すコード2が入ります。
宛先ネットワークアドレスが入ります。RIPではIP以外のプロトコルでも使用されることが考慮に入れられ宛先ネットワークアドレスとして12オクテット分のフィールドが確保されています。ただ、IPアドレスは4オクテットなので残りの8オクテットは未使用として0で埋められます。
エントリのメトリックが入ります。RIPでは1〜16の値が利用されますが、値16は到達不可能を意味します。
https://www.7key.jp/nw/routing/r_protocol/rip.html#timerRIPのようなディスタンスベクタ型のルーティングプロトコルでは、隣接ルータからアドバタイズを受けたルート情報の信頼性を確保するために、そのルート情報の有効期限を保持します。この有効期限の管理のために次の4つのタイマーが用意されています。
ルーティングアップデートの送信は、RIPでは標準で30秒間隔で行われます（IGRPでは90秒）。アップデートタイマーはその間隔を計るためのタイマーです。ルータはルーティングアップデートを送信する際、このタイマーを0にセットします。時間が経つにつれてこのタイマーはカウントされ、タイマーが30秒を示したとき、再度ルーティングアップデートを送信します。
隣接ルータから受信したルート情報をルーティングテーブルに加えた後、ある一定の時間を過ぎてもそのルート情報が送られて来ない場合は、そのルートに何らかの異常が発生したおそれがあります。そのルートの異常を調べるのが無効タイマーの役割です。ルータはルーティングアップデートを受信するたびに、以前受信したルート情報がそのアップデートに含まれているかどうかを確認し、確認ができたら無効タイマーを0にセットします。RIPでは標準で6回連続（IGRPでは3回連続）でルートが受信できなかった場合、そのエントリは無効になったものとみなしてホールドダウンタイマーを起動します。
RIP version1の仕様（RFC1058）では規定されていませんが、Cisco Systems社のルータではホールドダウンタイマーが実装されています。ホールドダウンタイマーが起動するのは、無効タイマーが上限に達したときや、宛先到達不可能を表すメトリックを受け取ったときなど、つまりそのルートがダウンしていると疑われるときです。ルートがダウンしたと疑われるとき、そのルートが無効になったことを全てのルータが認識できる程度の時間をホールドダウン時間と言います。ホールドダウンタイマーの上限は、RIPでは標準で180秒（IGRPで280秒）にセットされています。ホールドダウン状態ではルーティングテーブル上で"possibly down"と表示されますが、エントリは存在していますので、そのネットワーク宛に送信されたパケットはそのエントリに従ってルーティングされます（宛先ネットワークにそのパケットが到達するかどうかはわかりませんが）。
ルータはホールドダウン状態の間、ダウンしたと疑われるルートに関してメトリックが劣るか同等のものはすべて無視します。メトリックが優れるものを受信した場合は、新たなルートが発見されたものとみなしてホールドダウンタイマーをリセットします。ホールドダウンタイマーが上限に達した場合もリセットされます。
フラッシュタイマーはガーベージコレクションタイマー【Garbage Collection Timer】とも呼ばれます。フラッシュタイマーは無効タイマーと同時に起動し、RIPでは標準で240秒（IGRPでは630秒）で上限に達します。フラッシュタイマーが上限に達したルート、即ちフラッシュタイマーが上限に達するまでにアップデートを受け取ることができなかったルートは、ルーティングテーブルから削除されます。ただし、トリガアップデートを受け取るとフラッシュタイマーは0にセットされます。
RIP version1の仕様（RFC1058）では、フラッシュタイマーは120秒で上限に達すると規定されています。
あるエントリに対するルーティングアップデートを受信すると、無効タイマーとフラッシュタイマーがリセットされます。これは、定期的にアップデートを受信するたびに行われる動作です。ルーティングアップデートが途絶えると、無効タイマーが上限に達してそのエントリはホールドダウン状態となります。このときホールドダウンタイマーが起動されます。さらにその後もそのエントリに対するルーティングアップデートがなければフラッシュタイマーが上限に達し、そのエントリはルーティングテーブルから削除されます。
RIPの場合は無効タイマーとホールドダウンタイマーの上限がどちらも180秒です。よってホールドダウンタイマーが上限に達するよりも先にフラッシュタイマーが上限に達してしまいます。その時点でそのエントリはルーティングテーブル上から削除されますので、ホールドダウンタイマーも終了します。
https://www.7key.jp/nw/routing/r_protocol/rip.html#workRIPリクエストをはブロードキャストでUDPポート520から送られるのが一般的ですが、どの送信元ポートからでも送信をすることができます。送信元ポートが520であれば、RIPに能動的に関係しているホストのみが応答をします。送信元ポートが520以外であった場合は、その要求を受信した全てのRIPプロセスが応答をします。このことによって、管理のために隣接ホストにルーティング更新情報を送らない、ただ情報を受信するだけのホストからも応答を受信することが可能となります。
要求が受信されるとデータグラムに入っているエントリは順番に処理されます。エントリが1つしかなく、アドレスファミリー識別子が0、メトリックが16となっている要求には、ルーティングテーブル全体を応答することとなっています。また、要求の中にエントリがなければデータグラムは無視され、応答はなされません。エントリ数が1〜25であれば、全てのエントリがルーティングテーブルと比較され、ルートがあればそのメトリックがメトリックフィールドに入れられます。宛先ネットワークへのルートがルーティングテーブルになければ、メトリック16（無限大）がメトリックフィールドに入れられます。要求ルートに関する情報が揃うと、オペレーションフィールドの値を2（応答）とし、データグラムは要求元に返送されます。元の要求で使われた送信元ポートはこのデータグラムの宛先ポートとして使われます。
ルーティングテーブル全てが要求された場合は、スプリットホライズンの規則が適用されるのが一般的とされています。特定のルート情報が要求される場合はスプリットホライズンの規則は使われず、そのエントリがそのまま使われます。
応答を受信するのは、特定の要求に対して、通常の定期更新、トリガー式更新のいずれかの場合です。この応答がUDP520番ポート以外から送られてきた場合、受信ステーションはその応答データグラムを無視します。応答が有効であれば下図（図：Fig1）に示すチャートに従って受信側ステーションのルーティングテーブルが更新されます。
まず、広告されたメトリックにに、応答を受信したネットワークのコストを加算し、それを新たなメトリックとします。多くの場合、ネットワークに与えるコストは1とされていますので、インターネット上で隣接ルータへルートが渡されるごとにメトリックが1ずつ増えます。ただし、広告されたメトリックが16（無限大）の場合は、そのネットワークは既に到達不能と判断されますので、メトリックを更新する意味はありません。
広告されたネットワークへのルートがルーティングテーブルにない場合は、この更新でエントリを加えます。ただし、ここでもメトリックが16（無限大）の場合は無視されます。
広告されたネットワークへのルートがルーティングテーブルにない場合は、この広告を出したのがすでにあるルート情報を教えたルータと同じかどうかを調べます。そして、広告された情報がすでに知っているルート情報よりも優れている場合か、劣っていてもその情報を広告したのが元の広告を出したルータである場合は、新しい情報を採用します。広告された情報が既にある情報より劣っていれば、もともとある情報をそのまま使います。
元の広告を出したルータからのルート情報については、メトリックが同じであればタイマーをリセットしてルートが有効であることを示します。新しい宛先へのルート情報を教えられたか、又は既存のルートのメトリックが変更された場合は、変更フラグも設定し、トリガアップデートを送信しなければならないことを示します。既存のルートが到着不能となった場合はフラッシュタイマーが起動されます。この場合も変更フラグを設定し、トリガアップデートを送信しなければならないことを示します。
https://www.7key.jp/nw/routing/r_protocol/rip.html#begin初めて起動したルータが持っているのは最小限のルーティング情報だけです。もしかするとスタティックルートを持っているかもしれませんが、それ以外のルート情報についてルータは何も知りません。そこで、初めて起動した際にすべてのインターフェイスから要求をブロードキャストすることがほとんどです。この際、IPアドレスを0とし、メトリックを16としたリクエストを送信し、隣接ルータに対してすべてのルーティングテーブルを要請するものです。これによって完全なルーティングテーブルを最短時間で作成することができます。
https://www.7key.jp/nw/routing/r_protocol/rip.html#characteristichttps://www.7key.jp/nw/routing/r_protocol/rip.html#supplement広告