Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

基本的な BGP ルーティング ポリシー

ルーティングポリシーについて

各ルーティングポリシーは、ポリシー名で識別されます。名前には、文字、数字、ハイフン(-)を使用でき、最大255文字まで使用可能です。名前にスペースを含めるには、名前全体を二重引用符で囲みます。各ルーティングポリシー名は、コンフィギュレーション内で一意である必要があります。

ポリシーが作成され、名前が付けられると、アクティブになる前に適用される必要があります。ルーティングポリシーは、設定階層のprotocols protocol-nameレベルでimportおよびexportステートメントを使用して適用します。

import文には、ルーティングプロトコルからルーティングテーブルにルートを取り込むときに評価するルーティングポリシーの名前を記載します。

exportステートメントでは、ルートがルーティングテーブルからダイナミックルーティングプロトコルにエクスポートされるときに評価されるルーティングポリシーの名前をリストします。アクティブなルートのみがルーティングテーブルからエクスポートされます。

複数のポリシーを指定してポリシー チェーンを作成するには、スペースを区切り文字としてポリシーを一覧表示します。複数のポリシーが指定された場合、指定された順番に評価されます。受理または拒否のアクションが実行されると同時に、ポリシー チェーンの評価は終了します。

明示的に設定されたルート

明示的 に設定されたルート は、設定したルートです。 直接ルート は明示的に設定されていません。インターフェイス上で設定されたIPアドレスの結果として作成されます。明示的に設定されたルートには、集約ルート、生成ルート、ローカルルート、スタティックルートが含まれます。( 集約ルート とは、共通のアドレスを持つルートのグループを1つのルートに抽出するルートのことです。 生成されたルート は、ルーティングテーブルに特定の宛先に到達する方法に関する情報がない場合に使用されるルートです。 ローカルルート は、ルーターインターフェイスに割り当てられたIPアドレスです。 静的ルート は、宛先への不変のルートです。)

ポリシー フレームワーク ソフトウェアは、明示的に設定された直接ルートを、あたかもルーティング プロトコルを介して学習したかのように扱います。したがって、ルーティングテーブルにインポートできます。このプロトコルは実際のルーティングプロトコルではないため、ルートをルーティングテーブルから疑似プロトコルにエクスポートすることはできません。ただし、集約ルート、ダイレクトルート、生成ルート、スタティックルートはルーティングテーブルからルーティングプロトコルにエクスポートできますが、ローカルルートは書き出せません。

注:

デフォルトでは、BGPはBGPで学習したルートのみをエクスポートします。他のプロトコル(スタティック、ダイレクト、IGPなど)から学習したルートは、ルーティングポリシーで明示的に許可されない限り、エクスポートされません。

例:BGP階層の異なるレベルでのルーティングポリシーの適用

この例では、シンプルなネットワークトポロジーで設定された BGP を紹介し、ルーティングポリシーが BGP 設定の異なるレベルで適用されたときにどのように効果があるかを説明します。

要件

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

概要

BGPでは、次のようにポリシーを適用できます。

  • BGPグローバル import および export ステートメント—これらのステートメントを [edit protocols bgp] 階層レベルに含める(ルーティングインスタンスの場合は、これらのステートメントを [edit routing-instances routing-instance-name protocols bgp] 階層レベルに含める)。

  • グループ import および export ステートメント—これらのステートメントを [edit protocols bgp group group-name] 階層レベルに含める(ルーティングインスタンスの場合は、これらのステートメントを [edit routing-instances routing-instance-name protocols bgp group group-name] 階層レベルに含める)。

  • ピア import および export ステートメント—これらのステートメントを [edit protocols bgp group group-name neighbor address] 階層レベルに含める(ルーティングインスタンスの場合は、これらのステートメントを [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address] 階層レベルに含める)。

  • ファミリー import および export ステートメント—これらのステートメントを [edit protocols bgp family nlri] 階層レベルに含める(ルーティングインスタンスの場合は、これらのステートメントを [edit routing-instances routing-instance-name protocols bgp family nlri] 階層レベルに含める)。

ピアレベルの import または export ステートメントは、グループ import または export ステートメントを上書きします。グループレベルの import または export ステートメントは、グローバルBGP import または export ステートメントを上書きします。

この例では、 send-direct という名前のポリシーがグローバルレベルで適用され、 send-192.168.0.1 という名前の別のポリシーがグループレベルで適用され、 send-192.168.20.1 という名前の3つ目のポリシーがネイバーレベルで適用されています。

これは、重要なポイントであり、しばしば誤解され問題を引き起こす可能性がある点ですが、このような構成では、最も明示的なポリシーのみが適用されます。ネイバーレベルのポリシーは、グループレベルのポリシーよりも明示的であり、グループレベルのポリシーはグローバルポリシーよりも明示的です。

ネイバー172.16.2.2には、send-192.168.20.1ポリシーのみが適用されます。ネイバー172.16.3.3には、より具体的なものがないため、send-192.168.0.1ポリシーのみが適用されます。一方、other-groupのグループにあるネイバー172.16.4.4には、グループまたはネイバーレベルのポリシーがないため、send-directポリシーを使用します。

ネイバー172.16.2.2で3つのポリシーすべての機能を実行させる必要がある場合は、他の3つの機能を含む新しいネイバーレベルのポリシーを作成して適用するか、既存の3つのポリシーすべてをチェーンとして、ネイバー172.16.2.2に適用することができます。

トポロジー

図1 は、サンプルネットワークを示しています。

図1:ルーティングポリシーをBGPApplying Routing Policies to BGPに適用する

CLIクイックコンフィグレーション は、 図1に示すすべてのデバイスの構成を示しています。

セクション #d188e247__d188e501 では、デバイスR1の手順を説明しています。

設定

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

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

デバイスR1

デバイスR2

デバイスR3

デバイスR4

手順

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

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

IS-ISデフォルトルートポリシーを設定するには:

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

  2. インターフェイスでOSPFまたは別の内部ゲートウェイプロトコル(IGP)を有効にします。

  3. スタティックルートを設定します。

  4. ルーティングポリシーを有効にします。

  5. BGPを設定し、エクスポートポリシーを適用します。

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

  7. デバイスの設定が完了したら、設定をコミットします。

結果

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

検証

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

BGPルート学習の検証

目的

ルーティングテーブルをチェックして、BGPエクスポートポリシーが期待どおりに機能していることを確認します。

アクション
意味

デバイスR1では、 show route protocol direct コマンドは172.16.1.1/32と10.10.10.0/30の2つの直接ルートを表示します。 show route protocol static コマンドは、192.168.0.1/32と192.168.20.1/32の2つのスタティックルートを表示します。

デバイスR2では、 show route protocol bgp コマンドによって、デバイスR2がBGPで学習した唯一のルートが192.168.20.1/32ルートであることが示されています。

デバイスR3では、 show route protocol bgp コマンドによって、デバイスR3がBGPで学習した唯一のルートが192.168.0.1/32ルートであることが示されています。

デバイスR4では、 show route protocol bgp コマンドによって、デバイスR4がBGPを通じて学習したルートは172.16.1.1/32および10.10.10.0/30ルートのみであることが示されています。

BGPルート受信の検証

目的

デバイスR1から受信したBGPルートを確認し、BGPエクスポートポリシーが期待通りに機能していることを確認します。

アクション
意味

デバイスR2では、 route receive-protocol bgp 172.16.1.1 コマンドによって、デバイスR2がデバイスR1から1つのBGPルート192.168.20.1/32のみを受け取っていることが示されています。

デバイスR3では、 route receive-protocol bgp 172.16.1.1 コマンドによって、デバイスR3がデバイスR1から1つのBGPルート192.168.0.1/32のみを受け取っていることが示されています。

デバイスR4では、 route receive-protocol bgp 172.16.1.1 コマンドは、デバイスR4がデバイスR1から2つのBGPルート172.16.1.1/32および10.10.10.0/30を受け取っていることを示しています。

要約すると、BGPの異なるCLI階層に複数のポリシーが適用される場合、最も具体的なアプリケーションのみが評価され、より具体性の低い他のポリシーアプリケーションは除外されます。このポイントは理にかなっているように見えますが、ネイバーレベルのポリシーがグローバルポリシーまたはグループレベルのポリシーと組み合わされていると勘違いして、ポリシーの動作が予想と異なることに気付くと、ルーターの設定中に忘れられがちです。

