ポリシー言語には、セットとポリシーの 2 種類の持続的で名前を付けられるオブジェクトがあります。これらのオブジェクトの定義は、開始および終了のコマンド ラインとして括弧で囲まれます。たとえば、test という名前のポリシーを定義する設定構文は、次のようになります。

  route-policy test
  [ . . . policy statements . . . ]
  end-policy
  
  

ポリシー オブジェクトの正規名は、任意の連続する英数字（大文字および小文字）、数字の 0 ～ 9、および句読文字のピリオド、ハイフン、およびアンダースコアで指定できます。名前は、文字または数字ではじまる必要があります。

このコンテキストでは、セットという用語を、順序付けのない固有のエレメントの集合を意味する数学的な概念で使用されます。ポリシー言語は、セットをマッチング用の値のグループに対するコンテナとして提供します。セットは、条件式で使用されます。セットの要素はカンマで区切ります。ヌル（空）のセットは許可されます。

次の例で、

  prefix-set backup-routes 
    # currently no backup routes are defined 
  end-set
  
  

次の条件は、

  if destination in backup-routes then 
  
  

すべてのルートに対して FALSE として評価されます。これは、プレフィックス セットに一致する一致条件がないためです。

たとえば、2 つまたは 3 つのコミュニティ値のように少ない数の要素に対して比較を実行する場合があるとします。これらの比較を実現するため、ユーザはこれらの値を直接列挙できます。これらの列挙はインライン セットと呼ばれます。インライン セットは、機能的には名前付きセットと同じですが、単純なテストをインラインにできるようにします。つまり、1 つや 2 つだけの要素を比較する際には、別の名前付きセットの維持を比較では必要としません。構文については、次の項で説明するセット型を参照してください。通常、インラインセットの構文は、括弧で囲まれたカンマ区切りのリストです。ここで element-entry は、プレフィックスやコミュニティ値などの使用タイプに適切な項目のエントリです。

次に、インライン コミュニティ セットを使用する例を示します。

  route-policy sample-inline
  if community matches-any ([10..15]:100) then
  set local-preference 100
  endif
  end-policy
  
  

次に、test-communities という名前付きセットを使用する同等の例を示します。

  community-set test-communities
  10:100,
  11:100,
  12:100,
  13:100,
  14:100,
  15:100
  end-set
  
  route-policy sample
  if community matches-any test-communities then
  set local-preference 100
  endif
  end-policy
  
  

これらの両方のポリシーは機能的に同等ですが、インライン形式では、6 つの値を格納するだけのためにコミュニティ セットの設定を必要としません。設定コンテキストに適切な形式を選択できます。次の各項では、名前付きセット バージョンとインライン形式の両方の例が必要に応じて示されています。

AS パス セットは、AS パス属性と一致させるための演算で構成されます。一致演算は、正規表現一致だけです。

名前付きセット形式

名前付きセット形式は、ios-regex キーワードを使用して正規表現のタイプを示します。また、正規表現を単一引用符で囲む必要があります。

次の例では、名前付き AS パス セットの定義を示します。

  as-path-set aset1
  ios-regex ’_42$’,
  ios-regex ’_127$’
  end-set
  
  

この AS パス セットは 2 つの要素から構成されます。一致演算で使用する場合は、この AS パス セットは、AS パスが自律システム（AS）番号 42 または 127 のいずれかで終わる任意のルートと一致します。

名前付き AS パス セットを削除するには、no as-path-set aset1 コマンドライン インターフェイス（CLI）コマンドを使用します。

（注）	正規表現一致により、CPU の負荷が高くなります。ポリシー パフォーマンスを大幅に向上するには、次のいずれかを実行します。正規表現パターンをまとめて正規表現の合計呼び出し数を減らす、または「as-path neighbor-is」、「as-path originates-from」、「as-path passes-through」などの同等のネイティブ as-path 一致演算を使用します。

  (ios-regex '_42$', ios-regex '_127$')
  
  

コミュニティ セットは、BGP コミュニティ属性との一致のためにコミュニティ値を保持しています。コミュニティは、32 ビット量です。整数のコミュニティ値は半分に分けて、コロンで区切った、0 ～ 65535 の範囲内の 2 つの符号なし 10 進整数で表す必要があります。単一の 32 ビットコミュニティ値は指定できません。次に、名前付きセット形式を示します。

  community-set cset1
  12:34,
  12:56,
  12:78,
  internet
  end-set
  

  (12:34, 12:56, 12:78)
  ($as:34, $as:$tag1, 12:78, internet)
  
  

  community-set cset3
     123:*
  end-set
  
  

prefix-set は、それぞれ 4 つの部分（アドレス、マスク長、最小一致長、最大一致長）がある IPv4 または IPv6 プレフィックス一致指定を保持しています。アドレスは必須ですが、他の 3 つの部分は任意です。アドレスは、標準のドット付き IPv4 またはコロンで区切られた 16 進数の IPv6 アドレスです。マスク長（存在する場合）は、0 ～ 32（IPv6 の場合は 0 ～ 128）の範囲内の負以外の 10 進整数で、その前のアドレスはスラッシュで区切ります。アドレスと任意のマスク長の後には、任意の最小一致長が続き、これはキーワード ge（以上（greater than or equal to）のニーモニック）で表され、その後に 0 ～ 32（IPv6 の場合は 0 ～ 128）の範囲内の負以外の 10 進整数が続きます。最後には、任意の最大一致長が続き、これはキーワード le（以下（l ess than or equal to）のニーモニック）で表され、その後に 0 ～ 32（IPv6 の場合は 0 ～ 128）の範囲内の負以外の別の 10 進整数が続きます。一致させるプレフィックスの正確な長さを指定するための構文ショートカットは、eq キーワード（等しい（equal to）のニーモニック）です。

プレフィックス一致指定にマスク長がない場合は、デフォルトのマスク長は、IPv4 では 32、IPv6 では 128 です。デフォルトの最小マッチング長はマスク長です。最小一致長が指定されている場合、デフォルトの最大一致長は、IPv4 では 32、IPv6 では 128 です。最小と最大のいずれも指定しない場合は、デフォルトの最大長はマスク長になります。

