メインコンテンツまでスキップ

5. ルーティング実装の考慮事項 (Routing Implementation Considerations)

クラスフルネットワーク番号 (Classful Network Numbers) からクラスレスプレフィックス (Classless Prefixes) への変更により、IPv4アドレスの初期ビットパターンからネットワークマスクを推測することはできなくなりました。これは、ルーティング情報の保存と伝播方法に影響を与えます。ネットワークマスクまたはプレフィックス長 (Prefix Lengths) は、ルーティングプロトコルで明示的に伝達される必要があります。OSPF [RFC2328]、中間システム間システム (Intermediate System to Intermediate System, IS-IS) [RFC1195]、RIPv2 [RFC2453]、Cisco Enhanced Interior Gateway Routing Protocol (EIGRP) などの内部ルーティングプロトコル、およびBGP4外部ルーティングプロトコル [RFC4271] は、1990年代のクラスレスドメイン間ルーティングの展開の一環として開発または修正され、すべてこの機能をサポートしています。

RIP [RFC1058]、HELLO、Cisco Interior Gateway Routing Protocol (IGRP) などの古い内部ルーティングプロトコル、および Exterior Gateway Protocol (EGP) [RFC904] などの古い外部ルーティングプロトコルは、プレフィックス長/マスクの明示的な伝達をサポートしていないため、非常に限定されたスタブ構成以外ではインターネット上で効果的に使用できません。単純なレガシーエンドサイト構成ではそれらの使用が適切である可能性がありますが、それらは時代遅れと見なされ、グローバルインターネットに接続されたトランジットネットワークでは使用すべきではありません (SHOULD NOT)。

同様に、レイヤー3ネットワーク機器のルーティングおよび転送テーブルは、プレフィックスとプレフィックス長またはマスクの両方を保存するように編成される必要があります。レガシークラスA/B/Cネットワーク/サブネット規則に従ってルーティング/転送情報を編成する機器は、グローバルインターネットに接続されたネットワークで正しく機能することは期待できません。そのような機器の使用は推奨されません。幸いなことに、今日ではそのような機器はほとんど使用されていません。

5.1. ルート広告の規則 (Rules for Route Advertisement)​

  1. インターネットでの転送は最長一致ベース (Longest-Match Basis) で行われます。これは、ルーティングドメインに対してマルチホームされている宛先は、常にそのルーティングドメインに明示的に通知される必要があることを意味します (つまり、要約できません)。ネットワークがマルチホームされている場合、ネットワークの階層で「上位」にあるルーティングドメインへのすべてのパスは、「上位」ネットワークに知られている必要があります。

  2. 複数のより特定的なルートの集約ルートを生成するルーターは、集約ルートに一致するが、より特定的なルートのいずれにも一致しないパケットを破棄する必要があります (MUST)。言い換えれば、集約ルートの「ネクストホップ (Next Hop)」はヌル宛先 (Null Destination) である必要があります。これは、集約でカバーされている一部のアドレスに到達できない場合に、転送ループを防ぐために必要です。

障害時には、あるサービスプロバイダーからアドレス空間を取得しているが、実際には別のサービスプロバイダーを通じてのみ到達可能なサイト (つまり、サービスプロバイダーを変更したサイトの場合) への部分的なトラフィックルーティングが発生する可能性があります。これは、そのようなトラフィックが集約ルートによって広告されたパス沿いに転送されるためです。規則#2は、集約ルートの広告者がそのようなトラフィックを破棄することにより、パケットの誤配送を防ぎますが、「traceroute」やその他の同様のツールの出力は、より特定的なプレフィックスを広告しなくなったネットワークではなく、そのネットワーク内に問題が存在することを示唆します。これは、接続性の問題を診断しようとしている人々にとって混乱を招く可能性があります。詳細については、セクション6.2の例を参照してください。この認識された「問題」の解決策は、この文書の範囲を超えています。それは、ルーティング技術ではなく、ユーザー/オペレーターコミュニティのより良い教育にあります。