例:BGPルーティングテーブルへのOSPFルートの注入

この例では、OSPFルートをBGPルーティングテーブルに注入するポリシーを作成する方法を示します。

要件

始める前に:

概要

この例では、 injectpolicy1 というルーティングポリシーと injectterm1というルーティング条件を作成します。ポリシーは、OSPFルートをBGPルーティングテーブルに注入します。

トポロジー

設定

ルーティングポリシーの設定

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

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

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

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

OSPFルートをBGPルーティングテーブルに注入するには:

  1. ポリシー・タームを作成します。

  2. 一致条件として OSPF を指定します。

  3. OSPFエリアからのルートをマッチ条件として指定します。

  4. 前の条件にマッチした場合にルートを受け入れることを指定します。

  5. BGPにルーティングポリシーを適用します。

結果

コンフィギュレーション・モードから show policy-optionsshow protocols bgp コマンドを入力し、コンフィギュレーションを確認します。出力に意図した設定が表示されない場合は、この例の手順を繰り返して設定を修正します。

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

ルーティング・ポリシーのトレース設定

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

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

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

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

  1. ポリシーにトレースアクションを含めます。

  2. 出力するトレース・ファイルを設定します。

結果

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

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

検証

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

期待される BGP ルートが存在することの検証

目的

エクスポートポリシーの効果を確認します。

アクション

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

トラブルシューティング

show logコマンドを使用してルーティング・ポリシーのアクションを調べる

問題点

ルーティングテーブルに予期しないルートが含まれているか、ルーティングテーブルからルートが欠落しています。

ソリューション

この例のようにポリシー・トレースを設定すると、 show log ospf-bgp-policy-log コマンドを実行してルーティングポリシーの問題点を診断することができます。 show log ospf-bgp-policy-log コマンドは、 injectpolicy1 ポリシー条件が分析して作用するルートに関する情報を表示します。

BGPルートアドバタイズを制御するためのルーティングポリシーの設定

すべてのルーティングプロトコルは、Junos OSのルーティングテーブルを使用して、学習したルートを格納し、プロトコルパケットでどのルートをアドバタイズすべきかを決定します。ルーティングポリシーを使用すると、ルーティングプロトコルがどのルートをルーティングテーブルに格納し、どのルートから取得するかを制御できます。ルーティングポリシーについては、 ルーティングポリシー、ファイアウォールフィルター、およびトラフィックポリサーユーザーガイドを参照してください。

BGPルーティングポリシーを設定する場合、以下のタスクを実行できます。

ルーティングポリシーの適用

ルーティングポリシーは、 [edit policy-options] 階層レベルで定義します。BGPに定義したポリシーを適用するには、BGP設定内に import および export ステートメントを含めます。

ポリシーは次のように適用できます。

  • BGPグローバル import および export ステートメント—これらのステートメントを [edit protocols bgp] 階層レベルに含める(ルーティングインスタンスの場合は、これらのステートメントを [edit routing-instances routing-instance-name protocols bgp] 階層レベルに含める)。

  • グループ import および export ステートメント—これらのステートメントを [edit protocols bgp group group-name] 階層レベルに含める(ルーティングインスタンスの場合は、これらのステートメントを [edit routing-instances routing-instance-name protocols bgp group group-name] 階層レベルに含める)。

  • ピア import および export ステートメント—これらのステートメントを [edit protocols bgp group group-name neighbor address] 階層レベルに含める(ルーティングインスタンスの場合は、これらのステートメントを [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address] 階層レベルに含める)。

  • ファミリー import および export ステートメント-これらのステートメントを [edit protocols bgp family nlri] 階層レベルに含める(ルーティングインスタンスの場合は、これらのステートメントを [edit routing-instances routing-instance-name protocols bgp family nlri] 階層レベルに含める)。

ピアレベルの import または export ステートメントは、グループ import または export ステートメントを上書きします。グループレベルの import または export ステートメントは、グローバルBGP import または export ステートメントを上書きします。

ポリシーを適用するには、次のセクションを参照してください。

BGPからルーティングテーブルにインポートされるルートへのポリシーの適用

BGPからルーティングテーブルにインポートされるルートにポリシーを適用するには、評価される1つ以上のポリシーの名前を列挙した import ステートメントを含めます。

このステートメントを含めることができる階層レベルの一覧については、このステートメントの「ステートメント概要」セクションを参照してください。

複数のポリシーを指定した場合は、指定した最初から最後の順序で評価され、最初に一致するフィルタがルートに適用されます。一致しない場合、BGPはBGPルーティングデバイスから学習したルートだけをルーティングテーブルに配置します。

ルーティングテーブルからBGPにエクスポートされるルートへのポリシーの適用

ルーティングテーブルからBGPにエクスポートされるルートにポリシーを適用するには、評価対象の1つ以上のポリシーの名前を列挙した export ステートメントを含めます。

このステートメントを含めることができる階層レベルの一覧については、このステートメントの「ステートメント概要」セクションを参照してください。

複数のポリシーを指定した場合は、指定した最初から最後の順序で評価され、最初に一致するフィルタがルートに適用されます。フィルタに一致するルートがない場合、ルーティングテーブルはBGPから学習したルートのみをBGPにエクスポートします。

非アクティブなルートをアドバタイズするように BGP を設定する

デフォルトでは、BGPはアップデートメッセージから受け取ったルート情報をJunos OSのルーティングテーブルに格納し、ルーティングテーブルはアクティブなルートのみをBGPにエクスポートし、BGPはそれをピアにアドバタイズします。アクティブなルートとして選択しなかった場合でも、BGPによって学習された最適なルートをBGPするようにルーティングテーブルエクスポートするには、 advertise-inactive Junos OSステートメントを含めます。

このステートメントを含めることができる階層レベルの一覧については、このステートメントの「ステートメント概要」セクションを参照してください。

内部ピアに最適な外部ルートをアドバタイズする BGP の設定

一般に、デプロイされた BGP 実装では、ローカル プリファレンス値が最も高い外部ルートは、それが最良のルートでない限り、内部ピアにアドバタイズされません。この動作は、BGPバージョン 4仕様の以前のバージョンであるRFC 1771で要求されていましたが、アドバタイズされる情報量を最小限に抑え、ルーティングループを防ぐために、通常は従っていませんでした。しかしながら、最適な外部ルートをアドバタイズした方が有益なシナリオもあります。特に、IBGPルートが変動するような状況がそれにあたります。

Junos OS Release 9.3以降では、最適なルートが内部ルートである場合でも、内部BGP(IBGP)メッシュグループ、ルートリフレクタクラスター、または自律システム(AS)連合に最適な外部ルートをアドバタイズするようにBGPを設定することができます。

注:

ルートリフレクタで advertise-external ステートメントを設定するには、 no-client-reflect ステートメントでクラスタ内リフレクションを無効にする必要があります。

ルーティングデバイスがクラスターのルートリフレクタとして設定されている場合、ルートリフレクタによってアドバタイズされたルートは、同じクラスター識別子を持つ内部ピアから受信するか、両方のピアにクラスター識別子が設定されていなければ内部ルートとみなされます。別のクラスターに属する内部ピアから受信したルート、つまり異なるクラスター識別子を持つルートは外部ルートとみなされます。

コンフェデレーションでは、コンフェデレーション境界ルーターに対してルートをアドバタイズする場合、別のコンフェデレーションサブASからのルートは外部と見なされます。

また、ルート選択プロセスが複数出口識別子(MED)メトリックを評価するポイントに到達した場合にのみ、外部ルートをアドバタイズするようにBGPを設定することもできます。その結果、アクティブパスの外部ルートよりも悪い(つまり長い)ASパスを持つ外部ルートはアドバタイズされません。

Junos OS は、アドバタイズされたルートの状態にマッチする BGP エクスポートポリシーの設定もサポートしています。アクティブまたは非アクティブなルートでマッチングできます。詳細については、 『ルーティングポリシー、ファイアウォールフィルター、およびトラフィックポリサーユーザーガイド』を参照してください。

内部ピアに最適な外部パスをアドバタイズするようにBGPを設定するには、 advertise-external ステートメントを含めます。