prefix-set 自体は、プレフィックス一致指定のカンマ区切りのリストです。次に例を示します。

  prefix-set legal-ipv4-prefix-examples
     10.0.1.1,
     10.0.2.0/24,
     10.0.3.0/24 ge 28,
     10.0.4.0/24 le 28,
     10.0.5.0/24 ge 26 le 30,
     10.0.6.0/24 eq 28,
     10.0.7.2/32 ge 16 le 24,
     10.0.8.0/26 ge 8 le 16
  end-set
  
  prefix-set legal-ipv6-prefix-examples
    2001:0:0:1::/64,
    2001:0:0:2::/64 ge 96,
    2001:0:0:2::/64 ge 96 le 100,
    2001:0:0:2::/64 eq 100
  end-set
  
  

prefix-set の最初の要素は、唯一の有効値 10.0.1.1/32 またはホスト アドレス 10.0.1.1 と一致します。2 番めの要素は、唯一の有効値 10.0.2.0/24 と一致します。3 番めの要素は、10.0.3.0/28 ～ 10.0.3.255/32 の範囲のプレフィックス値と一致します。4 番めの要素は、10.0.4.0/24 ～ 10.0.4.240/28 の範囲の値と一致します。5 番めの要素は、10.0.5.0/26 ～ 10.0.5.252/30 の範囲内のプレフィックスと一致します。6 番めの要素は、10.0.6.0/28 ～ 10.0.6.240/28 の範囲内にある長さ 28 の任意のプレフィックスと一致します。7 番目の要素は、10.0.[0..255].2/32（10.0.0.2/32 ～ 10.0.255.2）の範囲内にある長さ 32 の任意のプレフィックスと一致します。8 番目の要素は、10.[0..255].8.0/26（10.0.8.0/26 ～ 10.255.8.0/26）の範囲内にある長さ 26 の任意のプレフィックスと一致します。

次の prefix-set はすべて、無効なプレフィックス一致指定からなります。

  prefix-set ILLEGAL-PREFIX-EXAMPLES
     10.1.1.1 ge 16,
     10.1.2.1 le 16,
     10.1.3.0/24 le 23,
     10.1.4.0/24 ge 33,
     10.1.5.0/25 ge 29 le 28
  end-set
  
  

最小長と最大長のいずれも、マスク長がないと無効です。IPv4 の場合、最小長は、IPv4 プレフィックスの最大長である 32 未満でなければなりません。IPv6 の場合、最小長は、IPv6 プレフィックスの最大長である 128 未満でなければなりません。最大長は、最小長以上でなければなりません。

rd-set は、ルート識別子（RD）要素を含むセットを作成するために使用します。RD セットは、固有のボーダー ゲートウェイ プロトコル（BGP）VPN IPv4 アドレスをグローバルに作成するために、IPv4 アドレスが前に付いた 64 ビット値です。

RD 値は、次のコマンドを使用して定義できます。

• a.b.c.d:m:*：IPv4 形式の BGP VPN RD とワイルドカード文字。たとえば、10.0.0.2:255.255.0.0:* です。

• a.b.c.d/m:n：IPv4 形式の BGP VPN RD とマスク。たとえば、10.0.0.2:255.255.0.0:666 です。

• a.b.c.d:**：IPv4 形式の BGP VPN RD とワイルドカード文字。たとえば、10.0.0.2:255.255.0.0 です。

• a.b.c.d:n：IPv4 形式の BGP VPN RD。たとえば、10.0.0.2:666 です。

• asn:*：ASN 形式の BGP VPN RD とワイルドカード文字。たとえば、10002:255.255.0.0 です。

• asn:n：ASN 形式の BGP VPN RD。たとえば、10002:666 です。

次に、rd-set の例を示します。

  rd-set rdset1
     10.0.0.0/8:*,
     10.0.0.0/8:777,
     10.0.0.0:*,
     10.0.0.0:777,
     65000:*,
     65000:777
  end-set
  
  

ポリシーが定義されるとき、値の範囲チェックなどのいくつかの簡単な検証が行われます。たとえば、設定される MED が MED 属性の適切な範囲内にあることを検証するためにチェックされます。しかし、この範囲チェックはパラメータ指定を対象にできません。これは、パラメータ指定が値をまだ定義していない可能性があるためです。パラメータ指定は、ポリシーが接続点に付加されたときに検証されます。ポリシー リポジトリでも、ポリシーの再帰定義がなく、パラメータの数値が正しいことが検証されます。付加時には、すべてのポリシーが正しく形成されている必要があります。参照されるすべてのセットおよびポリシーが定義されていて、有効値を持っている必要があります。同様に、パラメータ値もすべて適切な範囲内にある必要があります。

指定のポリシーが接続点に付加されていないかぎり、ポリシーは存在しないセットおよびポリシーを参照できます。これにより、ワークフローが自由になります。まだ定義されていないセットまたはポリシー ブロックを参照する設定を構築して、後からこれらの未定義のポリシーおよびセットに入力できます。これにより、ポリシー定義でのより高い柔軟性を実現します。参照するポリシーの各部分は、ポリシーを定義しているときに設定に存在する必要はありません。つまり、ユーザはポリシー バーが存在しない場合でも、apply ステートメントを使用してポリシー バーを参照するポリシー例を定義できます。同様に、ユーザは、存在しないセットを参照するポリシー ステートメントを入力できます。

ただし、参照されているすべてのポリシーとセットの存在は、ポリシーが付加されたときに適用されます。neighbor 1.2.3.4 address-family ipv4 unicast policy sample in コマンドを使用してインバウンド BGP ポリシーで未定義ポリシー バーを参照するポリシー サンプルをアタッチしようとすると、ポリシー バーが存在しないために設定が拒否されます。

同様に、接続点で現在使用中のルート ポリシーまたはセットは削除できません。これは、削除の結果、未定義参照が発生するためです。現在使用中のルート ポリシーまたはセットを削除しようとすると、ユーザに対してエラー メッセージが表示されます。

