Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
このページで
 

例:動的ルーティング ポリシーの設定

この例では、標準設定データベースで必要とされるものと同じ検証の対象とならない動的データベースにルーティングポリシーオブジェクトを設定する方法を示します。

要件

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

概要

設定変更をコミットするために必要な検証プロセスには、多大なオーバーヘッドと時間がかかります。

動的データベースへの変更をコミットするのにかかる時間は、標準構成データベースの場合よりもはるかに短くなります。これらのポリシーおよびポリシーオブジェクトは、標準データベースで設定するルーティングポリシーで参照できます。BGPは、動的データベースで設定されたポリシーおよびポリシーオブジェクトを参照するルーティングポリシーを適用できる唯一のプロトコルです。動的データベースに設定されたオブジェクトに基づいてルーティング・ポリシーを構成してコミットした後、動的データベース構成に変更を加えることによって、既存のルーティング・ポリシーを迅速に更新することができます。

注意:

Junos OS は動的データベースの設定変更を検証しないため、この機能を使用する際は、コミットする前にすべての設定変更をテストおよび検証する必要があります。

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

図 1: ダイナミック ルーティング ポリシーのサンプル ネットワークダイナミック ルーティング ポリシーのサンプル ネットワーク

この例では、外部 BGP(EBGP)セッションが確立されている 3 台のルーターが含まれています。デバイス R1 のみがダイナミック データベースを使用します。

デバイス R0 の fe-1/2/1 インターフェイスでは、複数の IPv4 インターフェイスが設定されており、ルーティング ポリシーは、デバイス R0 の fe-1/2/1 インターフェイスで設定されたすべての IP アドレスを指定するための簡略法として ポリシー条件を使用して、 これらのプレフィックスを BGP に挿入します。from interface fe-1/2/1.0

同様に、デバイスR2のfe-1/2/3インターフェイスでは、複数のIPv4アドレスが設定されており、ルーティングポリシーがこれらのプレフィックスをBGPに挿入します。デバイスR2の設定は、デバイスR2の設定がプレフィックスリストの使用を示しているという点で、デバイスR0の設定とは若干異なります。

デバイスR1の動的データベースでは、デバイスR0から学習したインターフェイスアドレス用とデバイスR2から学習したインターフェイスアドレス用の2つのプレフィックスリストが定義されています。デバイスR1の標準データベースには、動的データベースで定義されているものと同様のプレフィックスリストを持つルーティングポリシーが含まれています。

デバイス R0 とのピア セッションでは、デバイス R1 に静的データベース ポリシーが適用されます。これに対して、デバイス R2 とのピア セッションでは、デバイス R1 の設定は動的データベースを参照します。

これらの異なる構成の結果は、セクションで 分析されます。検証

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

このセクションでは 、デバイス R1 の動的データベースでの手順について説明します。#configuration776__policy-dynamic-st

セクション は、デバイス R1 の標準データベースの手順を説明します。#configuration776__policy-standard-st

設定

手順

CLIクイック構成

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

デバイスR0

デバイスR1動的データベース

デバイスR1標準データベース

デバイスR2

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

次の例では、設定階層のいくつかのレベルに移動する必要があります。手順については、 Junos OS CLIユーザーガイドのを参照してください。設定モードでのCLIエディターの使用https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-cli/junos-cli.html

デバイスR1のダイナミックデータベースを設定するには:

  1. 動的データベースの設定モードを開始します。

  2. デバイスR0から学習したインターフェイスアドレスのプレフィックスリストを作成します。

  3. デバイスR2から学習したインターフェイスアドレスのプレフィックスリストを作成します。

  4. ルーティングポリシーを設定します。

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

次の例では、設定階層のいくつかのレベルに移動する必要があります。手順については、 Junos OS CLIユーザーガイドのを参照してください。設定モードでのCLIエディターの使用https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/junos-cli/junos-cli.html

デバイス R1 の標準データベースを設定するには、次の手順に従います。

  1. ルーター インターフェイスを作成します。

  2. 動的データベース内のポリシーを参照するルーティング・ポリシーを作成します。

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

  4. 動的データベース ポリシーをデバイス R0 との BGP ピアリングに適用します。

  5. デバイスR0から学習したプレフィックスのプレフィックスリストを設定します。

  6. デバイスR2から学習したプレフィックスのプレフィックスリストを設定します。

  7. 静的データベース ポリシーを構成します。

  8. デバイスR2とのBGPピアリングを設定します。

  9. 静的データベースポリシーをデバイスR2とのBGPピアリングに適用します。

  10. (オプション)指定した期間、または手動でセッションを再確立するまで、アクティブなノンストップルーティングスイッチオーバー後にBGPピアリングセッションを再確立しないようにルーターを設定します。

    ノンストップアクティブルーティング(NSR)が有効になっている場合、動的データベースはバックアップルーティングエンジンと同期されないため、このステートメントは動的ルーティングポリシーで特に役立ちます。その結果、バックアップのルーティングエンジンに切り替えた場合、スイッチオーバー時にプライマリルーティングエンジンで実行されていたインポートおよびエクスポートポリシーが利用できなくなる可能性があります。そのため、スイッチオーバーが発生した直後にBGPピアリングセッションが自動的に再確立されないようにしたい場合があります。

  11. 自律システム(AS)番号を設定します。