注:

advertise-externalステートメントは、グループレベルとネイバーレベルの両方でサポートされています。ネイバーレベルでステートメントを設定する場合、グループ内のすべてのネイバーに設定する必要があります。そうでない場合は、グループは自動的に別のグループに分割されます。

このステートメントを設定できる階層レベルの全リストについては、このステートメントの概要のセクションを参照してください。

ルート選択プロセスがMED値を評価する地点に到達した場合にのみ、最適な外部パスをアドバタイズするようにBGPを設定するには、 conditional ステートメントを含めます。

BGPがルーティングテーブルとルートを交換する頻度の設定

BGPはアップデートメッセージから受け取ったルート情報をルーティングテーブルに格納し、ルーティングテーブルはアクティブなルートをルーティングテーブルからBGPにエクスポートします。次に、BGPはエクスポートされたルートをピアにアドバタイズします。デフォルトでは、BGPとルーティングテーブル間のルート情報の交換は、ルートを受信した直後に行われます。このようにルート情報を即座に交換すると、ネットワークの到達可能性情報が不安定になる可能性があります。これを防ぐために、BGPとルーティングテーブルがルート情報を交換するまでの時間を遅らせることができます。

BGPとルーティングテーブルがルート情報を交換する頻度を設定するには、 out-delay ステートメントを含めます。

デフォルトでは、ルーティングテーブルにはBGPから学習したルート情報の一部が保持されています。ルーティングテーブルがこの情報をすべて保持するか、まったく保持しないようにするには、 keep ステートメントを含めます。

これらのステートメントを含めることができる階層レベルの一覧については、これらのステートメントのステートメント概要セクションを参照してください。

ルーティングテーブルには、次のいずれかの方法でBGPから学習したルート情報を保持することができます。

  • デフォルト( keep ステートメントを省略)—ASパスがループしていて、そのループにローカルASが含まれているルートを除き、BGPから学習したすべてのルート情報を保持します。

  • keep all—BGPから学習したすべてのルート情報を保持します。

  • keep none—ピアから受信したルートのうち、インポートポリシーやその他の健全性チェック(ASパスやネクストホップなど)によって拒否されたルートを破棄します。BGPセッションに keep none を設定し、インバウンドポリシーが変更されると、Junos OSはピアによってアドバタイズされたルートの全セットの再アドバタイズを強制します。

ASパス修復状況では、ループしたパスを持つルートは、理論的にはソフト再設定時にASパスループ制限を変更することで使用可能になる可能性があります。ただし、デフォルトと keep allではメモリ使用量に大きな差があります。

次のシナリオを考えてみましょう。

  • ピアは、ルートの学習元であったピアに対してルートを再アドバタイズします。

    これは、次のような場合に発生する可能性があります。

    • 別のベンダーのルーティングデバイスが、送信ピアにルートを再度アドバタイズしています。

    • 送信側ピアにルートを再アドバタイズしないというJunos OSピアのデフォルトの動作は、 advertise-peer-asを設定することで上書きされます。

  • プロバイダエッジ(PE)ルーティングデバイスは、期待されるルートターゲットを持たないVPNルートを破棄します。

keep allを設定すると、上記のシナリオで受信したルートを破棄する動作が上書きされます。

ルートアドバタイズメントの抑制の無効化

Junos OSは、EBGPピアから学習したルートを、同じ外部BGP(EBGP)ピアに戻してアドバタイズしません。さらに、ソフトウェアは、ルーティングインスタンスに関係なく、送信元ピアと同じAS内にあるEBGPピアにルートをアドバタイズしません。この動作を変更するには、設定に advertise-peer-as ステートメントを含めます。デフォルトのアドバタイズ抑制を無効にするには、 advertise-peer-as ステートメントを含めます。

注:

as-overrideステートメントが設定に含まれている場合、ルート抑止のデフォルト動作は無効になります。

設定に advertise-peer-as ステートメントを含めると、このチェックに関係なくBGPルートがアドバタイズされます。

デフォルトの動作に戻すには、設定に no-advertise-peer-as ステートメントを含めます。

設定に as-override ステートメントと no-advertise-peer-as ステートメントの両方を含めると、 no-advertise-peer-as ステートメントは無視されます。これらのステートメントは、複数の階層レベルに含めることができます。

これらのステートメントを含めることができる階層レベルの一覧については、これらのステートメントの「ステートメント概要」セクションを参照してください。

例:内部ピアに最適な外部ルートをアドバタイズするルーティングポリシーの設定

RFC 1771で定義されているBGPプロトコル仕様では、BGPピアは、総合的に最適なパスでなくても(言い換えれば、最適なパスが内部経路であっても)、より優先度の高い外部パスを内部ピアにアドバタイズすることが定められています。実際には、デプロイされた BGP 実装はこのルールに従いません。仕様から逸脱する理由は、以下のとおりです。

  • アドバタイズされた情報量を最小限に抑える。BGPは、利用可能なパスの数に応じてスケーリングします。

  • ルーティングと転送ループを回避する。

しかし、RFC 1771で規定されている「最適な外部ルートをアドバタイズする」動作が有益となるシナリオがいくつかあります。パス情報を制限することは、パスの多様性が復元時間の短縮に役立つ可能性があるため、必ずしも望ましくありません。また、最適な外部パスをアドバタイズすると、RFC 3345、 境界ゲートウェイプロトコル(BGP)永続ルート発振条件に記載されているように、内部BGP(IBGP)ルート発振の問題に対処することもできます。

advertise-externalステートメントは、最適な総合パスが内部パスであっても、IBGPピアに最適な外部パスをアドバタイズするようにBGPスピーカーの動作を変更します。

注:

advertise-externalステートメントは、グループレベルとネイバーレベルの両方でサポートされています。ネイバーレベルでステートメントを設定する場合、グループ内のすべてのネイバーに設定する必要があります。そうでない場合は、グループは自動的に別のグループに分割されます。

conditionalオプションは、ルート選択プロセスが複数出口識別子(MED)メトリックが評価された場合のみに限り、外部ルートがアドバタイズされるように、advertise-external設定の動作を制限します。そのため、例えば、アクティブパスよりも悪い(長い)ASパスがある場合、外部ルートはアドバタイズされません。conditionalオプションは、最適な外部パスとアクティブなパスが等しい場合に、外部パスのアドバタイズメントをルート選択プロセスのMEDステップまで制限します。最適な外部パスを選択するために使用される基準は、conditionalオプションが設定されていても同じであることに注意してください。

Junos OS は、アドバタイズされたルートの状態に一致する BGP エクスポート ポリシーの設定もサポートしています。以下のように、アクティブまたは非アクティブなルートのいずれかをマッチングできます。

この修飾子は、エクスポートポリシーのコンテキストで使用される場合にのみマッチします。非アクティブなルートをアドバタイズできるプロトコル(BGPなど)によってルートがアドバタイズされる場合、 state inactiveadvertise-inactive ステートメントと advertise-external ステートメントの結果としてアドバタイズされたルートに一致します。

例えば、以下の設定は、ユーザー定義コミュニティとの advertise-external 設定によりアドバタイズされたルートをマークするために、内部ピアに対するBGPエクスポートポリシーとして使用できます。そのコミュニティーは、受信ルーターが後で使用して、転送テーブルからそのようなルートをフィルタリングすることができます。このようなメカニズムを使用して、送信者によって転送に使用されないアドバタイズパスが転送ループにつながるのではないかという懸念に対処できます。

要件

Junos OS 9.3以降が必要です。

概要

この例では、3つのルーティングデバイスを示しています。デバイスR2には、デバイスR1への外部BGP(EBGP)接続があります。デバイスR2には、デバイスR3へのIBGP接続があります。

デバイスR1は、172.16.6.0/24をアドバタイズします。デバイスR2は、デバイスR1のルートのインポートポリシーでローカルプリファレンスを設定していないため、172.16.6.0/24のデフォルトのローカルプリファレンス値は100です。

デバイスR3は、200のローカルプリファレンスで172.16.6.0/24をアドバタイズします。

advertise-externalステートメントがデバイスR2で設定されていない場合、172.16.6.0/24はデバイスR2によってデバイスR3に対してアドバタイズされません。

