Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

BGP ルート リフレクタ

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

このトピックでは、ルートリフレクタを使用して、設定を簡素化し、スケーリングを支援する方法について説明しています。トラフィック転送パスにないルートリフレクタのワークロードを削減するには、[edit protocols bgp family family-name]階層レベルでno-installステートメントを使用する方法があります。Junos OS リリース 15.1以降、no-installステートメントは、カーネルや分散型ファイアウォールデーモン(dfd)などのJunosシステムのルーティングプロトコルデーモン(Rpd)と、Junosシステムの他のコンポーネント間の相互作用を除去します。この相互作用は、関連するrpdルーティング情報ベース(RIB)内のルート(ルーティングテーブルと呼ばれる)が、これらのコンポーネントに公開されることを禁止することで排除されます。

注:

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

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

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

注:

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

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

図 1は、クラスタ127のルートリフレクタとして設定されたルーターRRを示しています。その他のルーターは、クラスタ内の内部ピアとして指定されています。BGPルートは、いずれかの内部ピアによってルーターRRにアドバタイズされます。その後RRは、クラスタ内の他のすべてのピアに再度アドバタイズします。

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

図 2: 基本的なルートリフレクション(複数のクラスタ)基本的なルートリフレクション(複数のクラスタ)

図 2は、ルートリフレクタRR1、RR2、RR3、およびRR4をフルメッシュされた内部ピアとして示しています。ルーターがRR1にルートをアドバタイズすると、RR1が他のルートリフレクタにルートを再度アドバタイズします。これにより、AS内の残りのルーターにルートが再度アドバタイズされます。ルートリフレクションにより、フルメッシュ要件で発生するスケーリング問題なしに、AS全体にルートが伝送されます。

注:

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

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

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

図 3は、クラスタ127、19、および45のルートリフレクタとして、RR2、RR3、RR4を示しています。ネットワーク管理者は、これらのルートリフレクタを完全にメッシュ化する代わりに、RR1がルートリフレクタである別のクラスタ(クラスタ6)の一部として設定しています。ルーターがRR2にルートをアドバタイズすると、RR2が独立したクラスタ内のすべてのルーターにルートを再度アドバタイズし、その後、RR1にルートを再度アドバタイズします。RR1は、クラスタ内のルーターにルートを再度アドバタイズし、これらのルーターがクラスタを介してルートを伝送します。

例:ルート リフレクタを設定する

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

要件

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

概要

一般に、内部 BGP(IBGP)対応機器は、IBGP が他の IBGP 対応機器に更新を再送信しないため、フル メッシュにする必要があります。フル メッシュは、IBGP 対応機器に複数のneighborステートメントを設定することで実現する論理的なメッシュです。フル メッシュは必ずしも物理的なフルメッシュとは限りません。フル メッシュ (論理的または物理的) を維持することは、大規模な展開ではうまくスケールしません。

図 4 は、機器Aがルート リフレクタとして動作する IBGP ネットワークを示しています。機器 B と機器 C は、ルート リフレクタのクライアントです。機器 D と機器 E はクラスタ外なので、ルート リフレクタの非クライアントとなります。

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

neighborルートリフレクタのクライアントである装置Bと装置Cでは、ルートリフレクタである装置Aとピア関係を形成する121文が1つだけ必要です。

neighbor非クライアントであるデバイスDとデバイスEでは、非クライアントデバイス(DtoE、EtoD)ごとに121文が必要です。neighborまた、ルートリフレクタ(D-to-A、E-to-A)用の121ステートメントも必要です。neighborデバイスDとデバイスEは、クライアントデバイス(デバイスBとデバイスC)に対する121ステートメントは必要ありません。

ヒント:

デバイスDとデバイスEは、互いにピア関係を明示的に設定しているため、非クライアントとみなされます。neighbor 192.168.5.5neighbor 192.168.0.1RRルートリフレクタクライアントとするために、機器Dのコンフィグレーションから121ステートメントを削除し、機器Eのコンフィグレーションから343ステートメントを削除してください。

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

設定

手順

CLIクイック構成

