Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

BGP ルートリフレクタ

BGP ルートリフレクタについて

このトピックでは、route リフレクタを使用して設定を簡素化し、スケーリングを容易にする方法について説明します。トラフィック転送パスにないルートリフレクタのワークロードを削減するには、 no-install[edit protocols bgp family family-name]階層レベルでステートメントを使用する方法があります。Junos OS リリース15.1 から開始するno-installと、カーネルや分散型ファイアウォールデーモン (dfwd) など、Junos システム内のルーティングプロトコルデーモン (rpd) とその他のコンポーネントとの相互作用を排除します。関連する rpd routing information ベース (リブ) 内のルート (ルーティングテーブルとも呼ばれる) をこれらのコンポーネントに公開しないことで、このような操作が不要になります。

注:

Junos OS リリース15.1 よりも前のリリースでは、BGP から学習したルートを拒否する転送テーブルのエクスポートポリシーを使用して、トラフィック転送パスにないルートリフレクタのワークロードを削減することができます。

リフレクタ (IBGP) のフルメッシュ要件 BGP があるため、ほとんどのネットワークでは、ルートを使用して設定を簡素化しています。フルメッシュに必要なセッション数を計算する数式は、v * (v-1)/2 (v は BGP 対応デバイスの数) です。フルメッシュモデルは、拡張性に優れていません。ルートリフレクタを使用して、ルーターをクラスターにグループ化します。これは、自律システムに固有の数値識別子によって識別されます (AS)。クラスター内では、単一のルーター (ルートリフレクタ) から各内部ピアへの BGP セッションを構成する必要があります。この構成では、IBGP フルメッシュ要件を満たしています。

