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文では,ルーティング テーブルからダイナミック ルーティング プロトコルにルートをエクスポートするときに評価するルーティング ポリシーの名前を列挙します。ルーティング テーブルからエクスポートされるのは、アクティブなルートのみです。

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

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

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

要件

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

概要

BGPでは、以下のようなポリシーを適用できます。

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

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

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

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

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

重要なポイントであり、しばしば誤解され問題につながる可能性がある点は、そのような設定では、最も明示的なポリシーのみが適用されることです。ネイバーレベルのポリシーは、グループレベルのポリシーよりも明示的で、そのグループレベルのポリシーは、グローバルポリシーよりも明示的です。

ネイバー 172.16.2.2 は、send-192.168.20.1 のポリシーにのみ適用されます。ネイバー 172.16.3.3 は何らかのより具体的なものに欠けており、send-192.168.0.1 ポリシーにのみ適用されます。一方、グループ他のグループのネイバー 172.16.4.4 は、グループまたはネイバーレベルのポリシーを持っていないので、send-ダイレクトポリシーを使用します。

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

トポロジー

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

図 1: BGP へのルーティング ポリシーの適用BGP へのルーティング ポリシーの適用

CLIクイック構成は、図 1でのすべてのデバイスの設定を示しています。

セクション#d99e200__d99e454は、デバイス 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ンドに 2 つのダイレクト ルートを表示します。172.16.1.1/32 および 10.10.10.0/30 です。show route protocol staticコマンドは、2 つのスタティック ルートを表示します。192.168.0.1/32 および 192.168.20.1/32 です。

デバイス 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ルートの注入

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

要件

開始する前に、以下を実行します。

概要

この例では、 injectpolicy1 と呼ばれるルーティング・ポリシーと injectterm1と呼ばれるルーティング・タームを作成します。ポリシーは、BGPルーティング・テーブルにOSPFルートを注入します。

トポロジー

設定

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

CLIクイック構成

この例を素早く設定するには、以下のコマンドをコピーしてテキスト・ファイルに貼り付け、改行を削除し、ネットワーク・コンフィギュレーションに合わせて必要な詳細を変更し、[edit]階層レベルのCLIにコマンドをコピー&ペーストし、コンフィギュレーション・モードからcommitを入力してください。

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

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

BGPルーティング・テーブルにOSPFルートをインジェクションするには:

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

  2. マッチ・コンディションにOSPFを指定します。

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

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

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

結果

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

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

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

CLIクイック構成

この例を素早く設定するには、以下のコマンドをコピーしてテキスト・ファイルに貼り付け、改行を削除し、ネットワーク・コンフィギュレーションに合わせて必要な詳細を変更し、[edit]階層レベルのCLIにコマンドをコピー&ペーストし、コンフィギュレーション・モードからcommitを入力してください。

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

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

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

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

結果

コンフィギュレーション・モードからとというコマshow routing-optionsンドを入力し、コンフィギュレーションshow policy-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の設定内にandステートexportメントimportを含めます。

ポリシーは、以下のように適用できます:

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

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

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

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

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

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

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

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

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

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

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

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

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

BGPが非アクティブなルートを告知する設定

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

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

内部ピアに最適な外部ルートを告知するBGPの設定

一般に、デプロイされたBGP実装においては、ローカル・プリファレンス値が最も高い外部ルートは、それが最良のルートでない限り、内部ピアにアドバタイズされません。この動作は、BGPバージョン4仕様の以前のバージョンであるRFC1771で要求されていましたが、アドバタイズされる情報量を最小限に抑え、ルーティング・ループを防ぐために、通常、順守されていませんでした。しかし、最適な外部ルートをアドバタイズすることが有益なシナリオでもあります。特に、IBGPルートの発振が発生する可能性のある状況について説明します。

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

注:

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

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

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

また,ルート選択プロセスでMultiple Exit Discriminator(MED)メトリックを評価する地点に到達した場合のみ,外部ルートを広告するようにBGPを設定することも可能です。その結果、アクティブパスの外部ルートより悪い(つまり長い)ASパスを持つ外部ルートはアドバタイズされません。

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

BGPが内部ピアに最適な外部パスを広告するように設定するには、次のステートadvertise-externalメントを含めます:

注:

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

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

