Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

BGPルートリフレクタ

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

このトピックでは、BGPルートリフレクタを使用して、設定を簡素化し、スケーリングを支援する方法について説明します。

BGP自律システム(AS)では、すべてのAS境界ルーターにルートを分散する必要があります。BGP(境界ゲートウェイプロトコル)は、内部 BGP(IBGP)ピアリング セッションを通じてこれを実現します。デフォルトでは、あるIBGPピアから学習したルートは、他のIBGPピアにはアドバタイズされません。この制限では、ルートを完全に可視化するために、AS内のすべてのルーター間でIBGPセッションのフルメッシュが必要です。

ただし、フルメッシュを維持すると、構成が複雑になり、拡張性が制限されます。新しいIBGPピアは、AS内の他のすべてのピアとセッションを確立する必要があります。フルメッシュに必要なセッションの総数は、v*(v-1)/2の式を使用して計算されます。 ここで、v はBGPピアの数を表します。

フルメッシュでは、構成のオーバーヘッドに加えて、ルートのスケーリングも向上する可能性があります。すべてのIBGPピアは、ネットワーク内のその場所に最適ではないルートが多くであっても、すべてのルートを受信します。

RFC 4456で定義されているBGPルートリフレクションは、IBGPフルメッシュトポロジーのスケーラビリティの課題に対処します。ルートリフレクションにより、ルートリフレクタ(RR)と呼ばれるルーターが、あるIBGPピアから他のIBGPピアに学習したルートを再分配することができます。これにより、ルートのIBGPからIBGPへのアドバタイズを防止するデフォルトのBGPルールが緩和されます。

ルートリフレクションはルーティングループの可能性をもたらすため、RFC 4456では、ループ防止と一貫したパス選択を保証する2つの新しいBGPパス属性を定義しています。

  • ORIGINATOR_ID - 最初にルートをアドバタイズしたBGPネイバーのルーター IDを識別します。ORIGINATOR_ID属性は、ルートが最初に反映された場合にのみアタッチされます。

  • CLUSTER_LIST - ネットワークを伝送するルートを反映したルートリフレクタのクラスター IDを記録します。

これらの属性が BGP 最適パス選択にどのように影響するかについては、 BGP パス選択についてを参照してください。

内部BGP(IBGP)フルメッシュ要件により、ほとんどのネットワークではルートリフレクタを使用して設定を簡素化します。ルートリフレクタを使用して、ルーターはクラスターにグループ化され、自律システムに固有の数値識別子によって識別されます。クラスター内では、単一のルーター(ルートリフレクタ)から各内部ピアへのBGPセッションを設定する必要があります。この設定では、IBGPフルメッシュ要件を満たしています。

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

注:

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

図1:シンプルなルートリフレクタトポロジー(1つのクラスター) Route Reflector topology with central RR node redistributing BGP routes to client routers in a cluster.

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

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

図2:基本的なルートリフレクション(完全にメッシュ化された複数のクラスター) Puzzle with circles labeled RR 1 to RR 4 connected by lines and arrows indicating directions or paths.

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

注:

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

クライアントは、ルートリフレクタからルートを受信するIBGPルーターです。非クライアントは、別のIBGPネイバーです。ルートリフレクタは、非クライアントから学習したルートを、非クライアントに対してではなく、そのクライアントに対してのみアドバタイズします。ただし、ルートリフレクタは、クライアントから学習したルートをクライアントと非クライアントの両方にアドバタイズします。

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

図3:階層ルートリフレクション(クラスターのクラスター) Hierarchical network topology with Route Reflectors RR 1, RR 2, RR 3, and RR 4 in BGP, showing cluster connections.

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

非転送ルートリフレクタ

多くのネットワークでは、BGPルートリフレクタはスケーラビリティを向上させるために導入されていますが、トラフィックの転送には直接関与していません。これらのルートリフレクタは、データ転送に関与することなくBGPコントロールプレーン機能を維持します。ルートリフレクタがトラフィックパスにない場合、リフレクタは、リフレクションしたルートを転送テーブルにインストールする必要はありません。このようなデバイスは、非転送ルートリフレクタと呼ばれます。

非転送ルートリフレクタは、以下のいずれかの方法で設定できます。

  • no-installステートメントの使用 – Junos OSリリース15.1で導入されたno-installステートメントは、BGPルートが転送テーブルにインストールされないようにします。このオプションは、以下の階層レベルでアドレスファミリーごとに設定できます。

  • 転送テーブルエクスポートポリシーの使用 – 15.1より前のJunos OSリリースでは、BGPから学習したルートを拒否する転送テーブルエクスポートポリシーを設定することで、同様の動作を実現できます。

非転送ルートリフレクタは、特に大規模なサービスプロバイダネットワークにおいて、主にコントロールプレーンルーターとして機能するデバイスのリソース負荷を軽減するのに役立ちます。

例:ルートリフレクタの設定

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

要件

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

概要

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

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

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

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

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