これらの規則に従う実装は、すべてのルーティング宛先に対して任意のネットワーク番号とマスクが受け入れられるように、一般化される必要もあります。唯一の未解決の制約は、マスクが左側で連続している必要があることです。プレフィックス 0.0.0.0/0 への縮退ルート (Degenerate Route) はデフォルトルート (Default Route) として使用され、すべての実装で受け入れられる必要があります (MUST)。さらに、ドメイン間プロトコルを介したこのルートの偶発的な広告から保護するため、このルートは、ルーターが明示的にそのように構成されている場合にのみ別のルーティングドメインに広告される必要があり、構成されていない「デフォルト」オプションとしては決して広告されません。

5.2. 規則の動作 (How the Rules Work)​

規則#1は、使用される転送アルゴリズムがルーティングプロトコルと実装全体で一貫していることを保証します。マルチホームネットワークは、それらがルーティングされるすべてのサービスプロバイダーによって常に明示的に広告されます。これは、それらが1つのサービスプロバイダーの集約の特定のサブセットである場合でも同様です (そうでない場合は、明らかに明示的に広告される必要があります)。「プライマリ」サービスプロバイダーがマルチホームサイトをその集約の一部として暗黙的に広告できるように思えるかもしれませんが、最長一致転送によりこれは機能しません。詳細は [RFC4116] に記載されています。

規則#2は、集約によりルーティングループが形成されないことを保証します。192.168.0.0/16 を持つ「親」プロバイダーによって 192.168.64/19 を割り当てられたサイトを考えてみてください。「親」ネットワークは 192.168.0.0/16 を「子」ネットワークに広告します。「子」ネットワークが 192.168.65.0/24 (その集約の一部) への内部接続を失った場合、192.168.65.1 宛ての「親」から「子」へのトラフィックは「子」の広告されたルートに従います。ただし、そのトラフィックが「子」に到達すると、子は転送ループが発生するため、ルート 192.168.0.0/16 を「親」に戻って従ってはなりません (MUST NOT)。規則#2は、「子」が、自身の集約ルートの1つに一致する宛先に対して、より特定的でないルートに従ってはならないと述べています (通常、これは、あるネットワークが別のネットワークに広告するすべての集約プレフィックスに対して「破棄 (Discard)」または「ヌル (Null)」ルートをインストールすることによって実装されます)。デフォルトルート (0.0.0.0/0) の処理は、この規則の特殊なケースであることに注意してください。ネットワークは、その集約広告の1つの一部である宛先に対してデフォルトに従ってはなりません (MUST NOT)。

5.3. プレフィックスフィルタ形式に関する注記 (A Note on Prefix Filter Formats)​

ルート通知を処理するシステムは、受信した情報がポリシー規則に従って受け入れ可能であることを検証できる必要があります。ルート広告をフィルタリングする実装は、フィルタ要素でマスクまたはプレフィックス長を許可する必要があります。したがって、以前は次のように指定されていたフィルタ要素:

accept 172.16.0.0
accept 172.25.120.0.0
accept 172.31.0.0
deny 10.2.0.0
accept 10.0.0.0

現在は次のようになります:

accept 172.16.0.0/16
accept 172.25.0.0/16
accept 172.31.0.0/16
deny 10.2.0.0/16
accept 10.0.0.0/8

これは、ネットワーク番号のクラスA/B/C分類によって暗黙的に示されていたネットワークマスクを明示的にしているだけです。プレフィックスと、同じビットパターンを持つすべてのより特定的なプレフィックスの一致を許可するようにフィルタリング機能を拡張することも有用です。幸いなことに、この機能は、インターネット上で使用される機器のほとんどのベンダーによって実装されています。

5.4. 集約の責任と構成 (Responsibility for and Configuration of Aggregation)​