デバイスR3へのセッションのデバイスR2で advertise-external ステートメントが設定されている場合、172.16.6.0/24はデバイスR2によってデバイスR3に対してアドバタイズされます。

デバイスR3へのセッションのデバイスR2で advertise-external conditional が設定されている場合、172.16.6.0/24はデバイスR2によってデバイスR3に対してアドバタイズされません。デバイスR3で then local-preference 200 設定を削除し、デバイスR2に path-selection as-path-ignore 設定を追加する(そのため、ルート選択プロセスのMEDステップまでパス選択基準を同一にする)場合、172.16.6.0/24はデバイスR2によってデバイスR3に対してアドバタイズされます。

注:

ルートリフレクタで advertise-external ステートメントを設定するには、 no-client-reflect ステートメントでクラスタ内リフレクションを無効にする必要があり、クライアントクラスターは、冗長ルートアドバタイズメントの送信を防止するために完全にメッシュ化する必要があります。

ルーティングデバイスがクラスターのルートリフレクタとして設定されている場合、ルートリフレクタによってアドバタイズされたルートは、同じクラスター識別子を持つ内部ピアから受信するか、両方のピアにクラスター識別子が設定されていなければ内部ルートとみなされます。別のクラスターに属する内部ピアから受信したルート、つまり異なるクラスター識別子を持つルートは外部ルートとみなされます。

トポロジー

図 2 は、サンプル ネットワークを示しています。

図2:外部アドバタイズBGP Topology for advertise-externalのBGPトポロジー

CLIクイックコンフィグレーション は、 図2に示すすべてのデバイスの構成を示しています。

セクション #d191e169__d191e347 では、デバイスR2の手順を説明しています。

設定

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

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

デバイスR1

デバイスR2

デバイスR3

手順

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

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

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

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

  2. OSPFまたは別の内部ゲートウェイプロトコル(IGP)を設定します。

  3. デバイスR1へのEBGP接続を設定します。

  4. デバイスR3へのIBGP接続を設定します。

  5. IBGPグループピアリングセッションに advertise-external ステートメントを追加します。

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

結果

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

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

検証

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

BGPアクティブパスの検証

目的

デバイスR2で、172.16.6.0/24プレフィックスがルーティングテーブルに存在し、予想されるアクティブパスがあることを確認します。

アクション
意味

デバイスR2は、デバイスR1とデバイスR3の両方から172.16.6.0/24ルートを受信します。デバイスR3からのルートは、アスタリスク(*)で指定されたアクティブパスです。アクティブなパスは、最も高いローカルプリファレンスを持っています。2つのルートのローカルプリファレンスが等しい場合でも、デバイスR3からのルートは、ASパスが最短であるため、アクティブなままになります。

外部ルートアドバタイズメントの検証

目的

デバイスR2では、172.16.6.0/24ルートがデバイスR3に対してアドバタイズされていることを確認します。

アクション
意味

デバイスR2は、デバイスR3に対して172.16.6.0/24ルートをアドバタイズしています。

デバイスR3でのルートの検証

目的

172.16.6.0/24プレフィックスがデバイスR3のルーティングテーブルに存在することを確認します。

アクション
意味

デバイスR3には、172.16.6.0/24の静的ルートとBGPルートがあります。

ルートに到達できない場合、またはネクストホップを解決できない場合、BGPルートはデバイスR3では非表示になることに注意してください。この要件を満たすために、この例ではデバイスR3(static route 0.0.0.0/0 next-hop 10.0.0.5)の静的デフォルトルートを含めています。

条件付きオプションでの実験

目的

BGPパス選択アルゴリズムのコンテキストで conditional オプションがどのように機能するかをご覧ください。

アクション
  1. デバイスR2で、 conditional オプションを追加します。

  2. デバイスR2で、172.16.6.0/24ルートがデバイスR3に対してアドバタイズされているかどうかを確認します。

    予想通り、ルートはもうアドバタイズされなくなります。この結果が表示されるまでには数秒かかる場合があります。

  3. デバイスR3で、 then local-preference ポリシーアクションを無効にします。

  4. デバイスR2で、2つのパスのローカルプリファレンスが等しいことを確認します。

  5. デバイスR2で、 as-path-ignore ステートメントを追加します。

  6. デバイスR2で、172.16.6.0/24ルートがデバイスR3に対してアドバタイズされているかどうかを確認します。

    予想通り、ASパス長が無視され、ローカルの基本設定が等しいため、ルートがアドバタイズされます。

Junosでコンバージェンスを高速化するためのBGP設定の最適化

Junos OSのBGPには、障害やトポロジーの変更後にトラフィック転送を迅速に復元するために設計されたいくつかの機能が含まれています。これには、BGPコア保護(PICエッジ)、eBGP高速再ルート(FRR)、状態圧縮、グレースフルリスタートが含まれます。ただし、トラフィックを再開する前に完全なプロトコルコンバージェンスが必要となるシナリオもあります。以下の推奨事項は、コンバージェンスを可能な限り高速化するために BGP 設定を最適化するのに役立ちます。

推奨事項

  1. 同じロジックを持つピア間で単一のポリシーを再利用します。

    ロジックは同じで名前が異なる複数のポリシーを作成することは避けてください。代わりに、複数のピアに対して単一のポリシーを再利用します。

  2. ピアが同様のロジックを共有している場合、ポリシーを結合します。

    複数のBGPピアが同じコアポリシーロジックを共有する場合、個別のピア固有のポリシーを維持するのではなく、それらのルールを単一のエクスポートポリシーに統合することで、ポリシー管理を最適化できます。このアプローチにより、設定の複雑さが軽減され、拡張性が向上します。

    例:

    1. ピアごとに個別のエクスポートポリシーを設定する代わりに、以下を行います。

    2. これらを単一のエクスポートポリシーに統合できます。

  3. グループレベルでエクスポートポリシーを設定します。

    1. 以下のようなエクスポートポリシーをネイバーごとに設定しないでください。
    2. 代わりに、同じエクスポートポリシーを共有するすべてのネイバーに対して、グループレベルでポリシーを設定します。

      注意:
      BGPグループ内で異なるネイバーごとのエクスポートポリシーが適用されている場合、Junos OSは グループ分割をトリガーし、影響を受けるピアはグループを強制的に退出してセッションをリセットします。これにより、トラフィックが中断され、予期しない動作が発生する可能性があります。これを回避するには、明示的なネイバーごとの上書きが必要でない限り、グループレベルで常に一貫したポリシー適用を確保します。
  4. パスMTU検出を有効にするか、TCP MSSを設定してIPのフラグメント化を回避します。

    BGPセッションのパフォーマンスを最適化し、IPのフラグメント化を防ぐには、以下のいずれかを実行する必要があります。

    1. パス MTU 検出(PMTUD)を有効にします。
    2. TCP最大セグメントサイズ(MSS)を最適な値に手動で設定します。

    設定コマンド:

    1. BGPセッションのパスMTU検出(PMTUD)を有効にします。

      これにより、ルーターはネットワークの状態に基づいて BGP セッションの MTU サイズを動的に調整できます。

    2. BGPセッションのTCP MSS値(1400バイトなど)を設定します。

      これにより、TCPセグメントのサイズが手動で制限され、PMTUDが無効になっている場合や信頼性が低下した場合のフラグメント化を防ぐことができます。

    注:可能な限りPMTUDを使用するのがベストプラクティスですが、ネットワークがPMTUDに必要なICMPメッセージをブロックする場合は、ネットワークMTUに基づいて適切なTCP MSS値を手動で設定します。
  5. BGPピア間のすべてのインターフェイスとリンクで大きなMTUを設定します。

    パフォーマンスを最適化するために、ピア間のすべてのインターフェイスとリンクが大きな MTU をサポートしていることを確認します。

注意事項

エクスポートポリシーの変更により、セッションがリセットされる場合があります。

  • Junos OSでは、共有Adj-RIB-Out内の1つのピアのエクスポートポリシーが変更された場合、Junosはピアを別の(または新しい)Adj-RIB-Outに移動します。この遷移により、そのピアの BGP セッションがリセットされます。

  • このリセットは、特に多数のプレフィックスをアドバタイズするピア(アップリンクプロバイダーなど)にとっては、混乱をもたらす可能性があります。

  • 推奨事項:セッションのリセットを回避することが重要な場合は、個別のBGPグループを設定して、専用のAdj-RIB-outを作成することを検討してください。このトレードオフにより安定性は向上しますが、パス処理のパフォーマンスに影響を与える可能性があります。

