Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
このページで
 

例:ポリシーチェーンとルートフィルターの設定

ポリシーチェーンは、構成の特定のセクション内に複数のポリシーを適用することをいいます。ルートフィルターは、一致するプリフィックスの集まりです。

要件

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

概要

BGP に適用されるポリシーチェーンの例は次のとおりです。

デフォルトの BGP ポリシー adv-small-aggregatesに加え、、、およびポリシーは、デバイス R1 の BGP ピアに適用されるポリシーチェーンを構成します。 adv-staticsadv-large-aggregates 2つのポリシーは、さまざまな種類のルートフィルターを示しています。その他のポリシーはすべての静的ルートと一致するため、ルートフィルターは必要ありません。

必要に応じて、このポリシーチェーンを、内部の BGP (IBGP) ピア用の単一の multiterm ポリシーに変換することもできます。そうすると、ポリシー チェーンのメリットの 1 つが失われます。つまり、ポリシーをさまざまな目的で再利用する機能です。

図 1デバイス R1 を64510として表示します。 IBGP ピア、デバイス R2、デバイス R3 を使用します。また、デバイス R1 は、デバイス R4 への外部 BGP (EBGP) 接続を64511として、デバイス R5 を64512としています。64510としての現在の管理ポリシーは、お客様の静的ルートを他の IBGP ピアにのみ送信することを示しています。転送サービスを提供する EBGP peer は、18ビット未満のマスク長を持つ集約ルートのみを受信します。すべての EBGP ピアは、すべての顧客ルートと、マスクの長さが19ビットを超えるすべての集約を受信します。これらの管理ポリシーの各部分は、 [edit policy-opitons]構成階層内の個別のルーティングポリシーに設定されています。これらのポリシーは、64510の管理者に対して、ピアへの広告ルート用の複数の設定オプションを提供します。

デバイス R4 は、64510として送信サービスを提供し、割り当てられたルーティングスペースをインターネットに通知することを可能にします。一方、デバイス R5 によって提供されるピアリングサービスでは、64510として、すべての顧客ルートの自律システム (提供) 間で直接トラフィックをルーティングできます。

Topology

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

図 1: ポリシーチェーンの BGP トポロジポリシーチェーンの BGP トポロジ

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

このセクション#configuration283__policy-chains-stでは、デバイス R1 の手順について説明します。

構成

CLI クイック構成

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

デバイス R1

デバイス R2

デバイス R3

デバイス R4

デバイス R5

手順

順を追った手順

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

デバイス R1 を構成するには、次のようになります。

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

  2. デバイス R2 およびデバイス R3 への IBGP 接続を構成します。

  3. 内部ピアのエクスポートポリシーを適用します。

  4. EBGP 接続をデバイス R4 に設定します。

  5. デバイス R4 用のエクスポートポリシーを適用します。

  6. EBGP 接続をデバイス R5 に設定します。

  7. デバイス R5 のエクスポートポリシーを適用します。

  8. デバイス R2 およびデバイス R3 への OSPF 接続を構成します。

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

  10. 静的な集約ルートを構成します。

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

結果

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

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

検証

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

Device R4 へのルートアドバタイズを確認しています

目的

デバイス R1 では、お客様のルートがデバイス R4 に通知されていることを確認してください。

アクション

このadv-large-aggregatesポリシーは、Device R4 とのピアリングセッションに適用され、16 ~ 18 ビットのサブネットマスク長を使用して集約ルートを通知します。172.16.0.0/16 集約ルートは、管理ポリシーの定義に従って送信されていますが、より大きなサブネットマスクを持つその他のルートもデバイス R4 に送信されています。

より長いルートの発信元を確認しています

目的

デバイス R1 上で、他のルートがどこから来ているかを探します。

アクション

デバイス R1 は、デバイス R3 との BGP セッションを介してこのルートを学習しています。アクティブな BGP ルートであるため、BGP デフォルトポリシーによって自動的に通知されます。デフォルトポリシーは、すべてのポリシーチェーンの最後に常に適用されることに注意してください。必要なのは、アドバタイズされたよりも具体的なルートをブロックするポリシーです。

より具体的なルートをブロックする

目的

172.16.0.0/16 アドレスnot-larger-than-18空間内で、サブネットマスク長が19ビット以上になっているルートをすべて拒否するというポリシーを作成します。これにより、16 ~ 18 ビットのマスクを使用したすべての集約が提供されるため、管理ポリシーの目標を達成できます。

アクション

  1. デバイス R1 上でnot-larger-than-18ポリシーを設定します。

  2. デバイス R1 上で、デバイス R4 を使用してピアリングセッションにポリシーを適用します。

  3. デバイス R1 上で、デバイス R4 にアドバタイズされているルートを確認します。

ポリシーチェーンは正常に機能しています。172.16.0.0/16 ルートのみがデバイス R4 に通知されます。

デバイス R5 へのルートアドバタイズを検証する

目的

デバイス R1 では、お客様のルートがデバイス R5 にアドバタイズされていることを確認します。

デバイスR5は、デバイスR1のEBGPピア(デバイス64512 ASです。管理ポリシーでは、このピアが18ビット長よりも大規模なルートとすべての顧客ルートのみを受信することが規定されています。デバイス R4 の問題と同様の問題を検出するために、16 ~ 18 ビットのマスクnot-smaller- than-18長を使用してすべての集約を拒否するというポリシーを作成することができます。

アクション

  1. デバイス R2 で、172.16.128.0/17 の集約ルートを構成します。

  2. デバイス R1 上で、デバイス R5 にアドバタイズされているルートを確認します。

    管理ポリシーに違反して、集約ルート 172.16.128.0/17 がアドバタイズされています。

  3. デバイス R1 上でnot-smaller-than-18ポリシーを設定します。

  4. デバイス R1 上で、デバイス R5 とのピアリングセッションにポリシーを適用します。

  5. デバイス R1 上で、デバイス R5 にアドバタイズされているルートを確認します。

ポリシーチェーンは正常に機能しています。長さが18ビットを超える集約ルートと、すべての顧客ルートはデバイス R5 にアドバタイズされます。