この例をすばやく設定するには、次のコマンドをコピーしてテキストファイルに貼り付け、改行を削除して、ネットワーク構成に合わせて必要な詳細を変更し、[edit]階層レベルのCLIにコマンドをコピー&ペーストしてください。

1 デバイスA 1

1 デバイスB 1

1 デバイスC 1

1 デバイスD 1

1 デバイスE 1

ステップバイステップでの手順

ルートリフレクタを設定する

ステップバイステップでの手順

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

Juniper Networks デバイス A をルートリフレクタとして使用し、ネットワークに IBGP を設定します。

  1. インターフェイスを設定します。

  2. クラスタ識別子や自律システム(AS)内のすべてのIBGP対応機器との近隣関係などのBGPを設定します。

    また、OSPFのルートをBGPに再配布するポリシーも適用します。

  3. スタティックルーティングまたはIGP(Interior Gateway Protocol)を設定する。

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

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

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

結果

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

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

注:

他の非クライアントデバイスが Juniper Networks 製である場合は、構成するクラスタ内の各非クライアント BGP ピアについて、これらの手順を繰り返します。それ以外の場合は、デバイスのマニュアルを参照してください。

クライアントピアの設定

ステップバイステップでの手順

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

クライアントピアを設定するには

  1. インターフェイスを設定します。

  2. ルートリフレクタとのBGPネイバー関係を設定します。

    また、OSPFのルートをBGPに再配布するポリシーも適用します。

  3. OSPFを設定します。

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

  5. ルーターID、AS番号を設定する。

結果

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

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

注:

他のクライアントデバイスが Juniper Networks 製の場合、設定するクラスタ内の各クライアント BGP ピアについて、これらのステップを繰り返します。それ以外の場合は、デバイスのマニュアルを参照してください。

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

ステップバイステップでの手順

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

非クライアントピアを設定するには

  1. インターフェイスを設定します。

  2. RRルートリフレクタおよび他の非クライアントピアとのBGPネイバーリレーションを設定します。

    また、OSPFのルートをBGPに再配布するポリシーも適用します。

  3. OSPFを設定します。

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

  5. ルーターID、AS番号を設定する。

結果

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

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

注:

他の非クライアントデバイスが Juniper Networks 製である場合は、構成するクラスタ内の各非クライアント BGP ピアについて、これらの手順を繰り返します。それ以外の場合は、デバイスのマニュアルを参照してください。

検証

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

BGP ネイバーの検証

目的

設定したインターフェイスでBGPが動作し,各近傍アドレスに対してBGPセッションが確立していることを確認します。

対処

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

BGP グループの検証

目的

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

対処

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

BGP サマリー情報の検証

目的

BGP の設定が正しいことを確認します。

対処

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

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

目的

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

対処

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

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

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

通常、1 つの RR は 1 つのクラスタにしか属しません。例えば、階層型 RR の設計において、第 2 階層の RR は第 1 階層の RR のクライアントになることはできても、お互いにクライアントになることはできないと考えます。

しかし、2 つの RR が互いのクライアントであり、あるクラスタから別のクラスタにルートが反映されている場合、クラスタリストには一方のクラスタ ID しか含まれません。これは、このケースでは、クラスタリストに 1 つのクラスタ ID があれば、ループ防止に十分だからです。

表 1は、ルートリフレクターが、反映されたルートのクラスタリストにクラスタ ID を記入する際に使用するルールを、要約しています。

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

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

設定

クライアントの 1 つから、非クライアントのルーターにルートを反映させる場合

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

RR は、反映されたルートのクラスタリストに、そのクライアントに関連するクラスタ ID を記入します。

非クライアントのルーターからクライアントのルーターに、ルートを反映させる場合

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

RR は、反映されたルートのクラスタリストに、そのクライアントに関連するクラスタ ID を記入します。

クライアントルーターから、異なるのクラスタに存在する別のクライアントルータに、ルートを反映させる場合

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

RRは、クライアント 1 に関連するクラスタ ID を、クラスタリストに記入してから、クラスタ ID をクライアント 2 に反映します。クライアント 2 に関連するクラスタ ID は、追加されません。