BGPがルート選択プロセスでMED値を評価する地点に到達した際においてのみ,最適な外部パスを広告するように設定する場合は,以下のステートconditionalメントを含みます:

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

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

BGPとルーティング・テーブルがルート情報を交換する頻度を設定する場合は、以下のステートout-delayメントを含めます:

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

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

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

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

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

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

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メントは無視されます。これらのステートメントは、複数の階層に含めることができます。

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

例:内部ピアに最適な外部ルートを告知するルーティングポリシーの設定

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

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

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

しかし、RFC1771で規定されている「最適な外部ルートを広告する」という動作が有益となるシナリオがいくつかあります。パス情報を制限することは、パス多様性が復元時間を削減する可能性があるため、必ずしも望ましくありません。また、最適な外部パスをアドバタイズすると、RFC3345、Border Gateway Protocol(BGP)永続ルート発振条件に記載されているように、内部BGP(IBGP)ルート発振の問題に対応することができます。

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

注:

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

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

Junos OSは、広告されたルートの状態にマッチするBGPエクスポートポリシーの設定もサポートしています。以下のように、アクティブまたは非アクティブなルートのいずれかを次のようにマッチすることができます。

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

例えば、以下の設定は、ユーザー定義コミュニティーとのadvertise-external設定によりアドバタイズされたルートをマークするために、内部ピアに対するBGPへの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に対してアドバタイズされません。

advertise-externalステートメントがデバイスR2で設定されている場合、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トポロジー外部アドバタイズに対するBGPトポロジー

CLIクイック構成は、図 2でのすべてのデバイスの設定を示しています。

セクション#d102e163__d102e341は、デバイス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ルートがあります。

ルートが到達可能ではない場合、またはNexthopが解決できない場合、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パス長が無視され、かつローカルの基本設定が同じになるため、ルートがアドバタイズされます。

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

この例では、ジュニパー・ネットワーク・ルーターがリモート・ピアからルート・フィルターを受 け取り、受け取ったフィルターを使用してアウトバウンド・ルート・フィルタリングを実行 するように設定する方法を示しています。

要件

開始する前に、以下を実行します。

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

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

概要

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

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

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

トポロジー

サンプル・ネットワークでは、デバイスCE1が他社製のルータとなります。この例で示すコンフィギュレーションは、ジュニパー・ネットワーク・ルータPE1上でのものです。

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

図 3: BGPプレフィックスベースのアウトバウンド・ルート・フィルタリングBGPプレフィックスベースのアウトバウンド・ルート・フィルタリング

設定

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

注:

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

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

PTXシリーズ・ルーターでの負荷分散およびBGPルートのデフォルトの動作は次のとおりです。以下のような好ましい特性を備えています:

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

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

  • アクセプトやリジェクトなどのフロー制御アクションを設定しません

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 Release 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インポートおよびエクスポート・ポリシー

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

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

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

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

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

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

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

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

要件

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

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

  • 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: プレフィックスの条件付きインストールプレフィックスの条件付きインストール

ルーター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ルーティングテーブル(この例では172.16.11.1/32)に存在する場合にのみ、0/0をSouthに送信します。

  • 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 group group-name]層レベル[edit protocols bgp]でステートkeep all | noneメントを設定することにより、ルーティングテーブルから保持またはドロップすることができます。

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

  • デフォルトでは、BGPから学習したルートはすべて保持されますが、ASパスがループするルートは除外されます。(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と自律システム番号を設定します。

    注:

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

結果

設定モードから、show interfacesshow protocols bgpshow policy-options、およびshow 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ルートのみがルーティングテーブルにリークされたことを確認します。

意味

設定された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.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.16.15.1/32)の存在を確認します。

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

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

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

ポリシーがない場合のデフォルトEBGPルート伝搬動作に関する暗示的フィルタ

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

メリット

この機能は、以下のメリットを提供します。

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

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

概要

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

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

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

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

価値

デフォルト・ポリシー

機能概要

受け入れ

受信

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

アドバタイズ

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

拒む

受信

インスタンス・タイプ・プライマリ、vrf、virtual-router、およびnon-forwardingでinet unicast並びにinet6 unicastのルートの受信を拒否します。

アドバタイズ

インスタンス・タイプ・プライマリ、vrf、virtual-router、およびnon-forwardingでinet unicast 並びにinet6 unicastのルートのアドバタイズを拒否します。

reject-ways

受信

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

アドバタイズ

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