例:BGPプレフィックスベースのアウトバウンドルートフィルタリングの設定

この例では、リモート ピアからのルート フィルターを受信し、受信したフィルターを使用してアウトバウンド ルート フィルタリングを実行するようにジュニパーネットワークス ルーターを構成する方法を示します。

要件

始める前に:

  • ルーター インターフェイスを設定します。

  • 内部ゲートウェイプロトコル(IGP)を設定します。

概要

リモートBGPピアからルートフィルターを受信し、受信したフィルターを使用してアウトバウンドルートフィルタリングを実行するように設定できます。不要なアップデートをフィルタリングすることで、送信ピアはアップデートの生成と送信に必要なリソースを節約し、受信ピアはアップデートの処理に必要なリソースを節約することができます。この機能は、例えば、仮想プライベートネットワーク(VPN)において、カスタマーエッジ(CE)デバイスのサブセットがVPN内のすべてのルートを処理できない場合に有効です。CEデバイスは、プレフィックスベースのアウトバウンド・ルート・フィルタリングを使用して、メイン・データ・センターへのルートのみなど、ルートのサブセットのみを送信するようにプロバイダ・エッジ(PE)ルーティング・デバイスと通信することができます。

BGPピアが受け入れることができるプレフィックスベースのアウトバウンド・ルート・フィルタの最大数は5000です 。リモートピアがピアアドレスに5000 を超えるアウトバウンドルートフィルターを送信した場合、追加のフィルターは破棄され、システムログメッセージが作成されます。

ルーティングデバイス全体、または特定のBGPグループやピアに対してのみ相互運用性を設定できます。

トポロジー

サンプル ネットワークでは、デバイス CE1 は他社製のルーターです。この例で示す設定は、ジュニパーネットワークスルーターPE1上でのものです。

図3 は、サンプルネットワークを示しています。

図3:BGPプレフィックスベースのアウトバウンドルートフィルタリング BGP Prefix-Based Outbound Route Filtering

設定

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

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

PE1

手順

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

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

ルーターPE1がデバイスCE1からのルート・フィルターを受信し、受信したフィルターを使用してアウトバウンド・ルート・フィルタリングを実行するように設定するには:

  1. ローカルの自律システムを設定します。

  2. デバイスCE1との外部ピアリングを設定します。

  3. ルーターPE1がデバイスCE1からのIPv4ルート・フィルターを受信し、受信したフィルターを使用してアウトバウンド・ルート・フィルタリングを実行するように設定します。

  4. (オプション)アウトバウンド・ルート・フィルタにベンダー固有の互換コード 130を使用し、コード・タイプ 128を使用するルーティング・デバイスとの相互運用性を可能にします。

    IANA標準コードは 3、標準コードタイプは64です 。

結果

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

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

検証

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

アウトバウンド・ルート・フィルターの検証

目的

デバイス CE1から受信したプレフィックスベースのアウトバウンド・ルート・フィルタに関する情報を表示します。

アクション

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

BGPネイバーモードの検証

目的

show bgp neighborコマンド出力にORFCiscoModeオプションが表示されていることを確認し、ピアでbgp-orf-cisco-mode設定が有効になっていることを確認します。

アクション

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

パケットトランスポートルーター(PTXシリーズ)のデフォルトBGPルーティングポリシーについて

PTXシリーズパケットトランスポートルーターでは、デフォルトのBGPルーティングポリシーが他のJunos OSルーティングデバイスとは異なります。PTXシリーズ3000および5000シリーズルーターのデフォルトルーティングポリシーは、別のポリシーを上書きするように設定しない限り、転送テーブルにBGPルートをインストールしません。他のすべてのPTXシリーズルーターは、ポリシーを必要とせずに、BGP学習ルートを転送情報ベース(FIB)およびパケットフォワーディングエンジン(PFE)にインストールします。

PTXシリーズルーターは、通常、内部ゲートウェイプロトコル(IGP)ルートを使用してIP転送を行うMPLSトランジットプラットフォームです。PTXシリーズのパケット転送エンジンは、比較的少数の可変長プレフィックスに対応できます。

注:

PTXシリーズルーターは、コントロールプレーンでフルBGPルートをサポートし、ルートリフレクタ(RR)として使用できます。正確な長さのルックアップ マルチキャスト転送が可能で、ユニキャスト コントロール プレーンが使用するマルチキャスト転送プレーンを構築できます(たとえば、マルチキャストのリバースパス転送ルックアップを実行する場合など)。

PFEの制限を考えると、PTXシリーズルーターのデフォルトのルーティングポリシーは、BGPルートが転送テーブルにインストールされないことです。デフォルトのルーティングポリシーを上書きして、特定のBGPルートを選択して転送テーブルにインストールできます。

PTXシリーズルーターでのロードバランシングおよびBGPルートのデフォルトの動作は次のとおりです。以下のような好ましい特性を備えています。

  • デフォルトポリシーを直接変更することなく、デフォルトの動作を上書きできます

  • デフォルトを無効にするような偶発的な変更の可能性を低減します

  • acceptやrejectなどのフロー制御アクションを設定しません

PTXシリーズルーターのデフォルトルーティングポリシーは次のとおりです。

ここに示すように、junos-ptx-series-defaultポリシーは[edit policy-options]で定義されています。ポリシーは、default-exportステートメントを使用して、[edit routing-options forwarding-table]で適用されます。これらのデフォルト設定は、| display inheritance フラグを使用して表示できます。

また、 show policy コマンドを使用して、デフォルトポリシーを表示することもできます。

注意:

junos-ptx-series-defaultルーティングポリシーを直接変更しないことを強くお勧めします。

Junos OSは、 junos-ptx-series-default ポリシーとユーザーが設定したエクスポートポリシーを連鎖させます。 junos-ptx-series-default ポリシーはフロー制御アクションを使用しないため、設定したエクスポートポリシーは、すべてのルートに対して(暗黙的なネクストポリシーアクションによって)実行されます。したがって、 junos-ptx-series-default ポリシーによって設定されたアクションを上書きできます。エクスポート・ポリシーを設定しない場合、 junos-ptx-series-default ポリシーで設定されたアクションのみがアクションとなります。

ポリシーアクション install-to-fib を使用して、 no-install-to-fib アクションを上書きできます。

同様に、 load-balance per-prefix アクションを設定して、 load-balance per-packet アクションを上書きすることもできます。

例:PTXシリーズパケットトランスポートルーターのデフォルトBGPルーティングポリシーの上書き

この例では、PTXシリーズ パケットトランスポートルーターなどのパケット トランスポート ルーターのデフォルト ルーティングポリシーを上書きする方法を示しています。

要件

この例では、Junos OS リリース 12.1 以降が必要です。

概要

デフォルトでは、PTXシリーズルーターは転送テーブルにBGPルートをインストールしません。

PTXシリーズルーターの場合、then acceptアクションでfrom protocols bgp条件を設定しても、他のJunos OSルーティングデバイスのような通常の結果にはなりません。PTXシリーズルーターで以下のルーティングポリシーを使用すると、BGPルートは転送テーブルにインストールされません。

転送テーブルに BGP ルートはインストールされていません。これは予期される動作です。

この例では、 then install-to-fib アクションを使用して、デフォルトのBGPルーティングポリシーを効果的に上書きする方法を示しています。

設定

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

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

選択した BGP ルートを転送テーブルにインストール

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

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

選択した BGP ルートを転送テーブルにインストールするには:

  1. 転送テーブルにインストールするプレフィックスのリストを設定します。

  2. プレフィックスリストを条件として適用して、ルーティングポリシーを設定します。

  3. ルーティングポリシーを転送テーブルに適用します。

結果

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

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

検証

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

選択したルートが転送テーブルにインストールされていることを確認

目的

設定されたポリシーがデフォルトのポリシーに上書きされていることを確認してください。

アクション

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

意味

この出力は、66.0.0.1/32 へのルートが転送テーブルにインストールされていることを示しています。

プレフィックスユースケースの条件付きインストールを可能にする条件付き広告