ヒント:

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

図4:ルートリフレクタNetwork topology showing BGP Route Reflector setup in AS 17. Route Reflector 192.168.6.5 connects to client routers 192.168.5.5, 192.168.0.1, 192.163.6.4, and 192.168.40.4.を使用したIBGPネットワーク

設定

手順

CLIクイックコンフィグレーション

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

注:

この例では、 send-ospf エクスポートポリシーを使用して、OSPFで学習したルートをBGPに再配布します。

通常、ルートリフレクタの動作には、OSPF の BGP への再配布は必要ありません。ここでは、ルートリフレクタがクライアントにアドバタイズできるBGPルートを作成するためにのみ使用し、シンプルなラボトポロジーでルートリフレクションがどのように動作するかを観察できるようにします。

実稼働環境では、ルートリフレクタは通常、クライアントから学習したBGPルートを反映し、この動作が特に望ましくない限り、IGPルートをBGPに再配布しません。

この例では、ルーターA、D、Eは非クライアントIBGPピアであり、ルートリフレクタクライアントクラスター外で一貫したルート交換を確保するためにフルメッシュで構成されています。

デバイスA

デバイスB

デバイスC

デバイスD

デバイスE

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

ルートリフレクタの設定

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

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

ジュニパーネットワークスデバイスAをルートリフレクタとして使用して、ネットワークにIBGPを設定するには:

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

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

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

  3. スタティックルーティングまたは内部ゲートウェイプロトコル(IGP)を設定します。

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

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

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

結果

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

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

注:

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

クライアントピアの設定

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

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

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

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

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

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

  3. OSPFを設定します。

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

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

結果

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

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

注:

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

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

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

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

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

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

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

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

  3. OSPFを設定します。

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

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

結果

設定モードから、 show interfacesshow protocolsshow policy-optionsshow 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)ルーティングデバイスが完全にメッシュ化されていない場合のループ防止です。これを実現するために、RR は通常の BGP 操作のルールの 1 つを破ります。 RR は、内部 BGPピアから学習したルートを他の内部 BGP ピアに再アドバタイズします。

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

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

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

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

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

設定

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

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

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

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

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

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

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

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

RR は、クラスター ID をクライアント 2 に反映する前に、クライアント 1 に関連するクラスター ID をクラスター リストに記入します。クライアント 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の10.13.1.3とRR1-RR2の10.12.1.2という2種類のクラスターIDが割り当てられています。

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

5を見てください。

図5:2つの異なるクラスターのルートリフレクタ Network topology diagram with routers: R0 Non-client 192.168.16.1, RR1 192.168.20.1, RR2 192.168.40.1, R3 Client 192.168.48.1, R4 Client 192.168.32.1. R0 connects to RR1, RR1 connects to RR2 and R3, RR2 connects to R4.

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

設定

前提条件

複数のクラスターでBGPルートリフレクタを設定する前に、すべてのBGPピア間にIP到達可能性が存在することを確認します。この例では、OSPFやIS-ISなどの内部ゲートウェイプロトコル(IGP)が、IBGPセッションに使用されるループバックインターフェイス間の到達性を提供します。インターフェイスとIGPの設定は、設定されていると想定されており、ここでは示されていません。

手順

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に送信すると、ルートにはRR1-R3のクラスターIDである10.13.1.3クラスターIDが付加されます。

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

目的

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

アクション

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

意味

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

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

ASボーダールーターでのルートリフレクション

ほとんどの導入環境では、BGPルートリフレクタは内部BGP(IBGP)ルーターとしてのみ動作します。ただし、一部のネットワーク設計では、ルートリフレクタが自律システム境界ルーター(ASBR)として機能し、外部BGP(EBGP)ピアリングセッションを維持することもあります。

Junos OSルーターが両方の役割を果たし、EBGPピアからルートを受信する場合、 cluster オプションを使用してルートリフレクタクライアントとして設定されたIBGPピアにそのルートをルーターアドバタイズする場合は、特別な考慮事項が適用されます。この場合、Junos OSはIBGPクライアントにルートを反映する際に、ORIGINATOR_IDとCLUSTER_LISTパス属性をアタッチします。

BGPルートリフレクションを定義するRFC 4456は、EBGPを介して学習し、その後、デュアルロールASBRとルートリフレクタによってIBGPクライアントに反映されるルートに期待される動作を明示的に指定していません。Junos OS は、ルーティングループを防ぎ、自律システム内で決定論的なパス選択を維持するために、このシナリオでルートリフレクション属性を一貫して適用します。

ASボーダールーターにルートリフレクションを展開する場合は、ルーティングポリシー、パス選択、障害シナリオを慎重に検討し、反映されたルートによって意図しないルーティング動作が発生しないようにしてください。

変更履歴テーブル

サポートされる機能は、使用しているプラットフォームとリリースによって決まります。 機能エクスプローラー を使用して、機能がお使いのプラットフォームでサポートされているかどうかを確認します。

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