ポリシー バーが存在しているものの、ステートメント、アクション、ディスポジションが存在しないヌル ポリシーと呼ばれる条件が存在します。つまり、ポリシー バーは次の場合に存在します。

  route-policy bar
  end-policy
  
  

これは、有効なポリシー ブロックです。これは、ルートを一切変更せず、pass ステートメントも含まれていないポリシー ブロックであるため、すべてのルートのドロップを実質的に強制します。したがって、ポリシー ブロックのドロップのデフォルト アクションが実行されます。

aggregation 接続点は、その集約のサブコンポーネントの条件付き存在に基づいてアドバタイズされる集約ルートを生成します。この接続点で付加されるポリシーでは、有効な BGP 属性であればどれでも集約ルートに設定できます。たとえば、生成される集約にポリシーによってコミュニティ値や MED を設定できます。名前付きポリシーによって評価されるルートのいずれかがポリシーをパスする場合、指定された集約が生成されます。集約の詳細は、suppress-route キーワードを使用してフィルタ処理されます。ルート内の属性を設定するアクションは、すべて集約上の属性に影響します。

ポリシー言語では、コンフィギュレーションはポリシーをパスするルートによって制御されます。summary-only フラグが設定されていない場合、抑制マップを使用して集約の特定のコンポーネントに対する選択的なフィルタリングや抑制を行います。つまり、集約およびさらに特定のコンポーネントが送出される場合、さらに特定のコンポーネントの一部を抑制マップを使用してフィルタできます。ポリシー言語では、ルートの選択と suppress フラグの設定によってこれを制御します。attribute-map を使用して、ユーザは集約されたルート上で特定の属性を設定できます。ポリシー言語では、集約されたルート上の属性設定は通常のアクション操作によって制御されます。

次の例では、範囲 10.0.0.0/8 ge 8 le 25（10.2.0.0/24 を除く）にルーティングされたコンポーネントがある場合、集約アドレス 10.0.0.0/8 が生成されます。summary-only が設定されていないため、集約のコンポーネントすべてがアドバタイズされます。しかし、特定のコンポーネント 10.1.0.0 は抑制されます。

  route-policy sample
    if destination in (10.0.0.0/8 ge 8 le 25) then
      set community (10:33)
    endif
    if destination in (10.2.0.0/24) then
      drop
    endif
    if destination in (10.1.0.0/24) then
      suppress-route
    endif
  end-policy
  
  router bgp 2
  address-family ipv4
    aggregate-address 10.0.0.0/8 route-policy sample
    .
    .
    .
  

集約の属性上の集約ポリシーの効果は累積します。集約ポリシーがより具体的なルートにマッチするたびに、ポリシー内の設定動作が集約を修正します。次の例の集約は、集約を構成する、より具体的なルートの数に応じて、異なる MED 値を持ちます。

  route-policy bumping-aggregation
    set med +5
  end-policy
  
  

3 種類のより具体的なルートにマッチした場合、集約の MED はデフォルトに 15 を加算したものになります。17 種類のより具体的なルートの場合、MED はデフォルトに 85 を加算したものになります。

集約ポリシーがプレフィックス パスに適用される順序は決定論的ですが、未指定です。つまり、あるルートのセットはいつでも同様の順序で出現しますが、順序を予測する方法はありません。

集約ポリシーのドロップが集約の生成を妨げることはありませんが、現在のより具体的なルートが集約に寄与できなくなります。別のより具体的なルートがルートにパスを渡す場合、集約が生成されます。集約の生成に必要なのは、より具体的なパス 1 つだけです。

additional-path 接続点を使用して、さまざまな属性のマッチング演算に基づいた、いっそう詳細な制御が行えます。この接続点は、BGP スピーカーがプレフィックスに対して複数のパスを送信できるように追加パスを選択するために、ルートポリシーを使用するかどうかを決定するために使用されます。

追加パスにより、エッジ ルータでの BGP プレフィックス独立コンバージェンス（PIC）が可能になります。

router bgp 100
 address-family ipv4 unicast
 additional-paths selection route-policy add-path-policy

default originate 接続点により、デフォルト ルート（0.0.0.0/0）を条件に応じて生成し、他のルートの存在に基づいてピアにアドバタイズできます。このコンフィギュレーションは、Routing Information Base（RIB）に対して関連付けられたポリシーの評価によって実行されます。ポリシーをパスするルートがある場合、デフォルト ルートが生成され、関連ピアに送られます。

次のポリシーでは、RIB 内に 10.0.0.0/8 ge 8 le 32 にマッチするルートが存在する場合に、デフォルト ルートを生成して BGP ネイバー 10.0.0.1 に送ります。

  route-policy sample-originate
    if rib-has-route in (10.0.0.0/8 ge 8 le 32) then
       pass
    endif
  end-policy
  
  router bgp 2
    neighbor 10.0.0.1
      remote-as 3
      address-family ipv4 unicast
      default-originate policy sample-originate
      .
      .
      .
  

neighbor export 接続点は、特定のピアまたはピアのグループに送信する BGP ルートを選択します。このルートは、関連するポリシー全体に考えられる BGP ルートのセットを実行することによって選択されます。ポリシーをパスするすべてのルートが、ピアまたはピア グループにアップデートとして送信されます。送信されるルートは、適用されているポリシーによってその BGP 属性が変更されている場合があります。

次のポリシーは、すべての BGP ルートをネイバー 10.0.0.5 に送ります。2:100 から 2:200 までの範囲内の任意のコミュニティ タグが付けられたルートは、MED の値が 100、コミュニティの値が 2:666 で送信されます。その他のルートは、MED の値が 200、コミュニティの値が 2:200 で送信されます。

  route-policy sample-export
    if community matches-any (2:[100-200]) then
      set med 100
      set community (2:666)
    else
      set med 200
      set community (2:200)
    endif
  end-policy
  
  router bgp 2
    neighbor 10.0.0.5
      remote-as 3
    address-family ipv4 unicast
      route-policy sample-export out
      .
      .
      .
  