ネットワークは通常、自律システム(AS)と呼ばれる、より小規模で管理しやすいユニットに分割されます。ルーターが BGP を使用して同じ AS 内でピア関係を形成する場合、それを内部 BGP(IBGP)と呼びます。BGPがルーターによって使用されて異なるASでピア関係を形成する場合、外部BGP(EBGP)と呼ばれます。

ルート正常性チェックを実行した後、BGP ルーターはピアから受信したルートを受け取り、ルーティングテーブルにインストールします。デフォルトでは、IBGP および EBGP セッションのすべてのルーターは標準 BGP アドバタイズルールに従います。IBGP セッションのルーターは、直接ピアから学習したルートのみをアドバタイズしますが、EBGP セッションのルーターは、直接および間接ピア(ピア オブ ピア)から学習したルートをすべてアドバタイズします。そのため、EBGP が設定された典型的なネットワークでは、ルーターは EBGP ピアから受信したすべてのルートをそのルーティングテーブルに追加し、すべての EBGP ピアにほぼすべてのルートをアドバタイズします。

顧客およびインターネット上のピアと BGP ルートを交換するサービス プロバイダーは、悪意のある、または意図しない脅威にさらされ、トラフィックの適切なルーティングやルーターの動作が損なわれる危険性があります。

これにはいくつかのデメリットがあります。

  • Non-aggregated route advertisements—顧客は、アドレス空間の集計ではなく、すべてのプレフィックスを誤ってISPにアドバタイズする可能性があります。インターネットルーティングテーブルのサイズを考えると、これは慎重に制御する必要があります。また、エッジルーターにはインターネットへのデフォルトルートのみが必要となり、代わりにアップストリームピアからBGPルーティングテーブル全体を受信している場合もあります。

  • BGP route manipulation—悪意のある管理者がBGPルーティングテーブルのコンテンツを変更した場合、トラフィックが意図した宛先に到達できなくなる可能性があります。

  • BGP route hijacking—BGPピアの不正な管理者は、ネットワークのプレフィックスを悪意を持って公開して、被害者のネットワークに向けられたトラフィックを管理者のネットワークに再ルーティングし、トラフィックの内容にアクセスしたり、被害者のオンラインサービスをブロックしたりする可能性があります。

  • BGP denial of service (DoS)—悪意のある管理者が、ルーターの利用可能な BGP リソースをすべて使用しようとして、予期しないまたは望ましくない BGP トラフィックをルーターに送信した場合、有効な BGP ルート情報を処理するルーターの能力が損なわれる可能性があります。

プレフィックスの条件付きインストールを使用して、前述したすべての問題に対処できます。顧客がリモート ネットワークへのアクセスを必要とする場合、リモート ネットワークに接続されているルーターのルーティングテーブルに特定のルートをインストールできます。これは、典型的なEBGPネットワークでは発生しないため、プレフィックスの条件付きインストールが不可欠となります。

ASは物理的な関係だけでなく、ビジネスやその他の組織の関係によっても制約を受けます。ASは、他の組織にサービスを提供したり、他の2つのAS間でトランジットASとして機能したりすることができます。これらのトランジット AS は、互いへの接続方法と、最も重要な、互いに転送するトラフィックの種類と量に関するパラメーターを含む当事者間の契約によって拘束されます。そのため、法的にも経済的にも、サービスプロバイダは、BGPルートをネイバーとどのように交換するか、どのルートをネイバーから受け入れるか、そしてそれらのルートがAS間のトラフィックにどのように影響するかを制御するポリシーを実装する必要があります。

BGPピアから受信したルートをフィルタリングするには、さまざまなオプションが用意されており、AS間ポリシーを強化するとともに、潜在的に有害なルートを受信するリスクを軽減することができます。従来のルート フィルタリングは、ルートの属性を調べ、その属性に基づいてルートを受け入れるか拒否するかを決定します。ポリシーまたはフィルターを使用して、ASパス、ネクストホップ値、コミュニティ値、プレフィックスのリスト、ルートのアドレスファミリーなどの内容を調べることができます。

場合によっては、特定の属性値に一致するという標準的な「受け入れ条件」では不十分なことがあります。サービスプロバイダは、ルート自体の外に別の条件(例えば、ルーティングテーブル内の別のルート)を使用する必要がある場合があります。例えば、このピアがさらにアップストリームの他のネットワークに到達可能であることが確認できた場合にのみ、アップストリーム ピアから受信したデフォルト ルートをインストールすることが望ましい場合があります。この条件付きルート インストールでは、ピアがアップストリームのルートを失い、ブラックホール トラフィックになった場合に、このピアへのトラフィック送信に使用されるデフォルト ルートをインストールしることを回避できます。これを実現するために、ルーターは、ルーティングテーブル内の特定のルートの存在を検索し、この知識に基づいて別のプレフィックスを受け入れる、または拒否するように設定できます。

例:ルーティングテーブルにおけるプレフィックスの条件付きインストールを可能にする条件付きアドバタイズのルーティングポリシーの設定 では、プレフィックスの条件付きインストールを設定し、確認する方法について説明します。

条件付き広告と特定のマッチ条件を持つインポート・ポリシー(ルーティング・テーブル)

BGPは、ネイバーから学習したループしていないルートをすべて受け入れ、RIB-Inテーブルにインポートします。これらのルートが BGP インポート ポリシーで受け入れられた場合、inet.0 ルーティングテーブルにインポートされます。特定のルートのみをインポートする必要がある場合は、条件または条件セットに基づいてピアルーティングデバイスがルートをエクスポートするように規定することができます。

ルートのエクスポートの条件は、以下のものがあります。

  • ルートが学習されたピア

  • ルートが学習されたインターフェイス

  • その他の必須属性

次に例を示します。

これはプレフィックスの条件付きインストールと呼ばれ、例で説明されています: ルーティングテーブルへのプレフィックスの条件付きインストールを可能にする条件付きアドバタイズのルーティングポリシーの設定

ルーティングポリシーの条件は、エクスポートポリシー、インポートポリシー、またはその両方に関係なく設定できます。エクスポートポリシーは、ルーティングポリシー内の別のルートの存在に基づいて、ルーティングポリシーから継承されたこれらの条件をサポートします。ただし、インポートポリシーはこれらの条件をサポートしておらず、条件が存在していても実行されません。

図4 は、BGPインポートおよびエクスポートポリシーが適用される場所を示しています。インポート・ポリシーは、 show route receive-protocol bgp neighbor-address コマンドの出力に表示されているインバウンド・ルートに適用されます。エクスポート・ポリシーは、 show route advertising-protocol bgp neighbor-address コマンドの出力に表示されているアウトバウンド・ルートに適用されます。

図4:BGPインポートおよびエクスポートポリシー BGP Import and Export Policies

プレフィックスの条件付きインストールを有効にするには、プレフィックスのエクスポートが行われるデバイスにエクスポート・ポリシーを設定する必要があります。エクスポート・ポリシーは各ルートを評価し、 from ステートメントに基づくすべての一致条件を満たすことを確認します。また、 condition ステートメントの下に定義されたルートの存在も検索します(これも from ステートメントの下に設定されます)。

ルートがポリシーで定義された必須条件のセットすべてに一致しない場合、または condition ステートメントで定義されたルートがルーティングテーブルに存在しない場合、ルートはBGPピアにエクスポートされません。このように、条件付きエクスポートポリシーは、ピアのルーティングテーブルにインストールしたい目的のルートまたはプレフィックスのルートを一致させます。

エクスポートポリシーを使用してプレフィックスの条件付きインストールを設定するには:

  1. プレフィックスをチェックする condition ステートメントを作成します。

  2. conditionステートメントを使用して、新しく作成した条件を含むエクスポートポリシーを作成します。

  3. 選択したプレフィックスのみをルーティングテーブルからエクスポートすることを要求するエクスポートポリシーをデバイスに適用します。

例:ルーティングテーブルにおけるプレフィックスの条件付きインストールを可能にする条件付きアドバタイズのルーティングポリシーの設定

この例では、エクスポートポリシーを使用して、ルーティングテーブルでのプレフィックスの条件付きインストールを設定する方法BGP説明します。

要件