結果

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

デバイスR1ダイナミック

デバイスR1標準

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

検証

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

デバイスR1の設定済みポリシーの確認

目的

デバイスR1に動的ポリシーと静的ポリシーが有効であることを確認します。

アクション

デバイスR1から コマンドを入力します 。show policy

意味

動的ポリシーは、動的データベース内の最初の中央構成の 2 回構成されているため、2 回リストされています。セカンダリ設定は、次に示すように、動的データベースが参照される静的データベース内にあります。

動的データベースで設定

静的データベースから参照

デバイスR0からデバイスR1にアドバタイズされたルートの確認

目的

デバイスR0のルーティングポリシーが機能していることを確認します。

アクション

デバイスR0から、デバイスR1のネイバーアドレスを使用して コマンドを入力します 。show route advertising-protocol bgp

意味

デバイスR0は、予期されたルートをデバイスR1に送信しています。

デバイスR1がデバイスR0から受信しているルートを確認する

目的

デバイスR1のインポートルーティングポリシーが機能していることを確認します。

アクション

デバイスR1から、デバイスR0のネイバーアドレスを使用して コマンドを入力します 。show route receive-protocol bgp

意味

デバイスR0が送信したルートの中には、デバイスR1が受信しないものがあります。ルート 172.16.9.0/24、172.16.10.0/24、および 10.0.0.0/30 が欠落しています。これは、ステートメント を使用してデバイス R0 との BGP ピアリング セッションに適用されるデバイス R1 のインポート ポリシーが、以下のルートに限定されたプレフィックス リストを具体的に定義しているためです。import dyn_policy1

デバイスR2からデバイスR1へアドバタイズされたルートの確認

目的

デバイスR2のルーティングポリシーが機能していることを確認します。

アクション

デバイスR2から、デバイスR1のネイバーアドレスを使用して コマンドを入力します 。show route advertising-protocol bgp

意味

デバイスR2は、デバイスR1に予期されたルートを送信しています。

デバイスR1がデバイスR2から受信しているルートを確認する

目的

デバイスR1のインポートルーティングポリシーが機能していることを確認します。

アクション

デバイスR1から、デバイスR0のネイバーアドレスを使用して コマンドを入力します 。show route receive-protocol bgp

意味

デバイスR2が送信したルートの1つが、デバイスR1で受信されていません。ルート 172.16.6.0/24 がありません。これは、ステートメント を使用してデバイスR2とのBGPピアリングセッションに適用されるデバイスR1のインポートポリシーが、以下のルートに限定されたプレフィックスリストを具体的に定義しているためです。import static_policy1

デバイスR1がデバイスR0にアドバタイズしているルートを確認する

目的

デバイスR1のエクスポートルーティングポリシーが機能していることを確認します。

アクション

デバイスR1から、デバイスR0のネイバーアドレスを使用して コマンドを入力します 。show route advertising-protocol bgp

意味

意外かもしれませんが、デバイスR1がBGP経由でデバイスR2から(172.16.6.0/24)を受信しなかったルートが、デバイスR1によってBGPを介してデバイスR0に対してアドバタイズされているのかもしれません。これには2つの理由があります。最初の理由は、次に示すように、ルート172.16.6.0/24が直接ルートではありますが、デバイスR1のルーティングテーブルに存在することです。

2つ目の理由は、 ステートメントを使用して デバイスR0とのBGPピアリングセッションに適用されるデバイスR1のエクスポートポリシーが、具体的に以下のルートに限定されたプレフィックスリストを定義していることです。export dyn_policy2

172.16.6.0/24 が含まれていることに注意してください。

デバイスR1がデバイスR2にアドバタイズしているルートを確認する

目的

デバイスR1のエクスポートルーティングポリシーが機能していることを確認します。

アクション

デバイスR1から、デバイスR2のネイバーアドレスを使用して コマンドを入力します 。show route advertising-protocol bgp

意味

デバイスR1は、予期されたルートをデバイスR2に送信しています。ステートメントを使用して デバイスR2とのBGPピアリングセッションに適用されるデバイスR1のエクスポートポリシーは、具体的に以下のルートに限定されたプレフィックスリストを定義します。export static_policy2