クライアントルーターから、異なる自律システムに存在する非クライアントルータに、ルートを反映させる場合

例えば、第 2 階層の RR および 2 つの BGP グループ(1 つは RR クライアント用、もう 1 つは第 1 階層の RR 用)を設定し、1 つの自律システムから別の自律システムへのルートを反映する場合

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

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

例:異なる2つのクラスターに属するルートリフレクタの設定

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

要件

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

概要

この例では、デバイスRR1が、デバイスR3とデバイスRR2の両方のルート・リフレクタになっています。ルート・リフレクタRR1には、RR1-R3の5.5.5.5とRR1-RR2の6.6.6.6という2種類のクラスタIDが割り当てられています。

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

図 5を見てください。

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

この例では、デバイスRR1とデバイスRR2でのBGPのコンフィギュレーションを示します。

設定

手順

CLIクイック構成

この例をすばやく設定するには、次のコマンドをコピーしてテキストファイルに貼り付け、改行を削除して、ネットワーク構成に合わせて必要な詳細を変更し、[edit]階層レベルのCLIにコマンドをコピー&ペーストしてください。

デバイスRR1

デバイスRR2

デバイスRR1の設定

ステップバイステップでの手順

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

デバイスRR1を設定するには:

  1. デバイスR3とのピアリング関係を設定します。

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

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

結果

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

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

デバイスRR2の設定

ステップバイステップでの手順

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

デバイスRR2を設定するには:

  1. デバイスR4とのピアリング関係を設定します。

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

結果

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

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

検証

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

ルート 10.3.3.3にアドバタイズされたクラスターーIDの確認

目的

設定したインターフェイスでBGPが動作し,各近傍アドレスに対してBGPセッションが確立していることを確認します。

対処

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

意味

10.3.3.3/32ルートは、デバイスRR1のクライアントピアであるデバイスR3を起点としています。このルートがRR1のクライアントであるデバイスRR2に送信されると、ルートに10.13.1.3クラスターIDが付加されます。これは、RR1-R3のクラスターIDです。

ルート10.1.0.1にアドバタイズされたクラスターIDの確認

目的

デバイスRR1からデバイスRR2へのルートアドバタイズを確認してください。

対処

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

意味

10.1.0.1/32ルートはデバイスRR1の非クライアントピアであるデバイスR0を起点としています。このルートをRR1のクライアントであるデバイスRR2に送信すると、ルートには 10.12.1.2クラスターIDが付加されます。これはRR1-RR2のクラスターIDです。

デバイスRR1は、異なるクラスターに属する別のクライアント(デバイスR4)に広告を出す際、デバイスRR2からの受信クラスターIDを保持します。

BGP最適ルート反映の理解

ルートリフレクタでIS-ISおよびOSPFを内部ゲートウェイプロトコル(IGP)としたBGP最適経路反映(BGP-ORR)を設定し,BGP-ORRクライアントグループに最適経路を広告することが可能です。これは、ルートリフレクタの視点ではなく、クライアントの視点から最短のIGPメトリックを使用することで実現されています。

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

BGP-ORR を有効にするには、[edit protocols bgp group group-name]階層レベルにoptimal-route-reflectionステートメントを記述します。

注:

BGP-ORR は、BGP のルート解決に IGP が使用されている場合にのみ機能します。ルート解決に 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 プレフィックスの場合:

別の方法は、IGP ルートを inet.3 にリークして、inet.3 の主要ルートにすることです。

BGP-ORR を設定するには、以下の CLI 階層を使用します:

ルートリフレクタでBGP最適経路を広告するための設定

ルートリフレクタでIS-ISおよびOSPFを内部ゲートウェイプロトコル(IGP)としたBGP最適経路反映(BGP-ORR)を設定し,BGP-ORRクライアントグループに最適経路を広告することが可能です。これは、ルートリフレクタの視点ではなく、クライアントの視点から最短のIGPメトリックを使用することで実現されています。

BGP-ORR を有効にするには、[edit protocols bgp group group-name]階層レベルにoptimal-route-reflectionステートメントを記述します。

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