neighbor import 接続点は、指定ピアからのルートの受け入れを制御します。ピアから受け取るすべてのルートは、アタッチされたポリシーについて実行されます。付加されたポリシーを渡すルートは、最適なパス ルート選択の候補として BGP Routing Information Base（BRIB）に渡されます。

BGP インポート ポリシーが変更されると、そのピアから受け取ったルートすべてを新しいポリシーに対して再実行することが必要になります。変更されたポリシーは、それまで全体に許可されていたルートを廃棄し、それまで廃棄されていたルートを全体に許可します。または、ルートが修正された方法を変更します。BGP の新しいコンフィギュレーション オプション（bgp auto-policy-soft-reset）によって、ソフト再設定が実行されるか BGP ルート リフレッシュ機能がネゴシエートされた場合に、この変更を自動的に発生させられます。

次の例は、ネイバー 10.0.0.1 からルートを受け取る方法を示しています。コミュニティ 3:100 で受け取ったルートは、ローカル プリファレンスが 100 に設定され、コミュニティ タグは 2:666 に設定されます。このピアからのその他のルートはすべて、ローカル プリファレンスが 200 に、コミュニティ タグが 2:200 に設定されます。

  route-policy sample_import
    if community matches-any (3:100) then
      set local-preference 100
      set community (2:666)
    else
      set local-preference 200
      set community (2:200)
    endif
  end-policy
  
  router bgp 2
    neighbor 10.0.0.1
      remote-as 3
      address-family ipv4 unicast
        route-policy sample_import in
        .
        .
        .
  

network 接続点は RIB から BGP へのルートの挿入を制御します。このポイントでアタッチされるルート ポリシーは、挿入されるルートのどの有効な BGP 属性でも設定できます。

次の例では、/24 よりも具体的なすべてのルートに対して well-known コミュニティ no-export を設定するネットワーク接続点にアタッチされたルート ポリシーを表示します。

  route-policy NetworkControl
    if destination in (0.0.0.0/0 ge 25) then
      set community (no-export) additive
    endif
  end-policy
  
  router bgp 2
    address-family ipv4 unicast
      network 172.16.0.5/27 route-policy NetworkControl
  

redistribute 接続点は、他のソースからのルートを BGP がアドバタイズできるようにします。このポイントでアタッチされるポリシーは、再配布されるルートのどの有効な BGP 属性でも設定できます。同様に、ユーザは選択演算子によって再配布されるルート送信元およびそれら送信元からのルートを制御できます。

次の例に、OSPF インスタンス 12 から BGP へのすべてのルートを再配布する方法を示します。デフォルトのルートを持つ OSPF はドロップされます。タグ 10 を持つルートは、ローカル プリファレンスが 300 に、コミュニティ値が 2:666 に設定され、no-advertise がアタッチされます。他のルートはすべて、ローカル プリファレンスが 200 に、コミュニティ値が 2:100 にセットされます。

  route-policy sample_redistribute
    if destination in (0.0.0.0/0) then
      drop
    endif
    if tag eq 10 then
       set local-preference 300
       set community (2:666, no-advertise)
    else
      set local-preference 200
      set community (2:100)
    endif
  end-policy
  
  router bgp 2
    address-family ipv4 unicast
      redistribute ospf 12 route-policy sample_redistribute
      .
      .
  

show bgp 接続点を使用して、指定のポリシーを渡す、選択した BGP ルートを表示できます。アタッチされたポリシーによってドロップされていないルートが、show bgp コマンドによる出力に似た形式で表示されます。

次の例では、show bgp route-policy コマンドを使用して、MED の値が 5 の BGP ルートを表示します。

  route-policy sample-display
    if med eq 5 then
      pass
    endif
  end-policy
  !
  show bgp route-policy sample-display
  
  

show bgp policy route-policy コマンドも存在しており、RIB がアウトバウンド BGP ポリシーであるかのようにして、名前付きポリシーを通過した RIB 内のすべてのルートを実行します。このコマンドは、次の例に示すように、各ルートが変更の前と後にどのようになったかを表示します。

  show rpl route-policy test2
  
  route-policy test2
    if (destination in  (10.0.0.0/8 ge 8 le 32)) then
      set med 333
    endif
  end-policy
  !

  show bgp
  
  BGP router identifier 10.0.0.1, local AS number 2
  BGP main routing table version 11
  BGP scan interval 60 secs
  Status codes:s suppressed, d damped, h history, * valid, > best
                i - internal, S stale
  Origin codes:i - IGP, e - EGP, ? - incomplete
     Network            Next Hop            Metric LocPrf Weight Path
  *> 10.0.0.0           10.0.1.2                10             0 3 ?
  *> 10.0.0.0/9         10.0.1.2                10             0 3 ?
  *> 10.0.0.0/10        10.0.1.2                10             0 3 ?
  *> 10.0.0.0/11        10.0.1.2                10             0 3 ?
  *> 10.1.0.0/16        10.0.1.2                10             0 3 ?
  *> 10.3.30.0/24       10.0.1.2                10             0 3 ?
  *> 10.3.30.128/25     10.0.1.2                10             0 3 ?
  *> 10.128.0.0/9       10.0.1.2                10             0 3 ?
  *> 10.255.0.0/24      10.0.101.2            1000    555      0 100 e
  *> 10.255.64.0/24     10.0.101.2            1000    555      0 100 e
  ....
  
  
show bgp policy route-policy test2
  
  10.0.0.0/8 is advertised to 10.0.101.2
  
    Path info:
      neighbor:10.0.1.2        neighbor router id:10.0.1.2
      valid  external  best  
    Attributes after inbound policy was applied:
      next hop:10.0.1.2
      MET ORG AS 
      origin:incomplete  neighbor as:3  metric:10  
      aspath:3
    Attributes after outbound policy was applied:
      next hop:10.0.1.2
      MET ORG AS 
      origin:incomplete  neighbor as:3  metric:333  
      aspath:2 3
  ...
  

