Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

インターネット交換ポイントの概要

 

VPLS や EVPN のようなレイヤー 2 MPLS ベースのサービスであるインターネット交換ポイント (IXP) はレイヤー2ネットワークです。たとえば、境界ゲートウェイプロトコル (BGP) プロトコルを使用してインターネットサービスプロバイダ (Isp) 間の相互接続を容易にし、Exchange のルーティングにも利用できるようにします。詳しく.

中核となるのは、IXP は基本的に、相互接続された複数のスイッチを含む1つ以上の物理的な場所で、ネットワーク間のトラフィックを移動します (通常、IXP コンテキストのメンバーと呼ばれることになっています)。ネットワークは、 Ixp lanまたはピアリング lanと呼ばれています。参照Figure 1してください。

メンバーは、さまざまな充電方式を通じて物理インフラと関連サービスを保守するコストを共有していますが、ほとんどすべての場合において、ポート速度とメンバーが使用するポート数に応じて、メンバーシップのコストは月額で固定されています。

Figure 1: IXP LAN
IXP LAN

IXP 上の2つのメンバー間のトラフィック交換は、BGP ルーティング構成 (ピアリングセッション) によって容易になります。メンバーは、ピアリングの関係–を通してルートをアナウンスします。または、そのアドレスへのルーティングや、接続先の他のネットワークのアドレスへのルーティング (顧客など) を行います。

相手側からピアリング関係までは、ルートフィルタリングを適用して、これらのルートを受け入れ、それに従ってトラフィックをルーティングし、そのルートを無視して、他のルートを使用してこれらのアドレスに到達させることができます。

メンバーに提供またはフィルタリングの対象とする広告については、1日で詳しく説明します。BGP ルーティングセキュリティの導入 (以下を参照してください)。https://www.juniper.net/us/en/training/jnbooks/day-one/deploying-bgp-routing-security/).

インターネットの交換ポイントの経済性

IXP の目的は、上流の伝送プロバイダを介して ISP が提供するトラフィックの量を削減することです。そのため、その他の点では、1ビット単位のトラフィックの平均配信コストを削減できることがあります。さらに、利用可能なパス数が増加することで、ルーティングの効率とフォールトトレランスが向上します。さらに、さらに重要な目標として、遅延を短縮し、ネットワークパスを短縮し、冗長性を向上させることもできます。

