このペーパーでは、シスコが設計および開発したルーティング プロトコルの Interior Gateway Routing Protocol(IGRP)スイートを紹介します。このペーパーは技術紹介のための情報提供目的の文書です。プロトコル仕様や製品説明は含まれていません。
このドキュメントに特有の要件はありません。
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。
IGRP は、TCP/IP およびオープン システム相互接続(OSI)インターネットで使用されます。オリジナルの IP バージョンは 1986 年に設計および導入されました。これは IGP とみなされますが、ドメイン間ルーティング用の外部ゲートウェイ プロトコル(EGP)としても広く使用されています。IGRP ではディスタンス ベクター ルーティング テクノロジーが使用されています。その概念は、各ルータがネットワーク全体のすべてのルータ/リンク関係を検知する必要がないというものです。各ルータは、宛先を対応する距離とともにアドバタイズします。この情報を受信した各ルータは、距離を調整し、その情報を隣接ルータに伝達します。
IGRP での距離情報は、使用可能な帯域幅、遅延、負荷使用状況、およびリンク信頼性の組み合わせとして表現されます。これにより、最適なパスを実現するリンク特性の微調整が可能になります。
EIGRP は、IGRP の拡張バージョンです。IGRP と同じディスタンス ベクター テクノロジーが EIGRP でも使用されており、基礎となる距離情報も変更されていません。このプロトコルは、コンバージェンス プロパティと処理効率が大幅に改善されています。そのため、IGRP への既存の投資を保護しながら、アーキテクチャを改善できます。
このコンバージェンス テクノロジーは、SRI International での研究成果に基づいています。Diffusing Update Algorithm(DUAL)は、ルート計算中のどの時点でもループを発生させないために使用されるアルゴリズムです。これによってトポロジの変更に関係するすべてのルータが同時に同期できます。トポロジ変更の影響を受けないルータは、再計算から除外されます。DUAL を使用した場合のコンバージェンス時間は、既存の他のルーティング プロトコルのコンバージェンス時間に匹敵します。
EIGRP は、ネットワーク層プロトコルに依存しないように拡張されています。そのため、DUAL は、他のプロトコル スイートをサポートできます。
EIGRP には次の 4 つの基本コンポーネントがあります。
ネイバー探索/リカバリ
信頼性の高いトランスポート プロトコル
DUAL 有限状態マシン(FSM)
プロトコル依存モジュール
ネイバー探索/リカバリとは、ルータが直接接続されているネットワーク上で他のルータを動的に学習するために使用するプロセスです。また、ネイバーが到達不能または動作不能になっていることを検出するためにも使用されます。このプロセスでは、小さな hello パケットを定期的に送信するため、オーバーヘッドが低く抑えられます。hello パケットを受信している限り、ルータはネイバーがダウンせずに機能しているものと判定します。この状態が確認されると、ネイバー ルータはルーティング情報を交換できます。
信頼性の高いトランスポートは、EIGRP パケットをすべてのネイバーに確実に、順序どおりに配信します。これは、マルチキャストまたはユニキャスト パケットの混在送信をサポートします。EIGRP パケットには、確実に送信する必要があるものと、その必要がないものがあります。効率化のため、信頼性は必要時にのみ提供されます。たとえば、マルチキャスト機能を備えているマルチアクセス ネットワーク(イーサネットなど)では、すべてのネイバーに対して個別に hello を高信頼性で送信する必要はありません。したがって、EIGRP はパケットへの確認応答が不要であることを知らせる、レシーバ宛ての情報をパケットに格納し、単一のマルチキャスト hello を送信します。その他のタイプのパケット(アップデートなど)には、確認応答が必要であり、そのことをパケットで示します。信頼性の高いトランスポートであれば、保留中の未確認応答パケットがある場合、マルチキャスト パケットを迅速に送信できます。これにより、さまざまな速度のリンクが存在している場合でも、コンバージェンス時間が短く保たれます。
DUAL 有限状態マシンには、すべてのルート計算の決定プロセスが組み込まれており、すべてのネイバーによってアドバタイズされたすべてのルートが追跡されます。DUAL では、ループのない効率的なパスを選択するために、「メトリック」と呼ばれる距離情報が使用されます。さらに DUAL はフィージブル サクセサに基づいて、ルーティング テーブルに挿入するルートを選択します。サクセサは、宛先への最小コスト パス(ルーティング ループに関連しないことが保証されている)を持つ、パケット転送に使用される隣接ルータです。フィージブル サクセサはないが、宛先をアドバタイジングするネイバーがある場合、再計算が行われ、この結果、新しいサクセサが決定されます。ルートの再計算に要する時間によって、コンバージェンス時間が変わります。再計算によるプロセッサの負荷は大きくありませんが、必要でない場合は、再計算しないようにしてください。トポロジが変更されると、DUAL はフィージブル サクセサが存在するかどうかを確認します。フィージブル サクセサがある場合、検出されたいずれかのフィージブル サクセサを使用して、不要な再計算を防止します。フィージブル サクセサについては、後で詳しく定義します。
プロトコル依存モジュールは、ネットワーク層で、プロトコル固有の要件に対応します。たとえば、IP-EIGRP モジュールは、IP でカプセル化された EIGRP パケットを送受信します。IP-EIGRP は、EIGRP パケットを解析して、受信した新しい情報を DUAL に通知します。また、ルーティング決定を行うように DUAL に依頼します。その結果は IP ルーティング テーブルに格納されます。IP-EIGRP は、他の IP ルーティング プロトコルによって学習されたルートの再配布も行います。
ここでは、シスコの EIGRP 実装に関するいくつかの詳細情報を提供します。データ構造と DUAL の概念の両方について説明します。
各ルータは、隣接するネイバーに関する状態情報を保持します。新たに検出されたネイバーが学習されると、そのネイバーのアドレスとインターフェイスが記録されます。この情報は、ネイバーのデータ構造に保存されます。ネイバー テーブルには、これらのエントリが保持されます。プロトコル依存モジュールごとに 1 つのネイバー テーブルが存在します。ネイバーは、hello を送信する際に HoldTime をアドバタイズします。HoldTime は、ルータがネイバーを到達可能で稼働状態にあるものとして扱う期間です。つまり、hello パケットが HoldTime の間に受信されない場合、HoldTime は期限切れになります。HoldTime が期限切れになると、DUAL にトポロジの変更が通知されます。
ネイバー テーブルのエントリには、信頼性の高いトランスポート メカニズムに必要な情報も含まれます。確認応答とデータ パケットと照合するためにシーケンス番号が使用されます。ネイバーから受信した最後のシーケンス番号が記録されるため、順序の正しくないパケットを検出できます。また、ネイバーごとの再送信に対応するため、送信リストを使用してパケットがキューに入れられます。最適な再送信間隔を判断するために、ラウンド トリップ タイマーがネイバー データ構造で保持されます。
トポロジ テーブルにはプロトコル依存モジュールが入力され、DUAL 有限状態マシンで使用されます。トポロジ テーブルには、隣接ルータによってアドバタイズされたすべての宛先が含まれます。各エントリには、宛先アドレスと、その宛先をアドバタイズしたネイバーのリストが関連付けられます。ネイバーごとに、アドバタイズされたメトリックが記録されます。これは、ネイバーのルーティング テーブルに保存されているメトリックです。ネイバーがこの宛先をアドバタイズしている場合は、必ず、そのルートを使用してパケットを転送しています。ディスタンス ベクター プロトコルは、この重要なルールを常に遵守します。
また、宛先には、ルータがその宛先に到達するために使用するメトリックも関連付けられます。これは、すべてのネイバーからのアドバタイズされたメトリックのうちで最適なものに最適なネイバーへのリンク コストを加えた合計です。ルータは、このメトリックをルーティング テーブルに保存し、他のルータへのアドバタイズに使用します。
フィージブル サクセサがある場合、宛先エントリはトポロジ テーブルからルーティング テーブルに移動します。その宛先へのすべての最小コスト パスにより、セットが形成されます。このセットから、現在のルーティング テーブルのメトリックよりも小さなメトリックをアドバタイズしたネイバーは、フィージブル サクセサとみなされます。
フィージブル サクセサは、ルータから見ると、宛先に対してダウンストリームにあるネイバーです。これらのネイバーとその関連するメトリックは、転送テーブルに入力されます。
ネイバーによってすでにアドバタイズされているメトリックが変更されるか、ネットワークでトポロジが変更されるときは、フィージブル サクセサのセットを再評価する必要がある場合があります。ただし、これは、ルートの再計算とはみなされません。
宛先のトポロジ テーブルのエントリは、2 つの状態のいずれかになります。ルータがルートの再計算を実行中でない場合は、ルートがパッシブ状態とみなされます。ルータがルートの再計算を実行中の場合は、ルートがアクティブ状態となります。フィージブル サクセサが常に存在する場合は、ルートがアクティブ状態になる必要はなく、ルートの再計算は実行されません。
フィージブル サクセサが存在しない場合、ルートはアクティブ状態になり、ルートの再計算が実行されます。ルートの再計算では、まず、ルータがすべてのネイバーにクエリ パケットを送信します。隣接ルータは、宛先へのフィージブル サクセサがある場合に応答するか、またはルートの再計算を実行中であることを示すクエリを任意に返すことができます。アクティブ状態のときは、ルータはパケット転送に使用しているネクストホップ ネイバーを変更できません。特定のクエリに対するすべての応答が受信されると、宛先はパッシブ状態に移行でき、新しいサクセサの選択が可能になります。
唯一のフィージブル サクセサであるネイバーへのリンクがダウンすると、そのネイバーを経由するすべてのルートでルートの再計算が開始され、それらのルートがアクティブ状態になります。
EIGRP では 次の 5 つのタイプのパケットが使用されます。
hello/ACK
アップデート
クエリ
応答
要求
前述のように、hello はネイバー探索/リカバリのためにマルチキャストされます。これらは確認応答を必要としません。データのない hello も確認応答(ACK)として使用されます。 ACK は常にユニキャスト アドレスを使用して送信され、ゼロ以外の確認応答番号が含まれます。
アップデートは、宛先の到達可能性を伝えるために使用されます。新しいネイバーが検出されると、ネイバーがそのトポロジ テーブルを構築できるようにアップデート パケットが送信されます。この場合、アップデート パケットはユニキャストです。それ以外の場合(リンク コストの変更など)は、アップデートはマルチキャストです。アップデートは常に確実に送信されます。
宛先がアクティブ状態になると、クエリと応答が送信されます。クエリは、受信したクエリに対する応答として送信される場合以外、常にマルチキャストです。この場合、クエリを発信したサクセサにはユニキャストで返信されます。応答は常にクエリに対する応答として送信され、フィージブル サクセサが存在するためにアクティブ状態になる必要がないことをクエリの発信元に通知します。応答は、クエリの発信元にユニキャストで送信されます。クエリと応答はどちらも確実に送信されます。
要求パケットは、1 つまたは複数のネイバーから特定の情報を取得するために使用されます。要求パケットはルーティング サーバ アプリケーションで使用され、マルチキャストの場合もあれば、ユニキャストの場合もあります。要求の送信の信頼性は高くありません。
EIGRP には内部ルートと外部ルートの概念があります。内部ルートとは、EIGRP 自律システム(AS)の内部で生成されたルートです。 したがって、EIGRP を実行するように設定された直接接続ネットワークが内部ルートとみなされ、このルート情報が EIGRP AS 全体に伝達されます。外部ルートとは、他のルーティング プロトコルによって学習されたルート、またはルーティング テーブルにスタティック ルートとして存在するルートです。これらのルートは、その生成元のアイデンティティによって個別にタグ付けされます。
外部ルートには、次のような情報がタグ付けされます。
そのルートを再配布した EIGRP ルータのルータ ID
宛先が存在する AS 番号
設定可能な管理者タグ
外部プロトコルのプロトコル ID
外部プロトコルから取得したメトリック
デフォルト ルーティングで使用されるビット フラグ
例として、3 台の境界ルータを持つ AS について考えてみます。境界ルータとは、複数のルーティング プロトコルを実行しているルータです。この AS は、ルーティング プロトコルとして EIGRP を使用しています。2 台の境界ルータである BR1 と BR2 は Open Shortest Path First(OSPF)を使用し、もう 1 台の境界ルータである BR3 は Routing Information Protocol(RIP)を使用しているとします。
OSPF 境界ルータの 1 つである BR1 で学習されたルートは、条件付きで EIGRP に再配布できます。これは、BR1 で動作している EIGRP によって、その所属する AS 内部に OSPF ルートがアドバタイズされることを意味します。この場合、OSPF ルートのルーティング テーブル メトリックと同じメトリックとともにそのルートがアドバタイズされ、OSPF 学習ルートとしてタグ付けされます。router-idはBR1に設定されます。EIGRPルートは他の境界ルータに伝搬されます。RIP境界ルータであるBR3もBR1と同じ宛先をアドバタイズするとします。そのため、BR3はRIPルートをEIGRP ASに再配布します。これにより、BR2 では、そのルートに関する AS エントリ ポイント、最初に使用されていたルーティング プロトコル、およびメトリックを判断するために十分な情報が得られます。また、ネットワーク管理者は、ルートが再配布されるときに、特定の宛先に対してタグ値を割り当てることができます。BR2 はこの情報を使用して、ルートを使用したり、OSPF に再アドバタイズしたりできます。
ネットワーク管理者は、EIGRP のルート タギングを使用することで、ポリシーを柔軟に制御し、ルーティングをカスタマイズできます。ルート タギングは、一般によりグローバルなポリシーを実装したドメイン間ルーティング プロトコルが EIGRP と連携する中継 AS の場合に特に役立ちます。この連携によって、非常にスケーラブルなポリシーベース ルーティングが可能になります。
EIGRP は、IGRP ルータとの互換性とシームレスな相互運用性を提供します。これは、両方のプロトコルの利点を利用することが可能になるため、重要です。この互換性機能は、EIGRP を有効にするための「フラグ デー(互換性を確保するためにシステムを変更する日)」を必要としません。中核拠点で慎重に作業すれば、IGRP のパフォーマンスを低下させることなく EIGRP を有効にできます。
互換性機能には自動再配布メカニズムが組み込まれているため、IGRP ルートの EIGRP へのインポート、および EIGRP ルートの IGRP へのインポートが実行されます。両方のプロトコルのメトリックは直接変換できるため、各プロトコルが所属する AS で生成されたルートと同様に、両方のルートを容易に比較できます。また、EIGRP では、IGRP ルートが外部ルートとして扱われるため、タギング機能を使用してカスタム チューニングを行うことが可能です。
デフォルトでは、IGRP ルートの方が EIGRP ルートより優先されます。これは、コンフィギュレーション コマンドで変更でき、ルーティング プロセスを再起動する必要はありません。
次のネットワーク図は、DUAL をコンバージする方法を示しています。この例は、宛先 N にのみ注目しています。各ノードは N へのコスト(ホップ数)を示します。 矢印はノードのサクセサを示します。たとえば、C は A を使用して N に到達し、そのコストは 2 です。
A と B の間のリンクで障害が発生すると、B はそのネイバーに対してフィージブル サクセサが存在しなくなったことを通知するクエリを送信します。D はそのクエリを受信し、他にフィージブル サクセサが存在するかどうかを確認します。存在しない場合、D はルート計算を開始し、ルートがアクティブ状態になります。ただし、この場合、宛先 N に対し、C のコスト(2)の方が D の現在のコスト(3)よりも小さいため、C がフィージブル サクセサとなります。D はサクセサとして C に切り替わることができます。A と C はこの変化の影響を受けないため、これには関与しないことに注意してください。
次に、ルートが計算される例を示します。このシナリオでは、A と C の間のリンクで障害が発生したとします。C はサクセサが存在しなくなったことを検出しますが、他にフィージブル サクセサはありません。宛先 N に到達するためのアドバタイズされたメトリック(3)が C の現在のコスト(2)よりも大きいため、D はフィージブル サクセサとみなされません。C は宛先 N のルート計算を実行する必要があります。C は唯一のネイバーである D にクエリを送信します。D のサクセサは変更されていないため、D は応答します。D はルート計算を実行する必要はありません。Reply を受信した C は、すべての近接ルータで、N へのリンク障害に関する通知が処理されたことを認識します。この時点で C は、宛先 N までのコストが 4 である D を新しいフィジブル サクセサとして選択します。A と B は、このトポロジの変化の影響を受けず、D は単に C に返答するだけで済みます。
はい、EIGRP は IGRP と同じように設定します。ルーティング プロセスと、プロトコルが実行されるネットワークを設定します。既存のコンフィギュレーション ファイルを使用できます。
はい、debug コマンドには、プロトコルに依存しないものと依存するものの両方があり、プロトコルの動作を通知します。ネイバー テーブルのステータス、トポロジ テーブルのステータス、および EIGRP トラフィックの統計情報を表示する一連の show コマンドもあります。
IGRP で使用していた機能はすべて、EIGRP でも使用できます。特記すべき機能として、複数のルーティング プロセスがあります。IGRP と EIGRP の両方が動作する単一のプロセスを使用することも、両方が動作する複数のプロセスを使用することもできます。また、IGRP が動作するプロセスと、EIGRP が動作する別のプロセスを使用することもできます。これらのプロセスは、混在させることも統一することもできます。これにより、ニーズの変化に応じて、特定のプロトコルに対してルーティングをカスタマイズできます。
帯域幅の使用率の問題は、部分更新と差分更新の実装によって対処されてきました。そのため、トポロジの変更が発生した場合にのみ、ルーティング情報が送信されます。プロセッサの使用率については、フィージブル サクセサ テクノロジーにより、トポロジ変更の影響を受けるルータだけでルータの再計算を行うようになったため、AS の全体的なプロセッサの使用率が大幅に減少しました。さらに、ルートの再計算は影響を受けるルートでのみ実行されます。該当するデータ構造だけがアクセスと使用の対象となります。このため、複雑なデータ構造を検索する時間が大幅に短縮されます。
はい。IP-EIGRP は IGRP と同じ方法でルート集約を実行します。つまり、IP ネットワークのサブネットは他の IP ネットワークではアドバタイズされません。サブネット ルートは 1 つのネットワーク番号集約に要約されます。さらに、IP-EIGRP により IP アドレスのビット境界での集約を実行でき、ネットワーク インターフェイス単位で設定できます。
いいえ、単一の EIGRP プロセスはリンクステート プロトコルのエリアに類似しています。しかし、そのプロセス内では、どのインターフェイス境界でも情報のフィルタリングと集約が可能です。ルーティング情報の伝達を制限する場合、階層構造を構築するために複数のルーティング プロセスを設定できます。DUAL 自体がルート伝達を制限するため、通常は複数のルーティング プロセスを使用して構造上の境界を定義します。