table policy 接続点を使用して、グローバル ルーティング テーブルにインストールされるときのルートのトラフィック索引の値を設定できます。この接続点は、BGP ポリシー アカウンティング機能をサポートします。BGP ポリシー アカウンティングは、BGP ルートに設定されたトラフィック索引を使用してさまざまなカウンタをトラックします。このように、ルータ演算子は、マッチング演算を使用して、BGP ルート属性の複数の異なるセットを選択し、トラッキング対象のルートのクラスそれぞれに異なるトラフィック インデックスを設定できます。

次に、自律システム 10.33 を始点とする IPv4 ユニキャスト ルートでトラフィック索引を 10 に設定する例を示します。同様に、自律システム 11.60 を始点とする IPv4 ユニキャスト ルートのトラフィック索引は、FIB にインストールされるときに 11 に設定されます。これらトラフィック索引は、対象インターフェイス上で BGP ポリシー アカウンティング カウンタを有効にすることで、ルート インラインカード上で転送されるトラフィックをカウントするために使用されます。

  route-policy sample-table
    if as-path originates-from ‘10.33’ then
      set traffic-index 10
    elseif as-path originates-from ‘11.60’ then
      set traffic-index 11
    endif
  end-policy
  
  router bgp 2
    address-family ipv4 unicast
      table-policy sample-table
      .
      .
      .
  

import 接続点を使用して、グローバル VPN IPv4 テーブルから特定の VPN ルーティングおよび転送（VRF）インスタンスへのルートのインポートを制御できます。

レイヤ 3 VPN ネットワークの場合、Provider Edge（PE）ルータは他の PE ルータから Multiprotocol Internal Border Gateway Protocol（MP-iBGP）を通じて VPN IPv4 ルートを学習し、その VRF のインポート ルート ターゲットにマッチするルート ターゲットを含まないルート通知を自動的にフィルタリングして除外します。

この自動ルート フィルタリングは RPL コンフィギュレーションなしで発生します。ただし、VRF でのルートのインポートをより詳細に制御するために、VRF インポート ポリシーを設定できます。

次の例に、ルート ターゲット拡張コミュニティに基づいたマッチングおよびそれに続くネクスト ホップ設定の実行方法を示します。ルートのルート ターゲット値が 10:91 が設定されている場合、ネクスト ホップは 172.16.0.1 に設定されます。ルートのルート ターゲット値が 11:92 が設定されている場合、ネクスト ホップは 172.16.0.2 に設定されます。ルートの Site of Origin（SoO）値が 10:111111 または 10:111222 の場合、ルートはドロップされます。一致しないすべてのルートはドロップされます。

  route-policy bgpvrf_import
    if extcommunity rt matches-any (10:91) then
      set next-hop 172.16.0.1
    elseif extcommunity rt matches-every (11:92) then
      set next-hop 172.16.0.2
    elseif extcommunity soo matches-any (10:111111, 10:111222) then
      pass
    endif
  end-policy
  
  vrf vrf_import
    address-family ipv4 unicast
      import route-policy bgpvrf_import
      .
      .
      .
  

export 接続点は、特定の VRF からグローバル VPN IPv4 テーブルへのルートのエクスポート全体を制御します。

レイヤ 3 VPN ネットワークでは、VRF IPv4 ルートが VPN IPv4 ルートに変換され MP-iBGP 経由で他の PE ルータへアドバタイズされる場合（またはある VRF から PE ルータ内の他の VRF へ流れる場合）、エクスポート ルート ターゲットは VPN IPv4 ルートに追加されます。

エクスポート ルート ターゲットのセットは RPL コンフィギュレーションなしで VRF に設定されます。ただし、条件に応じてルート ターゲットを設定するために、VRF エクスポート ポリシーを設定できます。

エクスポート ルート ポリシー用にサポートされているマッチングと設定の操作例を次に示します。あるルートが 172.16.1.0/24 にマッチした場合、ルート ターゲット拡張コミュニティは 10:101 に、重みは 211 に設定されます。ルートが 172.16.1.0/24 にマッチしないもののその始点が egp である場合、ローカル プリファレンスが 212 に、ルート ターゲット拡張コミュニティは 10:101 に設定されます。指定された条件にマッチしないルートの場合、ルート ターゲット拡張コミュニティ 10:111222 がルートに追加されます。さらに、前記の条件のいずれかにマッチするルートにも RT 10:111222 が追加されます。

  route-policy bgpvrf_export
    if destination in (172.16.1.0/24) then
      set extcommunity rt (10:101)
      set weight 211
    elseif origin is egp then
      set local-preference 212
      set extcommunity rt (10:101)
    endif
    set extcommunity rt (10:111222) additive
  end-policy
  
  vrf vrf-export
    address-family ipv4 unicast
      export route-policy bgpvrf-export
      .
      .
      .
  

BGP 内の retain route target 接続点を使用して、ルート ターゲット拡張コミュニティだけに基づいたマッチング条件を指定できます。この接続点は、Route Reflector（RR）または Autonomous System Boundary Router（ASBR）で役立ちます。

通常、RR はその PE ルータとのピアのためにすべての IPv4 VPN ルートを保持しておく必要があります。これら PE は、異なるルート ターゲット IPv4 VPN ルートでタグ付けされたルータを要求する場合があり、結果として RR が拡張不能になります。ルート ターゲット拡張コミュニティの定義済みセット、およびサービスする VPN の特定のセットを持つルートを RR が保持するよう設定することで、拡張性が得られます。

この接続点を使用する別の理由は、ASBR のためです。ASBR では VRF を設定する必要はありませんが、このコンフィギュレーションによって IPv4 VPN プレフィックス情報を保持する必要があります。

次の例に、ルート ポリシー リテイナーを設定し、retain route target 接続点に適用する方法を示します。ルート ターゲット拡張コミュニティ 10:615、10:6150、15.15.15.15.15:15 を含むルートが受け入れられます。一致しないすべてのルートはドロップされます。

  extcommunity-set rt rtset1
    0:615, 
    10:6150, 
    15.15.15.15.15:15
    end-set
  
  route-policy retainer
    if extcommunity rt matches-any rtset1 then
      pass
    endif
  end-policy
  
  router bgp 2
    address-family vpnv4 unicast
      retain route-target route-policy retainer
      .
      .
      .
  