IXPs は、economists がネットワーク Externality 効果(https://en.wikipedia.org/wiki/Network_effect) を呼び出す方法の特性を示しているか、製品またはサービスの価値が製品またはサービスのユーザー数に比例しています。インターネットの交換は、この効果の特殊なケースです。交換ポイントの価値は、参加者の数ではありませんが、ルートの数や一意性、トラフィックの量など、わずかに複雑な計算になります。Ixp の価値は、ISP によってピアリング関係が IXP から交換されるトラフィック量に比例するため、IXP の値は、『 Figure 2the network externality graph に従っています。

Figure 2: IXP の価値
IXP の価値

Figure 2.は、i XP (Vcap) の価値のプロットを、参加者数の機能として示しています。さらに多くの参加者が exchange ポイントに接続するにつれて、参加者は互いに相手と通信できるようになります。参加者の視点から見ると、潜在的な各ピアによって、交換ポイントの価値が増していきます。

ピアリング関係

Bilateral のピアリング(2 つのメンバー間でネゴシエートおよび確立) が、以前はルートを交換する最も一般的な方法であったので、高密度相互接続によって生じるオーバーヘッドによって大規模な ixps のメンバーの運用面で大きな問題が発生する可能性があります。

複数の相互接続は、 “外部のブローカリング”システムを使用してメンバー間を接続する方法です。一般的にはルートサーバーと呼ばれ、通常は ixp で管理します。各マルチ側面相互接続の参加者 (ルートサーバークライアントと呼ばれる) は、外部境界ゲートウェイプロトコル (ebgp) を使用してルートサーバーへのルートをアナウンスします。その後、ルートサーバーは、この情報を接続されている各ルートサーバークライアントに透過的に転送します。

ルートサーバーとは

組織がメンバーになるためのエントリの障壁があるため、通常、IXP でピアリングを開始するのは非常に低いものです。少なくとも、1台の物理またはリモート (バックホール) ポートが IXP ピアリング LAN に接続され、IX LAN サブネットから IP アドレスが割り当てられている必要があります。ピアリング LAN 上の他者との間で BGP ピアリングを構成することが可能になります。

そのためには、ピアする相手との BGP ピアリングセッションを手動で設定する必要があります。これをbilateral 相互接続と呼びます。つまり、ユーザーとピア間にセッションが1回あり、ユーザーと特定のピア交換ルート通知のみが存在することを意味します。

多数 (100 以上) のメンバーを持つ大規模な IXP を想像してみてください。このような方法は、急速に煩雑になります。特に、インターネットルーティングレジストリなどに基づいて、適切なルートアドバタイズメントでピアごとにフィルタリングする場合:https://en.wikipedia.org/wiki/Internet_Routing_Registry)、プリフィックス、パスなどをお勧めします。Brainer が利用できるようになると、より簡単な解決策を使用することはできません。

Figure 3: EBGP (IXP LAN でルートサーバーなし)
EBGP (IXP LAN でルートサーバーなし)

各メンバーとの個別の EBGP セッションで、10 ~ 100 mb (大規模な IXPs Xps の一部または複数の接続を持つメンバーを含む) を構成および維持できないようにするには、2つのセッションが必要な場合に、ルートサーバーを使用するのが最も賢いオプションです。ルートサーバーは、通常、IXP によってそのメンバーへのサービスとして提供されます。

ISP’のルーターとルートサーバー間の1つの BGP セッションでは、ixp のその他すべてのメンバーに対してルートをアナウンスして受信する必要がありFigure 4ます (図を参照)。当然ながら、ルーティング情報を交換できるのは、ルートサーバーとの BGP セッションを持つメンバーともなります。そのため、IXP にプレゼンスを持つメンバーの間で完全なメッシュピアリングを提供することもできます。

Isp によっては、ルートサーバーセッションのみに依存していますが、それを IXP ファブリック上の既存の EBGP peerings のバックアップとして使用することもあります。ほとんどの IXPs は、冗長化されたルートサーバーを保有し、両方のメンバーにピアを持たせることを提案します。

IXP’のルートサーバーとのピアリングでは、コミュニティなどのメリットを活用してフィルタリングを行うことができます。たとえば、送信元の国または元のデータセンターなどです。

Figure 4: EBGP (ルートサーバーを使用した IXP LAN)
EBGP (ルートサーバーを使用した IXP LAN)

ルートサーバーには次のものがあります。

  • EBGP ルートリフレクションは、IXP の各サービスプロバイダに対してカスタマイズされたポリシーサポートを提供します。

  • 構成の複雑さを軽減 (このため、数 BGP のセッションを数百ではなく管理できます)。

  • 各メンバールーターの CPU とメモリの要件を削減します。その場合でもすべての接頭番号を’受け取りますが、すべての個別 BGP ピアリングセッションを必要としているわけではありません。

  • 個別化されたピアリング契約によって発生する管理オーバーヘッドコストを削減します。

  • その他のフィルタオプション (IRRdb、RPKI、定義済みの BGP コミュニティ) を使用することなく、それを実装する必要はありません。

  • IXP 経由でトラフィックを1日目に送信して受信できます (個々の peerings が整理されるまで待つ必要はありません)。

  • 考えられるバックアップパス他のメンバーへの BGP セッションが非アクティブになると、ルートサーバーから学習したルートを介してメンバーネットワークにアクセスできる可能性があります。

Note

ルートサーバー自体は実際のトラフィック転送には関与せず、ルーティング情報 (パス、ルート、コミュニティー、次ホップなど) のみを提供します。その視点から見ると、転送ハードウェアが不要になるため、ルートサーバーは、物理ボックスではなく仮想マシン (VM) またはコンテナに簡単に使用できます。また、ルートサーバーとのピアリングでは、その他すべてのルートサーバーの参加者からのすべてのルートを受け付ける必要があるとは限らないので、すべてのルートを他のすべてのメンバーにアドバタイズする必要があります。どのようにして構成していますか。を読む…

BGP ルーティング情報ベース (リブ)

本書全体では、さまざまなタイプのルーティング情報ベース (リブ) について説明しています。この段落は、そのために用意されています。一般に、リブはルーティング情報を保持していますが、BGP スピーカー内には3つの突起部分が関連しています。

  1. 形容詞-イン: 受信 BGP 更新メッセージから学習したルーティング情報を格納します。これには、BGP の判断プロセスへの入力として利用可能なルートが含まれています。

  2. (リブ): [形容詞-インところに保存されたルーティング情報にインポートポリシーを適用した後、ルーティング情報を格納します。

  3. 形容詞-アウト: ピアへの広告用に選択された情報を格納します。形容詞-アウトに格納されたルーティング情報は、送信更新メッセージとそのピアへの通知に使用されることになります。

まとめると、この形容詞では、ピアから受信した未処理のルーティング情報が含まれています。各リブには、ローカルの BGP スピーカー’s 意思決定プロセスによって選択されたルートが含まれており、各形容詞は、更新メッセージによって特定のピアへのアドバタイズメント用ルートが含まれています。

ルートリフレクタ対ルートサーバー対ルートコレクター

わかりやすくするために、このガイドと同じページにいることを確認するために、ルートリフレクタ’、ルートサーバー、ルートコレクターを定義してみましょう。ルートリフレクタとルートサーバーの主な違いは、ルートリフレクタの IBGP セマンティクスとルートサーバーで必要とされる EBGP セマンティクスにあります。ルートコレクターは、ユニークなケースです。

Route Reflector

ルートリフレクタは、多くの場合、IBGP スピーカー間でセッションのフルメッシュを必要としないようにするために使用されます。ルートリフレクタは、IBGP セマンティクスを維持する’ために、ピアのアナウンスを別のピアに反映するタイミングを認識している必要があります。ルートリフレクタは、その Loc の中の最適なパスをすべてのクライアント (そのルーターが学習したものを除く) に送信します。通常、ルートリフレクタは属性を変更しないので、 next-hop-selfノブまたはローカルに構成されたポリシーですが、これは IBGP のデフォルトの動作です。

Route Server

ルートサーバーは、透過的 (属性は変更されない) と同様の役割を果たしますが、この場合、EBGP スピーカーでは、独自の (プライベートな) ASN をアドバタイズルートに付加することができないようにする必要があります。

また、そのクライアントに固有のポリシーを適用できる、クライアント Loc 単位の各クライアントに固有のリブも保持します。クライアントは、グローバルな Loc からではなく、そのリブから更新を取得します。

Route Collector

パケットを転送したり、誰にもプレフィックスを知らせたりすることはないため、私たちの最中にはルートコレクターが出ています。その目的は、その名前が何であるかを明らかにすることで、ルーティング情報を収集することです。このようにすることで、ルートコレクターとそのアクセサリツール‘は、ネットワーク’‘’のポイントで認識されるルーティング情報のパブリックビューを提供することを目的としたガラスのように見えます。IXP のコンテキストでは、ルートコレクターによって提供される情報は、以下に関する有用な情報を提供します。

  • IXP のメンバーは、BGP フィルターの機能を確認します。

  • 将来のメンバーへの参加価値の評価

  • トラブルシューティングを目的とした運用コミュニティーです。

今後は、本書に記載されているルートサーバーについて説明します。

ルートサーバー属性の透過性

ルートサーバーがブローカリングサービスを主に実行するため、属性の変更によって、ルートサーバークライアントは、受信したプレフィックスの到達可能性情報に対して BGP の判断プロセスを変更し、それによって exchange の意図したルーティングポリシーを変更することができます。参加者. (詳細については、Juniper のテクニカルライブラリを参照してください。 https://www.juniper.net/documentation/en_US/Junos/topics/reference/general/routing-protocols-address-representation.html)

通常の EBGP ルート処理ルールとは異なり、ルートサーバーは既知の BGP 属性を (明示的に設定されている場合を除き) デフォルト  で更新せず、サーバークライアントの1台から受信した後、他のクライアントに再配布することはありません。ローカルの IXP オペレータの構成によって適用される場合を除き、オプションで認識および認識できない BGP 属性は、推移性または非推移性を問わず、ルートサーバーによって更新もされないため、他のルートサーバークライアントに渡されます。よく知られているのは、次のような属性です。

  • Next_Hop 属性

  • AS_Path 属性

  • Multi_Exit_Descriminator

  • コミュニティー

ルートサーバーの導入でのパス非表示の軽減

従来の bilateral 相互接続モデルでは、サードパーティーの exchange 構成要素に対するクライアントごとのポリシー制御が、その参加者との bilateral 相互関係に関係していないか、または BGP に送信フィルタリングを実装することによって実現されます。セッションをその参加者に向かいます。しかし、複数の相互接続環境では、ルートサーバーのみがルートサーバークライアントの方向に発信フィルタリングを実行できます。ルートサーバークライアントは、ルートサーバーに依存して、送信フィルタリングを実行します。

デフォルトの BGP 決定プロセスに従った場合、複数のルートサーバークライアントから同じプレフィックスがルートサーバーにアドバタイズされると、ルートサーバーは、接続されているすべてのクライアントに対して、単一のパスを選択して伝達します。しかし、ルートサーバーが、特定のルートサーバークライアントに到達するために、計算された最適なパスをフィルターするように設定している場合、ルートサーバーによって受信された代替パスがポリシーである可能性がありますが、そのクライアントはそのプレフィックスのパスを受け取りません。そのクライアントに準拠します。この現象は、パスの隠ぺいと呼ばれています。

4つの顧客ルーター Figure 5で示された例を使用して、4つの異なる BGP 自律システム (AS) で exchange ルートを C [1-4] に示します。AS64496 の C1 は、AS644967 の C2 でプレフィックス情報を直接交換するのではありません。 IXP では AS64498 の C3 を使用しませんが、AS64499 の C4 と相互接続するだけではありません。AS64496、AS64497、AS64498、AS64499 の線は、ダイレクト (bilateral) EBGP セッションを介して、またはルートサーバー (複数の場合) を使用しているかにかかわらず、相互接続関係を表します。

Figure 5: IXP でのパスの非表示
IXP でのパスの非表示

AS64497’と AS64499 の両方からルートサーバーにプリフィックスが広告され、ルートサーバー上の BGP の意思決定プロセスに従って、AS64497 経由のルートが適切だったとしましょう。すべて問題なく、プレフィックスが到達可能になります。この例外は、AS64497’s policy がルートサーバーから AS64496 へのパスを送信できなかった場合に発生します。 AS64496 は、ルートサーバーが AS64499 を通じて有効な代替パスを受信している場合でも、このプレフィックスへのパスを受信することはありません。これは、すべてのクライアントに対して、ルートサーバー上で BGP 決定プロセスが1回だけ実行されるために発生します。

ルートサーバー環境では、パスの隠ぺい (https://tools.ietf.org/html/rfc7947#section-2.3.2) を緩和するいくつかのオプションが用意されていますが、 Figure 6 Junos OS は複数のルートサーバークライアントのリブ (and and https://tools.ietf.org/html/rfc7947#section-2.3.2.1) を採用しています。Juniper ルートサーバーの BGP 実装では、クライアント側のリブを使用して、プレフィックスへのパスの各セットに対して、クライアントごとの最適なパス計算を実行します。この場合、「形容詞-イン」と「クライアント単位」の間に実装されているパスフィルタリングがあります。詳細については、このガイドの後半で詳しく説明します。

Figure 6: Junos Loc 実装
Junos Loc 実装

ルートサーバーの導入のアーキテクチャ

ここでは、IXP 環境でルートサーバーを設定して運用する方法について、概念的なアイデアを示します。

BGP コミュニティーを使用したルートサーバークライアントポリシーごと

ポリシー制御は、通常、BGP コミュニティーを使用して処理されます。ルートサーバーに送信されるプレフィックスは、特定の標準 BGP コミュニティー (https://tools.ietf.org/html/rfc1997)、拡張コミュニティー (https://tools.ietf.org/html/rfc4360)、または大規模なコミュニティー (https://tools.ietf.org/html/rfc8092) 属性でタグ付けされており、ixp とすべての ixp メンバーの間で合意した事前定義された値に基づいています。現在、IXPs 全体でコミュニティの使用に関して相互に合意した標準はありませんが、次のような標準を定義するための作業がいくつか行われています。https://tools.ietf.org/html/draft-adkp-grow-ixpcommunities-00.

この例では、説明の目的で標準のコミュニティーを使用しています。拡張または大規模なコミュニティーを使用すると、メリットが得られます。

BGP ルートは、コミュニティの価値に応じて、他のすべてのクライアント、クライアントのサブセット、またはクライアントに伝達されないことがあります。このメカニズムにより、ルートサーバーのクライアントは、ルートサーバーに対して、クライアント別のエクスポートルーティングポリシーを実装するよう指示できます。例として、IXP のメンバーは、ルートサーバーを介しTable 1てコントロールポリシーを制御するために、に示されているルートにタグを付けている場合があります。

Table 1: 標準 BGP コミュニティーの例: クライアントごとのポリシーを制御する

ポリシーの説明

BGP コミュニティー

特定のピアへのルートのブロックアナウンス

0:<peer-as>

特定のピアへのルートのアナウンス

> as > として < rs: < ピア

すべてのピアへのルートのブロックアナウンス

0:<rs-as>

すべてのピアへのルートのアナウンス

> として < rs-< rs-as >

冗長性

IXP ルートサーバーの実装の目的は、信頼性の高い到達可能な通信事業者サービスを提供することです。そのため、 Figure 7ixp operators は通常、複数のルートサーバーを導入します (を参照)。

BGP セッションが特定のルートサーバー上の特定の IXP メンバールーターに対しては停止していても、その他のルーティングサーバーには存在しない場合、到達可能性があることを確認するには、ルートサービス間でルートをアドバタイズすることをお勧めします。このイベントは非常にまれな場合もあります’が、ルートサーバーベースのサービスを提供する場合には慎重に検討する価値があります。

Figure 7: 冗長構成のルートサーバーの導入
冗長構成のルートサーバーの導入

ただし、このスタイルの冗長ルートサーバーの導入によって、ルートサーバー間のセッション管理、および Junos OS パス緩和手法に関連するインスタンスインポート/エクスポートポリシーの複雑さが少し複雑になる場合があります。でFigure 7は、このような複雑さを、転送されていないルーティングインスタンス (nfri) BGP セッションおよびポリシーの形で示しています。そのため、これは慎重に評価する必要があります。ほとんどの IXPs では、2つの独立したルートサーバーのセットを運用しています。これは、冗長性と複雑さのバランスが最適になると考えられます。

ルートサーバーのセキュリティに関する考慮事項

以下の基本的な EBGP のベストプラクティスは、セキュリティ上の検討事項を対象としています。

Generalized TTL Security Mechanism (RFC3682)

GTSM は、ルーター’の制御プレーンを CPU の使用率ベースの攻撃から保護するように設計されています。GTSM は、プロトコル peerings の大部分は、IX LAN 上の EBGP ピアのように、隣接しているルーター間で確立されているという事実に基づいています。TTL スプーフィングは非常に不可能であるため、予想される TTL 値を基にしたメカニズムは、ネットワーク外部からのプロトコルパケットに基づいて、シンプルで合理的なインフラストラクチャ攻撃からの防御を実現できます。

Session Authentication (RFC2385)

典型的な IXP ピアリング LAN は、1つの大規模レイヤー2ファブリックを形成する複数のスイッチで構成されています。このアーキテクチャのマイナス面は、MAC や IP アドレスを‘スプーフィング’すること’で、他のメンバー s BGP セッションをハイジャックするのがかなり簡単であるということです。IXP では、特定の MAC アドレスのみを使用するようにメンバーを制限するなど、アクセスポートにフィルターを導入すること’をお勧めします。

Securing BGP Sessions (MD5/TCP-AO)

BGP セッション自体を保護することはセキュリティの追加レイヤーであると考えられており、ピアリングと考えている相手との間でピアリングを行っていることを確認します。

MD5 は、BGP のセキュリティを強化する TCP 拡張です。TCP セグメントで MD5 (https://tools.ietf.org/html/rfc1321) ダイジェストを実行するための、新しい tcp オプションを定義しています。このダイジェストは、そのセグメントの署名と同じように動作し、接続エンドポイント (ピア) にのみ知られている情報を組み込みます。BGP は TCP をトランスポートとして使用しているため、MD5 を使用することで、BGP 上の特定のセキュリティ攻撃の危険性が大幅に減少します。

しかし、1996では MD5 の設計に問題が発見されましたが、2004では MD5 がコリジョンによる耐性ではないことが示されていました。したがって、MD5 は推奨されていないため、適切でhttps://en.wikipedia.org/wiki/MD5#Securityはないと考えられています。しかし、これはまだ広く使用されています。今日では、TCP 認証オプション (RFC5925 など) など、より優れた代替手段を利用できます。https://tools.ietf.org/html/rfc5925)。残念ながら、これまで多くのネットワークベンダーによって実装されているわけではありません。

Maximum Prefix Limits

ピアから受け付けられるプレフィックスの数を制限することは、ルーティングやポリシーの誤りが原因でルートサーバーを故意または意図せずに過負荷にすることを防ぐための最もシンプルな方法の1つです。この制限の目的は、最終的なフェイルセーフとして機能することです。インポートポリシーが失敗した場合、EBGP セッションを停止すると、 “不正”が発生したという警告が送信されます。

プレフィックスの最大“数を定義する際には、 ”いくつかの点について検討する必要があります。これは、インポートポリシーや BGP に送信される前の受信プリフィックスの最大数です。 best-pathが実行されるか、またはインポートポリシーが適用された後に受け入れられるプレフィックスの最大数と BGP best-pathが計算されますか?

さらに、最大の価値についてさまざまな推奨事項があります。たとえば、必要なプレフィックス’数の10% は IX メンバールーターから得られるものですか? 問題は、これらの強い制限が設定されている場合、それらが適切に配置されていることを忘れてしまうため、プレフィックスの急激な飛び越しが発生した場合にセッションが誤ってリセットされるということです。

したがって、最大値は誤って防御することのない十分な価値があるだけでなく、そのままでも、完全なルーティングテーブルを使用していることを確認するまでは十分ではありません。以下のような提案があります。

  1. 予想されるルート数に10倍を乗算します。

  2. 対数スケールを使用して、適切な制限を導きます。

  3. セッションあたりの最大数を監視、学習、変更するには、外部のアプリケーションやコントローラーを活用します。このソリューションの詳細についUsing a cRPD-based Route Serverに関する章をご覧ください。

Table 2: 最大プレフィックス値の例

必要なルート数

シンプル (両) 最大値

ログ (n) 最大値

10

100

100

1,000

10,000

3,000

50,000

500,000

234,500

アウトバウンド最大’プレフィックスフィルターを適用するのは、現在広く使用されているテクニックではあり“ませんが” 、 “fat フィンガーのために完全なテーブルをリークするのを防ぐのに役立つ可能性があります。”

受信フィルタリングと同様に、最大プレフィックスは、他方“の側でミス”が発生‘した場合’に備えて最新のフェイルセーフであると見なされるため、他のサイドの hurting の防御として考慮することもできます。

現在、IETF は、プレ/ポスト“の最大プレフィックス数”制限を標準化するために、BGP 最大プレフィックス制限と呼ばれるドラフトで作業を行っています。https://datatracker.ietf.org/doc/draft-sa-grow-maxprefix/.

多くの場合、その他のパラメーターとして、最大のプレフィックス制限を設定することができます。これは、通常、自動化した方が迅速に変化できるためです。たとえば、あるメンバーが別のメンバーを購入したり、新しい顧客をネットワークに接続したりする場合、更新する必要があるフィルターは多数あります。これ’は、デフォルトの Free ゾーン (dfz) でネットワークを運用していることです (以下を参照してください)。https://en.wikipedia.org/wiki/Default-free_zone)最新の PeeringDB (https://www.peeringdb.com/) プロファイルを保持します。多くのネットワークでは、すでに PeeringDB の情報を使用してフィルターを自動的に作成しています。たとえば、Python を使用してピアリングプロセスの一部を自動化する方法については、以下のページでご覧いただけます。https://github.com/coloclue/keesと at https://github.com/coloclue/kees/blob/master/peering_filtersです。

Default EBGP Route Propagation Behavior Without Policies (RFC8212)

デフォルトでは、多くの BGP スピーカー (ルーター) は、その相手との間でルートアナウンスをアドバタイズし、受け入れます。この日付はインターネットの初期の時代に戻ります。通信事業者は、すべてのネットワークを相互に接続できるように、ルーティング情報を送信することを許可されていませんでした。インターネットがますます相互接続されているため、問題のある BGP スピーカーが発生する可能性があるため、グローバルルーティングテーブルやインターネットにとっても重大なリスクが発生します。

RFC8212 (https://tools.ietf.org/html/rfc8212 ) では、このような状況に対処するために、顧客や同僚などの ebgp セッションに対して BGP インポートポリシーとエクスポートポリシの両方を明示的に設定する必要があります。この仕様に従った BGP スピーカーは、EBGP セッションでルートを使用したり送信したりすることはありません。特に設定されている場合を除きます。言い換えると、ルーティング情報を近傍に明示的に提供するためのポリシーが用意されています。

ルートサーバーによるクライアントプレフィックス検証の数

多くの IXPs は、すべてのルートサーバー上で受信したプレフィックスを検証します。検証は、インターネットルーティングレジストリ (IRR) またはルートオブジェクト認定 (ROA) オブジェクトの有無に基づいています。ルートオブジェクトをベースとした有効な発信元と有効なプレフィックスのリストは、経路リストとして、ルーティングフィルターリストまたはプレフィックスリストの形式で構築されます。ROAs が見つからないために、有効なルートに関する特定の通知が拒否されることがよくあります。IXP members PeeringDB record 内の有効な AS が検索されます。有効なセットが見つからない場合、多くの場合、メンバーの ASN のみが使用されます。

Table 3以下の例では、入口検証の結果に基づいた、標準的なコミュニティーベースのタグ付けについて説明します。

Table 3: 入口標準のコミュニティーベースタグ付けの例

ポリシーの説明

BGP コミュニティー

接頭辞が、セットとし’て発表されたとして表示

<rs-as>:650010

接頭辞は、/セットとし’てアナウンスされたとしては存在しません。

<rs-as>:650010

プレフィックスは設定時の有効な発信元です

<rs-as>:650012

プレフィックスには、設定中の有効な発信元がありません

<rs-as>:650013

プレフィックス検証はしばしば行われ、IXP メンバーはそのプレフィックスに設定されているコミュニティを確認し、ルートサーバーまたはルートコレクターの調査結果を検証することができます。送信時に、検証に失敗したフィルタリングされたプリフィックスは拒否します。一部の IXPs のメンバーは、フィルター処理されていない一連のプリフィックスを受信することを希望しています。このことは、明らかな理由では推奨されていません。’ルーティングテーブルに無効なルーティング情報を保持することは、適切な根拠ではありません。

RPKI を使用した BGP の発信元検証

グローバルルーティングテーブルのルートアドバタイズの大部分が無効になっているか、有効なルート送信元承認 (ROAs) (https://www.ripe.net/manage-ips-and-asns/resource-management/certifi/resource-roas management #---route-Origin/authorisations--) が見つかりませんでした。この NIST rpki モニターには、以下のように表示されることがあります。https://rpki-monitor.antd.nist.gov/. このガイドを執筆していますが、2019年6月より、0.74% ルートは無効で、グローバルルーティングテーブル ROAs 86.32% が見つかりませんでした。もちろん、これらの数値は可能な限り早くダウンする必要があります。

最も一般的なルーティングエラーは、ポリシーエラーが発生した場合、またはプレフィックス (fat フィンガー) が誤って発生した場合、またはユーザーが所有者でない IP プレフィックスを故意に知らない場合、または RIR データベースで有効なルーティングオブジェクトを使用せずに特定のルートをアドバタイズすることを意味します。後者の場合、BGP ルーターは、特定のルート“を”より簡単に宣言し、正しいルート上で優先させることができます。これは、IP スペースの rightful 所有者のネットワークにつながるわけではありません。この問題に対する (部分的な) 回答として、リソース公開鍵インフラ (RPKI) を使用した送信元の検証によって、BGP 発生元の検証が提供されます。回答しようとしている質問は以下のとおりです。“この特定のルートアナウンスはアドレススペースの正当な所有者によって承認されていますか?

RPKI により、通信事業者は、ルートアナウンスに関する暗号署名文を作成できます。これらの明細書は、route origin authorization (ROAs) と呼ばれています。ROA は、特定の IP プレフィックスを発信 (アドバタイズ) する権限を持っています。さらに、AS がアドバタイズを許可されているプレフィックスの最大長を決定することもできます。この情報に基づいて、ルーターで基準を導入した他のネットワークは、受信した広告が有効または無効であるかどうかを検証し、その情報を使用してルーティングの決定を下すことができます。

ネットワークを接続するだけでなく、IXP はインターネットの安全性と安定性を維持する責任を持っています。その視点から、ルートサーバーでの発信元検証を展開するのは brainer ですが、どの方向 (インバウンドまたはアウトバウンド) で RPKI を導入しようとしているのかを検討する必要があります。理想的には、悪意のある広告をドロップすると、ネットワークまたはこの場合はルートサーバーを入力したときに発生します。しかし、これにより、ルートサーバーにアドバタイズされているルートを見ることができなくなるため、トラブルシューティングが困難になります。

顧客が、ルートサーバーがプレフィックスを受信したかどうかを確認するためには、そのような情報を使用する必要がある’場合、その結果を取得するには、「形容詞で」と「リブ」の間でフィルタリングを行う必要があります。

そのため、実際には、ルートサーバーが顧客に無効なルートをアドバタイズしないようにするために、外部に入力する広告を受け入れて、形容詞を入力するときにフィルター処理を適用することが考えられます。

Note

RPKI の詳細については、本書の範囲外です。本書では、書籍の Day One の詳細について説明しています。Https://www.juniper.net/us/en/training/jnbooks/day-one/deploying-bgp-routing-security/のルーティングセキュリティhttps://www.juniper.net/us/en/training/jnbooks/day-one/deploying-bgp-routing-security/導入 BGP

Note

Junos OS ルーターまたはルートサーバーを構成して送信元の検証を実行する方法について説明します。https://www.juniper.net/documentation/en_US/Junos/topics/topic-map/bgp-origin-as-validation.html.

ポリシーの実装に関する考慮事項

ルートサーバーのポリシー実装の詳細に進む前に、いくつ’かのはし BGP 実装に関する考慮事項を確認しておくことをお勧めします。他のピアからルーティング更新を受信する BGP スピーカーは、ローカルでの使用に関する情報を処理した後、事前定義済みのポリシーに基づいて、選択したルートを異なるピアに通知します。BGP がこの機能を実行できるようにするために、この情報をBGP ルーティング情報ベースと呼ばれる特別なタイプのデータベースに保存します。

BGP ルーティング情報ベースは、次の3つの部分で構成されています。

  1. 形容詞-イン」 (リブ): さまざまなピアから受信した BGP ルーティング情報を BGP しているリブストア保存された情報は、BGP の決定プロセスへの入力として使用されます。言い換えると、これはピアから取得した情報であり、属性の変更やルートフィルタリングを適用する前に発生します。

  2. ローカルリブ: ローカルルーティング情報ベースには、リブイン情報を処理した後のポストポリシー情報が格納されます。これらは、BGP ポリシーと決定プロセスを適用した後にローカルで使用されるルートです。

  3. 「すべての形容詞-リブ」この1つは、BGP 更新メッセージを通じてそのピアに通知するために、ローカル BGP ルーターによって選択されたルーティング情報を格納しています。

Note

Scaling, Troubleshooting, and Monitoring Considerationsこの章では、3つの BGP リブ部品をそれぞれ監視するための詳細な CLI 例について説明します。

この基本的なルーティング情報フローは、クライアントからルートサーバーへ、そしてクライアントに戻るようFigure 8に、に示されています。また、特定のポリシーがどのように適用されているかを示し、IXP と一般的な BGP ポリシーを管理する方法についても説明します。

Figure 8: ルートサーバー設定ワークフローの例
ルートサーバー設定ワークフローの例

ここで説明するデータベースはルーティングテーブルと混同されません。これは、BGP プロセスで使用される単なるテーブルであり、パケット転送にはルーターによって決して送信されません。ローカルの BGP スピーカー (ベンダーの実装とルーティングプロトコルの設定によって異なります) によって指定された基準に基づいてルーティングテーブルにインストールされるのは、そのルートセットだけです。