AS でルート リフレクションを使用するには、1 つ以上のルーターをルート リフレクタとして指定します(通常は 1 つのルーターポイント オブ プレゼンス(POP)。ルートリフレクタは、内部ピアから他の内部ピアに学習したルートを readvertise するための特別な BGP 機能を備えています。そのため、すべての内部ピアーが相互に完全にメッシュする必要はなく、ルートリフレクタはすべての内部ピアで完全にメッシュする必要があります。ルートリフレクタとその内部のすべてのピアが、に図 1示すようにクラスターを形成します。

注:

一部のジュニパーネットワークスデバイスでは、ルートリフレクタを使用する各デバイスに、高度な BGP 機能ライセンスがインストールされている必要があります。ライセンスの詳細については、『ソフトウェアのインストールとアップグレードガイド』を参照してください。

図 1: シンプルルートリフレクタトポロジ (1 つのクラスター)シンプルルートリフレクタトポロジ (1 つのクラスター)

図 1 は、クラスター 127 のルート リフレクタとして設定されたルーター RR を示しています。その他のルーターは、クラスター内で内部的にピアとして指定されています。BGP ルートは、どの内部ピアからもルーター RR にアドバタイズされます。その後、RR は、クラスター内の他のすべてのピアへのルートを readvertises します。

ルートリフレクタの完全なメッシュを構成することで、複数のクラスターを構成し図 2、それらをリンクすることができます (を参照)。

図 2: 基本的なルートの反映 (マルチクラスター)基本的なルートの反映 (マルチクラスター)

図 2ルートリフレクタ RR 1、RR 2、RR 3、RR 4 を、完全にメッシュされた内部ピアとして表示します。ルーターが RR 1 へのルートをアドバタイズすると、RR 1 は他のルートリフレクタへのルートを readvertises します。これにより、AS 内の残りのルーターへのルートが readvertise されます。ルートリフレクションを使用すると、完全なメッシュ要件で作成されたスケーリングの問題がなくても、ルートを全体に伝達できます。

注:

複数のクラスターをサポートするルートリフレクタは、非クライアントルーターからの同じクラスター ID を持つルートを受け付けません。そのため、他のクラスターへのルートを反映するために、冗長な RR 用に異なるクラスター ID を構成する必要があります。

しかし、クラスターが大きくなるにつれて、ルートリフレクタを使用したフルメッシュは、ルートリフレクタ間の完全なメッシュと同様に拡張が困難になります。この問題を相殺するために、階層的なルートリフレクションのためにルーターのクラスターをクラスターのクラスター 図 3にまとめてグループ化することができます (を参照)。

図 3: 階層ルートリフレクション (クラスターのクラスター)階層ルートリフレクション (クラスターのクラスター)

図 3クラスター127、19、45のルートリフレクタとして、RR 2、RR 3、RR 4 を示しています。ネットワーク管理者は、これらのルートリフレクタを完全にメッシュするのではなく、RR 1 がルートリフレクタである別のクラスター (クラスター 6) の一部として構成されています。ルーターが RR 2 へのルートを通知する場合、RR 2 readvertises が自身のクラスター内のすべてのルーターにルートを送信し、RR 1 へのルートを readvertises します。RR 1 は、クラスター内のルーターへのルートを readvertises し、それらのルーターがクラスターを介してルートを下位に伝達します。

例:ルートリフレクタの構成

この例では、ルートリフレクタを構成する方法を示します。

要件

この例を設定する前に、デバイス初期化以外に特別な設定は必要ありません。

概要

一般に、内部の BGP (IBGP) 対応デバイスは、IBGP が他の IBGP 対応デバイスに対して更新を readvertise していないため、完全にメッシュする必要があります。フルメッシュは、各 IBGP 対応デバイスで複数neighborのステートメントを設定して得られる論理メッシュです。フルメッシュは、必ずしも物理フルメッシュであるとは限りません。フルメッシュ (論理または物理) を維持することは、大規模な導入環境では十分ではありません。

図 4は、デバイス A がルートリフレクタとして機能する IBGP ネットワークを示しています。デバイス B とデバイス C はルートリフレクタのクライアントです。デバイス D とデバイス E はクラスター外にあるため、ルートリフレクタの非クライアントです。

デバイス A(ルート リフレクタ)で、クライアント(デバイス B およびデバイス C)と non(デバイス D およびデバイス E)のステートメントを含めて、すべての IBGP 対応デバイスとピア関係を形成する必要があります neighbor 。また、 clusterステートメントとクラスター識別子も含める必要があります。クラスター識別子には、任意の32ビット値を使用できます。この例では、ルートリフレクタのループバックインターフェイス IP アドレスを使用しています。

デバイス B とデバイス C のルートリフレクタクライアントでは、ルートリフレクタ、デバイスneighbor a とのピアリレーションシップを形成する1つのステートメントだけが必要です。

デバイス D およびデバイス E (非クライアント) では、各クライアントneighborデバイスに対してステートメントを記述する必要があります (d ~ E および e-D)。また、ルートリフレクタneighbor (D から a、E から a) のためのステートメントも必要です。デバイス D およびデバイス E は、クライアントneighborデバイス (デバイス B およびデバイス C) に対するステートメントを必要としません。

ヒント:

デバイス D とデバイス E は、相互にピア関係が明示的に設定されているため、非クライアントと見なされます。これらをルートリフレクタクライアントにするには、 neighbor 192.168.5.5デバイス D の構成からステートメントを削除し、デバイスneighbor 192.168.0.1 E の構成からこのステートメントを削除してください。

図 4: ルートリフレクタを使用する IBGP ネットワークルートリフレクタを使用する IBGP ネットワーク

構成

手順

CLI クイック構成

この例を簡単に構成するには、以下のコマンドをコピーしてテキストファイルに貼り付け、改行を削除し、ネットワーク設定に一致する必要がある詳細情報を変更してから、コマンド[edit]を階層レベルで CLI にコピー & ペーストします。

デバイス A

デバイス B

デバイス C

デバイス D

デバイス E

順を追った手順

ルートリフレクタの構成

順を追った手順

次の例では、構成階層のさまざまなレベルを移動する必要があります。デバイスのナビゲーションの詳細については、「 CLI ガイド 」の「 設定モードでの CLI Junos OS CLI エディター の使用 」 を参照してください

ジュニパーネットワークスデバイス A をルートリフレクタとして使用してネットワークの IBGP を構成するには、次のようにします。

  1. インターフェイスを構成します。

  2. 自律システム (AS) 内のすべての IBGP 対応デバイスとのクラスター識別子と近隣の関係を含め、BGP を構成します。

    OSPF ルートを BGP に再分配するポリシーを適用することもできます。

  3. 静的ルーティングまたは内部ゲートウェイプロトコル (IGP) を構成します。

    この例では OSPF を使用しています。

  4. OSPF ルートを BGP に再分配するポリシーを設定します。

  5. ルーター ID と AS (自律システム) 番号を設定します。

結果

構成モードからshow interfaces、、、 show protocolsshow policy-options、およびshow routing-optionsコマンドを入力して設定を確認します。出力に意図した構成が表示されない場合は、この例の手順を繰り返して設定を修正します。

デバイスの設定が完了したら、設定commitモードから入力します。

注:

その他の非クライアントデバイスがジュニパーネットワークスから作成されている場合、構成しているクラスター内の BGP ピア各クライアントに対して、これらの手順を繰り返します。それ以外の場合は、デバイスのマニュアルを参照して手順を確認してください。

クライアントピアの構成

順を追った手順

次の例では、構成階層のさまざまなレベルを移動する必要があります。デバイスのナビゲーションの詳細については、「 CLI ガイド 」の「 設定モードでの CLI Junos OS CLI エディター の使用 」 を参照してください

クライアントピアを構成するには

  1. インターフェイスを構成します。

  2. ルートリフレクタを使用して BGP の近隣関係を構成します。

    OSPF ルートを BGP に再分配するポリシーを適用することもできます。

  3. OSPF を構成します。

  4. OSPF ルートを BGP に再分配するポリシーを設定します。

  5. ルーター ID と AS 番号を設定します。

結果

構成モードからshow interfaces、、、 show protocolsshow policy-options、およびshow routing-optionsコマンドを入力して設定を確認します。出力に意図した構成が表示されない場合は、この例の手順を繰り返して設定を修正します。

デバイスの設定が完了したら、設定commitモードから入力します。

注:

他のクライアントデバイスがジュニパーネットワークスから構成されている場合は、クラスター内のクライアント BGP ピアごとにこの手順を繰り返します。それ以外の場合は、デバイスのマニュアルを参照して手順を確認してください。

非クライアントピアの設定

順を追った手順

次の例では、構成階層のさまざまなレベルを移動する必要があります。デバイスのナビゲーションの詳細については、「 CLI ガイド 」の「 設定モードでの CLI Junos OS CLI エディター の使用 」 を参照してください

非クライアントピアを構成するには

  1. インターフェイスを構成します。

  2. BGP の近隣関係を、RRroute リフレクタおよびその他の非クライアントピアとの間で構成します。

    OSPF ルートを BGP に再分配するポリシーを適用することもできます。

  3. OSPF を構成します。

  4. OSPF ルートを BGP に再分配するポリシーを設定します。

  5. ルーター ID と AS 番号を設定します。

結果

構成モードからshow interfaces、、、 show protocolsshow policy-options、およびshow routing-optionsコマンドを入力して設定を確認します。出力に意図した構成が表示されない場合は、この例の手順を繰り返して設定を修正します。

デバイスの設定が完了したら、設定commitモードから入力します。

注:

他の非クライアントデバイスがジュニパーネットワークスから設定されている場合に、構成中のクラスター内の BGP ピアごとに、これらの手順を繰り返します。それ以外の場合は、デバイスのマニュアルを参照して手順を確認してください。

検証

構成が正常に機能していることを確認します。

BGP の近隣ノードの検証

目的

BGP が構成済みのインターフェイスで実行されていることと、各近隣アドレスに対して BGP セッションが確立されていることを確認します。

アクション

動作モードから、 show bgp neighborコマンドを入力します。

BGP グループの確認

目的

BGP グループが正しく構成されていることを確認します。

アクション

動作モードから、 show bgp groupコマンドを入力します。

BGP 概要情報を確認します。

目的

BGP 構成が正しいことを確認します。

アクション

動作モードから、 show bgp summaryコマンドを入力します。

ルーティングテーブル情報の検証

目的

ルーティングテーブルに IBGP ルートが含まれていることを確認します。

アクション

動作モードから、 show routeコマンドを入力します。

2つの異なるクラスターに属するルートリフレクタについて理解する

ルートリフレクションの目的は、内部 BGP (IBGP) ルーティングデバイスが完全にメッシュ化されていない場合のループ防御です。これを実現するには、通常の BGP 操作のルールの1つを中断します。Readvertise は、内部の BGP ピアから、内部 BGP の他のピアに学習したルートをルーティングしています。

通常、単一の RR は1つのクラスターのみのメンバーです。たとえば、階層型 RR の設計では、tier 2 RR を tier 1 RR のクライアントにすることができますが、相互にクライアントを指定することはできません。

しかし、2つの Rr が互いにクライアントであり、ルートがクラスター間で反映されている場合、クラスターのリストには1つのクラスター Id のみが含まれます。これは、この場合には、クラスターリストに1つのクラスター ID があってもループ防御に適しているためです。

表 1 は、ルート リフレクタがクラスタDで反映されたルートのクラスタリストを記入する際に使用するルールをまとめっています。

表 1: ルートリフレクタのルール

ルートリフレクションシナリオ

構成

1つのクライアントから非クライアントルーターへのルートを反映する場合

client -> RR ->非クライアント

この RR によって、そのクライアントに関連付けられているクラスター ID が、反映されたルートのクラスターリストに格納されます。

非クライアントルーターからクライアントルーターへのルートを反映するとき

non-client -> RR -> クライアント

この RR によって、そのクライアントに関連付けられているクラスター ID が、反映されたルートのクラスターリストに格納されます。

クライアントルーターから別のクラスターにある他のクライアントルーターへルートを反映する場合

client1 -> RR -> client2(異なるクラスタ)

RR は、クラスター ID を順番に反映する前に、client1 に関連付けられたクラスター ID を入力します。クライアント2に関連付けられているクラスター ID は追加されません。

クライアントルーターから、別の自律システムにある非クライアントルーターへのルートを反映したとき。

たとえば、Tier 2 RR および 2 BGP グループ(1 つは RR クライアント用、もう 1 つはティア 1 RR)を設定した場合、ある自律システムから別の自律システムへのルートが反映されます。

client -> RR ->非クライアント(異なるAS)

非クライアントデバイスへのルートを反映する前に、RR によってクラスターリストがクラスター ID でいっぱいになることはありません。この場合、クラスター ID は1つの自律システムに固有のものであるためです。

例:2つの異なるクラスターに属しているルートリフレクタの構成

この例では、2つの異なるクラスターに属するルートリフレクタ (Rr) を構成する方法を示しています。これは一般的なシナリオではありませんが、状況によっては役に立つ場合があります。

要件

デバイスインターフェイスと内部ゲートウェイプロトコル (IGP) を設定します。インターフェイスと IGP の構成を含む RR 設定の例については、 次の例を参照してください。ルートリフレクタの構成

概要

この例では、デバイス RR1 はデバイス R2 とデバイス RR2 のルートリフレクタです。ルートリフレクタ RR1 には2つの異なるクラスター Id が割り当てられています。1つは RR1-R2 と 6.6.6.6 for RR1 の5.5.5.5 用です。

デバイスの RR2 は、デバイス R4 用のルートリフレクタです。

図 5を考えてみましょう。

図 5: 2つの異なるクラスターのルートリフレクタ2つの異なるクラスターのルートリフレクタ

この例で BGP は、デバイス RR1 とデバイス RR2 の構成を示しています。

構成

手順

CLI クイック構成

この例を簡単に構成するには、以下のコマンドをコピーしてテキストファイルに貼り付け、改行を削除し、ネットワーク設定に一致する必要がある詳細情報を変更してから、コマンド[edit]を階層レベルで CLI にコピー & ペーストします。

デバイス RR1

デバイス RR2

デバイス RR1 の構成

順を追った手順

次の例では、構成階層のさまざまなレベルを移動する必要があります。デバイスのナビゲーションの詳細については、「 CLI ガイド 」の「 設定モードでの CLI Junos OS CLI エディター の使用 」 を参照してください

デバイス RR1 を構成するには、次のようにします。

  1. デバイス R2 とのピアリング関係を構成します。

  2. デバイス R0 とのピアリング関係を構成します。

  3. デバイス RR2 とのピアリング関係を構成します。

結果

設定モードから、 show protocolsコマンドを入力して設定を確認します。出力に意図した構成が表示されない場合は、この例の手順を繰り返して設定を修正します。

デバイスの設定が完了したら、設定commitモードから入力します。

デバイス RR2 の構成

順を追った手順

次の例では、構成階層のさまざまなレベルを移動する必要があります。デバイスのナビゲーションの詳細については、「 CLI ガイド 」の「 設定モードでの CLI Junos OS CLI エディター の使用 」 を参照してください

デバイス RR2 を構成するには、次のようにします。

  1. デバイス R4 とのピアリングリレーションシップを設定します。

  2. デバイス RR1 とのピアリング関係を構成します。

結果

設定モードから、 show protocolsコマンドを入力して設定を確認します。出力に意図した構成が表示されない場合は、この例の手順を繰り返して設定を修正します。

デバイスの設定が完了したら、設定commitモードから入力します。

検証

構成が正常に機能していることを確認します。

ルート2.2.2.2 のためにアドバタイズされたクラスター ID を確認しています

目的

BGP が構成済みのインターフェイスで実行されていることと、各近隣アドレスに対して BGP セッションが確立されていることを確認します。

アクション

動作モードから、 show route advertising-protocol bgp neighbor-addressコマンドを入力します。

2.2.2.2/32ルートは、デバイスRR1のクライアントピア、デバイスR2を由来とします。このルートがRR1のクライアントであるデバイスRR2に送信された場合、ルートには5.5.5.5クラスターIDがアタッチされています。これはRR1-R2のクラスタIDです。

ルート1.1.1.1 のためにアドバタイズされたクラスター ID を確認しています

目的

デバイス RR1 からデバイス RR2 に送信されたルートアドバタイズを確認します。

アクション

動作モードから、 show route advertising-protocol bgp neighbor-address コマンドを入力します。

1.1.1.1/32 ルートは、デバイス RR1 の非クライアント ピア、デバイス R0 から発生しました。このルートがRR1のクライアントであるデバイスRR2に送信された場合、ルートには6.6.6.6クラスターIDがアタッチされています。これはRR1-RR2のクラスタIDです。

デバイスRR1は、別のクラスタ(デバイスR4)内の別のクライアントに広告する際に、デバイスRR2からのインバウンドクラスタIDを保持します。

最適なルートリフレクション BGP 理解する

IS-IS を使用して最適なルート反転 (BGP-ORR) を構成し、ルートリフレクタで内部ゲートウェイプロトコル (IGP) として OSPF して、BGP-ORR クライアントグループに対して最適のパスを通知できます。 BGP。これは、ルートリフレクタのビュー IGPではなく、クライアントの視点から最も短い指標と指標を使用して行われます。

同一または類似の IGP トポロジを共有するクライアントグループは、1つの BGP ピアグループとしてグループ化できます。その BGP ピアグループoptimal-route-reflectionで BGP-orr を有効にするように設定できます。また、クライアントノードの1つを BGP ピアグループのプライマリノード (igp-primary) として設定して、そのプライマリノードから IGP メトリックを使用して最適なパスを選択し、同じ BGP ピアグループ内のクライアントにアドバタイズすることもできます。必要に応じて、別のクライアントノードをバックアップノード (igp-backup) として選択することもできます。igp-primaryこれは、プライマリノード () がダウンするか、到達不能になったときに使用されます。

BGP-ORR を有効にするにoptimal-route-reflectionは、[edit protocols bgp group group-name] 階層レベルにステートメントを追加してください。

注:

BGP-ORR は、IGP が BGP のルート解決に使用されている場合にのみ機能します。MPLSLDP/RSVP がルート解決に使用されている場合、BGP-ORR は機能しません。

注:

BGP-ORR を機能するには、これらのプレフィックスBGPを使用して解決する必要IGP。通常のレイヤー 3 VPN、レイヤー 2 VPN、VPLS、MVPN、EVPN のシナリオでは、プレフィックスは inet.3 上で解決されます。inet.3 では、プレフィックスのプロトコルネクスト ホップのプライマリ ルートは RSVP または LDP( であり、IS-IS や OSPF のような IGP プロトコルではありません。BGP-ORR を機能するには、レイヤー 3 VPN、レイヤー 2 VPN、VPLS、MVPN、EVPN プレフィックスのルート解決に inet.0 を使用するルーターを設定する必要があります。これを実行するには、次のコマンドを使用します。

  • レイヤー 3 VPN プレフィックスの場合:

  • レイヤー 2 VPN または VPLS プレフィックスの場合:

  • EVPN プレフィックスの場合:

  • MVPN プレフィックスの場合:

もう 1 つの方法は、ネットワーク ルートIGP inet.3 に漏洩して、inet.3 のプライマリ ルートとして作成します。

次の CLI の階層を使用して BGP-ORR を構成します。

最適な経路を提供するためのルートリフレクタに対する最適なルートリフレクションの構成 BGP

IS-IS を使用して最適なルート反転 (BGP-ORR) を構成し、ルートリフレクタで内部ゲートウェイプロトコル (IGP) として OSPF して、BGP-ORR クライアントグループに対して最適のパスを通知できます。 BGP。これは、ルートリフレクタのビュー IGPではなく、クライアントの視点から最も短い指標と指標を使用して行われます。

BGP-ORR を有効にするにoptimal-route-reflectionは、[edit protocols bgp group group-name] 階層レベルにステートメントを追加してください。

同一または類似の IGP トポロジを共有するクライアントグループは、1つの BGP ピアグループとしてグループ化できます。その BGP ピアグループoptimal-route-reflectionで BGP-orr を有効にするように設定できます。

BGP-ORR を構成するには、以下のようにします。

  1. 最適なルートリフレクションを構成します。
  2. クライアントノードのいずれか1つを BGP ピアグループのigp-primaryプライマリノード () として設定し、そのプライマリノードから IGP メトリックを使用して最適なパスを選択し、同じ BGP ピアグループ内のクライアントに通知します。
  3. ナ別のクライアントノードをバックアップノード (igp-backup) として設定します。これは、igp-primaryプライマリノード () がダウンするか到達不能になったときに使用されます。

次の CLI コマンドを使用して BGP-ORR の設定を監視およびトラブルシューティングします。

  • show bgp group—BGP-ORR のプライマリおよびバックアップ設定を表示します。

  • show isis bgp-orr—RIB(IS-IS BGP-ORR メトリック)を表示します。

  • show ospf bgp-orr—RIB(OSPF BGP-ORR メトリック)を表示します。

  • show ospf route—デバイスのエントリーをOSPF ルーティング テーブル

  • show route—ルーティング テーブルのアクティブなエントリーを表示します。

  • show route advertising protocol bgp peer—ルートがホスト-ORR ルールに従ってアドバタイズBGP確認します。

BGP ルートサーバーの概要

BGP ルートサーバーは、ネットワークに必要なダイレクトポイントツーポイント EBGP セッションの数を簡素化する、内部 IBGP (IBGP) ルートリフレクタに相当する外部 BGP (EBGP) として機能します。EBGP ルートサーバーは、ルートサーバーから受信したルートが直接接続された EBGP ピアからのルートである場合に BGP 属性のセット (NEXT_HOP、AS_PATH、MULTI_EXIT_DISC、AIGP、コミュニティー) を伝達するように BGP 属性の伝達の観点から透過的に実行されます。

IBGP ルートリフレクタと同様に、EBGP ルートサーバーは、ルートサーバー機能を使用して、EBGP ピア間のダイレクト転送パスの外部にあるネットワークにアタッチされます。この接続には、ダイレクト物理リンクを使用する方法と、VPLS LAN や EVPN などのレイヤー2ネットワークを使用する方法と、ピアのループバックアドレスの到達可能性を提供するポイントツーポイント EBGP リンクの IP ファブリック (データセンターネットワーク内の典型的な場合) があります。

BGP プロトコルは、RFC 7947 に記載されている以下の機能を使用して、ルートサーバー機能を提供するように拡張しています。

  • NEXT_HOP、AS_PATH、MULTI_EXIT_DISC、AIGP、コミュニティーの属性の透過性。

  • クライアント単位のポリシー制御と複数のルートサーバーのリブにより、パスの非表示を緩和します。

BGP のプログラマビリティにより、ルートサーバーの機能を活用できます。以下のとおりBGP JET APIが拡張 bgp_route_service.proto され、ルートサーバーの機能をサポートしています。

  • EBGP ルートサーバーをプログラムします。

  • 特定のルートサーバーのリブにルートを挿入して、クライアント固有の突起でクライアントグループに対して選択的にアドバタイズすることができます。

BGP JET API には、EBGP または IBGP(デフォルト)として個々のルートを識別するピアタイプ オブジェクト bgp_route_service.proto が含まれています。

ルートサーバー機能は、一般的にはアドレスファミリに依存しませんが、特定の BGP 属性のサポートはアドレスファミリ固有である場合があります。たとえば、AIGP はラベル付きユニキャストアドレスシリーズに対してのみサポートされます。ルートサーバー機能は、すべての EBGP アドレスファミリーでサポートされています。

BGP 属性の透過性

EBGP 属性透過性 [RFC7947] がサポートされるのは、ルートサーバーの標準 BGP ルートの伝達を変更することにより、推移性の属性や非推移性の特性をルートの伝達中に削除したり変更したりしないようにすることです。

通常の EBGP 動作の変更は、 route-server-client CLI 構成によって制御されます。[ route-server-clientedit protocols bgp group group-name] 階層レベルの CLI 構成は、ルートサーバー BGP 属性透明度動作を実装します。

  • ルートサーバーは、単一ホップの EBGP とマルチホップの両方の構成に属性の透過性を提供します。したがって、 route-server-clientこの構成には、シングルno-nexthop-changeホップセッションとマルチ・ホップを使用するための機能が暗黙的に含まれています。マルチホップ BGP セッションでは、 multihopキーワードを設定する必要があります。

  • route-server-client 、[edit protocol bgp] 階層のプロトコル、グループ、または近傍レベルで設定できます。

  • この route-server-client 設定は、グループ タイプが外部の場合にのみ適用 されます。内部グループ route-server-client に対して 設定すると 、コミットしようとすると設定エラーが発行されます。

  • 構成route-server-clientにパラメーターがありません。

  • この設定に適用されるroute-server-client通常の BGP 権限。

注:

属性は、属性の透過性に関して個別に処理されます。次ホップをルートサーバーによって変更できない場合でも、その他の属性は、その属性に応じて透過的に送信されます。

以下に、構成例route-server-clientを示します。

次ホップ

ポリシーによって明示的に設定されていない場合、次ホップの self 属性を変更したり、次ホップを変更したりする必要があります。ルートサーバーは、RFC 4271 のサードパーティーのネクストホップルールに従って BGP ホップを伝達しなければなりません。

次ホップ動作は、ルートサーバーの以下のシナリオに対して指定されています。

  • LAN と WAN の相互接続では、ルートサーバーが共有 LAN と WAN サブネット経由でクライアントピアに接続されている場合、受信したサードパーティーの次ホップは、RFC 4271 で定義された変更なしにルートサーバーによって通知されます。

  • データセンターマルチホップ相互接続の場合、ルートサーバーがマルチホップ相互接続を介してクライアントピアに接続されている場合は、EBGP マルチホップを構成しno-nexthop-changeて、CLI 構成の動作がroute-server-client暗黙的に設定されています。構成. 受信したサードパーティーの次ホップは、RFC 4271 で定義されているオプションのサードパーティーの動作に従って、変更されずにルートサーバーによって通知を受けます。

  • ルートサーバーとクライアントピア間のポイントツーポイントのシングルホップ接続などの場合は、通常のネクストホップアドバタイズメント手順を使用して、BGP ピアによって拒否される次ホップのアドバタイズを防止します (たとえば、ほとんどの BGPデフォルトの実装では、非マルチポイントセッションのサブネットアドレスの対象になっていない次ホップアドレスが拒否されます。

AS Path

AS のローカル パス番号を追加することで、パスを変更ASすることはできません。CLI route-server-clientをピアに設定すると、広告にはローカル数として指定されません。さらに、ローカルshow route advertising-protocol bgp peer AS がアドバタイズメトリックに表示されていない場合は、ルートサーバークライアントであるピアに対して CLI コマンドが変更されます。

その他の属性

  • MULTI_EXIT_DISC 属性 (オプション、非推移性) は受信したものとして反映される必要があります。

  • 広告なし、エクスポートなし、非推移性の拡張コミュニティなど、すべてのコミュニティー属性は、受信したものとして伝達される必要があります。

  • 累積 IGP (AIGP) 属性 (オプション、非推移性) を受信時に反映する必要があります。

    注:

    Junos OS は BGP のアドレスファミリー (IPv4 および IPv6) に対してのみ AIGP をサポートします。

BGP ルートサーバークライアントリブ

ルートサーバーのクライアント固有のリブは、1つの宛先に対して他のビューとは異なるルートを含めることができる、BGP Loc の特徴的なビューです。ルートサーバークライアントは、ピアグループを通じて、1つのクライアント固有のビューまたは共有された共通のリブと関連付けられる場合があります。

同じ宛先に対して異なるクライアントに異なるルートをアドバタイズする機能を提供するには、同じ宛先に対して複数の BGP パス選択を実行できるようにする必要があります。また、別のクライアント/グループでは、用途.

クライアント/グループパスを選択することで、柔軟なポリシー制御という高いレベルの要件を実現するには、BGP ルートサーバーは、ノン転送ルーティングインスタンス (Nfsd) を使用して、BGP パス選択を含む、BGP パイプラインの複数インスタンスへのアプローチを実行します。各リブおよびポリシー。ルートサーバーは、個別の転送不可ルーティングインスタンス内に構成された BGP グループ内のルートサーバークライアントをグループ化するように設定されています。このアプローチは、ルーティングインスタンス内で実行される BGP が、パス選択を行い、他のルーティングインスタンスで実行されている BGP とは異なるリブを持っていることを活用しています。

ポリシーの要件と考慮事項

ルートサーバーのクライアント間でルートを伝達するために、ルートは設定されたポリシーに基づいてルーティングインスタンスのリブ間でリークされます。

ポリシー制御のためのルートサーバーの設定には、以下の考慮事項が含まれます。

  • ルート サーバー クライアントは、同じ Loc-RIB ビューを受信するように、同じプライマリ インスタンスまたはルーティング インスタンス内に構成する必要があります。

  • 完全に一意な Loc ビューを受信するには、ルートサーバークライアントを独自のルーティングインスタンス内に構成する必要があります。

  • ルートサーバークライアントは、同じ場所にある異なる BGP ピアグループで構成して、同じ場所のリブビューで異なるエクスポートポリシーを持つようにする必要があります。

  • ルートサーバークライアント固有のリブビューは、デフォルトで他のテーブルからすべてのルートを受信するために、 instance-importポリシーのフルメッシュinstance-anyを使用して構成されています。ポリシーをinstance-import含むinstance-any設定時:

    • instance-any次のような用途で使用できます。

      • policy-statement ... term ... from

      • policy-statement ... from

      • policy-statement ... term ... to

      • policy-statement ... to

    • instance-anyにパラメーターがありません。

    • そのinstance-any他のinstance-importポリシーでを使用しても効果はありません。

  • 多くの異なるルーティングインスタンスとピアグループを設定すると、拡張性とパフォーマンスに影響を及ぼします。

  • [forwarding-context] edit protocols bgp group neighbor階層レベルの BGP CLI 構成は、BGP の近隣ノードのルーティングインスタンスを構成インスタンスと転送インスタンスに分割します。BGP CLI設定は、指定されたインスタンスが、転送タイプ非転送ではないプライマリまたはルーティング インスタンスを転送できるインスタンスであるとして設定された BGP ピアを持つ非転送インスタンスもサポートしています。 forwarding-contextroute-server-client

リリース履歴テーブル
リリース
説明
15.1
Junos OS リリース15.1 から開始するno-installと、カーネルや分散型ファイアウォールデーモン (dfwd) など、Junos システム内のルーティングプロトコルデーモン (rpd) とその他のコンポーネントとの相互作用を排除します。
15.1
Junos OS リリース15.1 よりも前のリリースでは、BGP から学習したルートを拒否する転送テーブルのエクスポートポリシーを使用して、トラフィック転送パスにないルートリフレクタのワークロードを削減することができます。