この例では、以下のハードウェアおよびソフトウェアコンポーネントを使用しています。

  • M Seriesマルチサービスエッジルーター、MXシリーズ 5Gユニバーサルルーティングプラットフォーム、またはT Seriesコアルーター

  • Junos OSリリース9.0以降

概要

この例では、3つの異なる自律システム(AS)にある3つのルーターが接続され、BGPプロトコルで設定されています。アップストリームルーターであるインターネットとラベル付けされたルーターは、lo0.0 ループバックインターフェイスで設定された 5 つのアドレス(172.16.11.1/32、172.16.12.1/32、172.16.13.1/32、172.16.14.1/32、および 172.16.15.1/32)があり、追加のループバックアドレス(192.168.9.1/32)がルーター ID として設定されています。これら6つのアドレスは、インターネットに接続されたルーターのBGPルーティングテーブルの内容をエミュレートするためにBGPにエクスポートされ、Northにアドバタイズされます。

NorthルーターとSouthルーターは、それぞれ10.0.89.12/30および10.0.78.12/30ネットワークを使用し、それぞれのループバックアドレスに192.168.7.1と192.168.8.1を使用します。

図5 は、この例で使用されているトポロジーを示しています。

図5:プレフィックスConditional Installation of Prefixesの条件付きインストール

ルーターNorthは、ルーターインターネットから学習した172.16.0.0/16 BGPルートをルーターSouthにエクスポートします。これらのルートは、インターネットルーターのドメインが所有するルートを表す場合があります。さらに、特定の172.16.11.1/32ルートが存在する場合、ルーターNorthはデフォルトルートもアドバタイズします。172.16.11.1ルートは、完全なインターネット接続を提供するティア1トランジットピアリングプロバイダへのインターネットルーターのリンクを表す場合があります。

ルーターSouthは6つのルートすべてを受信しますが、ルーティングテーブルにはデフォルトルートと1つの他の特定のルート(172.16.11.1/32)のみをインストールする必要があります。

要約すると、この例は次の要件を満たしています。

  • Northでは、すべての172.16/16プレフィックスを送信します。さらに、特定のルートがinet.0ルーティングテーブルに存在する場合にのみ、0/0をSouthに送信します(この例では172.16.11.1/32)。

  • Southで、ルーティングテーブルと転送テーブルにデフォルトルートと172.16.11.1/32ルートを受け入れてインストールします。その他すべてのルートをドロップします。Southが完全なインターネットルーティングテーブルを受け入れられないローエンドデバイスかもしれないことを考慮してください。その結果、運用担当者はSouthにデフォルトルートと1つの他の特定のプレフィックスのみを割り当てたいと考えています。

最初の要件は、Northのエクスポートポリシーで満たされています。

条件付きエクスポートポリシーのロジックは、以下のように要約できます。 0/0が存在する場合、172.16.11.1/32が存在する場合は、0/0プレフィックスを送信します。つまり、172.16.11.1/32が存在しない場合、0/0を送信しないということです。

2つ目の要件は、Southのインポートポリシーで満たされています。

この例では、Southのインポートポリシーの結果として、4つのルートがドロップされます。これは、Northのエクスポートポリシーがインターネットから受信したルートを全てリークし、Southのインポートポリシーがこれらのルートの一部を除外しているためです。

Junos OSでは、インポートポリシー(インバウンドルートフィルター)がルートを拒否する、トラフィック転送に使用しない、他のピアへのアドバタイズに含まれないこと、ルーターがこれらのルートを非表示ルートとして保持することを理解しておくことが重要です。これらの非表示ルートは、ポリシーまたはルーティング目的に使用できません。ただし、これらはルーターのメモリ領域を占有します。ルートをフィルタリングして、メモリに保管され、ルーターによって処理される情報量を制御するサービスプロバイダは、インポートポリシーによって拒否されたルートを完全にドロップするようにルーターを望む場合があります。

非表示のルートは、show route receive-protocol bgp neighbor-address hiddenコマンドを使用して表示できます。その後、非表示のルートは、[edit protocols bgp]または[edit protocols bgp group group-name]階層レベルでkeep all | noneステートメントを設定することで、ルーティングテーブルから保持またはドロップすることができます。

BGPルート保持のルールは、以下のとおりです。

  • デフォルトでは、ASパスがループするルートを除き、BGPから学習したすべてのルートが保持されます。(ASパスにはローカルASが含まれます。)

  • keep allステートメントを設定することで、BGPから学習したすべてのルートは、ASパスにローカルASがあるルートも含めて保持されます。

  • keep noneステートメントを設定することで、BGPはピアから受信したルート、およびインポートポリシーまたはその他のサニティーチェックによって拒否されたルートを破棄します。このステートメントが設定され、インバウンドポリシーが変更されると、Junos OSはピアによってアドバタイズされたすべてのルートを再アドバタイズします。

keep allまたはkeep noneを設定し、ピアがルート更新をサポートする場合、ローカルスピーカーはリフレッシュメッセージを送信し、インポート評価を実行します。これらのピアに対してセッションは再起動されません。ピアが更新をサポートしているかどうかを確認するには、show bgp neighborコマンドの出力でPeer supports Refresh capabilityを確認します。

注意:

keep allまたはkeep noneを設定し、ピアがセッション再起動をサポートしていない場合、関連するBGPセッションが再起動(フラップ)されます。

トポロジー

設定

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

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

ルーターインターネット

ルーターNorth

ルーターSouth

プレフィックスの条件付きインストールの設定

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

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

プレフィックスの条件付きインストールを設定するには:

  1. 3つのルーター間のリンクを形成するルーターインターフェイスを設定します。

  2. ルーターインターネットで5つのループバックインターフェイスアドレスを設定して、ルーターSouthのルーティングテーブルにインポートされるインターネットから学習したBGPルートをエミュレートし、ルーターIDとして設定する追加アドレス(192.168.9.1/32)を設定します。

    また、ルーターNorthとSouthでループバックインターフェイスアドレスを設定します。

  3. ルーターNorthで、ルーターSouthにアドバタイズされる静的デフォルトルートを設定します。

  4. ルーターNorthのルーティングテーブルからプレフィックスをエクスポートする条件を定義します。

  5. ルーターインターネットとNorthでそれぞれエクスポートポリシー(into-bgpconditional-export-bgp )を定義し、BGPにルートをアドバタイズします。

    注:

    エクスポートポリシーで、条件 prefix_11 (ステップ 4で設定)を参照する必要があります。

  6. ルーターSouthでインポートポリシー(import-selected-routes)を定義して、ルーターNorthによってアドバタイズされたルートの一部をルーティングテーブルにインポートします。

  7. 3つのルーターすべてでBGPを設定し、自律システム間でプレフィックスのフローを有効にします。

    注:

    プレフィックスアドバタイズメントが行われるように、定義したインポートおよびエクスポートポリシーをそれぞれBGPグループに適用してください。

  8. 3 つのルーターすべてのルーター ID と自律システム番号を設定します。

    注:

    この例では、ルーターのlo0.0インターフェイスで設定されたIPアドレスに基づいてルーターIDが設定されています。

結果

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

デバイスインターネット

デバイスNorth

デバイスSouth

ルーターの設定が完了したら、設定モードから commit を入力します。

検証

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

BGPの検証

目的

3つのルーター間でBGPセッションが確立されていることを確認します。

アクション

動作モードから、 show bgp neighbor neighbor-address コマンドを実行します。

  1. ルーターインターネットでBGPセッションをチェックして、ルーターNorthがネイバーであることを確認します。

  2. ルーターNorthのBGPセッションをチェックして、ルーターインターネットがネイバーであることを確認します。

これらの出力で以下のフィールドをチェックして、BGPセッションが確立されたことを確認します。

  • Peer—ピアAS番号が表示されているかどうか確認します。

  • Local—ローカルAS番号が表示されているかどうか確認します。

  • State—値が Establishedであることを確認します。そうでない場合は、設定を再度確認し、出力フィールドの詳細については show bgp neighbor を参照してください。

同様に、ルーターNorthとSouthが互いにピア関係を形成していることを確認します。

意味

BGPセッションは、3つのルーター間で確立されます。

ルーターインターネットからルーターNorthへのプレフィックスアドバタイズの検証

目的

ルーターインターネットから送信されたルートがルーターNorthによって受信されていることを確認します。

