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つのクラスタ)](../concept/../../images/g015018.gif)
図 1は、クラスタ127のルートリフレクタとして設定されたルーターRRを示しています。その他のルーターは、クラスタ内の内部ピアとして指定されています。BGPルートは、いずれかの内部ピアによってルーターRRにアドバタイズされます。その後RRは、クラスタ内の他のすべてのピアに再度アドバタイズします。
図 2ルートリフレクタのフルメッシュを設定することで、複数のクラスタを設定し、それらをリンクすることができます(を参照)。
![基本的なルートリフレクション(複数のクラスタ)](../concept/../../images/g015019.gif)
図 2は、ルートリフレクタRR1、RR2、RR3、およびRR4をフルメッシュされた内部ピアとして示しています。ルーターがRR1にルートをアドバタイズすると、RR1が他のルートリフレクタにルートを再度アドバタイズします。これにより、AS内の残りのルーターにルートが再度アドバタイズされます。ルートリフレクションにより、フルメッシュ要件で発生するスケーリング問題なしに、AS全体にルートが伝送されます。
複数のクラスタをサポートするルートリフレクタは、非クライアントルーターから同じクラスタIDを持つルートを受信しません。そのため、他のクラスタへのルートを反映するために、冗長RRに異なるクラスタIDを設定する必要があります。
しかし、クラスタが大きくなるにつれ、ルートリフレクタを使用したフルメッシュは、ルートリフレクタ間のフルメッシュと同様に、拡張が困難になります。図 3この問題を相殺するために、ルーターのクラスタを、階層ルートリフレクションを行うために、クラスタのクラスタにまとめてグループ化することができます(を参照)。
![階層ルートリフレクション(クラスタのクラスタ)](../concept/../../images/g015020.gif)
図 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.5
neighbor 192.168.0.1
RRルートリフレクタクライアントとするために、機器Dのコンフィグレーションから121ステートメントを削除し、機器Eのコンフィグレーションから343ステートメントを削除してください。
![ルートリフレクタを使用したIBGPネットワーク](../example/../../images/g040867.gif)
設定
手順
CLIクイック構成
この例をすばやく設定するには、次のコマンドをコピーしてテキストファイルに貼り付け、改行を削除して、ネットワーク構成に合わせて必要な詳細を変更し、[edit]
階層レベルのCLIにコマンドをコピー&ペーストしてください。
1 デバイスA 1
set interfaces fe-0/0/0 unit 1 description to-B set interfaces fe-0/0/0 unit 1 family inet address 10.10.10.1/30 set interfaces fe-0/0/1 unit 3 description to-D set interfaces fe-0/0/1 unit 3 family inet address 10.10.10.9/30 set interfaces lo0 unit 1 family inet address 192.168.6.5/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 192.168.6.5 set protocols bgp group internal-peers export send-ospf set protocols bgp group internal-peers cluster 192.168.6.5 set protocols bgp group internal-peers neighbor 192.163.6.4 set protocols bgp group internal-peers neighbor 192.168.40.4 set protocols bgp group internal-peers neighbor 192.168.0.1 set protocols bgp group internal-peers neighbor 192.168.5.5 set protocols ospf area 0.0.0.0 interface lo0.1 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.1 set protocols ospf area 0.0.0.0 interface fe-0/0/1.3 set policy-options policy-statement send-ospf term 2 from protocol ospf set policy-options policy-statement send-ospf term 2 then accept set routing-options router-id 192.168.6.5 set routing-options autonomous-system 17
1 デバイスB 1
set interfaces fe-0/0/0 unit 2 description to-A set interfaces fe-0/0/0 unit 2 family inet address 10.10.10.2/30 set interfaces fe-0/0/1 unit 5 description to-C set interfaces fe-0/0/1 unit 5 family inet address 10.10.10.5/30 set interfaces lo0 unit 2 family inet address 192.163.6.4/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 192.163.6.4 set protocols bgp group internal-peers export send-ospf set protocols bgp group internal-peers neighbor 192.168.6.5 set protocols ospf area 0.0.0.0 interface lo0.2 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.2 set protocols ospf area 0.0.0.0 interface fe-0/0/1.5 set policy-options policy-statement send-ospf term 2 from protocol ospf set policy-options policy-statement send-ospf term 2 then accept set routing-options router-id 192.163.6.4 set routing-options autonomous-system 17
1 デバイスC 1
set interfaces fe-0/0/0 unit 6 description to-B set interfaces fe-0/0/0 unit 6 family inet address 10.10.10.6/30 set interfaces lo0 unit 3 family inet address 192.168.40.4/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 192.168.40.4 set protocols bgp group internal-peers export send-ospf set protocols bgp group internal-peers neighbor 192.168.6.5 set protocols ospf area 0.0.0.0 interface lo0.3 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.6 set policy-options policy-statement send-ospf term 2 from protocol ospf set policy-options policy-statement send-ospf term 2 then accept set routing-options router-id 192.168.40.4 set routing-options autonomous-system 17
1 デバイスD 1
set interfaces fe-0/0/0 unit 4 description to-A set interfaces fe-0/0/0 unit 4 family inet address 10.10.10.10/30 set interfaces fe-0/0/1 unit 7 description to-E set interfaces fe-0/0/1 unit 7 family inet address 10.10.10.13/30 set interfaces lo0 unit 4 family inet address 192.168.0.1/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 192.168.0.1 set protocols bgp group internal-peers export send-ospf set protocols bgp group internal-peers neighbor 192.168.6.5 set protocols bgp group internal-peers neighbor 192.168.5.5 set protocols ospf area 0.0.0.0 interface lo0.4 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.4 set protocols ospf area 0.0.0.0 interface fe-0/0/1.7 set policy-options policy-statement send-ospf term 2 from protocol ospf set policy-options policy-statement send-ospf term 2 then accept set routing-options router-id 192.168.0.1 set routing-options autonomous-system 17
1 デバイスE 1
set interfaces fe-0/0/0 unit 8 description to-D set interfaces fe-0/0/0 unit 8 family inet address 10.10.10.14/30 set interfaces lo0 unit 5 family inet address 192.168.5.5/32 set protocols bgp group internal-peers type internal set protocols bgp group internal-peers local-address 192.168.5.5 set protocols bgp group internal-peers export send-ospf set protocols bgp group internal-peers neighbor 192.168.0.1 set protocols bgp group internal-peers neighbor 192.168.6.5 set protocols ospf area 0.0.0.0 interface lo0.5 passive set protocols ospf area 0.0.0.0 interface fe-0/0/0.8 set policy-options policy-statement send-ospf term 2 from protocol ospf set policy-options policy-statement send-ospf term 2 then accept set routing-options router-id 192.168.5.5 set routing-options autonomous-system 17
ステップバイステップでの手順
ルートリフレクタを設定する
ステップバイステップでの手順
次の例では、設定階層のいくつかのレベルに移動する必要があります。CLIのナビゲーションについては、Junos OS CLIユーザーガイドの 設定モードでCLIエディターを使用する を参照してください。
Juniper Networks デバイス A をルートリフレクタとして使用し、ネットワークに IBGP を設定します。
インターフェイスを設定します。
[edit interfaces] user@A# set fe-0/0/0 unit 1 description to-B user@A# set fe-0/0/0 unit 1 family inet address 10.10.10.1/30 user@A# set fe-0/0/1 unit 3 description to-D user@A# set fe-0/0/1 unit 3 family inet address 10.10.10.9/30 user@A# set lo0 unit 1 family inet address 192.168.6.5/32
クラスタ識別子や自律システム(AS)内のすべてのIBGP対応機器との近隣関係などのBGPを設定します。
また、OSPFのルートをBGPに再配布するポリシーも適用します。
[edit protocols bgp group internal-peers] user@A# set type internal user@A# set local-address 192.168.6.5 user@A# set export send-ospf user@A# set cluster 192.168.6.5 user@A# set neighbor192.163.6.4 user@A# set neighbor 192.168.40.4 user@A# set neighbor 192.168.0.1 user@A# set neighbor 192.168.5.5
スタティックルーティングまたはIGP(Interior Gateway Protocol)を設定する。
この例では、OSPFを使用しています。
[edit protocols ospf area 0.0.0.0] user@A# set interface lo0.1 passive user@A# set interface fe-0/0/0.1 user@A# set interface fe-0/0/1.3
OSPF ルートを BGP に再分配するポリシーを設定します。
[edit policy-options policy-statement send-ospf term 2] user@A# set from protocol ospf user@A# set then accept
ルーターIDと自律システム(AS)番号を設定する。
[edit routing-options] user@A# set router-id 192.168.6.5 user@A# set autonomous-system 17
結果
設定モードから、show interfaces
、show protocols
、show policy-options
、およびshow routing-options
のコマンドを入力して設定を確認します。出力結果に意図した設定内容が表示されない場合は、この例の手順を繰り返して設定を修正します。
user@A# show interfaces fe-0/0/0 { unit 1 { description to-B; family inet { address 10.10.10.1/30; } } } fe-0/0/1 { unit 3 { description to-D; family inet { address 10.10.10.9/30; } } } lo0 { unit 1 { family inet { address 192.168.6.5/32; } } }
user@A# show protocols bgp { group internal-peers { type internal; local-address 192.168.6.5; export send-ospf; cluster 192.168.6.5; neighbor 192.163.6.4; neighbor 192.168.40.4; neighbor 192.168.0.1; neighbor 192.168.5.5; } } ospf { area 0.0.0.0 { interface lo0.1 { passive; } interface fe-0/0/0.1; interface fe-0/0/1.3; } }
user@A# show policy-options policy-statement send-ospf { term 2 { from protocol ospf; then accept; } }
user@A# show routing-options router-id 192.168.6.5; autonomous-system 17;
デバイスの設定が完了したら、設定モードから commit
を入力します。
他の非クライアントデバイスが Juniper Networks 製である場合は、構成するクラスタ内の各非クライアント BGP ピアについて、これらの手順を繰り返します。それ以外の場合は、デバイスのマニュアルを参照してください。
クライアントピアの設定
ステップバイステップでの手順
次の例では、設定階層のいくつかのレベルに移動する必要があります。CLIのナビゲーションについては、Junos OS CLIユーザーガイドの 設定モードでCLIエディターを使用する を参照してください。
クライアントピアを設定するには
インターフェイスを設定します。
[edit interfaces] user@B# set fe-0/0/0 unit 2 description to-A user@B# set fe-0/0/0 unit 2 family inet address 10.10.10.2/30 user@B# set fe-0/0/1 unit 5 description to-C user@B# set fe-0/0/1 unit 5 family inet address 10.10.10.5/30 user@B# set lo0 unit 2 family inet address 192.163.6.4/32
ルートリフレクタとのBGPネイバー関係を設定します。
また、OSPFのルートをBGPに再配布するポリシーも適用します。
[edit protocols bgp group internal-peers] user@B# set type internal user@B# set local-address 192.163.6.4 user@B# set export send-ospf user@B# set neighbor 192.168.6.5
OSPFを設定します。
[edit protocols ospf area 0.0.0.0] user@B# set interface lo0.2 passive user@B# set interface fe-0/0/0.2 user@B# set interface fe-0/0/1.5
OSPF ルートを BGP に再分配するポリシーを設定します。
[edit policy-options policy-statement send-ospf term 2] user@B# set from protocol ospf user@B# set then accept
ルーターID、AS番号を設定する。
[edit routing-options] user@B# set router-id 192.163.6.4 user@B# set autonomous-system 17
結果
設定モードから、show interfaces
、show protocols
、show policy-options
、およびshow routing-options
のコマンドを入力して設定を確認します。出力結果に意図した設定内容が表示されない場合は、この例の手順を繰り返して設定を修正します。
user@B# show interfaces fe-0/0/0 { unit 2 { description to-A; family inet { address 10.10.10.2/30; } } } fe-0/0/1 { unit 5 { description to-C; family inet { address 10.10.10.5/30; } } } lo0 { unit 2 { family inet { address 192.163.6.4/32; } } }
user@B# show protocols bgp { group internal-peers { type internal; local-address 192.163.6.4; export send-ospf; neighbor 192.168.6.5; } } ospf { area 0.0.0.0 { interface lo0.2 { passive; } interface fe-0/0/0.2; interface fe-0/0/1.5; } }
user@B# show policy-options policy-statement send-ospf { term 2 { from protocol ospf; then accept; } }
user@B# show routing-options router-id 192.163.6.4; autonomous-system 17;
デバイスの設定が完了したら、設定モードから commit
を入力します。
他のクライアントデバイスが Juniper Networks 製の場合、設定するクラスタ内の各クライアント BGP ピアについて、これらのステップを繰り返します。それ以外の場合は、デバイスのマニュアルを参照してください。
非クライアントピアの設定
ステップバイステップでの手順
次の例では、設定階層のいくつかのレベルに移動する必要があります。CLIのナビゲーションについては、Junos OS CLIユーザーガイドの 設定モードでCLIエディターを使用する を参照してください。
非クライアントピアを設定するには
インターフェイスを設定します。
[edit interfaces] user@D# set fe-0/0/0 unit 4 description to-A user@D# set fe-0/0/0 unit 4 family inet address 10.10.10.10/30 user@D# set fe-0/0/1 unit 7 description to-E user@D# set fe-0/0/1 unit 7 family inet address 10.10.10.13/30 user@D# set lo0 unit 4 family inet address 192.168.0.1/32
RRルートリフレクタおよび他の非クライアントピアとのBGPネイバーリレーションを設定します。
また、OSPFのルートをBGPに再配布するポリシーも適用します。
[edit protocols bgp group internal-peers] user@D# set type internal user@D# set local-address 192.168.0.1 user@D# set export send-ospf user@D# set neighbor 192.168.6.5 user@D# set neighbor 192.168.5.5
OSPFを設定します。
[edit protocols ospf area 0.0.0.0] user@D# set interface lo0.4 passive user@D# set interface fe-0/0/0.4 user@D# set interface fe-0/0/1.7
OSPF ルートを BGP に再分配するポリシーを設定します。
[edit policy-options policy-statement send-ospf term 2] user@D# set from protocol ospf user@D# set then accept
ルーターID、AS番号を設定する。
[edit routing-options] user@D# set router-id 192.168.0.1 user@D# set autonomous-system 17
結果
設定モードから、show interfaces
、show protocols
、show policy-options
、およびshow routing-options
のコマンドを入力して設定を確認します。出力結果に意図した設定内容が表示されない場合は、この例の手順を繰り返して設定を修正します。
user@D# show interfaces fe-0/0/0 { unit 4 { description to-A; family inet { address 10.10.10.10/30; } } } fe-0/0/1 { unit 7 { description to-E; family inet { address 10.10.10.13/30; } } } lo0 { unit 4 { family inet { address 192.168.0.1/32; } } }
user@D# show protocols bgp { group internal-peers { type internal; local-address 192.168.0.1; export send-ospf; neighbor 192.168.6.5; neighbor 192.168.5.5; } } ospf { area 0.0.0.0 { interface lo0.4 { passive; } interface fe-0/0/0.4; interface fe-0/0/1.7; } }
user@D# show policy-options policy-statement send-ospf { term 2 { from protocol ospf; then accept; } }
user@D# show routing-options router-id 192.168.0.1; autonomous-system 17;
デバイスの設定が完了したら、設定モードから commit
を入力します。
他の非クライアントデバイスが Juniper Networks 製である場合は、構成するクラスタ内の各非クライアント BGP ピアについて、これらの手順を繰り返します。それ以外の場合は、デバイスのマニュアルを参照してください。
検証
設定が正常に機能していることを確認します。
BGP ネイバーの検証
目的
設定したインターフェイスでBGPが動作し,各近傍アドレスに対してBGPセッションが確立していることを確認します。
アクション
動作モードからshow bgp neighbor
コマンドを入力します。
user@A> show bgp neighbor Peer: 192.163.6.4+179 AS 17 Local: 192.168.6.5+62857 AS 17 Type: Internal State: Established (route reflector client)Flags: <Sync> Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Export: [ send-ospf ] Options: <Preference LocalAddress Cluster Refresh> Local Address: 192.168.6.5 Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 192.163.6.4 Local ID: 192.168.6.5 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 0 BFD: disabled, down NLRI for restart configured on peer: inet-unicast NLRI advertised by peer: inet-unicast NLRI for this session: inet-unicast Peer supports Refresh capability (2) Restart time configured on the peer: 120 Stale routes from peer are kept for: 300 Restart time requested by this peer: 120 NLRI that peer supports restart for: inet-unicast NLRI that restart is negotiated for: inet-unicast NLRI of received end-of-rib markers: inet-unicast NLRI of all end-of-rib markers sent: inet-unicast Peer supports 4 byte AS extension (peer-as 17) Peer does not support Addpath Table inet.0 Bit: 10000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 0 Received prefixes: 6 Accepted prefixes: 1 Suppressed due to damping: 0 Advertised prefixes: 6 Last traffic (seconds): Received 5 Sent 3 Checked 19 Input messages: Total 2961 Updates 7 Refreshes 0 Octets 56480 Output messages: Total 2945 Updates 6 Refreshes 0 Octets 56235 Output Queue[0]: 0 Peer: 192.168.0.1+179 AS 17 Local: 192.168.6.5+60068 AS 17 Type: Internal State: Established (route reflector client)Flags: <Sync> Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Export: [ send-ospf ] Options: <Preference LocalAddress Cluster Refresh> Local Address: 192.168.6.5 Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 192.168.0.1 Local ID: 192.168.6.5 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 3 BFD: disabled, down NLRI for restart configured on peer: inet-unicast NLRI advertised by peer: inet-unicast NLRI for this session: inet-unicast Peer supports Refresh capability (2) Restart time configured on the peer: 120 Stale routes from peer are kept for: 300 Restart time requested by this peer: 120 NLRI that peer supports restart for: inet-unicast NLRI that restart is negotiated for: inet-unicast NLRI of received end-of-rib markers: inet-unicast NLRI of all end-of-rib markers sent: inet-unicast Peer supports 4 byte AS extension (peer-as 17) Peer does not support Addpath Table inet.0 Bit: 10000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 0 Received prefixes: 6 Accepted prefixes: 1 Suppressed due to damping: 0 Advertised prefixes: 6 Last traffic (seconds): Received 18 Sent 20 Checked 12 Input messages: Total 15 Updates 5 Refreshes 0 Octets 447 Output messages: Total 554 Updates 4 Refreshes 0 Octets 32307 Output Queue[0]: 0 Peer: 192.168.5.5+57458 AS 17 Local: 192.168.6.5+179 AS 17 Type: Internal State: Established (route reflector client)Flags: <Sync> Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Export: [ send-ospf ] Options: <Preference LocalAddress Cluster Refresh> Local Address: 192.168.6.5 Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 192.168.5.5 Local ID: 192.168.6.5 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 2 BFD: disabled, down NLRI for restart configured on peer: inet-unicast NLRI advertised by peer: inet-unicast NLRI for this session: inet-unicast Peer supports Refresh capability (2) Restart time configured on the peer: 120 Stale routes from peer are kept for: 300 Restart time requested by this peer: 120 NLRI that peer supports restart for: inet-unicast NLRI that restart is negotiated for: inet-unicast NLRI of received end-of-rib markers: inet-unicast NLRI of all end-of-rib markers sent: inet-unicast Peer supports 4 byte AS extension (peer-as 17) Peer does not support Addpath Table inet.0 Bit: 10000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 0 Received prefixes: 7 Accepted prefixes: 7 Suppressed due to damping: 0 Advertised prefixes: 6 Last traffic (seconds): Received 17 Sent 3 Checked 9 Input messages: Total 2967 Updates 7 Refreshes 0 Octets 56629 Output messages: Total 2943 Updates 6 Refreshes 0 Octets 56197 Output Queue[0]: 0 Peer: 192.168.40.4+53990 AS 17 Local: 192.168.6.5+179 AS 17 Type: Internal State: Established (route reflector client)Flags: <Sync> Last State: OpenConfirm Last Event: RecvKeepAlive Last Error: None Export: [ send-ospf ] Options: <Preference LocalAddress Cluster Refresh> Local Address: 192.168.6.5 Holdtime: 90 Preference: 170 Number of flaps: 0 Peer ID: 192.168.40.4 Local ID: 192.168.6.5 Active Holdtime: 90 Keepalive Interval: 30 Peer index: 1 BFD: disabled, down NLRI for restart configured on peer: inet-unicast NLRI advertised by peer: inet-unicast NLRI for this session: inet-unicast Peer supports Refresh capability (2) Restart time configured on the peer: 120 Stale routes from peer are kept for: 300 Restart time requested by this peer: 120 NLRI that peer supports restart for: inet-unicast NLRI that restart is negotiated for: inet-unicast NLRI of received end-of-rib markers: inet-unicast NLRI of all end-of-rib markers sent: inet-unicast Peer supports 4 byte AS extension (peer-as 17) Peer does not support Addpath Table inet.0 Bit: 10000 RIB State: BGP restart is complete Send state: in sync Active prefixes: 0 Received prefixes: 7 Accepted prefixes: 7 Suppressed due to damping: 0 Advertised prefixes: 6 Last traffic (seconds): Received 5 Sent 23 Checked 52 Input messages: Total 2960 Updates 7 Refreshes 0 Octets 56496 Output messages: Total 2943 Updates 6 Refreshes 0 Octets 56197 Output Queue[0]: 0
BGP グループの検証
目的
BGP グループが正しく設定されていることを確認します。
アクション
動作モードからshow bgp group
コマンドを入力します。
user@A> show bgp group Group Type: Internal AS: 17 Local AS: 17 Name: internal-peers Index: 0 Flags: <> Export: [ send-ospf ] Options: <Cluster> Holdtime: 0 Total peers: 4 Established: 4 192.163.6.4+179 192.168.40.4+53990 192.168.0.1+179 192.168.5.5+57458 inet.0: 0/26/16/0 Groups: 1 Peers: 4 External: 0 Internal: 4 Down peers: 0 Flaps: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 26 0 0 0 0 0
BGP サマリー情報の検証
目的
BGP の設定が正しいことを確認します。
アクション
動作モードからshow bgp summary
コマンドを入力します。
user@A> show bgp summary Groups: 1 Peers: 4 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 26 0 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 192.163.6.4 17 2981 2965 0 0 22:19:15 0/6/1/0 0/0/0/0 192.168.0.1 17 36 575 0 0 13:43 0/6/1/0 0/0/0/0 192.168.5.5 17 2988 2964 0 0 22:19:10 0/7/7/0 0/0/0/0 192.168.40.4 17 2980 2964 0 0 22:19:14 0/7/7/0 0/0/0/0
ルーティング テーブル情報の検証
目的
ルーティング テーブルに IBGP ルートが含まれていることを確認します。
アクション
動作モードからshow route
コマンドを入力します。
user@A> show route inet.0: 12 destinations, 38 routes (12 active, 0 holddown, 10 hidden) + = Active Route, - = Last Active, * = Both 10.10.10.0/30 *[Direct/0] 22:22:03 > via fe-0/0/0.1 [BGP/170] 22:20:55, MED 2, localpref 100, from 192.168.40.4 AS path: I > to 10.10.10.2 via fe-0/0/0.1 [BGP/170] 22:20:51, MED 3, localpref 100, from 192.168.5.5 AS path: I > to 10.10.10.10 via fe-0/0/1.3 10.10.10.1/32 *[Local/0] 22:22:03 Local via fe-0/0/0.1 10.10.10.4/30 *[OSPF/10] 22:21:13, metric 2 > to 10.10.10.2 via fe-0/0/0.1 [BGP/170] 22:20:51, MED 4, localpref 100, from 192.168.5.5 AS path: I > to 10.10.10.10 via fe-0/0/1.3 10.10.10.8/30 *[Direct/0] 22:22:03 > via fe-0/0/1.3 [BGP/170] 22:20:51, MED 2, localpref 100, from 192.168.5.5 AS path: I > to 10.10.10.10 via fe-0/0/1.3 [BGP/170] 22:20:55, MED 3, localpref 100, from 192.168.40.4 AS path: I > to 10.10.10.2 via fe-0/0/0.1 10.10.10.9/32 *[Local/0] 22:22:03 Local via fe-0/0/1.3 10.10.10.12/30 *[OSPF/10] 22:21:08, metric 2 > to 10.10.10.10 via fe-0/0/1.3 [BGP/170] 22:20:55, MED 4, localpref 100, from 192.168.40.4 AS path: I > to 10.10.10.2 via fe-0/0/0.1 192.163.6.4/32 *[OSPF/10] 22:21:13, metric 1 > to 10.10.10.2 via fe-0/0/0.1 [BGP/170] 22:20:55, MED 1, localpref 100, from 192.168.40.4 AS path: I > to 10.10.10.2 via fe-0/0/0.1 [BGP/170] 22:20:51, MED 3, localpref 100, from 192.168.5.5 AS path: I > to 10.10.10.10 via fe-0/0/1.3 192.168.0.1/32 *[OSPF/10] 22:21:08, metric 1 > to 10.10.10.10 via fe-0/0/1.3 [BGP/170] 22:20:51, MED 1, localpref 100, from 192.168.5.5 AS path: I > to 10.10.10.10 via fe-0/0/1.3 [BGP/170] 22:20:55, MED 3, localpref 100, from 192.168.40.4 AS path: I > to 10.10.10.2 via fe-0/0/0.1 192.168.5.5/32 *[OSPF/10] 22:21:08, metric 2 > to 10.10.10.10 via fe-0/0/1.3 [BGP/170] 00:15:24, MED 1, localpref 100, from 192.168.0.1 AS path: I > to 10.10.10.10 via fe-0/0/1.3 [BGP/170] 22:20:55, MED 4, localpref 100, from 192.168.40.4 AS path: I > to 10.10.10.2 via fe-0/0/0.1 192.168.6.5/32 *[Direct/0] 22:22:04 > via lo0.1 [BGP/170] 22:20:51, MED 2, localpref 100, from 192.168.5.5 AS path: I > to 10.10.10.10 via fe-0/0/1.3 [BGP/170] 22:20:55, MED 2, localpref 100, from 192.168.40.4 AS path: I > to 10.10.10.2 via fe-0/0/0.1 192.168.40.4/32 *[OSPF/10] 22:21:13, metric 2 > to 10.10.10.2 via fe-0/0/0.1 [BGP/170] 22:20:55, MED 1, localpref 100, from 192.163.6.4 AS path: I > to 10.10.10.2 via fe-0/0/0.1 [BGP/170] 22:20:51, MED 4, localpref 100, from 192.168.5.5 AS path: I > to 10.10.10.10 via fe-0/0/1.3 224.0.0.5/32 *[OSPF/10] 22:22:07, metric 1 MultiRecv
2 つの異なるクラスターに属するルートリフレクタを理解する
ルートリフレクションの目的は、内部 BGP(IBGP)ルーティングデバイスが完全にメッシュ化されていない場合のループ防止です。これを実現するために、RR は通常の BGP 操作のルールの 1 つを破っています。内部の BGP ピアから学習したルートを、他の内部 BGP ピアに再告知します。
通常、1 つの RR は 1 つのクラスタにしか属しません。例えば、階層型 RR の設計において、第 2 階層の RR は第 1 階層の RR のクライアントになることはできても、お互いにクライアントになることはできないと考えます。
しかし、2 つの RR が互いのクライアントであり、あるクラスタから別のクラスタにルートが反映されている場合、クラスタリストには一方のクラスタ ID しか含まれません。これは、このケースでは、クラスタリストに 1 つのクラスタ ID があれば、ループ防止に十分だからです。
表 1は、ルートリフレクターが、反映されたルートのクラスタリストにクラスタ ID を記入する際に使用するルールを、要約しています。
ルートリフレクションのシナリオ |
設定 |
---|---|
クライアントの 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を見てください。
![2つの異なるクラスターでのルートリフレクタ](../example/../../images/g041322.png)
この例では、デバイスRR1とデバイスRR2でのBGPのコンフィギュレーションを示します。
設定
手順
CLIクイック構成
この例をすばやく設定するには、次のコマンドをコピーしてテキストファイルに貼り付け、改行を削除して、ネットワーク構成に合わせて必要な詳細を変更し、[edit]
階層レベルのCLIにコマンドをコピー&ペーストしてください。
デバイスRR1
set protocols bgp group RR1_client type internal set protocols bgp group RR1_client local-address 192.168.20.1 set protocols bgp group RR1_client cluster 10.13.1.3 set protocols bgp group RR1_client neighbor 192.168.48.1 set protocols bgp group Non_client type internal set protocols bgp group Non_client local-address 192.168.20.1 set protocols bgp group Non_client neighbor 192.168.16.1 set protocols bgp group RR1_to_RR2 type internal set protocols bgp group RR1_to_RR2 local-address 192.168.20.1 set protocols bgp group RR1_to_RR2 cluster 10.12.1.2 set protocols bgp group RR1_to_RR2 neighbor 192.168.40.1
デバイスRR2
set protocols bgp group RR2_client type internal set protocols bgp group RR2_client local-address 192.168.40.1 set protocols bgp group RR2_client cluster 10.24.2.4 set protocols bgp group RR2_client neighbor 192.168.32.1 set protocols bgp group RR2_to_RR1 type internal set protocols bgp group RR2_to_RR1 local-address 192.168.40.1 set protocols bgp group RR2_to_RR1 neighbor 192.168.20.1
デバイスRR1の設定
ステップバイステップでの手順
次の例では、設定階層のいくつかのレベルに移動する必要があります。CLIのナビゲーションについては、Junos OS CLIユーザーガイドの 設定モードでCLIエディターを使用する を参照してください。
デバイスRR1を設定するには:
-
デバイスR3とのピアリング関係を設定します。
[edit protocols bgp group RR1_client] user@RR1# set type internal user@RR1# set local-address 192.168.20.1 user@RR1# set cluster 10.13.1.3 user@RR1# set neighbor 192.168.48.1
-
デバイスR0とのピアリング関係を設定します。
[edit protocols bgp group Non_client] user@RR1# set type internal user@RR1# set local-address 192.168.20.1 user@RR1# set neighbor 192.168.16.1
-
デバイスRR2とのピアリング関係を設定します。
[edit protocols bgp group RR1_to_RR2] user@RR1# set type internal user@RR1# set local-address 192.168.20.1 user@RR1# set cluster 10.12.1.2 user@RR1# set neighbor 192.168.40.1
結果
設定モードから、show protocols
コマンドを入力して設定を確認します。出力結果に意図した設定内容が表示されない場合は、この例の手順を繰り返して設定を修正します。
user@RR1# show protocols bgp { group RR1_client { type internal; local-address 192.168.20.1; cluster 10.13.1.3; neighbor 192.168.48.1; } group Non_client { type internal; local-address 192.168.20.1; neighbor 192.168.16.1; } group RR1_to_RR2 { type internal; local-address 192.168.20.1; cluster 10.12.1.2; neighbor 192.168.40.1; } }
デバイスの設定が完了したら、設定モードから commit
を入力します。
デバイスRR2の設定
ステップバイステップでの手順
次の例では、設定階層のいくつかのレベルに移動する必要があります。CLIのナビゲーションについては、Junos OS CLIユーザーガイドの 設定モードでCLIエディターを使用する を参照してください。
デバイスRR2を設定するには:
-
デバイスR4とのピアリング関係を設定します。
[edit protocols bgp group RR2_client] user@RR2# set type internal user@RR2# set local-address 192.168.40.1 user@RR2# set cluster 10.24.2.4 user@RR2# set neighbor 192.168.32.1
-
デバイスRR1とのピアリング関係を設定します。
[edit protocols bgp group RR2_to_RR1] user@RR2# set type internal user@RR2# set local-address 192.168.40.1 user@RR2# set neighbor 192.168.20.1
結果
設定モードから、show protocols
コマンドを入力して設定を確認します。出力結果に意図した設定内容が表示されない場合は、この例の手順を繰り返して設定を修正します。
user@RR2# show protocols bgp { group RR2_client { type internal; local-address 192.168.40.1; cluster 10.24.2.4; neighbor 192.168.32.1; } group RR2_to_RR1 { type internal; local-address 192.168.40.1; neighbor 192.168.20.1; } }
デバイスの設定が完了したら、設定モードから commit
を入力します。
検証
設定が正常に機能していることを確認します。
ルート 10.3.3.3にアドバタイズされたクラスターーIDの確認
目的
設定したインターフェイスでBGPが動作し,各近傍アドレスに対してBGPセッションが確立していることを確認します。
アクション
動作モードからshow route advertising-protocol bgp neighbor-address
コマンドを入力します。
user@RR1> show route advertising-protocol bgp 192.168.40.1 active-path 10.3.3.3 extensive inet.0: 61 destinations, 61 routes (60 active, 0 holddown, 1 hidden) * 10.3.3.3/32 (1 entry, 1 announced) BGP group RR1_to_RR2 type Internal Nexthop: 192.168.48.1 Localpref: 100 AS path: [100] I Cluster ID: 10.13.1.3 Originator ID: 192.168.48.1
意味
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
コマンドを入力します。
user@RR1> show route advertising-protocol bgp 192.168.40.1 active-path 10.1.0.1/32 extensive inet.0: 61 destinations, 61 routes (60 active, 0 holddown, 1 hidden) * 10.1.0.1/32 (1 entry, 1 announced) BGP group RR1_to_RR2 type Internal Nexthop: 192.168.16.1 Localpref: 100 AS path: [100] I Cluster ID: 10.12.1.2 Originator ID: 192.168.16.1
意味
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 プレフィックスの場合:
user@host# set routing-options resolution rib bgp.l3vpn.0 resolution-ribs inet.0
-
レイヤー 2 VPN、または VPLS プレフィックスの場合:
user@host# set routing-options resolution rib bgp.l2vpn.0 resolution-ribs inet.0
-
EVPN プレフィックスの場合:
user@host# set routing-options resolution rib bgp.evpn.0 resolution-ribs inet.0
-
MVPN プレフィックスの場合:
user@host# set routing-options resolution rib bgp.mvpn.0 resolution-ribs inet.0
別の方法は、IGP ルートを inet.3 にリークして、inet.3 の主要ルートにすることです。
BGP-ORR を設定するには、以下の CLI 階層を使用します:
[edit protocols bgp] group group-name{ optimal-route-reflection { igp-primary ipv4-address; igp-backup ipv4-address; } }
関連項目
ルートリフレクタで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を設定するには、次のようにします。
BGP-ORRの設定を監視し、トラブルシューティングするには、次のCLIコマンドを使用します。
show bgp group
121-BGP-ORRのプライマリおよびバックアップの構成を表示します。show isis bgp-orr
121-View IS-IS BGP-ORR metric (RIB)を表示します。show ospf bgp-orr
121-View OSPF BGP-ORR metric (RIB)を表示します。show ospf route
121-OSPFルーティングテーブルのエントリを表示するshow route
121-ルーティングテーブルのアクティブなエントリを表示します。show route advertising protocol bgp peer
121-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-client
がinternalグループに設定されている場合、コミットしようとすると構成エラーが発生します。route-server-client
の構成にはパラメータがありません。route-server-client
の構成には、通常の BGP 権限が適用されます。
属性は、属性の透明度に関して独立して処理されます。ネクストホップがルート サーバーで修正されずに送信できない場合でも、他の属性はその属性に該当するものとして透過的に送信されます。
以下は、 のroute-server-client
構成例です。
[edit] protocols { bgp { group R0 { type external; route-server-client; family inet { unicast; } peer-as 100; neighbor 10.0.0.1; } } }
ネクストホップ
ポリシーで明示的に設定されていない限り、ネクストホップ属性を変更して、ネクストホップ セルフを課したり、ネクストホップを変更しないでください。ルート サーバーは、RFC 4271 のサードパーティ製のネクストホップ ルールに従って BGP ネクストホップを伝送させる必要があります。
ネクストホップ動作は、以下のルート サーバーのシナリオで指定します。
LAN や WAN 相互接続の場合、ルート サーバーがクライアント ピアと LAN や WAN サブネットを共有して接続されている場合、RFC 4271 に定義されているように、受信したサードパーティ製のネクストホップをそのままルート サーバーで広告することができます。
route-server-client
データ センターのマルチホップ相互接続で、ルート サーバーがクライアント ピアとマルチホップ相互接続する場合、EBGP マルチホップを設定する必要があり、 Cno-nexthop-change
LI 設定の動作は 設定によって暗黙的に課されることになります。受信したサードパーティ製のネクストホップは、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 ネイバーのルーティング インスタンスが設定インスタンスと転送インスタンスに分割されます。BGPforwarding-context
の CLI 設定は、BGP ピアをroute-server-client
に設定した非転送インスタンスもサポートし、指定されたインスタンスはプライマリを転送できる任意のインスタンスまたは非転送タイプでないルーティング インスタンスです。
関連項目
変更履歴
サポートされる機能は、使用しているプラットフォームとリリースによって決まります。 特定の機能がお使いのプラットフォームでサポートされているかどうかを確認するには、 Feature Explorer をご利用ください。
no-install
ステートメントは、カーネルや分散型ファイアウォールデーモン(dfd)などのJunosシステムのルーティングプロトコルデーモン(Rpd)と、Junosシステムの他のコンポーネント間の相互作用を除去します。