allocate-label 接続点を使用して、さまざまな属性のマッチング操作に基づいた、いっそう詳細な制御が行えます。この接続点は、IPv4 ラベル付きユニキャスト アドレス ファミリ用にアップデートをネイバーに送信するときに、inter-AS オプション C 内のラベル割り当てが必要かどうか判断するために使用されます。サポートされている属性設定アクションは、パスとドロップです。

ラベルモード接続点では、プレフィックス値、コミュニティなどの任意の一致基準に基づいてラベル モードを選択する機能が提供されます。この接続点は、通常、ラベル モードのタイプを、展開環境設定に基づいて per-ce または per-vrf または per-prefix に設定するために使用されます。サポートされている属性設定アクションは、パスとドロップです。

neighbor-orf 接続点によって、プレフィックス ベースのマッチングだけを使用した着信 BGP ルート アップデートのフィルタリングが行えます。インバウンド フィルタとしての使用に加え、フィルタリングを実行できるよう、Outbound Route Filter（ORF）としてプレフィックスと処理内容（ドロップまたはパス）が上流ネイバーに送られます。

次の例に、ルート ポリシー orf-preset を設定し、ネイバー ORF 接続点に適用する方法を示します。orf-preset で指定されたプレフィックス（172.16.1.0/24、172.16.5.0/24、172.16.11.0/24）にマッチした場合、ルートのプレフィックスはドロップされます。ネイバーが宛先に送信する前にフィルタ更新を行うことができるように、BGP も、このインバウンド フィルタリングのほかに、許可または拒否とともにこれらのプレフィックス エントリをアップストリーム ネイバーに送信します。

  prefix-set orf-preset
    172.16.1.0/24,
    172.16.5.0/24,
    172.16.11.0/24
  end-set
  
  route-policy policy-orf
    if orf prefix in orf-preset then
      drop
    endif
    if orf prefix in (172.16.3.0/24, 172.16.7.0/24, 172.16.13.0/24) then
      pass
    endif
  
  router bgp 2
    neighbor 1.1.1.1
      remote-as 3
      address-family ipv4 unicast
        orf route-policy policy-orf
      .
      .
      .
  

next-hop 接続点を使用して、より詳細なプロトコル ベースの制御とプレフィックス ベースのマッチング操作が行えます。この接続点は通常、ネクスト ホップ通知（アップまたはダウン）イベントで実行するかどうか決定するために使用されます。

ネクスト ホップのトラッキングにより、BGP は BGP プレフィックスに直接影響を与える Routing Information Base（RIB）内のルートの到達可能性をモニタできます。BGP ネクスト ホップ接続点でのルート ポリシーは、特定のプレフィックス向けに BGP に配信される通知を抑制するのに役立ちます。ルート ポリシーは RIB ルートに割り当てられます。通常、非 BGP ルート監視のため、ルート ポリシーはネクスト ホップ トラッキングとともに使用されます。

次の例に、プレフィックス 10.0.0.0 およびプレフィックス長 8 を持つスタティック ルートまたは接続ルートを監視するための、ルート ポリシーを使用した BGP ネクスト ホップ トラッキング機能の設定方法を示します。

  route-policy nxthp_policy_A
    if destination in (10.0.0.0/8) and protocol in (static, connected) then
      pass
    endif
  end-policy
  
  router bgp 2
    address-family ipv4 unicast
      nexthop route-policy nxthp_policy_A
        .
        .
        .
  

clear-policy 接続点によって、clear bgp コマンドを使用するときに、さまざまな AS パス マッチング操作に基づいたより詳細な制御が行えます。この接続点は、通常、AS パス ベースのマッチング操作に基づいて BGP フラップ統計情報をクリアするかどうか判断するときに使用します。

次の例に、セット my-as-set 内でマッチングを行う 1 つ以上の正規表現がルートに関連付けられた AS パスにマッチした場合に in 演算子が真となるルート ポリシーの設定方法を示します。マッチした場合、clear コマンドは関連付けられたフラップ統計情報をクリアします。

  as-path-set my-as-set
    ios-regex '_12$',
    ios-regex '_13$'
  end-set
  
  route-policy policy_a
    if as-path in my-as-set then
      pass
    else
      drop
    endif
  end-policy
  
  clear bgp ipv4 unicast flap-statistics route-policy policy_a
  

debug 接続点を使用して、より詳細なプレフィックス ベースのマッチング演算が行えます。この接続点、通常、ルートのプレフィックスに基づいてさまざまな BGP コマンドのデバッグ出力をフィルタリングするために使用されます。

次に、プレフィックス長が 8 のプレフィックス 20.0.0.0 だけをパスするルート ポリシーを設定する例を示します。デバッグ出力はそのプレフィックスに対してだけに表示されます。

  route-policy policy_b
    if destination in (10.0.0.0/8) then
      pass
    else
      drop
  
    endif
  end-policy
  
  debug bgp update policy_b
  

このテーブルでは、接続点ごとの BGP 属性と演算子をまとめます。

default-information originate 接続点を使用して、条件に応じてデフォルトのルート 0.0.0.0/0 を OSPF リンクステート データベースに挿入できます。これはアタッチされたポリシーの評価によって実行されます。ローカル RIB の任意のルートがポリシーをパスすると、デフォルトのルートがリンクステート データベースに挿入されます。

次の例では、10.0.0.0/8 ge 8 le 25 に一致するルートが RIB に存在する場合に、デフォルトのルートを生成する方法を示します。

  route-policy ospf-originate
    if rib-has-route in (10.0.0.0/8 ge 8 le 25) then
      pass
    endif
  end-policy
  
  router ospf 1
    default-information originate policy ospf-originate
    .
    .
    .
  