通常の状況では、一連のプレフィックスを割り当てられたルーティングドメイン (または「自律システム (Autonomous System)」) は、それらのプレフィックスの集約に対する単独の責任を持ちます。通常の場合、ASは、内部ルーティングシステムに知られているより特定的なルートに基づいて集約ルートを生成するために、1つ以上のルーターに構成をインストールします。これらの集約ルートは、ルーティングドメインの境界ルーターによってグローバルルーティングシステムに広告されます。集約ルートと重複するより特定的な内部ルートは、グローバルに広告されるべきではありません。場合によっては、ASが別のASに集約責任を委任することを望む場合があります (たとえば、顧客がそのサービスプロバイダーに代わって集約ルーティング情報を生成することを望む場合)。そのような場合、集約は、第1のASから受信したルートと、それらのルートがどのように集約されるべきかを記述する構成されたポリシー情報と組み合わせて、第2のASのルーターによって実行されます。

あるプロバイダーは、明示的な合意なしに別のプロバイダーから受信したルートで集約を実行することを選択する場合があることに注意してください。これは「プロキシ集約 (Proxy Aggregation)」と呼ばれます。これは、ASが運搬して顧客や隣接ネットワークに伝播する必要があるルーティング状態の量を削減するための有用なツールになり得ます。ただし、プロキシ集約はトラフィックエンジニアリングにおいて意図しない結果を生み出す可能性もあります。AS 2と AS 3の両方が AS 1からルートを受信するが、AS 2はプロキシ集約を実行し、AS 3は実行しない場合に何が起こるかを考えてみてください。AS 2と AS 3の両方からトランジットルーティング情報を受信する他のASは、AS 1によって発信されたルーティング情報の一貫性のないビューを見ることになります。これは、AS 3の顧客およびAS 3からトランジットルートを受信する他の人々に対して、AS 3を通じてAS 1へのトラフィックの予期しないシフトを引き起こす可能性があります。プロキシ集約は、集約されたルートのソースまたは集約を提供する当事者のいずれとも関係のないインターネットの部分に対して予期しない結果を引き起こす可能性があるため、極めて慎重に使用する必要があります。

集約に結合されるルートの構成は、ルーティングポリシーの実装であり、手動で維持される情報を必要とします。ルーティング可能なプレフィックスのセットに対して維持される必要がある情報への追加として、集約構成は通常、集約されるIPv4アドレスのブロックの範囲を定義する1行または2行にすぎません。独自の集約を実行しているサイトは、割り当てられたアドレスブロックに対してそれを行っています。別のサイトに代わって集約を実行しているサイトは、集約を委任する合意があるため、この情報を知っています。ネットワーク管理者の最良の一般的な実践が互いに受け入れるプレフィックスのリストを交換することであると仮定すると、集約情報の構成は、大幅な追加の管理オーバーヘッドを導入しません。

集約ルートの生成は、通常、静的に指定されるか、集約ルート内に含まれるプレフィックスのアクティブな動的ルートを学習したことに応答して指定されます。そのような動的集約ルート広告が行われる場合、ルートが過度に追加または撤回されない (「ルートフラッピング (Route Flapping)」として知られる) ように注意する必要があります。一般に、動的集約ルート広告は、集約の少なくとも1つのコンポーネントが到達可能になったときに追加され、すべてのコンポーネントが到達不能になったときにのみ撤回されます。適切に構成された集約ルートは、非集約ルートよりも安定しているため、グローバルルーティングの安定性を向上させます。

実装上の注意: 「クラスD」(マルチキャスト) アドレス空間の集約は、この文書の範囲外です。

5.5. ルート伝播とルーティングプロトコルの考慮事項 (Route Propagation and Routing Protocol Considerations)​

CIDRの最初の展開前は、外部ルーティングプロトコル (つまり、EGPまたはBGP) を介して学習したルートを、サイトの内部ルーティングプロトコル (通常、OSPF、IS-IS、またはRIP) を通じて伝播することが一般的な慣行でした。これは、それらのプロトコルを通じて学習した宛先に送信されるトラフィックに対して、一貫性があり正しい出口点が選択されることを保証するために行われました。4つの進化的効果 - CIDRの登場、グローバルルーティング状態の爆発的な成長、BGP4の広範な採用、および完全なパス情報を伝播する要件 - が組み合わさって、その慣行を非推奨にしました。適切なパス伝播を保証し、AS間ルーティングの不整合を防ぐために、現在の推奨事項は、BGP4がAS内で実行されることです。

に最終更新