アクション

  1. ルーターインターネット上のオペレーショナルモードから、 show route advertising-protocol bgp neighbor-address コマンドを実行します。

    出力では、ルーターインターネットがルート172.16.11.1/32、172.16.12.1/32、172.16.13.1/32、172.16.14.1/32、172.16.15.1/32、192.168.9.1/32(ルーターIDとして使用されるループバックアドレス)をルーターNorthにアドバタイズすることを確認します。

  2. ルーターNorthの運用モードから、 show route receive-protocol bgp neighbor-address コマンドを実行します。

    出力では、ルーターNorthがルーターインターネットによってアドバタイズされたすべてのルートを受信したことを確認します。

意味

ルーターインターネットによって送信されたプレフィックスは、ルーターNorthのルーティングテーブルに正常にインストールされました。

ルーターNorthからルーターSouthへのプレフィックスアドバタイズの検証

目的

ルーターインターネットから受信したルートと静的デフォルトルートが、ルーターNorthからルーターSouthでアドバタイズされていることを確認します。

アクション
  1. ルーターNorthの運用モードから、 show route 0/0 exact コマンドを実行します。

    出力では、ルーターNorthのルーティングテーブルに静的デフォルトルート(0.0.0.0/0)が存在することを検証します。

  2. ルーターNorthの運用モードから、 show route advertising-protocol bgp neighbor-address コマンドを実行します。

    出力では、ルーターNorthがルーターインターネットから受信した静的ルートと172.16.11.1/32ルート、その他多くのルートをルーターSouthにアドバタイズしていることを確認します。

プレフィックスのインストールに関するBGPインポートポリシーの検証

目的

BGPインポートポリシーにより、必要なプレフィックスが正しくインストールされていることを確認します。

アクション

ルーターNorthからの静的デフォルトルートとルーターSouthからの172.16.11.1/32ルートのみがルーティングテーブルにインストールされているかどうか、ルーターSouthのインポートルーティングテーブルにインストールされているかどうかを確認します。

動作モードから、 show route receive-protocol bgp neighbor-address コマンドを実行します。

出力では、BGPインポートポリシーがルーターSouthで動作していること、さらにルーターNorthからの0.0.0.0/0の静的デフォルトルートと、ルーターインターネットからの172.16.11.1/32ルートのみがルーターSouthのルーティングテーブルにリークされたことを確認します。

意味

設定されたBGPインポートポリシーにより、プレフィックスのインストールが成功しました。

ルーターNorthからルーターSouthへの条件付きエクスポートの検証

目的

デバイスインターネットが172.16.11.1/32ルートの送信を停止すると、デバイスNorthがデフォルト0/0ルートの送信を停止することを確認します。

アクション
  1. ループバックインターフェイスで172.16.11.1/32アドレスを無効にすることにより、デバイスインターネットが172.16.11.1/3ルートの送信を停止する原因となります。

  2. ルーターNorthの運用モードから、 show route advertising-protocol bgp neighbor-address コマンドを実行します。

    出力では、ルーターNorthがルーターSouthにデフォルトルートをアドバタイズしていないことを確認します。これは、172.16.11.1/32ルートが存在しない場合に予想される動作です。

  3. デバイスインターネットのループバックインターフェイスで172.16.11.1/32アドレスを再有効化します。

ポリシーによって非表示とされているルートの存在の検証(オプション)

目的

ルーターSouthで設定されたインポートポリシーによって非表示とされているルートの存在を確認します。

注:

このセクションでは、ニーズに応じて設定に加えることができるさまざまな変更による効果を説明します。

アクション

ルーターSouthのルーティングテーブルから非表示となっているルートを表示するには、次の方法があります。

  • show route receive-protocol bgp neighbor-addressコマンドのhiddenオプションを使用します。

  • インポートポリシーを無効にします。

  1. オペレーショナルモードから、 show route receive-protocol bgp neighbor-address hidden コマンドを実行して、非表示ルートを表示します。

    出力では、ルーターSouthのインポートポリシー(172.16.12.1/32、172.16.13.1/32、172.16.14.1/32、および172.16.15.1/32)によって非表示となっているルートの存在を確認します。

  2. [edit protocols bgp group group-name]階層レベルでdeactivate importステートメントを設定して、BGPインポートポリシーを無効にします。

  3. インポートポリシーを無効にした後、 show route receive-protocol bgp neighbor-address 動作モードコマンドを実行して、ルートをチェックします。

    出力では、過去に非表示となっているルート(172.16.12.1/32、172.16.16.13.1/32、172.16.16.14.1/32、および172.16.15.1/32)の存在を確認します。

  4. BGPインポートポリシーを有効にし、[edit protocols bgp group group-name]階層レベルでそれぞれactivate importステートメントとkeep noneステートメントを設定することにより、ルーティングテーブルから非表示ルートを削除します。

  5. オペレーショナルモードから、インポートポリシーを有効にし、keep noneステートメントを設定した後、show route receive-protocol bgp neighbor-address hiddenコマンドを実行してルートをチェックします。

    出力では、設定された keep none ステートメントにより、非表示ルートがルーティングテーブルで維持されていないことを確認します。

ポリシーなしのデフォルトEBGPルート伝搬動作の暗示的フィルタ

このセクションでは、明示的なポリシーが設定されていない場合に、EBGPルート伝搬の動作を制御する暗示的なフィルターを使用する方法について説明します。

利点

この機能には、次のメリットがあります。

  • Regulates BGP implementation—EBGPスピーカーが、デフォルトですべてのルートを受け入れてアドバタイズしたサイレントパススルーになるのを防ぎます。この機能により、特に上流のインターネットサービスプロバイダとマルチホームしている場合、リーフ自律システム上のトランジットトラフィックの増加を効果的に抑制することができます。したがって、トラフィックのサイレント・ドロップ、サービス拒否、およびグローバルなインターネットの停止も防ぐことができます。

  • Implicit filter- この設定は、暗示的フィルタの使用を容易にします。デフォルトの動作は、デフォルトですべてのルートを受信してアドバタイズするように設定されたままです。コンフィグレーション・ステートメントは、accept、reject、reject-always項目の有効または無効を指定するオプションが必要な場合のみ追加されます。暗示的フィルタにより、デフォルトのBGPポリシーに依存する既存のデプロイメントを持つユーザーが、運用に支障をきたさないようにすることができます。

概要

BGPは、グローバルなインターネットルーティングに使用されている現在のドメイン間自律プロトコルです。また、VPNやリンクステートなど、グローバルな利用を想定していない様々なサービスにも対応しています。

デフォルトのEBGP動作を含めたBGP実装は、 RFC4271、A境界ゲートウェイプロトコル4(BGP-4)に準拠しています。しかし、どのようなルートを配信すべきかを指定する明示的なガイダンスは提供されていません。これにより、元の BGP 実装では、フィルタリングを行わずにルートのサイレント パススルーとなるため、トラフィックが増加し、グローバルにインターネットが停止する原因となります。

Junos OSリリース20.3R1以降、既存の[edit protocols bgp]階層レベルに暗黙的なフィルターdefaults ebgp no-policyを導入しました。この設定では、受信とアドバタイズのデフォルトポリシーを個別の項目(accept、reject、reject-always)に分離して、動作を個別に変更できるようにしています。

明示的なポリシーが設定されていない場合、暗示的なフィルタを使用すると、次の3つの状態のいずれかでデフォルトのeBGP受信およびアドバタイズ動作を有効にすることができます。

価値

デフォルト・ポリシー

内容

同意する

受信

すべてのルートを受信することを受け入れます(デフォルトの動作でもあります)。

アドバタイズ

すべてのルートをアドバタイズすることを受け入れます(デフォルトの動作でもあります)。

拒否する

受信

インスタンス・タイプ・プライマリ、vrf、仮想ルーター、および非転送で、inet ユニキャスト・タイプおよびinet6ユニキャストのルートの受信を拒否します。

アドバタイズ

インスタンス タイプ プライマリ、vrf、仮想ルーター、および非転送で、タイプinet ユニキャストおよび inet6 ユニキャストのルートのアドバタイズを拒否します。

reject-ways

受信

すべてのルートの受信を拒否します。

アドバタイズ

すべてのルートのアドバタイズを拒否します。