OSPF 内の redistribute 接続点は、他のルーティング プロトコル ソースから OSPF リンクステート データベースにルートを挿入します。各プロトコルからインポートするルートを選択することで実行されます。その後、コストとメトリック タイプの OSPF パラメータを設定します。ポリシーは、set metric-type または set ospf-metric コマンドを使用して OSPF へのルート挿入を制御できます。

次の例に、ポリシー OSPF-redist を使用して IS-IS instance_10 から OSPF インスタンス 1 にルートを再配布する方法を示します。ポリシーは再配布されたすべてのルートでメトリック タイプを type-2 に設定します。タグ 10 を持つ IS-IS ルートはコストが 100 に設定され、タグ 20 を持つ IS-IS ルートは OSPF コストが 200 に設定されます。タグが 10 と 20 のいずれでもない IS-IS ルートは OSPF リンクステート データベースに再配布されません。

  route-policy OSPF-redist
    set metric-type type-2
    if tag eq 10 then
      set ospf cost 100
    elseif tag eq 20 then
      set ospf cost 200
    else
      drop
    endif
  end-policy
  router ospf 1
    redistribute isis instance_10 policy OSPF-redist
    .
    .
    .
  

OSPF 内の area-in 接続点では、受信 OSPF タイプ 3 サマリー リンク ステート アドバタイズメント（LSA）をフィルタリングできます。この接続点ではプレフィックス ベースのマッチングが行えるため、より詳細なタイプ 3 サマリー LSA のフィルタリングが実現します。

次の例では、OSPF サマリー LSA のプレフィックスの設定方法を示します。プレフィックスが 10 .105.3.0/24、10 .105.7.0/24、10 .105.13.0/24 のいずれかに一致する場合、受け入れられます。プレフィックスが 10 .106.3.0/24、10 .106.7.0/24、10 .106.13.0/24 のいずれかに一致する場合、ドロップされます。

  route-policy OSPF-area-in
    if destination in (10
.105.3.0/24, 10
.105.7.0/24, 10
.105.13.0/24) then
      drop
    endif
    if destination in (10
.106.3.0/24, 10
.106.7.0/24, 10
.106.13.0/24) then
      pass
    endif
  end-policy
  
  router ospf 1
    area 1
      route-policy OSPF-area-in in 
  

OSPF 内の area-in 接続点では、発信 OSPF タイプ 3 サマリー LSA をフィルタリングできます。この接続点ではプレフィックス ベースのマッチングが行えるため、より詳細なタイプ 3 サマリー LSA のフィルタリングが実現します。

次の例では、OSPF サマリー LSA のプレフィックスの設定方法を示します。プレフィックスが 10 .105.3.0/24、10 .105.7.0/24、10 .105.13.0/24 のいずれかに一致する場合、通知されます。プレフィックスが 10 .105.3.0/24、10 .105.7.0/24、10 .105.13.0/24 のいずれかに一致する場合、ドロップされ、通知はされません。

  route-policy OSPF-area-out
    if destination in (10
.105.3.0/24, 10
.105.7.0/24, 10
.105.13.0/24) then
      drop
    endif
    if destination in (10
.105.3.0/24, 10
.105.7.0/24, 10
.105.13.0/24) then
      pass
    endif
  end-policy
  
  router ospf 1
    area 1
      route-policy OSPF-area-out out
  
  

この表では接続点ごとの OSPF 属性と演算子をまとめます。

OSPF 内の distribute-list in 接続点では、ルート ポリシーを使用して、OSPF プレフィックスをフィルタリングできます。distribute-list in ルート ポリシーは、OSPF インスタンス、エリア、およびインターフェイス レベルで設定できます。distribute-list in コマンドで使用されるルート ポリシーは、match ステートメント、「destination」および「rib-metric」をサポートします。「set」コマンドはルート ポリシーではサポートされません。

route-policy DEST
  if destination in (10.10.10.10/32) then
    drop
  else
    pass
  endif
end-policy

route-policy METRIC
  if rib-metric ge 10 and rib-metric le 19 then
    drop
  else
    pass
  endif
end-policy

prefix-set R-PFX
  10.10.10.30
end-set

route-policy R-SET
  if destination in R-PFX and rib-metric le 20 then
    pass
  else
    drop
  endif
end-policy

OSPFv3 内の redistribute 接続点は、他のルーティング プロトコル ソースから OSPFv3 リンクステート データベースにルートを挿入します。各プロトコルからインポートするルート タイプを選択することで実行されます。その後、コストとメトリック タイプの OSPFv3 パラメータを設定します。ポリシーは、metric type コマンドを使用して OSPFv3 へのルート挿入を制御できます。

次の例に、ポリシー OSPFv3-redist を使用して BGP インスタンス 15 から OSPF インスタンス 1 にルートを再配布する方法を示します。ポリシーは再配布されたすべてのルートでメトリック タイプを type-2 に設定します。タグ 10 を持つ BGP ルートはコストが 100 に設定され、タグ 20 を持つ BGP ルートは OSPFv3 コストが 200 に設定されます。タグが 10 と 20 のいずれでもない BGP ルートは OSPFv3 リンクステート データベースに再配布されません。

  route-policy OSPFv3-redist
    set metric-type type-2
    if tag eq 10 then
      set extcommunity cost 100
    elseif tag eq 20 then
      set extcommunity cost 200
    else
      drop
    endif
  end-policy
  
  router ospfv3 1
    redistribute bgp 15 policy OSPFv3-redist
    .
    .
    .
  

この表では、接続点ごとの OSPFv3 属性と演算子をまとめます。

IS-IS 内の default-information originate 接続点を使用して、デフォルトのルート 0.0.0.0/0 を条件に応じて IS-IS ルート データベースに挿入できます。

次の例では、10.0.0.0/8 ge 8 le 25 に一致するルートが RIB に存在する場合に、IPv4 ユニキャストのデフォルト ルートを生成する方法を示します。IS-IS データベースに挿入されるデフォルト ルート上で、IS-IS ルートのコストは 100 に、レベルは level-1-2 に設定されます。

  route-policy isis-originate
    if rib-has-route in (10.0.0.0/8 ge 8 le 25) then
      set metric 100
      set level level-1-2
    endif
  end-policy
  
  router isis instance_10
    address-family ipv4 unicast
      default-information originate policy isis_originate
      .
  