BGP-ORRを設定するには、次のようにします。

  1. 最適経路反映を設定する。
  2. BGP ピアグループのプライマリノード (igp-primary) にクライアントノードを設定し,プライマリノードからの IGP メトリッ クで最適経路を選択し,同じ BGP ピアグループのクライアントに広告するようにします。
  3. (オプション)プライマリノード(igp-primary)がダウンした場合や到達できない場合に使用するバックアップノード(igp-backup)として、別のクライアントノードを設定します。

BGP-ORRの設定を監視し、トラブルシューティングするには、次のCLIコマンドを使用します。

  • show bgp group121-BGP-ORRのプライマリおよびバックアップの構成を表示します。

  • show isis bgp-orr121-View IS-IS BGP-ORR metric (RIB)を表示します。

  • show ospf bgp-orr121-View OSPF BGP-ORR metric (RIB)を表示します。

  • show ospf route121-OSPFルーティングテーブルのエントリを表示する

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

  • show route advertising protocol bgp peer121-BGP-ORRのルールに従って経路が広告されているかどうかを確認します。

BGP ルート サーバーの概要

BGP ルート サーバーは、内部 IBGP(IBGP)ルート リフレクタの外部 BGP(EBGP)に相当し、ネットワークで必要な直接ポイントツーポイント EBGP セッションの数を簡略化します。EBGP ルート サーバーは、BGP 属性の伝送に関して透過的であり、ルート サーバーから受け取ったルートは、直接接続された EBGP ピアからのルートであれば、BGP 属性のセット(NEXT_HOP、AS_PATH、MULTI_EXIT_DISC、AIGP、Communities)を伝えることができます。

EBGP ルート サーバーは、IBGP ルート リフレクタと同様に、ルート サーバー機能を使用する EBGP ピア間の直接の転送パスの外側のネットワークに接続されます。この接続は、直接的な物理リンク、VPLS LAN や EVPN などのレイヤー 2 のネットワーク、またはピアのループバック アドレスに到達可能なポイントツーポイント EBGP リンクの IP ファブリック(データセンター ネットワークで一般的)を介して行うことができます。

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

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

  • クライアント単位のポリシー制御と複数のルート サーバー RIB によるパスハイドの緩和。

BGP のプログラマビリティは、ルート サーバーの機能を利用しています。BGP JET bgp_route_service.proto API は、ルート サーバー機能をサポートするために、以下のように拡張されました。

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

  • 特定のルート サーバー RIB にルートを挿入して、クライアント固有の RIB 内のクライアント グループにルートを選択的にアドバタイズします。

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

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

BGP 属性の透過性

ルート サーバーの EBGP 属性透過性 [RFC7947] は、通常の BGP ルート伝送を変更することで、ルート伝送中に遷移属性も非遷移属性も削除または変更されないようにすることでサポートされます。

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

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

  • は、[edit protocol bgp] 階層のプロトコル、グループ、ネイバー レベルで設定するroute-server-clientことができます。

  • route-server-client設定は、グループタイプがexternalの場合のみ適用されます。route-server-clientinternalグループに設定されている場合、コミットしようとすると構成エラーが発生します。

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

  • route-server-client の構成には、通常の BGP 権限が適用されます。

注:

属性は、属性の透明度に関して独立して処理されます。ネクストホップがルート サーバーで修正されずに送信できない場合でも、他の属性はその属性に該当するものとして透過的に送信されます。

以下は、 のroute-server-client構成例です。

ネクストホップ

ポリシーで明示的に設定されていない限り、ネクストホップ属性を変更して、ネクストホップ セルフを課したり、ネクストホップを変更しないでください。ルート サーバーは、RFC 4271 のサードパーティ製のネクストホップ ルールに従って BGP ネクストホップを伝送させる必要があります。