IS-IS 内の inter-area-propagate 接続点を使用して、プレフィックスをあるレベルから同じ IS-IS インスタンス内の別のレベルへと条件に応じてプロパゲートできます。

次の例に、プレフィックスのいずれかが 10.0.0.0/8 ge 8 le 25 に一致した場合に、プレフィックスをレベル 1 LSP からレベル 2 LSP へリークさせる方法を示します。

  route-policy isis-propagate
    if destination in (10.0.0.0/8 ge 8 le 25) then
      pass
    endif
  end-policy
  
  
  router isis instance_10
    address-family ipv4 unicast
      propagate level 1 into level 2 policy isis-propagate
      .
  

IS-IS 内の inter-area-propagate 接続点を使用して、プレフィックスをあるレベルから同じ IS-IS インスタンス内の別のレベルへと条件に応じてプロパゲートできます。

次の例に、プレフィックスのいずれかが 10.0.0.0/8 ge 8 le 25 に一致した場合に、プレフィックスをレベル 1 LSP からレベル 2 LSP へリークさせる方法を示します。

  route-policy isis-propagate
    if destination in (10.0.0.0/8 ge 8 le 25) then
      pass
    endif
  end-policy
  
  
  router isis instance_10
    address-family ipv4 unicast
      propagate level 1 into level 2 policy isis-propagate
      .
  

default-accept-in 接続点を使用すると、付加されたポリシーの評価によって EIGRP ルートの条件付きデフォルト フラグの設定とリセットが行えます。

次の例に、10.0.0.0/8 にマッチするルートと最大 10.0.0.0/25 までの長いプレフィックスすべてに条件付きデフォルト フラグを設定するポリシーを示します。

  route-policy eigrp-cd-policy-in
    if destination in (10.0.0.0/8 ge 8 le 25) then
      pass
    endif
  end-policy
  !
  router eigrp 100
    address-family ipv4
      default-information allowed in route-policy eigrp-cd-policy-in
      .
      .
      .
  

Emacs エディタを使用してルーティング ポリシーの内容を編集するには、XR EXEC モードで次の CLI コマンドを使用します。

  
         edit 
         
            route-policy
           
         
            name 
  
            emacs
  
           
  
  
      

ルート ポリシーのコピーが一時ファイルにコピーされ、エディタが起動します。編集後に、Ctrl+X および Ctrl+S のキーストロークを使用して編集バッファを保存します。エディタを保存して終了するには、Ctrl+X および Ctrl+C のキーストロークを使用します。エディタを終了すると、バッファがコミットされます。解析エラーがなければ、コンフィギュレーションがコミットされます。

  RP/0/RP0/cpu 0: router# edit route-policy policy_A
  ----------------------------------------
  == MicroEMACS 3.8b () == rpl_edit.139281 ==
    if destination in (2001::/8) then
      drop
    endif
  end-policy
  !
  
  == MicroEMACS 3.8b () == rpl_edit.139281 ==
  Parsing.
  83 bytes parsed in 1 sec (82)bytes/sec
  Committing.
  1 items committed in 1 sec (0)items/sec
  Updating.
  Updated Commit database in 1 sec 
  
  

解析エラーがある場合は、編集を続行するかどうかを尋ねられます。

  RP/0/RP0/cpu 0: router#edit route-policy policy_B
  == MicroEMACS 3.8b () == rpl_edit.141738
  route-policy policy_B
   set metric-type type_1
   if destination in (2001::/8) then
      drop
    endif  
  end-policy
  !
  == MicroEMACS 3.8b () == rpl_edit.141738 ==
  Parsing.
  105 bytes parsed in 1 sec (103)bytes/sec
  
  % Syntax/Authorization errors in one or more commands.!! CONFIGURATION 
  FAILED DUE TO SYNTAX/AUTHORIZATION ERRORS
   set metric-type type_1
   if destination in (2001::/8) then
      drop
    endif
  end-policy
  !
  
  Continue editing? [no]:
  
  

yes と答えると、エディタは、中断した場所からテキスト バッファを続行します。no と答えると、実行コンフィギュレーションは変更されず、編集セッションは終了します。

Vim（Vi IMproved）を使用したルーティング ポリシーの要素の編集は、保存や終了のキーストロークといった一部機能の違いを除き、Emacs での編集に似ています。現在のファイルに書き込んで終了するには、:wq、:x、または ZZ のキーストロークを使用します。終了して確認するには、:q キーストロークを使用します。終了して変更を廃棄するには、:q! キーストロークを使用します。

Vim の詳細なオンライン マニュアルは、次の URL から参照できます。http://www.vim.org/

CLI を使用して、ルート ポリシー ステートメントの入力や削除が行えます。ポリシー コンフィギュレーション ブロックは、end-policy や end-set といった適用可能なコマンドの入力によって完了できます。または、CLI インタープリタでは exit コマンドでポリシー コンフィギュレーション ブロックを完了させることも可能です。現在のポリシー コンフィギュレーションを廃棄して モードに戻るには、abort コマンドを使用します。

Nano エディタを使用してルーティング ポリシーの内容を編集するには、XR EXEC モードで次の CLI コマンドを使用します。

  
         edit route-policy 
         
            name
           
         
            nano
           
  
  
      

ルート ポリシーのコピーが一時ファイルにコピーされ、エディタが起動します。編集後、Ctrl-X を入力してファイルを保存し、エディタを終了します。利用可能なエディタのコマンドは画面上に表示されます。

Nano エディタの使用について詳しくは、次の URL を参照してください。http://www.nano-editor.org/

ソフトウェアでは、Nano エディタの機能の一部がサポートされていません。

RPL は、XML を使用した設定要素の編集をサポートしています。XML 経由で、既存のセットを置き換えることなくエントリの後方追加、前方追加、削除が行えます。