ネクストホップ動作は、以下のルート サーバーのシナリオで指定します。

  • LAN や WAN 相互接続の場合、ルート サーバーがクライアント ピアと LAN や WAN サブネットを共有して接続されている場合、RFC 4271 に定義されているように、受信したサードパーティ製のネクストホップをそのままルート サーバーで広告することができます。

  • route-server-clientデータ センターのマルチホップ相互接続で、ルート サーバーがクライアント ピアとマルチホップ相互接続する場合、EBGP マルチホップを設定する必要があり、 Cno-nexthop-changeLI 設定の動作は 設定によって暗黙的に課されることになります。受信したサードパーティ製のネクストホップは、RFC 4271 で定義されているサードパーティ製のオプション動作に従って、そのままルート サーバーで広告されます。

  • ルート サーバーとクライアント ピアの間のポイントツーポイント の シングルホップ接続などの他のケースでは、BGP ピアによって拒否される可能性のあるネクストホップを広告しないように、通常のネクストホップ広告手順を使用します(例えば、ほとんどの BGP 実装では、デフォルトでマルチポイント以外のセッションでサブネット アドレスによってカバーされていないネクストホップ アドレスが拒否されます)。

ASパス

AS パスは、ルート サーバーのローカル AS 番号を先頭につけて変更しないでください。ピアに route-server-client CLI を設定すると、アドバタイズメントでのローカル AS 番号の付加が抑制されます。また、ルート サーバーのクライアントであるピアに対して、広告するメトリックにローカル AS を表示しないように show route advertising-protocol bgp peer CLI コマンドを変更しました。

その他の属性

  • MULTI_EXIT_DISC 属性(オプション、非遷移型)は、受信時に伝送される必要があります。

  • アドバタイズ禁止、輸出禁止、非移行性拡張コミュニティを含むすべてのコミュニティ属性は、受信時に伝送する必要があります。

  • 蓄積された IGP(AIGP)属性(オプション、非遷移的)は、受信として伝送する必要があります。

    注:

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

BGP ルート サーバー クライアント RIB

ルート サーバー クライアント固有 RIB は、BGP Loc-RIB の異なるビューであり、同じ宛先に対して他のビューとは異なるルートを含むことができます。ルート サーバー クライアントは、そのピア グループを通じて、個々のクライアント固有のビューまたは共有の共通 RIB に関連付けることができます。

同じ宛先に対して異なるクライアントに異なるルートを広告する機能を提供するためには、同じ宛先に対して異なるクライアント コンテキストまたはグループ コンテキストで BGP ルート選択の複数のインスタンスが発生することを許容することが概念的に必要です。

BGP ルート サーバーは、クライアントまたはグループ単位のルート選択で柔軟にポリシーを制御するという高度な要件を実現するために、非転送ルーティング インスタンス(NFI)を用いて、BGP ルート選択、Loc-RIB、ポリシーなどの BGP パイプラインをマルチインスタンス化するアプローチを取っています。ルート サーバーは、別々の非転送ルーティング インスタンス内に設定された BGP グループ内でルート サーバー クライアントをグループ化するように構成されています。この方法は、ルーティング インスタンス内で動作する BGP がルート選択を行い、他のルーティング インスタンスで動作する BGP とは別の RIB を持っていることを利用します。

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

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

ポリシー制御のためのルート サーバーの構成には、次のような考慮事項があります。

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

  • ルート サーバー クライアントは、完全に一意の Loc-RIB ビューを受信するように、自身のルーティング インスタンス内で設定する必要があります。

  • ルート サーバー クライアントは、同じルーティング インスタンス内の異なる BGP ピア グループに設定し、同じ Loc-RIB ビューで異なるエクスポート ポリシーを設定する必要があります。

  • instance-anyルート サーバー クライアント別の RIB ビューがデフォルトで他のテーブルからすべてのルートを受信するために、 で instance-importポリシーのフルメッシュが構成されます。instance-any を含むポリシーで instance-import を構成する場合。

    • instance-any で使用することができます。

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

      • policy-statement ... from

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

      • policy-statement ... to

    • instance-any はパラメータを持ちません。

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

  • 多数の異なるルーティング インスタンスとピアグループを設定すると、規模や性能に影響を及ぼします。

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

変更履歴

サポートされる機能は、使用しているプラットフォームとリリースによって決まります。 特定の機能がお使いのプラットフォームでサポートされているかどうかを確認するには、 Feature Explorer をご利用ください。

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