Cisco ASR 9000 シリーズ アグリゲーション サービス ルータ ルーティング コンフィギュレーション ガイド リリース 4.3.x

BGP はトランスポート プロトコルとして TCP を使用します。 2 台の BGP ルータが互いの間に TCP 接続を形成し（ピア ルータ）、接続パラメータを開いて確認するためにメッセージを交換します。

BGP ルータはネットワーク到達可能性情報を交換します。 この情報は、主に、宛先ネットワークに到達するためにルートで経由する必要のあるフル パス（BGP 自律システム番号）を示します。 この情報は、ループ フリーである自律システムや、ルーティング動作に制限が適用されるルーティング ポリシーを表すグラフの作成に役立ちます。

TCP 接続を確立して BGP ルーティング情報を交換している 2 台のルータは、ピアまたはネイバーと呼ばれます。 BGP ピアは最初に BGP ルーティング テーブル全体を交換します。 この交換の後、ルーティング テーブルが変更されたとき差分更新が送信されます。 BGP は BGP テーブルのバージョン番号を保存します。これはすべての BGP ピアで同一です。 ルーティング情報の変更によって BGP がテーブルを更新するたびに、バージョン番号は変更されます。 BGP ピア間の接続が維持されていることを確認するキープアライブ パケットが送信され、エラーまたは特殊な状態に応じて通知パケットが送信されます。

（注）

マルチ プロトコル ラベル スイッチング（MPLS）レイヤ 3 バーチャル プライベート ネットワーク（VPN）情報を配信するように BGP を設定する方法については、『Cisco ASR 9000 Series Aggregation Services Router MPLS Configuration Guide』を参照してください。 BGP による双方向フォワーディング検出（BFD）のサポートについては、『Cisco ASR 9000 Series Aggregation Services Router Interface and Hardware Configuration Guide』および『Cisco ASR 9000 Series Aggregation Services Router Interface and Hardware Command Reference』を参照してください。

ネイバー間に BGP セッションを確立するには、BGP にルータ ID を割り当てる必要があります。 ルータ ID は、BGP セッションが確立されると、OPEN メッセージに含めて BGP ピアに送信されます。

BGP は次の方法（プリファレンス順）でルータ ID の取得を試みます。

• ルータ コンフィギュレーション モードで bgp router-id コマンドを使用して設定されたアドレスを使用する。
• 保存されたループバック アドレス設定を使用してルータがブートされた場合に、システムのループバック インターフェイス上の最大の IPv4 アドレスを使用する。
• 保存された設定に存在しない場合に、設定される最初のループバック アドレスのプライマリ IPv4 アドレスを使用する。

このいずれの方法でもルータ ID を取得できない場合、BGP はルータ ID を持たず、BGP ネイバーとのピアリング セッションを確立できません。 そのような場合は、エラー メッセージがシステム ログに記録され、show bgp summary コマンドでは、ルータ ID として 0.0.0.0 が表示されます。

ルータ ID を取得した BGP では、さらに適したルータ ID が使用可能になっても、同じルータ ID の使用を続行します。 この使用方法によって、いずれの BGP セッションでも不要なフラッピングが発生しないようにします。 一方、現在使用中のルータ ID が無効になった場合（インターフェイスがダウンするか、設定が変更されたことによる）、BGP では新しいルータ ID を選択し（上記のルールを使用）、確立したすべてのピアリング セッションをリセットします。

（注）	ルータ ID の不要な変更（およびそれによる BGP セッションのフラッピング）を避けるために、bgp router-id コマンドを設定することを、強く推奨します。

Cisco IOS XR BGP では、ルータに設定できるネイバーの最大数、および特定のアドレス ファミリのピアから受け入れるプレフィックスの最大数に制限を設定しています。 この制限は、ルータにとって、ローカルまたはリモート ネイバーのいずれかの設定ミスに起因する、リソースの枯渇に対する予防措置となります。 BGP 設定には、次の制限が適用されます。

• 設定できるピアのデフォルトの最大数は 4000 です。 このデフォルトは、bgp maximum neighbor コマンドを使用して変更できます。 制限の範囲は 1 ～ 15000 です。 最大制限値を超えてさらにピアを設定しようとしたり、現在設定されているピアの数未満の最大制限値を設定しようとしたりすると失敗します。
• アドバタイズメントによりピアが BGP をフラッディングしないようにするために、サポートされているアドレス ファミリごとに、1 つのピアから受け入れるプレフィックスの数に対する制限が課されます。 デフォルトの制限値は、該当するアドレス ファミリのピアに対して maximum-prefix limit コマンドを設定することにより、上書きできます。 ユーザがそのアドレス ファミリに対するプレフィックスの最大数を設定していない場合は、次のデフォルト制限値が使用されます。
  • IPv4 ユニキャストに対する 512K（524,288）のプレフィックス
  • IPv4 マルチキャストに対する 128K（131,072）のプレフィックス
  • IPv6 ユニキャストに対する 128K（131,072）のプレフィックス
  • VPNv4 ユニキャストに対する 512K（524,288）のプレフィックス
  特定のアドレス ファミリのピアから受信したプレフィックスの数が、このアドレス ファミリに対する最大制限値（デフォルト設定またはユーザ設定のいずれかによる）を超えると、停止通知メッセージがそのネイバーに送信され、このネイバーとのピアリングが終了されます。 特定のアドレス ファミリのネイバーとのピアリングが確立され、そのネイバーから一定数のプレフィックスをすでに受信した後で、そのネイバーのプレフィックスの最大数が設定されていることがあります。 設定されたプレフィックスの最大数が、アドレス ファミリのネイバーからすでに受信したプレフィックスの数よりも小さい場合は、設定直後に停止通知メッセージがそのネイバーに送信され、そのネイバーとのピアリングが終了されます。

ネクストホップ情報が変更されると、BGP はルーティング情報ベース（RIB）から通知を受信します（イベント駆動型の通知）。 BGP は RIB からネクスト ホップ情報を取得して次の処理を行います。

• ネクスト ホップが到達可能であるかどうかを確認する。
• ネクスト ホップへの完全再帰 IGP メトリックを見つける（最適パス計算で使用）。
• 受信したネクスト ホップを検証する。
• 発信ネクスト ホップを計算する。
• ネイバーの到達可能性および接続を確認する。

BGP は、次のいずれかのイベントが発生したときに通知を受けます。

• ネクスト ホップが到達不能になった。
• ネクスト ホップが到達可能になった。
• ネクスト ホップへの完全な繰り返し IGP メトリックが変更される。
• ファースト ホップの IP アドレスまたはファースト ホップのインターフェイスが変更される。
• ネクスト ホップが接続された。
• ネクスト ホップが接続解除された。
• ネクスト ホップがローカル アドレスになった。
• ネクスト ホップが非ローカル アドレスになった。

（注）	到達可能性および再帰メトリック イベントは、最適パスの再計算をトリガーします。

RIB からのイベント通知は、クリティカルおよび非クリティカルとして分類されます。 クリティカルおよび非クリティカル イベントの通知は、別々のバッチで送信されます。 ただし、非クリティカル イベントが保留中であり、クリティカル イベントを読み込む要求がある場合は、非クリティカル イベントがクリティカル イベントとともに送信されます。

• クリティカル イベントは、ネクスト ホップの到達可能性（到達可能と到達不能）、接続性（接続と非接続）、および局在性（ローカルと非ローカル）に関係があります。 これらのイベントの通知は遅延しません。
• 非クリティカル イベントには、IGP メトリックの変更のみが含まれます。 これらのイベントは 3 秒の間隔で送信されます。 メトリック変更イベントは最後の 1 つが送信されてから 3 秒後にバッチ処理され、送信されます。

クリティカルおよび非クリティカル イベントのネクスト ホップ トリガー遅延は、nexthop trigger-delay コマンドを使用して、クリティカルおよび非クリティカル イベントの最小バッチ間隔を指定するように設定できます。 トリガー遅延は、アドレス ファミリに依存します。

BGP ネクストホップ トラッキング機能では、次の特性を持つルートを持つネクスト ホップだけを BGP ルートの解決に使用するように指定することができます。

• 集約ルートを回避するために、プレフィックスの長さは指定された値よりも長くなっている。
• 振動につながる可能性のあるネクスト ホップの解決に BGP ルートが使用されないように、選択したリストにソース プロトコルが含まれている。

このルート ポリシーのフィルタリングが可能なのは、RIB により、ネクスト ホップを解決するルートのソース プロトコル、およびこのルートに関連付けられているマスクの長さが特定されるからです。 nexthop route-policy コマンドは、ルート ポリシーを指定するために使用します。

ネクスト ホップ付加ポイントを使用したネクスト ホップのルート ポリシー フィルタリングの詳細については、『Cisco ASR 9000 シリーズ アグリゲーション サービス ルータ ルーティング コンフィギュレーション ガイド』（本書）の「Cisco ASR 9000 シリーズ ルータ へのルーティング ポリシーの実装」モジュールを参照してください。

自律システム番号（ASN）は、自律システム（AS）を識別するために使用されるグローバルに一意な識別子であり、これにより、AS では、ネイバー AS との間で外部ルーティング情報を交換できるようになります。 一意の ASN は、BGP ルーティングで使用するために各 AS に割り当てられます。 BGP では、ASN を 2 バイトの番号および 4 バイトの番号としてエンコードします。

Cisco IOS XR ソフトウェアでの BGP は、特定のネイバーに対するすべての設定を、ネイバー設定の下の 1 箇所にまとめる必要のある、ネイバーベースの設定モデルに従っています。 ネイバー間での設定の共有と、アップデート メッセージの共有のいずれについても、ピア グループはサポートされていません。 ピア グループの概念は、BGP 設定でテンプレートとして使用する一連の設定グループおよびネイバー間でアップデート メッセージを共有するために自動生成されるアップデート グループによって置き換えられました。

BGP では、デフォルト アドレス ファミリの概念に対応していません。 アドレス ファミリを BGP でアクティブにするには、このアドレス ファミリを BGP ルータ コンフィギュレーションで明示的に設定する必要があります。 同様に、このアドレス ファミリの BGP セッションをアクティブにするには、ネイバーでそのアドレス ファミリを明示的に設定する必要があります。 ネイバーを設定するために、BGP ルータ コンフィギュレーション レベルでアドレス ファミリを設定する必要はありません。 ただし、ネイバーにアドレス ファミリを設定するには、BGP ルータ コンフィギュレーション レベルでそのアドレス ファミリを設定する必要があります。

外部 BGP（eBGP）ネイバーには、インバウンドおよびアウトバウンドのポリシーを設定する必要があります。 ポリシーが設定されていない場合、そのネイバーからのルートは受け入れられず、いずれのルートもそのネイバーにアドバタイズされません。 この付加的なセキュリティ手段によって、設定を誤って省略した場合に、ルートが偶然受け入れられたり、アドバタイズされたりすることが決してなくなります。

（注）	この制約は eBGP ネイバー（このルータと異なる自律システムに属すネイバー）だけに適用されます。 内部 BGP（iBGP）ネイバー（同じ自律システム内のネイバー）の場合は、ポリシーがなければ、すべてのルートが受け入れられるか、アドバタイズされます。

次の例では、すべてのルートが変更なしで許可およびアドバタイズされる場合に、eBGP ネイバーに対して単純な pass-all ポリシーが設定されています。

  RP/0/RSP0/CPU0:router(config)# route-policy pass-all
  RP/0/RSP0/CPU0:router(config-rpl)# pass
  RP/0/RSP0/CPU0:router(config-rpl)# end-policy
  RP/0/RSP0/CPU0:router(config)# commit
  

ネイバーに pass-all ポリシーを適用するには、ネイバー アドレス ファミリ コンフィギュレーション モードで route-policy (BGP) コマンドを使用します。 次の例は、ネイバー 192.168.40.42 からの受信と、このネイバーに対するすべての IPv4 ユニキャスト ルートのアドバタイズを、すべての IPv4 ユニキャスト ルートに許可する方法を示します。

  RP/0/RSP0/CPU0:router(config)# router bgp 1
  RP/0/RSP0/CPU0:router(config-bgp)# neighbor 192.168.40.24
  RP/0/RSP0/CPU0:router(config-bgp-nbr)# remote-as 21
  RP/0/RSP0/CPU0:router(config-bgp-nbr)# address-family ipv4 unicast
  RP/0/RSP0/CPU0:router(config-bgp-nbr-af)# route-policy pass-all in
  RP/0/RSP0/CPU0:router(config-bgp-nbr-af)# route-policy pass-all out
  RP/0/RSP0/CPU0:router(config-bgp-nbr-af)# commit
 

すべてのアクティブ アドレス ファミリに対するインバウンドとアウトバウンドの両方のポリシーを持っていない eBGP ネイバーを表示するには、show bgp summary コマンドを使用します。 次の例の出力では、該当する eBGP ネイバーが感嘆符（!）によって示されています。

  RP/0/RSP0/CPU0:router# show bgp all all summary
  
  Address Family: IPv4 Unicast
  ============================
  
  BGP router identifier 10.0.0.1, local AS number 1
  BGP generic scan interval 60 secs
  BGP main routing table version 41
  BGP scan interval 60 secs
  BGP is operating in STANDALONE mode.
  
  Process         RecvTblVer    bRIB/RIB  SendTblVer
  Speaker                 41          41          41
  
  Neighbor        Spk    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  St/PfxRcd
  10.0.101.1        0     1     919     925       41    0    0 15:15:08       10
  10.0.101.2        0     2       0       0        0    0    0 00:00:00 Idle
  
  
  Address Family: IPv4 Multicast
  ==============================
  
  BGP router identifier 10.0.0.1, local AS number 1
  BGP generic scan interval 60 secs
  BGP main routing table version 1
  BGP scan interval 60 secs
  BGP is operating in STANDALONE mode.
  
  Process         RecvTblVer    bRIB/RIB  SendTblVer
  Speaker                  1           1           1
  
  Some configured eBGP neighbors do not have both inbound and
  outbound policies configured for IPv4 Multicast address family.
  These neighbors will default to sending and/or receiving no
  routes and are marked with ’!’ in the output below. Use the
  ’show bgp neighbor <nbr_address>’ command for details.
  
  Neighbor        Spk    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  St/PfxRcd
  10.0.101.2        0     2       0       0        0    0    0 00:00:00 Idle!
  
  
  Address Family: IPv6 Unicast
  ============================
  
  BGP router identifier 10.0.0.1, local AS number 1
  BGP generic scan interval 60 secs
  BGP main routing table version 2
  BGP scan interval 60 secs
  BGP is operating in STANDALONE mode.
  
  Process         RecvTblVer    bRIB/RIB  SendTblVer
  Speaker                  2           2           2
  
  Neighbor        Spk    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  St/PfxRcd
  2222::2           0     2     920     918        2    0    0 15:15:11        1
  2222::4           0     3       0       0        0    0    0 00:00:00 Idle
  
  
  Address Family: IPv6 Multicast
  ==============================
  
  BGP router identifier 10.0.0.1, local AS number 1
  BGP generic scan interval 60 secs
  BGP main routing table version 1
  BGP scan interval 60 secs
  BGP is operating in STANDALONE mode.
  
  Process         RecvTblVer    bRIB/RIB  SendTblVer
  Speaker                  1           1           1
  
  Some configured eBGP neighbors do not have both inbound and
  outbound policies configured for IPv6 Multicast address family.
  These neighbors will default to sending and/or receiving no
  routes and are marked with ’!’ in the output below. Use the
  ’show bgp neighbor <nbr_address>’ command for details.
  
  Neighbor        Spk    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  St/PfxRcd
  2222::2           0     2     920     918        0    0    0 15:15:11        0
  2222::4           0     3       0       0        0    0    0 00:00:00 Idle!
  

BGP のテーブル ポリシー機能を使用すると、ルートのトラフィック索引の値をグローバル ルーティング テーブルにインストールされるときに設定できます。 この機能をイネーブルにするには table-policy コマンドを使用します。また BGP ポリシー アカウンティング機能もサポートされています。

BGP ポリシー アカウンティングでは、BGP ルートに設定されたトラフィック索引を使用してさまざまなカウンタをトラックします。 テーブル ポリシーの使用法の詳細については、 『Cisco ASR 9000 Series Aggregation Services Router Routing Configuration Guide』の「Implementing Routing Policy on Cisco ASR 9000 Series Router」モジュールを参照してください。 BGP ポリシー アカウンティングの詳細については、 『Cisco ASR 9000 Series Aggregation Services Router IP Addresses and Services Command Reference』の「 Cisco Express Forwarding Commands on Cisco ASR 9000 Series Router」モジュールを参照してください。

テーブル ポリシーを使用すると、一致基準に基づいて RIB からのルートをドロップすることもできます。 この機能は特定のアプリケーションにおいて有用ですが、BGP がグローバル ルーティングおよびフォワーディング テーブルにインストールしていないネイバーに対して、BGP がルートをアドバタイズするところに、簡単にルーティング「ブラック ホール」が作成されてしまうため、注意して使用する必要があります。

BGP アップデート グループ機能には、アウトバウンド ポリシーを共有し、アップデート メッセージを共有できるネイバーのアップデート グループをダイナミックに計算し、最適化する新しいアルゴリズムが含まれています。 BGP アップデート グループ機能では、アップデート グループ レプリケーションはピア グループ コンフィギュレーションから分離されるため、ネイバー コンフィギュレーションのコンバージェンス時間が短縮され、柔軟性が高まります。

この機能を使用するには、次の概念を理解しておく必要があります。

BGP コスト コミュニティは非推移的な拡張コミュニティ属性で、内部 BGP（iBGP）およびコンフェデレーション ピアへ渡されますが、外部 BGP（eBGP）ピアへは渡されません。 コスト コミュニティ機能により、コスト値を特定のルートに割り当てることで、ローカル ルート プリファレンスをカスタマイズし、最適パス選択プロセスに反映させることができます。 拡張コミュニティ形式は、最適パス アルゴリズムの異なるポイントでの最適パスの決定に影響する標準の挿入ポイント（POI）を定義します。

コスト コミュニティ属性は、ルート ポリシーで set extcommunity cost コマンドを設定することにより、内部ルートに適用されます。 set extcommunity cost コマンドについては、『Cisco ASR 9000 Series Aggregation Services Router Routing Command Reference』の「Routing Policy Language Commands on Cisco ASR 9000 シリーズ ルータ 」モジュールを参照してください。 cost community set 句は、コスト コミュニティ ID 番号（0 ～ 255）およびコスト コミュニティ番号（0 ～ 4294967295）を使用して設定されます。 コスト コミュニティ番号によってパスの優先度が判断されます。 最も低いコスト コミュニティ番号を持つパスが優先されます。 コスト コミュニティ番号を具体的に設定していないパスには、デフォルトのコスト コミュニティ番号である 2147483647（0 ～ 4294967295 の中央値）が割り当てられ、最適パス選択プロセスにより評価されます。 2 つのパスが同じコスト コミュニティ番号を使用して設定されている場合、パス選択プロセスでは最も低いコスト コミュニティ ID のパスが優先されます。 このコスト拡張コミュニティ リンク属性は、拡張コミュニティ交換がイネーブルなとき、iBGP ピアに伝播します。

次のコマンドには route-policy キーワードが含まれています。このキーワードは、cost community set 句を使用して設定されるルート ポリシーを適用するために使用できます。

• aggregate-address
• redistribute
• network

BGP ルータは、通常は同じ宛先に対する複数のパスを受信します。 BGP の最適パス アルゴリズムは、IP ルーティング テーブルに格納し、トラフィックの転送に使用する最適なパスを決めるものです。 この項では、インターネット技術特別調査委員会（IETF）のネットワーク ワーキング グループによる draft-ietf-idr-bgp4-24.txt 資料の 9.1 項で指定されている BGP 最適パス アルゴリズムの Cisco IOS XR ソフトウェア実装について説明します。

BGP 最適パス アルゴリズムは、次の 3 つのパートに分かれて実行されます。

• パート 1：2 つのパスを比較して、いずれが優れているのかを判別します。
• パート 2：すべてのパスを順に処理し、全体として最適なパスを選択するためにパスを比較する順序を決定します。
• パート 3：新しい最適パスを使用するに足るだけの差が新旧の最適パスにあるかどうかを判別します。

（注）	比較演算が推移的ではないため、パート 2 で決定された比較の順序は重要です。つまり、3 つのパス、A、B、C がある場合、A と B を比較したときに A の方が優れていて、B と C と比較したときに B の方が優れている場合、A と C を比較したときに必ずしも A が優れているとは限りません。 この非推移性は、Multi Exit Discriminator（MED）は、すべてのパス間ではなく、同じネイバー自律システム（AS）からのパス間のみで比較されるために生じます。

アドミニストレーティブ ディスタンスは、ルーティング情報源の信頼性を示す評価基準です。 通常は、値が大きいほど、信頼性の格付けが下がります。 BGP のアドミニストレーティブ ディスタンスを指定する方法については、 『Cisco ASR 9000 Series Aggregation Services Router Routing Command Reference』 の「BGP コマンド」のモジュールを参照してください。

一般的にルートは複数のプロトコルによって検出されます。 アドミニストレーティブ ディスタンスは、複数のプロトコルから学習したルートを区別するために使用されます。 最もアドミニストレーティブ ディスタンスが低いルートが IP ルーティング テーブルに組み込まれます。 BGP はデフォルトで、表 1のアドミニストレーティブ ディスタンスを使用します。

（注）	ディスタンスは BGP パス選択アルゴリズムに影響しませんが、BGP で学習されたルートを IP ルーティング テーブルに組み込むかどうかを左右します。

通常、eBGP を介して学習されたルートは、ディスタンス（20）を理由として IP ルーティング テーブルに組み込まれます。 ただし、2 つの AS には IGP-learned バックドア ルートと eBGP-learned のルートがあります。 ポリシーは、IGP-learned パスを優先パスとして使用し、IGP パスが停止しているときに eBGP-learned パスを使用するなどの内容になります。 図 1を参照してください。

図 3. バックドアの例

図 1 では、ルータ A と C、ルータ B と C が eBGP を実行しています。 ルータ A および B は、IGP を実行しています（ルーティング情報プロトコル（RIP）、Enhanced Interior Gateway Routing Protocol（IGRP）、Enhanced IGRP、または Open Shortest Path First（OSPF）など）。 RIP、IGRP、Enhanced IGRP、および OSPF のデフォルト ディスタンスは、それぞれ、120、100、90、および 110 です。 これらの距離はすべて eBGP のデフォルト ディスタンス（20）よりも長くなります。 通常は、ディスタンスの一番小さいルートが優先されます。

ルータ A は、160.10.0.0 に関するアップデートを、eBGP と IGP の 2 つのルーティング プロトコルから受信します。 eBGP のデフォルト ディスタンスは、IGP のデフォルト ディスタンスよりも小さいため、ルータ A では、ルータ C からの eBGP-learned ルートを選択します。 ルータ A はルータ B（IGP）から 160.10.0.0 について学習させる場合は、BGP バック ドアを確立します。 を参照してください。

次の例では、ネットワーク バックドアが設定されています。

RP/0/RSP0/CPU0:router(config)# router bgp 100
RP/0/RSP0/CPU0:router(config-bgp)# address-family ipv4 unicast
RP/0/RSP0/CPU0:router(config-bgp-af)# network 160.10.0.0/16 backdoor

ルータ A では、eBGP-learned ルートをローカルとして扱い、ディスタンス 200 で IP ルーティング テーブルに組み込みます。 このネットワークは Enhanced IGRP を介しても学習しているため（ディスタンスは 90）、Enhanced IGRP ルートは、IP ルーティング テーブルに正常に組み込まれ、トラフィックの転送に使用されます。 Enhanced IGRP-learned ルートが停止すると、eBGP-learned ルートが IP ルーティング テーブルに組み込まれ、トラフィックの転送に使用されます。

Although BGP ではネットワーク 160.10.0.0 をローカル エントリとして扱いますが、通常、ローカル エントリをアドバタイズするようにネットワーク 160.10.0.0 をアドバタイズすることはありません。

マルチプロトコル BGP は、BGP の拡張バージョンで、複数のネットワーク層プロトコル、および IP マルチキャスト ルートに関するルーティング情報を伝送します。 BGP は、ユニキャスト ルーティングのセットと、マルチキャスト ルーティングのセットの 2 つのルート セットを伝送します。 マルチキャスト ルーティングと関連付けられたルートは、データ分散ツリーを構築するためにプロトコル独立マルチキャスト（PIM）機能で使用されます。

マルチプロトコル BGP は、トラフィックの種類別に使用するリソースを制限するなどの目的で、マルチキャスト トラフィック専用のリンクが必要な場合に役立ちます。 マルチプロトコル BGP を使用すると、マルチキャスト ルーティング トポロジとは異なるユニキャスト ルーティング トポロジによって、ネットワークおよびリソースの制御を向上できます。

BGP でドメイン間マルチキャスト ルーティングを実行する唯一の方法は、ユニキャスト ルーティングに対応できる BGP インフラストラクチャを使用することでした。 通常は、すべてのマルチキャスト トラフィックを 1 つのネットワーク アクセス ポイント（NAP）で交換します。 これらのルータがマルチキャスト対応でないか、マルチキャスト トラフィックのフローに適用するさまざまなポリシーがある場合は、マルチプロトコル BGP なしでマルチキャスト ルーティングをサポートできません。

（注）	ユニキャストとマルチキャストの両方のネットワーク層到達可能性情報（NLRI）を交換する BGP ピアを設定することはできますが、マルチ プロトコル BGP クラウドと BGP クラウドを接続することはできません。 つまり、マルチプロトコル BGP ルートを BGP に再配布できません。

図 1に、一致しておらず、したがって、マルチプロトコル BGP なしでは実現できない、単純なユニキャストとマルチキャストのトポロジを示します。

自律システム 100、200、および 300 は、FDDI リングである 2 つの NAP にそれぞれ接続しています。 1 つはユニキャスト ピアリング（ユニキャスト トラフィックの交換）に使用されます。 Multicast Friendly Interconnect（MFI）リングは、マルチキャスト ピアリング（マルチキャスト トラフィックの交換）に使用されます。 各ルータは、ユニキャストおよびマルチキャスト対応です。

図 4. 不一致のユニキャスト ルートおよびマルチキャスト ルート

図 2 は、ユニキャストだけに対応したルータおよびマルチキャストだけに対応したルータのトポロジです。 左側にある 2 つのルータはユニキャストだけに対応しています（マルチキャスト ルーティングをサポートしていないか、マルチキャスト ルーティングを実行するよう設定されていない）。 右側にある 2 つのルータはマルチキャストだけに対応したルータです。 ルータ A および B は、ユニキャストおよびマルチキャスト ルーティングの両方をサポートしています。 ユニキャストだけに対応したルータおよびマルチキャストだけに対応したルータは、1 つの NAP に接続されています。

図 2 では、ユニキャスト トラフィックだけがルータ A からユニキャスト ルータを経由してルータ B との間を行き来できます。 マルチキャスト トラフィックは、このパス上を流れることができないため、別のルーティング テーブルが必要です。 マルチキャスト トラフィックは、ルータ A からマルチキャスト ルータを経由してルータ B との間を行き来するパスを使用します。

図 2 に、ルータ A からルータ B へユニキャスト ルートおよびマルチキャスト ルートを別々に持つマルチプロトコル BGP 環境を示します。 マルチプロトコル BGP では、これらのルートが不一致であることが許可されます。 この図では、両方の自律システムに内部マルチプロトコル BGP（IMBGP）が設定されている必要があります。

PIM などのマルチキャスト ルーティング プロトコルでは、マルチキャスト BGP データベースを使用して、マルチキャスト対応の送信元に対する Reverse Path Forwarding（RPF）検索を実行します。 したがって、マルチキャスト トポロジ上ではパケットの送信と受け入れが可能ですが、ユニキャスト トポロジ上ではできません。

図 5. マルチキャスト BGP 環境

ルート ダンプニングは、インターネットワーク上でのフラッピング ルートの伝搬を最小限に抑える BGP 機能です。 ルートの状態が使用可能、使用不可能、使用可能、使用不可能という具合に、繰り返し変化する場合、ルートはフラッピングと見なされます。

たとえば、自律システム 1、自律システム 2、および自律システム 3 の 3 つの BGP 自律システムがあるネットワークについて考えます。 自律システム 1 のネットワーク A へのルートがフラッピングする（利用できなくなる）と仮定します。 ルート ダンプニングがない状況では、自律システム 1 から自律システム 2 への eBGP ネイバーは、取り消しメッセージを自律システム 2 に送信します。 次に自律システム 2 内の境界ルータは、取り消しメッセージを自律システム 3 に伝播します。 ネットワーク A へのルートが再出現したとき、自律システム 1 は自律システム 2 に、自律システム 2 は自律システム 3 にアドバタイズメント メッセージを送信します。 ネットワーク A へのルートが利用可能になったり不可になったりを繰り返す場合、取り消しメッセージおよびアドバタイズメント メッセージが多数送信されます。 ルート フラッピングは、インターネットに接続されたインターネットワークでの問題です。インターネットのバックボーンでルートのフラッピングが生じると、通常、多くのルートに影響を与えるからです。

iBGP メッシュを削減する方法の 1 つとして、ある自律システムを複数の副自律システムに分割し、単一のコンフェデレーションにグループ化することがあげられます。 外部からは、このコンフェデレーションは単一の自律システムであるかのように見えます。 各自律システムは内部で完全にメッシュ化されていて、同じコンフェデレーション内の他の自律システムとの間には数本の接続があります。 異なる自律システム内にあるピアは eBGP セッションを持ちますが、ルーティング情報は iBGP ピアと同様な方法で交換されます。 具体的には、ネクスト ホップ、MED、およびローカル プリファレンス情報は維持されます。 この機能により、自律システムすべてに対して単一の IGP を保持できます。

BGP を使用するには、すべての iBGP スピーカーが完全メッシュ化されている必要があります。 ただし、iBGP スピーカーの数が多い場合、この要件には適切な拡張性がありません。 コンフェデレーションを設定する代わりに、ルート リフレクタ設定を使用すると iBGP メッシュを削減できます。

図 1 に、3 つの iBGP スピーカー（ルータ A、B、C）を持つ、単純な iBGP 設定の例を示します。 ルート リフレクタがない場合、外部ネイバーからルートを受信したとき、ルータ A では、ルータ B と C の両方にアドバタイズする必要があります。 ルータ B および C では、内部のネイバーから学習したルートを他の内部ネイバーに渡さないため、これらのルータでは iBGP が学習したルートを他の iBGP スピーカーに再アドバタイズしません。こうして、ルーティング情報のループを回避します。

図 6. 完全メッシュ化された 3 つの iBGP スピーカー

ルート リフレクタがある場合は、学習したルートをネイバーに渡す方法があるため、すべての iBGP スピーカーを完全にメッシュ化する必要はありません。 このモデルでは、iBGP が学習したルートを一連の iBGP ネイバーに渡す役割を持つルート リフレクタとして、1 つの iBGP ピアを設定しています。 図 2 では、ルータ B がルート リフレクタとして設定されています。 ルータ A からアドバタイズされたルートをルート リフレクタが受信すると、ルータ C にアドバタイズします。逆の場合も同じです。 このスキームにより、ルータ A とルータ C 間の iBGP セッションは不要になります。

図 7. ルート リフレクタのある単純な BGP モデル

ルート リフレクタの内部ピアは、次の 2 種類のグループに分けられます。クライアントのピアと、自律システム内の他の全ルータ（非クライアント ピア）です。 ルート リフレクタは、これらの 2 つのグループ間でルートを反映させます。 ルート リフレクタおよびそのクライアント ピアは、クラスタを形成します。 非クライアント ピアは相互に完全メッシュ構造にする必要がありますが、クライアント ピアはその必要はありません。 クラスタ内のクライアントは、クラスタ外の iBGP スピーカーとは通信しません。

図 8. より複雑な BGP ルート リフレクタのモデル

図 3 に、より複雑なルート リフレクタのスキームを示します。 ルータ A は、ルータ B、C、および D を持つクラスタのルート リフレクタです。 ルータ E、F、および G は完全メッシュ化された、非クライアント ルータです。

ルート リフレクタがアドバタイズされたルートを受信すると、ネイバーに応じて、次のようなアクションを取ります。

• 外部 BGP スピーカーからのルートをすべてのクライアントおよび非クライアント ピアにアドバタイズします。
• 非クライアント ピアからのルートをすべてのクライアントにアドバタイズします。
• クライアントからのルートをすべてのクライアントおよび非クライアント ピアにアドバタイズします。 したがって、クライアントを完全メッシュ構造にする必要はありません。

ルート リフレクタ対応の BGP スピーカーとともに、ルート リフレクタの概念に対応していない BGP スピーカーを併用することもできます。 これらは、クライアントまたは非クライアント グループのメンバとなることができます。したがって、旧 BGP モデルからルート リフレクタ モデルへ、簡単に順次移行できます。 たとえば、最初に、ルート リフレクタおよびいくつかのクライアントを持つ単一のクラスタを作成します。 他のすべての iBGP スピーカーはルート リフレクタに対して非クライアント ピアとすることができ、クラスタを作成して徐々に追加します。

自律システムは複数のルート リフレクタを持つことができます。 ルート リフレクタは、他のルート リフレクタを他の iBGP スピーカーと同様に扱います。 ルート リフレクタは、他のルート リフレクタをクライアント グループまたは非クライアント グループに含むように設定できます。 単純な設定では、バックボーンを多数のクラスタに分割してもかまいません。 各ルート リフレクタは、非クライアント ピアとして他のルート リフレクタとともに設定されます（このため、すべてのルート リフレクタは完全メッシュ化されます）。 クライアントは、所属するクラスタのルート リフレクタとだけ、iBGP セッションを維持するように設定されます。

通常、クライアントのクラスタには、ルート リフレクタが 1 つ存在します。 その場合、クラスタはルート リフレクタのルータ ID で識別されます。 冗長性を向上させ、シングル ポイント障害を避けるために、クラスタは複数のルート リフレクタを含むことがあります。 この場合、クラスタ内のすべてのルート リフレクタにクラスタ ID を設定し、ルート リフレクタが同一クラスタ内のルート リフレクタからのアップデートを識別できるようにする必要があります。 クラスタに機能を提供しているルート リフレクタはすべて完全メッシュ化され、同一のクライアントおよび非クライアント ピアのセットを持っている必要があります。

デフォルトでは、ルート リフレクタのクライアントは完全メッシュ化されている必要はなく、クライアントからのルートは他のクライアントに反映されます。 ただし、クライアントが完全メッシュ化されている場合は、ルート リフレクタはルートをクライアントに反映する必要はありません。

iBGP が学習したルートが反映されるため、ルーティング情報がループする場合があります。 ルート リフレクタ モデルには、ルーティングのループを防ぐ、次のようなメカニズムがあります。

• 送信元 ID は、任意で非推移的な BGP 属性です。 これは 4 バイトの属性で、ルート リフレクタにより作成されます。 この属性は、ローカル自律システムのルートの送信元のルータ ID を保持します。 したがって、設定ミスによりルーティング情報が送信元に戻ってくる場合、その情報は無視されます。
• クラスタ リストは任意で非推移的な BGP 属性です。 これは、ルートが渡したクラスタ ID のシーケンスです。 ルート リフレクタでは、クライアントから非クライアント ピアにルートを反映するとき（およびその逆のとき）、ローカル クラスタ ID をクラスタ リストに付加します。 クラスタ リストが空の場合は、新規のクラスタ リストが作成されます。 ルート リフレクタでは、この属性を使用して、設定ミスによりルーティング情報が同じクラスタにループ バックしているかどうかを識別できます。 クラスタ リストにローカル クラスタ ID が見つかった場合、そのアドバタイズメントは無視されます。

show コマンドのほとんどは、アドレス ファミリ（AFI）およびサブアドレス ファミリ（SAFI）の引数を使用します（AFI および SAFI については、RFC 1700 および RFC 2858 を参照してください）。 Cisco IOS XR ソフトウェア パーサーには、afi および safi を設定して、show コマンドの実行時には指定する必要がないようにする機能があります。 次のパーサー コマンドがあります。

• set default-afi { ipv4 | ipv6 | all }
• set default-safi { unicast | multicast | all }

パーサーでは、デフォルト afi 値に ipv4 を、デフォルト safi 値に unicast を自動設定します。 デフォルトの afi 値を ipv4 から変更する、あるいはデフォルトの safi 値を unicast から変更する場合、使用する必要があるのはパーサー コマンドだけです。 show コマンドに指定された afi または safi キーワードは、パーサー コマンドを使用して設定された値を上書きします。 afi および safi に現在設定されている値を確認するには、次の show default-afi-safi-vrf コマンドを使用します。

Carrier Supporting Carrier（CSC）は、サービス プロバイダーの 1 つが別のサービス プロバイダーに自社のバックボーン ネットワークのセグメントの使用を許可する状況を記述した用語です。 他のプロバイダーにバックボーン ネットワークのセグメントを提供するサービス プロバイダーは、バックボーン キャリアと呼ばれます。 バックボーン ネットワークのセグメントを使用するサービス プロバイダーは、カスタマー キャリアと呼ばれます。

バックボーン キャリアは、ボーダー ゲートウェイ プロトコル/マルチプロトコル ラベル スイッチング（BGP/MPLS）VPN サービスを提供します。 カスタマー キャリアは、次のいずれかになります。

• インターネット サービス プロバイダー（ISP）（定義上、ISP は VPN サービスを提供しません）
• BGP/MPLS VPN サービス プロバイダー

BGP をイネーブルにするように CSC ネットワークを設定して、バックボーン キャリア プロバイダー エッジ（PE）ルータとカスタマー キャリア カスタマー エッジ（CE）ルータ間のルートおよび MPLS ラベルを、複数パスを使用して転送できます。 BGP を使用して IPv4 ルートと MPLS ラベル ルートを配布する利点を次に示します。

• BGP は、VPN ルーティング/転送（VRF）テーブル内で内部ゲートウェイ プロトコル（IGP）およびラベル配布プロトコル（LDP）の代わりをします。 BGP を使用して、ルートおよび MPLS ラベルを配布できます。 2 つではなく単一のプロトコルを使用すると、設定およびトラブルシューティングが簡単になります。
• BGP は、2 つの ISP を接続する場合の優先ルーティング プロトコルです。主な理由は、そのルーティング ポリシーと拡張性です。 ISP では、通常、2 つのプロバイダー間で BGP を使用します。 この機能を使用すると、これらの ISP は BGP を使用できます。

BGP を使用した MPLS VPN CSC の設定の詳細については、 『Cisco ASR 9000 Series Aggregation Services Router MPLS Configuration Guide』の「Implementing MPLS Layer 3 VPNs on Cisco ASR 9000 シリーズ ルータ 」モジュールを参照してください。

BGP キーチェーンを使用すると、2 つの BGP ピア間のキーチェーン認証がイネーブルになります。 BGP のエンドポイントは、どちらも draft-bonica-tcp-auth-05.txt を順守する必要があり、一方のエンドポイントのキーチェーンと、もう一方のエンドポイントのパスワードは機能しません。

キーチェーン管理の詳細については、 『Cisco ASR 9000 Series Aggregation Services Router System Security Configuration Guide』を参照してください。

BGP では、認証にこのキーチェーンを使用して、ヒットレス キー ロールオーバーを実装できます。 キー ロールオーバーの仕様は時間に基づいているため、ピア間で時計のずれがあるとロールオーバーのプロセスに影響します。 許容値の指定を設定できるため、承認時間枠をその分だけ（前後に）拡張できます。 この承認時間枠により、アプリケーション（ルーティング プロトコルおよび管理プロトコルなど）のヒットレス キー ロールオーバーが容易になります。

キーのロール オーバーは、エンドポイントでのキーチェーン設定の不一致が原因でセッション トラフィック（送信または受信）で使用する共通のキーがない場合を除き、BGP セッションには影響しません。

ボーダー ゲートウェイ プロトコル（BGP）のノンストップ ルーティング（NSR）とステートフル スイッチオーバー（SSO）機能を使用すると、すべての bgp ピアリングで BGP 状態を維持し、サービスを中断させるおそれのあるイベントの実行中にも連続的なパケット転送を行えるようになります。 NSR の下では、サービスを中断するおそれのあるイベントは、ピア ルータに表示されません。 プロトコル セッションは中断されず、ルーティング ステートはプロセスの再起動とスイッチオーバーをまたがって維持されます。

BGP NSR では、次のイベントの際のノンストップ ルーティングを実現します。

• ルート プロセッサ スイッチオーバー
• BGP または TCP でのプロセスのクラッシュまたはプロセス障害

  （注）

  プロセスのクラッシュまたはプロセス障害が発生した場合、NSR は nsr process-failures switchover コマンドが設定されている場合のみ維持されます。 アクティブなインスタンスのプロセス障害が発生した場合は、nsr process-failures switchover により復旧処理としてフェールオーバーが設定され、スタンバイ ルート プロセッサ（RP）またはスタンバイ分散ルート プロセッサ（DRP）にスイッチ オーバーが行われて、その結果 NSR が維持されます。 nsr process-failures switchover コマンドは、BGP または TCP プロセスのが再起動される際に、NSR セッションと BGP セッションの両方が維持されるようにします。 nsr process-failures switchover を設定しないと、BGP または TCP プロセスの再起動によって、BGP のフラップが発生します。 これは予期された動作です。

ルート プロセッサ スイッチオーバーおよびインサービス システムのアップグレード（ISSU）の間、NSR は TCP と BGP の両方のステートフル スイッチオーバー（SSO）によって実現されます。

NSR では、ネットワーク内の他のルータ上でソフトウェア アップグレードを強要せず、NSR をサポートするためにピア ルータは必要ありません。

障害に起因するルート プロセッサ スイッチオーバーが発生した場合、TCP 接続および BGP セッションはトランスペアレントにスタンバイ ルート プロセッサに移行され、スタンバイ ルート プロセッサがアクティブになります。 既存のプロトコル ステートは、アクティブになるスタンバイ ルート プロセッサ上で維持されて、ピアによるプロトコル ステートのリフレッシュは不要です。

ソフト再設定やポリシーの変更などのイベントにより、BGP の内部状態が変化することがあります。 このようなイベントの際に、アクティブとスタンバイの BGP プロセスの間でステートの一貫性を確保するために、同期ポイントとして機能する、ポストイットの概念が導入されています。

BGP NSR には次の機能があります。

• NSR 関連のアラームおよび通知
• 設定され、動作している NSR の状態は、個別に追跡される
• NSR 統計情報の収集
• show コマンドを使用した NSR 統計情報の表示
• XML スキーマのサポート
• アクティブとスタンバイのインスタンス間のステート同期を検証する監査メカニズム
• NSR をイネーブルおよびディセーブルにする CLI コマンド
• 5000 NSR セッションのサポート

ボーダー ゲートウェイ プロトコル プレフィックス独立コンバージェンス ユニパス（BGP PIC Unipath）プライマリ/バックアップ機能には、バックアップ パスを転送テーブルに組み込む機能があります。 バックアップ パスを組み込むと、プライマリ PE-CE リンクの障害時に、プレフィックスに依存しないコンバージェンスが可能になります。

プライマリ/バックアップ パスのメカニズムにより、BGP では、バックアップ最適パスを決定できます。 バックアップ最適パスは、全体としての最適パス（プライマリ最適パス）のバックアップとして機能します。 BGP では、両方のパスを転送情報ベース（FIB）にプログラムします。

バックアップ最適パスを決定する手順を次に示します。

1. プレフィックスに利用可能なパスの全セットから最適パスを決定します。
2. 現在の最適パスを除外します。
3. 現在の最適パスと同じネクスト ホップを持つすべてのパスを除外します。
4. 残りのパスのセットに対して最適パス アルゴリズムを再度実行し、バックアップ最適パスを決定します。

10000 個のプレフィックスの PE-CE ローカル コンバージェンスには、4 ～ 5 秒かかります。 プライマリ PE-CE リンクの障害の際に転送情報ベース（FIB）で即座に代替パスへの切り替えが可能なようにバックアップ パスをラインカードに組み込むと、コンバージェンス時間が短縮されます。

プライマリ PE-CE リンクの障害の際、FIB では、受信したトラフィックをバックアップ PE に転送し始めます。 FIB では、ネットワーク コンバージェンスの期間、受信したトラフィックのバックアップ PE への転送を続行します。 バックアップ パスを使用する方法はプレフィックスから独立しているため、プレフィックス独立コンバージェンス ユニパス機能により、プレフィックスに依存しない 1 秒未満のコンバージェンスが実現されます。

additional-paths selection コマンドを使用すると、バックアップ パスが転送情報ベース（FIB）に組み込まれて、プライマリ バックアップ パスが有効になります。

プライマリ PE-CE リンクが故障した場合、BGP では、プライマリ パスに対応するルートおよびこのルートのローカル ラベルを取り消し、デフォルトでは、ルーティング情報ベース（RIB）および転送情報ベース（FIB）にバックアップ パスをプログラムします。

ただし、プライマリ PE のすべての内部ピアがバックアップ パスを新しい最適パスとして使用するように再コンバージェンスするまで、トラフィックは、プライマリ パスに割り当てられたローカル ラベルとともに、引き続きプライマリ PE に転送されます。 したがって、プライマリ パスに前に割り当てられていたローカル ラベルは、再コンバージェンス後、設定可能な期間、プライマリ PE 上で保持する必要があります。 BGP Local Label Retention 機能を使用すると、ローカル ラベルを指定期間保持できます。 時間を指定していない場合、ローカル ラベルは、デフォルト値の 5 分間保持されます。

retain local-label コマンドを使用すると、ネットワークがコンバージェンスされるまで、ローカル ラベルを保持できます。

Cisco IOS XR リリース 3.9.0 以降のボーダー ゲートウェイ プロトコル（BGP）コマンドでは、 disable キーワードを使用して、機能をディセーブルにします。 キーワード inheritance-disable では、親レベルからの機能プロパティの継承がディセーブルになります。

ボーダー ゲートウェイ プロトコル（BGP）の追加パス機能では、1 つのプレフィックスに対して複数のパスを送信できるように、BGP スピーカーの BGP プロトコル機械を変更します。 これにより、ネットワークに「パスの多様性」が生まれます。 追加パスにより、エッジ ルータでの BGP プレフィックス独立コンバージェンス（PIC）が可能になります。

BGP 追加パスでは、iBGP ネットワーク内の追加パス アドバタイズメントが可能になり、プレフィックスに対する次のタイプのパスがアドバタイズされます。

• バックアップ パス：高速コンバージェンスおよび接続の回復をイネーブルにします。
• グループ最適パス：ルート振動を解決します。
• すべてのパス：iBGP フル メッシュをエミュレートします。

  （注）	追加パスは、MDT、トンネル、および L2VPN アドレス ファミリと eBGP ピアリングでは、サポートされていません。

ローカル ポリシーが設定されていないボーダー ゲートウェイ プロトコル（BGP）対応ルータが複数のネットワーク層到達可能性情報（NLRI）を同じ宛先の内部 BGP（iBGP）から受信すると、このルータは 1 つの iBGP パスを最適パスとして選択します。 この最適パスは、次にこのルータの IP ルーティング テーブルに組み込まれます。

iBGP のマルチパス ロード シェアリング機能を使用すると、BGP 対応ルータでは、複数の iBGP パスを宛先への最適パスとして選択できます。 この最適パスまたはマルチパスは、次にこのルータの IP ルーティング テーブルに組み込まれます。

eBGP から取得した到達可能性情報を持つ複数の境界 BGP ルータがあり、ローカル ポリシーが適用されていない場合、境界ルータでは、eBGP パスを最適パスとして選択します。 境界ルータでは、この最適パスを ISP ネットワークの内部にアドバタイズします。 コア ルータの場合は、同じ宛先への複数のパスが存在することがありますが、1 つのパスのみが最適として選択され、このパスが転送に使用されます。 iBGP マルチパス ロード シェアリングでは、複数の等距離パス間のロード シェアリングを可能にすることができるようになります。

複数の iBGP の最適パスを設定すると、ルータでは、特定のサイトを宛先とするトラフィックを均等に負担できるようになります。

iBGP のマルチパス ロード シェアリング機能は、サービス プロバイダー バックボーンを持つマルチプロトコル ラベル スイッチング（MPLS）バーチャル プライベート ネットワーク（VPN）と同様に機能します。

同じ宛先への複数のパスをマルチパスと見なすには、次の基準を満たす必要があります。

• すべての属性が同じである必要があります。 属性には、重み、ローカル プリファレンス、自律システム パス（長さだけでなく属性全体）、発信元コード、Multi Exit Discriminator（MED）、および Interior Gateway Protocol（IGP）距離が含まれます。
• 各マルチパスのネクスト ホップ ルータが異なっている必要があります。

基準を満たしていて、複数のパスがマルチパスと見なされても、BGP 対応ルータは、引き続きマルチパスの 1 つを最適パスに指定し、この最適パスをそのネイバーにアドバタイズします。

累積内部ゲートウェイ プロトコル（AiGP）属性は、オプションで非推移的な BGP パス属性です。 AiGP 属性の属性タイプ コードは、IANA によって割り当てられます。 AiGP 属性の値フィールドは、タイプ、長さ、値（TLV）の要素として定義されます。 AiGP TLV には、累積 IGP メトリックが含まれます。

AiGP 機能は 3107 ネットワークに必要であり、パスに関連付けられた距離を計算する現在の OSPF の動作をシミュレートします。 OSPF/LDP では、プレフィックスおよびラベル情報をローカル領域だけに入れて伝送します。 次に、BGP では、エリア境界にある BGP にルートを再配布することにより、すべてのリモート エリアにプレフィックスおよびラベルを伝送します。 次に、ルートおよびラベルが、LSP を使用してアドバタイズされます。 ルートのネクスト ホップはローカル ルータに対する各 ABR で変更されます。これによって、エリア境界を越えて OSPF ルートをリークする必要がなくなります。 各コア リンクで使用可能な帯域幅が OSPF コストにマップされます。したがって、BGP では、各 PE 間でこのコストを正しく伝送する必要があります。 この機能は、AiGP を使用して実現されています。

IPv6 のための VRF ごとおよび CE ごとのラベルの機能により、デフォルト VRF ごとまたは CE ネクスト ホップごとにラベルを割り当てることにより、ラベル スペースを節約できるようになります。

デフォルトでは、すべての IPv6 プロバイダー エッジ（6PE）ラベルは、プレフィックスごとに割り当てられます。 VRF インスタンスに属する各プレフィックスは 1 つのラベルを使ってアドバタイズされます。これは、パケットのカスタマー エッジ（CE）ネクスト ホップを決定するために、VRF フォワーディング テーブルでさらにルックアップが行われる原因になります。

ただし、PE ルータでさらにルックアップが行われることを回避し、ラベル スペースを節約するには、label-allocation-mode コマンドに per-ce キーワードまたは per-vrf キーワードを付けて使用します。

一意のカスタマー エッジ（CE）ピアまたはルータからアドバタイズされたすべてのルートで同じラベルを使用することを指定するには、per-ce キーワードを使用します。 一意の VRF からアドバタイズされたすべてのルートで同じラベルを使用することを指定するには、per-vrf キーワードを使用します。

ボーダー ゲートウェイ プロトコル（BGP）ポリシー アカウンティングは、異なるピア間で送受信される IP トラフィックを測定および分類します。 ポリシー アカウンティングは個々の入力または出力インターフェイス単位でイネーブルになります。 IP トラフィックを識別するために、コミュニティ リスト、自律システム番号、または自律システム パスなどのパラメータに基づくカウンタが割り当てられます。

BGP ポリシー アカウンティングを使用して、通過するルートに基づいてトラフィックのアカウンティングを行うことができます。 サービス プロバイダーは、すべてのトラフィックをカスタマー別に識別してアカウンティングを実施し、それに応じて課金できます。

BGP ポリシー アカウンティングと、BGP ポリシー アカウンティングを設定する方法については、『Cisco ASR 9000 Series Aggregation Services Router IP Addresses and Services Configuration Guide』の「Implementing Cisco Express Forwarding」モジュールを参照してください。

Cisco ASR 9000 の A9K-SIP-700 には、すべてのインターネット プロトコル バージョン 6（IPv6）ユニキャスト機能が備わっています。

IPv6 ユニキャスト アドレスは、単一ノード上の単一インターフェイスの識別子です。 ユニキャスト アドレスに送信されたパケットは、そのアドレスが示すインターフェイスに配信されます。 Cisco IOS XR ソフトウェアでは、次の IPv6 ユニキャスト アドレス タイプがサポートされます。

• 集約可能グローバル アドレス
• サイトローカル アドレス
• リンクローカル アドレス
• IPv4 互換 IPv6 アドレス

IPv6 ユニキャスト アドレッシングの詳細については、『Cisco ASR 9000 Series Aggregation Services Router IP Addresses and Services Configuration Guide』の「Implementing Network Stack IPv4 and IPv6」モジュールを参照してください。

ユニキャスト IPv6 リバース パス転送（uRPF）は、検証可能な IP 送信元アドレスを欠いている IP パケットを廃棄することにより、不正な形式の IP 送信元アドレスまたはスプーフィングされた IP 送信元アドレスがネットワークに侵入した場合に生じる問題を軽減します。 ユニキャスト RPF はシスコ エクスプレス フォワーディング（CEF）テーブルで逆ルックアップを実行することで、この処理を行います。 このため、uRPF が可能になるのは、ルータで CEF がイネーブルになっている場合だけです。

IPV6 uRPF をイネーブルにするには、インターフェイス コンフィギュレーション モードで ipv6 verify unicast source reachable-via {any | rx} [allow-default] [allow-self-ping] コマンドを使用します。

IPv6 uRPF の詳細については、 『Cisco ASR 9000 Series Aggregation Services Router IP Addresses and Services Command Reference』の「Implementing Cisco Express Forwarding」モジュールを参照してください。

プライベート自律システム番号（ASN）は、グローバルに一意な AS 番号を保護するために、インターネット サービス プロバイダー（ISP）およびお客様のネットワークで使用されます。 プライベート AS 番号は一意でないため、グローバル インターネットへのアクセスには使用できません。 AS 番号はルーティング アップデートの eBGP AS パスに表示されます。 プライベート ASN を使用している場合にグローバル インターネットにアクセスするには、AS パスからプライベート ASN を削除する必要があります。

パブリックな AS 番号は、InterNIC によって割り当てられ、グローバルに一意です。 範囲は 1 ～ 64511 です。 プライベート AS 番号は、グローバルに一意な AS 番号（有効な範囲は 64512 ～ 65535）を保護するために使用されます。 プライベート AS 番号はグローバル BGP ルーティング テーブルにリークできません。プライベート AS 番号は一意ではなく、BGP 最適パスの計算には一意の AS 番号が必要であるからです。 そのため、ルートが BGP ピアに伝播される前に、AS パスからプライベート AS 番号を削除する必要がある可能性があります。

外部 BGP（eBGP）では、グローバルなインターネットへのルーティングで、グローバルに一意な AS 番号を使用する必要があります。 プライベート AS 番号（これは一意でない）を使用すると、グローバルなインターネットにアクセスできません。 BGP の AS パスからプライベート ASN を削除および交換する機能によって、プライベート AS に属するルータがグローバルなインターネットにアクセスできるようになりました。 ネットワーク管理者は、発信アップデート メッセージに含まれる AS パスからプライベート AS を削除するようにルータを設定します。場合によっては、これらの番号をローカル ルータの ASN で置き換えて、AS パス長が変化しないようにします。

AS パスからプライベート ASN を削除および交換する機能は、次のように拡張されました。

• remove-private-as コマンドでは、AS パスにパブリックとプライベートの両方の ASN が含まれる場合でも、AS パスからプライベート AS 番号が削除されます。
• remove-private-as コマンドでは、AS パスにプライベート AS 番号のみが含まれる場合でも、AS パスからプライベート AS 番号を削除します。 このコマンドは eBGP ピアのみに適用され、その場合、eBGP ピアではローカル ルータの AS 番号が AS パスに付加されるため、長さ 0 の AS パスにはなることはありません。
• remove-private-as コマンドでは、AS パスでコンフェデレーション セグメントの前にプライベート ASN が出現する場合でも、プライベート AS 番号が削除されます。
• replace-as コマンドでは、パスから削除されるプライベート AS の番号をローカルの AS 番号に置き換えることができるため、AS パスの長さは同じままに保つことができます。

この機能は、アドレス ファミリごとにネイバーに適用できます（アドレス ファミリ コンフィギュレーション モード）。 そのため、この機能をあるアドレス ファミリのネイバーには適用して、別のアドレス ファミリでは適用しないようにすることで、機能が設定されているアドレス ファミリのみのアウトバウンド側のアップデート メッセージに影響を与えることができます。

プライベート AS 番号が削除または交換されたこと確認するには、show bgp neighbors コマンドおよび show bgp update-group コマンドを使用します。

選択的 VRF ダウンロード（SVD）機能を使用すると、ラインカード経由でのトラフィックの転送に必要なラインカードに、これらのプレフィックスおよびラベルだけをダウンロードできるようになります。

統合エッジ MSE プラットフォームにおける要件を満たすために、VRF の数、VRF インターフェイスの数、およびプレフィックス容量が増大しています。 コンバージェンスのタイミングは、ラインカードのエンジンによって異なります。 コンバージェンスのタイミングを決定する重要な要因の 1 つが、プレフィックスとそれに関連付けられたデータ構造を操作およびプログラムするのにかかる時間です。 プレフィックスとラベルの数が少ないほど、コンバージェンスのタイミングが向上します。 Engine 3（E3）と Engine 5（E5）の両方のラインカードへ VRF ルートの選択的ダウンロードをイネーブルにすると、SVD レイヤ 3 VPN（L3VPN）のスケーラビリティとコンバージェンスの問題が緩和されます。

デフォルトでは、SVD はこれらのラインカードでイネーブルにされています。 SVD をディセーブルにするには、selective-vrf-download disable コマンドを使用します。 ラインカードの SVD のロールおよびステート情報を表示するには、show svd role コマンドおよび show svd state コマンドを使用します。

選択的 VRF ダウンロードの詳細については、http:/​/​www.cisco.com/​en/​US/​technologies/​collateral/​tk648/​tk365/​white_​paper_​c11-681649.html にあるシスコのホワイト ペーパー『Selective Virtual Routing and Forwarding Table Download: A solution to increase Layer3 VPN scale』を参照してください。

BGP Accept Own 機能を使用すると、自動送信 VPN ルート（BGP スピーカーがルート リフレクタ（RR）から受信するルート）を処理できるようになります。 「自動送信」ルートは、スピーカー自体によって最初にアドバタイズされたルートです。 BGP プロトコル（RFC4271）に従って、BGP スピーカーは、スピーカー自体によって送信されたアドバタイズメントを拒否します。 ただし、BGP Accept Own メカニズムを使用すると、プレフィックスの特定の属性を変更するルート リフレクタから反映された場合に、ルータは自身がアドバタイズしたプレフィックスを受け入れることが可能になります。 ACCEPT-OWN と呼ばれる特別なコミュニティがルート リフレクタによってプレフィックスに付加されます。これは ORIGINATOR_ID および NEXTHOP/MP_REACH_NLRI チェックをバイパスするための受信側ルータに対する信号です。 通常、BGP スピーカーは自動送信されたプレフィックスを自動送信チェック（ORIGINATOR_ID、NEXTHOP/MP_REACH_NLRI）によって検出し、受信した更新をドロップします。 ただし、更新に Accept Own コミュニティがあれば、BGP スピーカーはそのルートを処理します。

BGP Accept Own の応用例の 1 つは、MPLS VPN ネットワーク内のエクストラネットの自動設定です。 エクストラネットの設定では、ある VRF にあるルートは同じ PE の別の VRF にインポートされます。 通常、エクストラネットのメカニズムでは、別の VRF からのプレフィックスのインポートを制御するために、エクストラネット VRF のインポート RT またはインポート ポリシーを編集する必要があります。 ただし、Accept Own 機能を使用すると、ルート リフレクタは、PE で設定変更することなく、その制御をアサートできます。 このように Accept Own 機能によって、異なる VRF 間でのルートのインポートの制御を集中管理できます。

BGP Accept Own 機能は、ネイバー コンフィギュレーション モードの VPNv4 および VPNv6 アドレス ファミリ向けにのみサポートされています。

Accept Own の設定例

この設定例の内容は次のとおりです。

• PE11 にカスタマー VRF とサービス VRF が設定されています。
• OSPF は IGP として使用されます。
• VPNv4 ユニキャストおよび VPNv6 ユニキャストのアドレス ファミリが PE ネイバーと RR ネイバーとの間でイネーブルになっており、IPv4 および IPv6 が PE ネイバーと CE ネイバーとの間でイネーブルになっています。

Accept Own の設定は次のように動作します。

1. CE1 がプレフィックス X を発信します。
2. プレフィックス X は、カスタマー VRF に (RD1:X) として設定されています。
3. プレフィックス X は IntraAS-RR11 に (RD1:X, RT1) としてアドバタイズされます。
4. IntraAS-RR11 が InterAS-RR1 に X を (RD1:X, RT1) としてアドバタイズします。
5. InterAS-RR1 はインバウンドのプレフィックス X とアウトバウンドの ACCEPT_OWN コミュニティに RT2 を付加し、IntraAS-RR31 にプレフィックス X をアドバタイズします。
6. IntraAS-RR31 が PE11 に X をアドバタイズします。
7. PE11 は X をサービス VRF に (RD2:X,RT1, RT2, ACCEPT_OWN) としてインストールします。

不等コストの連続ロード バランシングに対するボーダー ゲートウェイ プロトコル非武装地帯（BGP DMZ）リンク帯域幅により、BGP DMZ リンク帯域幅を使用して、ローカル ノード上で連続プレフィックスに対する不等コスト ロード バランシングをサポートできます。 不等ロード バランスは、BGP ネイバー コンフィギュレーション モードの dmz-link-bandwidth コマンドおよびインターフェイス コンフィギュレーション モードの bandwidth コマンドを使用して実現されます。

BGP では、双方向転送検出マルチホップ（BFD-MH）のサポートがイネーブルです。 BFD マルチホップでは複数のネットワーク ホップにまたがることのある 2 つのアドレス間に BFD セッションを確立します。 Cisco IOS XR ソフトウェア BFD マルチホップは RFC 5883 に基づきます。 BFD マルチホップの詳細については、 『Cisco ASR 9000 Series Aggregation Services Router Interface and Hardware Component Configuration Guide』および 『Cisco ASR 9000 Series Aggregation Services Router Interface and Hardware Component Command Reference』を参照してください。

Multi-Instance BGP は、複数の BGP インスタンスに対応しています。 各 BGP インスタンスは、同じまたは異なる RP/DRP ノードで実行される独立したプロセスです。 BGP インスタンス間ではプレフィックス テーブルは共有されません。 分散 BGP と同様に、共通 adj-rib-in（bRIB）は不要です。 BGP インスタンスは互いに通信することはなく、また互いにピアリングを設定することもありません。 個々のインスタンスは他のルータとのピアリングを独立して設定できます。

Multi-AS BGP を使用すると、Multi-Instance BGP の各インスタンスに異なる AS 番号を設定できるようになります。

BGP ルートは、BGP アナウンスメントの形で、プレフィックスが経由したドメイン間パスを識別する自律システム（AS）の設定と、アドレス プレフィックスを関連付けます。 この設定は、BGP 内で AS_PATH 属性として表され、プレフィックスを発信した AS で開始されます。

誤ったプレフィックスのアナウンス、中間者攻撃など、BGP に対する既知の脅威を低減しやすくするためのセキュリティ要件の 1 つは、BGP ルートの発信元 AS を検証する能力です。 アドレス プレフィックスの発信元であるとする AS 番号（BGP ルートの AS_PATH 属性から導出）は、プレフィックスの所有者によって検証および許可される必要があります。

Resource Public Key Infrastructure（RPKI）は、IP アドレスとリソースとしての AS 番号の公的で検証可能なデータベースを構築するためのアプローチです。 RPKI は、BGP（インターネット）プレフィックスから許可された元の AS 番号への情報マッピングなどの情報を含む、グローバルに分散されたデータベースです。 BGP を実行しているルータは、RPKI に接続して、BGP パスの元の AS を検証できます。

グローバル プレフィックス用 BGP 3107 PIC アップデート機能は、MPLS VPN プロバイダー ネットワークでの、グローバル IPv4 および IPv6 プレフィックス用のプレフィックス独立コンバージェンス（PIC）アップデートをサポートします。 この機能は、BGP を使用した、グローバルな IPv4 または IPv6 のプレフィックス用の MPLS ラベルの配布について記述した、RFC 3107 に基づいています。 これにより、IGP の拡張性が向上され、高速コンバージェンスのための PIC アップデートも実現されます。

RFC 3107 により、ルートおよびラベルを BGP で伝送できるようになります。 特定のルートへの配布に BGP を使用する場合は、このルートにマッピングされている MPLS ラベルの配布にも使用できます。 特定の 1 つのルートに対するラベル マッピング情報は、ルート自体の配布に使用される、同じ BGP アップデート メッセージに同梱されます。 RFC 3107 では、OSPF からネクスト ホップ ループをフィルタリングでき、LDP によってアドバタイズされるラベルを削減できます。 この実装によって、OSPF および LDP データベースが大幅に削減されます。

3107 PIC 実装では、additional-path 設定を含めて、次のアドレス ファミリをサポートしています。

• address-family ipv4 unicast
• address-family ipv6 unicast
• address-family vpnv4 unicast
• address-family vpnv6 unicast

（注）	address-family l2vpn vpls-vpws では、additional-path をサポートしていません。 したがって、address-family l2vpn vpls-vpws を使用する L2VPN サービスでは、PIC コンバージェンス時間が保証されません。

3107 PIC 実装では、次の Cisco IOS XR 機能をサポートしています。

• 3107 の PIC エッジ
• Traffic Engineering Fast-reroute（TE FRR）：逐語的なトンネルを使用して、コア リンク障害に対する 50 ミリ秒以内のトラフィック コンバージェンスが保証されます。
• L2VPN サービス
• L3VPN VPNv4 サービス
• 6 PE サービス
• 6 VPE サービス
• VPLS サービス

グローバル プレフィックス用 BGP 3107 PIC アップデート実装では、Light-Weight Recursive（LW-RLDI）オブジェクトの代わりに共有 Recursive Load Info（RLDI）転送オブジェクトを使用します。 RLDI は複数リーフ間で共有されますが、LW-RLDI はリーフごとにインスタンス化されます。 処理がプレフィックスに依存しなくなるため、共有は PIC アップデートの処理で有用です。

RIB および FIB 用 BGP PIC によって、PE-CE としてのスタティック再帰のサポートおよび Fast Re-Route トリガーを使用したバックアップ アクティベーションの高速化のサポートが加わります。

RIB および FIB 用 BGP PIC 機能では、次の要素をサポートしています。

• コンバージェンス時間をさらに削減する、高速な PE-CE リンク ダウン検出用の FRR に似たトリガー（PIC エッジの高速アクティベーション）。
• スタティック再帰ルートのための PIC エッジ。
• 明示的に /32 スタティック ルートを設定しない、PIC エッジのための BFD シングルホップ トリガー。
• 第 1（IGP）レベルでの失敗トリガーの際の第 3 レベル以降での再帰 PIC アクティベーション。
• BGP ネクスト ホップの解決に関して、FIB が BGP と同期していることを保証する、FIB での BGP パス再帰制約。

BGP 属性フィルタ機能によって、BGP アップデート メッセージ内の BGP アップデートの整合性を確認し、無効な属性を検出したときには最適な対応を行います。 BGP アップデート メッセージには、必須およびオプションの属性のリストが含まれています。 アップデート メッセージのこれらの属性には、MED、LOCAL_PREF、COMMUNITY などが含まれています。属性の形式が正しくない場合は、ルータの受信側でこれらの属性をフィルタ処理する必要があります。 BGP 属性フィルタ機能では、着信アップデート メッセージで受信した属性をフィルタリングします。 属性フィルタは、受信側ルータで好ましくない動作を引き起こす可能性のある属性を排除するためにも使用できます。

BGP アップデートの中には、ネットワーク層到達可能性情報（NLRI）またはアップデート メッセージ内の他のフィールドなどの誤った形式の属性のために、形式が不正になるものがあります。 これらの不正なアップデートを受信すると、受信側ルータで好ましくない動作が発生します。 このような不正な動作は、アップデート メッセージの解析時や、受信した NLRI の再アドバタイズ時に発生することがあります。 このような場合に備えて、受信側でこれらの破損した属性をフィルタ処理することが重要です。

不正な形式のアップデート パケットをルータが受信すると、ROUTING-BGP-3-MALFORM_UPDATE タイプの ios_msg がコンソールに出力されます。 このレートは、すべてのネイバーで 1 分間に 1 つのメッセージになるよう制限されています。 不正なパケットが「Discard Attribute」（A5）または「Local Repair」（A6）アクションの対象になった場合は、ネイバー 1 つおよびアクション 1 つごとに ios_msg メッセージが出力されます。 これは、ネイバーが直前の「Established」状態に到達して以降に受信した不正な形式のアップデートの数とは関係ありません。

%ROUTING-BGP-3-MALFORM_UPDATE : Malformed UPDATE message received from neighbor 13.0.3.50 - message length 90 bytes,
 error flags 0x00000840, action taken "TreatAsWithdraw". 
Error details: "Error 0x00000800, Field "Attr-missing", Attribute 1 (Flags 0x00, Length 0), Data []"

[4843.46]RP/0/0/CPU0:Aug 21 17:06:17.919 : bgp[1037]: %ROUTING-BGP-5-UPDATE_FILTERED : 
One or more attributes were filtered from UPDATE message received from neighbor 40.0.101.1 - message length 173 bytes,
 action taken "DiscardAttr".
 Filtering details: "Attribute 16 (Flags 0xc0): Action "DiscardAttr"". NLRIs: [IPv4 Unicast] 88.2.0.0/17

[391.01]RP/0/0/CPU0:Aug 20 19:41:29.243 : bgp[1037]: %ROUTING-BGP-5-UPDATE_FILTERED :
 One or more attributes were filtered from UPDATE message received from neighbor 40.0.101.1 - message length 166 bytes,
 action taken "TreatAsWdr".
 Filtering details: "Attribute 4 (Flags 0xc0): Action "TreatAsWdr"". NLRIs: [IPv4 Unicast] 88.2.0.0/17

アップデート生成機能のためのボーダー ゲートウェイ プロトコル ルーティング情報ベース（BGP-RIB）のフィードバック メカニズムによって、ネットワークで不完全なルート アドバタイズメントが行われて、それによってパケット損失が発生するのを防ぐことができます。 このメカニズムによって、ルートがネイバーにアドバタイズされる前にローカルに組み込まれるようになります。

BGP は RIB からのフィードバックを待ちます。このフィードバックには、BGP によって RIB に組み込まれたルートが、BGP がネイバーにアップデートを送信する前に転送情報ベース（FIB）に組み込まれたことが示されています。 RIB は BCDL のフィードバック メカニズムを使用して、そのバージョンのルートが FIB によって使用されたかを判断し、BGP をそのバージョンで更新します。 BGP がアップデートを送信するのは、FIB が組み込んだバージョン以下のバージョンのルートだけです。 この選択的な更新によって、BGP が不完全なアップデートを送信しないようになり、ルータのリロード、LC OIR、または代替パスが使用可能になるリンク フラップ後にデータ プレーンがプログラミングされる前であっても、トラフィックの引き込みが行われるようになります。

BGP が RIB に組み込んだルートが FIB に組み込まれたことを示す RIB からのフィードバックを BGP が待機し、その後で BGP がネイバーに更新を送信するように設定するには、ルータ アドレス ファミリ IPv4 またはルータ アドレス ファミリ VPNv4 コンフィギュレーション モードで、update wait-install インストール コマンドを使用します。 show bgp, show bgp neighbors コマンドおよび show bgp process performance-statistics コマンドでは、update wait-install の設定の情報が表示されます。

BGP ルーティングをイネーブルにし、BGP ルーティング プロセスを設定するには、次の作業を実行します。 BGP ネイバーの設定は、BGP ルーティングのイネーブル化の一部として含まれています。

（注）	BGP ルーティングをイネーブルにするには、1 つ以上のネイバーおよび 1 つ以上のアドレス ファミリを設定する必要があります。 address family コマンドおよび remote as コマンドを使用して、リモート AS とアドレス ファミリの両方を持つ 1 つ以上のネイバーをグローバルに設定する必要があります。

はじめる前に

BGP はルータ ID（設定済みループバック アドレスなど）を取得できなければなりません。 1 つ以上のアドレス ファミリを BGP ルータ コンフィギュレーションに設定する必要があり、同じアドレス ファミリをネイバーの下にも設定する必要があります。

（注）	ネイバーが外部 BGP（eBGP）ピアとして設定されている場合は、route-policy コマンドを使用して、インバウンドおよびアウトバウンドのルート ポリシーをネイバー上に設定する必要があります。

1.    configure


2.    route-policy route-policy-name


3.    end-policy


4.    次のいずれかを実行します。

• end
• commit

5.    configure


6.    router bgp as-number


7.    bgp router-id ip-address


8.    address-family { ipv4 | ipv6 } unicast


9.    exit


10.    neighbor ip-address


11.    remote-as as-number


12.    address-family { ipv4 | ipv6 } unicast


13.    route-policy route-policy-name { in | out }


14.    次のいずれかを実行します。

• end
• commit

RP/0/RSP0/CPU0:router# configure

RP/0/RSP0/CPU0:router(config)# route-policy drop-as-1234
  RP/0/RSP0/CPU0:router(config-rpl)# if as-path passes-through '1234' then
  RP/0/RSP0/CPU0:router(config-rpl)# apply check-communities
  RP/0/RSP0/CPU0:router(config-rpl)# else
  RP/0/RSP0/CPU0:router(config-rpl)# pass
  RP/0/RSP0/CPU0:router(config-rpl)# endif
  

RP/0/RSP0/CPU0:router(config-rpl)# end-policy

RP/0/RSP0/CPU0:router(config)# end

RP/0/RSP0/CPU0:router(config)# commit

RP/0/RSP0/CPU0:router# configure

RP/0/RSP0/CPU0:router(config)# router bgp 120

RP/0/RSP0/CPU0:router(config-bgp)# bgp router-id 192.168.70.24

RP/0/RSP0/CPU0:router(config-vrf)# address-family ipv4 unicast

RP/0/RSP0/CPU0:router(config-bgp-af)# exit

RP/0/RSP0/CPU0:router(config-bgp)# neighbor 172.168.40.24

RP/0/RSP0/CPU0:router(config-bgp-nbr)# remote-as 2002

RP/0/RSP0/CPU0:router(config-vrf)# address-family ipv4 unicast

RP/0/RSP0/CPU0:router(config-bgp-nbr-af)# route-policy drop-as-1234 in

RP/0/RSP0/CPU0:router(config-bgp-nbr-af)# end

RP/0/RSP0/CPU0:router(config-bgp-nbr-af)# commit

1.    configure


2.    router bgp as-number


3.    bgp confederation identifier as-number


4.    bgp confederation peers as-number


5.    次のいずれかを実行します。

• end
• commit

RP/0/RSP0/CPU0:router# configure

RP/0/RSP0/CPU0:router# router bgp 120

RP/0/RSP0/CPU0:router(config-bgp)# bgp confederation identifier 5

RP/0/RSP0/CPU0:router(config-bgp)# bgp confederation peers 1091
  RP/0/RSP0/CPU0:router(config-bgp)# bgp confederation peers 1092
  RP/0/RSP0/CPU0:router(config-bgp)# bgp confederation peers 1093
  RP/0/RSP0/CPU0:router(config-bgp)# bgp confederation peers 1094
  RP/0/RSP0/CPU0:router(config-bgp)# bgp confederation peers 1095
  RP/0/RSP0/CPU0:router(config-bgp)# bgp confederation peers 1096
  

RP/0/RSP0/CPU0:router(config-bgp)# end

RP/0/RSP0/CPU0:router(config-bgp)# commit

デフォルトでは、リンクがダウンすると、直接隣接する外部ピアの BGP セッションはすべて即時にリセットされます。 自動リセットをディセーブルにするには bgp fast-external-fallover disable コマンドを使用します。 自動リセットをイネーブルにするには no bgp fast-external-fallover disable コマンドを使用します。

RP/0/RSP0/CPU0:router#configure 
RP/0/RSP0/CPU0:router(config)#lpts pifib hardware police location 0/2/CPU0
RP/0/RSP0/CPU0:router(config-pifib-policer-per-node)#flow bgp configured rate 4000
RP/0/RSP0/CPU0:router(config-pifib-policer-per-node)#flow bgp known rate 4000
RP/0/RSP0/CPU0:router(config-pifib-policer-per-node)#flow bgp default rate 4000
RP/0/RSP0/CPU0:router(config-pifib-policer-per-node)#commit

ネイバー変更のロギングはデフォルトでイネーブルになっています。 ロギングをオフにするには、log neighbor changes disable コマンドを使用します。 ロギングがディセーブルにされている場合にロギングを再びイネーブルにするには、no log neighbor changes disable コマンドを使用します。

1.    configure


2.    router bgp as-number


3.    timers bgp keepalive hold-time


4.    neighbor ip-address


5.    timers keepalive hold-time


6.    次のいずれかを実行します。

• end
• commit

RP/0/RSP0/CPU0:router# configure

RP/0/RSP0/CPU0:router(config)# router bgp 123

RP/0/RSP0/CPU0:router(config-bgp)# timers bgp 30 90

RP/0/RSP0/CPU0:router(config-bgp)# neighbor 172.168.40.24

RP/0/RSP0/CPU0:router(config-bgp-nbr)# timers 60 220

RP/0/RSP0/CPU0:router(config-bgp-nbr)# end

RP/0/RSP0/CPU0:router(config-bgp-nbr)# commit

1.    configure


2.    router bgp as-number


3.    bgp default local-preference value


4.    次のいずれかを実行します。

• end
• commit

RP/0/RSP0/CPU0:router# configure

RP/0/RSP0/CPU0:router(config)# router bgp 120

RP/0/RSP0/CPU0:router(config-bgp)# bgp default local-preference 200

RP/0/RSP0/CPU0:router(config-bgp)# end

RP/0/RSP0/CPU0:router(config-bgp)# commit

1.    configure


2.    router bgp as-number


3.    default-metric value


4.    次のいずれかを実行します。

• end
• commit

RP/0/RSP0/CPU0:router# configure

RP/0/RSP0/CPU0:router(config)# router bgp 120

RP/0/RSP0/CPU0:router(config-bgp)# default metric 10

RP/0/RSP0/CPU0:router(config-bgp)# end

RP/0/RSP0/CPU0:routerr(config-bgp)# commit

はじめる前に

（注）	新たに設定した重みを反映するには、clear bgp コマンドを使用する必要があります。

1.    configure


2.    router bgp as-number


3.    neighbor ip-address


4.    remote-as as-number


5.    address-family { ipv4 | ipv6 } unicast


6.    weight weight-value


7.    次のいずれかを実行します。

• end
• commit

RP/0/RSP0/CPU0:router# configure

RP/0/RSP0/CPU0:router(config)# router bgp 120

RP/0/RSP0/CPU0:router(config-bgp)# neighbor 172.168.40.24

RP/0/RSP0/CPU0:router(config-bgp-nbr)# remote-as 2002 

RP/0/RSP0/CPU0:router(config-vrf)# address-family ipv4 unicast

RP/0/RSP0/CPU0:router(config-bgp-nbr-af)# weight 41150

RP/0/RSP0/CPU0:router(config-bgp-nbr-af)# end

RP/0/RSP0/CPU0:router(config-bgp-nbr-af)# commit

1.    configure


2.    router bgp as-number


3.    bgp bestpath med missing-as-worst


4.    bgp bestpath med always


5.    bgp bestpath med confed


6.    bgp bestpath as-path ignore


7.    bgp bestpath compare-routerid


8.    次のいずれかを実行します。

• end
• commit

RP/0/RSP0/CPU0:router# configure

RP/0/RSP0/CPU0:router(config)# router bgp 126

RP/0/RSP0/CPU0:router(config-bgp)# bgp bestpath med missing-as-worst

RP/0/RSP0/CPU0:router(config-bgp)# bgp bestpath med always

RP/0/RSP0/CPU0:router(config-bgp)# bgp bestpath med confed

RP/0/RSP0/CPU0:router(config-bgp)# bgp bestpath as-path ignore

RP/0/RSP0/CPU0:router(config-bgp)# bgp bestpath compare-routerid

RP/0/RSP0/CPU0:router(config-bgp)# end

RP/0/RSP0/CPU0:router(config-bgp)# commit

1.    configure


2.    router bgp as-number


3.    address-family { ipv4 | ipv6 } unicast


4.    network { ip-address / prefix-length | ip-address mask } backdoor


5.    次のいずれかを実行します。

• end
• commit

RP/0/RSP0/CPU0:router# configure

RP/0/RSP0/CPU0:router(config)# router bgp 120

RP/0/RSP0/CPU0:router(config-vrf)# address-family ipv4 unicast

RP/0/RSP0/CPU0:router(config-bgp-af)# network 172.20.0.0/16 

RP/0/RSP0/CPU0:router(config-bgp-af)# end

RP/0/RSP0/CPU0:router(config-bgp-af)# commit

1.    configure


2.    router bgp as-number


3.    address-family { ipv4 | ipv6 } unicast


4.    aggregate-address address/mask-length [ as-set ] [ as-confed-set ] [ summary-only ] [ route-policy route-policy-name ]


5.    次のいずれかを実行します。

• end
• commit

RP/0/RSP0/CPU0:router# configure

RP/0/RSP0/CPU0:router(config)# router bgp 120

RP/0/RSP0/CPU0:router(config-vrf)# address-family ipv4 unicast

RP/0/RSP0/CPU0:router(config-bgp-af)# aggregate-address 10.0.0.0/8 as-set

RP/0/RSP0/CPU0:router(config-bgp-af)# end

RP/0/RSP0/CPU0:router(config-bgp-af)# commit

Intermediate System-to-Intermediate System（IS-IS）や Open Shortest Path First（OSPF）など、内部ゲートウェイ プロトコル（IGP）に iBGP ルートを再配布するには、次の作業を実行します。

（注）	bgp redistribute-internal コマンドを使用するには、すべての BGP ルートを IP ルーティング テーブルに再インストールするために、clear route * コマンドを発行する必要があります。

注意	IGP への iBGP ルートの再配布は、自律システム内にルーティング ループが作成される原因となる可能性があります。 このコマンドの使用には注意が必要です。

1.    configure


2.    router bgp as-number


3.    bgp redistribute-internal


4.    次のいずれかを実行します。

• end
• commit

RP/0/RSP0/CPU0:router# configure

RP/0/RSP0/CPU0:router(config)# router bgp 120

RP/0/RSP0/CPU0:router(config-bgp)# bgp redistribute-internal

RP/0/RSP0/CPU0:router(config-bgp)# end

RP/0/RSP0/CPU0:router(config-bgp)# commit

1.    configure


2.    router bgp as-number


3.    address-family { ipv4 | ipv6 } unicast


4.    次のいずれかを実行します。

• redistribute connected [ metric metric-value ] [ route-policy route-policy-name ]
• redistribute eigrp process-id [ match { external | internal }] [ metric metric-value ] [ route-policy route-policy-name ]
• redistribute isis process-id [ level { 1 | 1-inter-area | 2 }] [ metric metric-value ] [ route-policy route-policy-name ]
• redistribute ospf process-id [ match { external [ 1 | 2 ] | internal | nssa-external [ 1 | 2 ]]} [ metric metric-value ] [ route-policy route-policy-name ]
• redistribute ospfv3 process-id [ match { external [ 1 | 2 ] | internal | nssa-external [ 1 | 2 ]]} [ metric metric-value ] [ route-policy route-policy-name ]
• redistribute rip [ metric metric-value ] [ route-policy route-policy-name ]
• redistribute static [ metric metric-value ] [ route-policy route-policy-name ]

5.    次のいずれかを実行します。

• end
• commit

RP/0/RSP0/CPU0:router# configure

RP/0/RSP0/CPU0:router(config)# router bgp 120

RP/0/RSP0/CPU0:router(config-vrf)# address-family ipv4 unicast

RP/0/RSP0/CPU0:router(config-bgp-af)# redistribute ospf 110

RP/0/RSP0/CPU0:router(config-bgp-af)# end

RP/0/RSP0/CPU0:router(config-bgp-af)# commit

1.    configure


2.    router bgp as-number


3.    address-family { ipv4 | ipv6 } unicast


4.    bgp dampening [ half-life [ reuse suppress max-suppress-time ] | route-policy route-policy-name ]


5.    次のいずれかを実行します。

• end
• commit

6.    show bgp [ ipv4 { unicast | multicast | labeled-unicast | all } | ipv6 unicast | all { unicast | multicast | all | labeled-unicast } | vpnv4 unicast [ rd rd-address ] | vrf { vrf-name | all } [ ipv4 { unicast | labeled-unicast } | ipv6 unicast ]] flap-statistics


7.    show bgp [ ipv4 { unicast | multicast | labeled-unicast | all } | ipv6 unicast | all { unicast | multicast | all | labeled-unicast } | vpnv4 unicast [ rd rd-address ] | vrf { vrf-name | all } [ ipv4 { unicast | labeled-unicast } | ipv6 unicast ]] flap-statistics regexp regular-expression


8.    show bgp [ ipv4 { unicast | multicast | labeled-unicast | all } | ipv6 unicast | labeled all { unicast | multicast | all | labeled-unicast } | vpnv4 unicast [ rd rd-address ] | vrf { vrf-name | all } [ ipv4 { unicast | labeled-unicast } | ipv6 unicast ]] flap-statistics route-policy route-policy-name


9.    show bgp [ ipv4 { unicast | multicast | labeled-unicast | all } | ipv6 unicast | labeled all { unicast | multicast | all | labeled-unicast } | vpnv4 unicast [ rd rd-address ] | vrf { vrf-name | all } [ ipv4 { unicast | labeled-unicast } | ipv6 unicast ]] flap-statistics { ip-address { mask | /prefix-length }}


10.    show bgp [ ipv4 { unicast | multicast | labeled-unicast | all } | ipv6 unicast | all { unicast | multicast | all | labeled-unicast } | vpnv4 unicast [ rd rd-address ] | vrf { vrf-name | all } [ ipv4 { unicast | labeled-unicast } | ipv6 unicast ]] flap-statistics { ip-address [{ mask | /prefix-length } [ longer-prefixes ]]}


11.    clear bgp { ipv4 { unicast | multicast | labeled-unicast | all } | ipv6 unicast | all { unicast | multicast | all | labeled-unicast } | vpnv4 unicast | vrf { vrf-name | all } { ipv4 { unicast | labeled-unicast } | ipv6 unicast } } flap-statistics


12.    clear bgp { ipv4 { unicast | multicast | labeled-unicast | all } | ipv6 unicast | all { unicast | multicast | all | labeled-unicast } | vpnv4 unicast | vrf { vrf-name | all } { ipv4 { unicast | labeled-unicast } | ipv6 unicast }} flap-statistics regexp regular-expression


13.    clear bgp { ipv4 { unicast | multicast | labeled-unicast | all } | ipv6 unicast | all { unicast | multicast | all | labeled-unicast } | vpnv4 unicast | vrf { vrf-name | all } { ipv4 { unicast | labeled-unicast } | ipv6 unicast } } flap-statistics route-policy route-policy-name


14.    clear bgp { ipv4 { unicast | multicast | labeled-unicast | all } | ipv6 unicast | all { unicast | multicast | all | labeled-unicast } | vpnv4 unicast | vrf { vrf-name | all } { ipv4 { unicast | labeled-unicast } | ipv6 unicast } } flap-statistics network / mask-length


15.    clear bgp { ipv4 { unicast | multicast | labeled-unicast | all } | ipv6 unicast | all { unicast | multicast | all | labeled-unicast } | vpnv4 unicast | vrf { vrf-name | all } { ipv4 { unicast | labeled-unicast } | ipv6 unicast } } flap-statistics ip-address / mask-length


16.    show bgp [ ipv4 { unicast | multicast | labeled-unicast | all } | ipv6 unicast | labeled all { unicast | multicast | all | labeled-unicast } | vpnv4 unicast [ rd rd-address ] | vrf { vrf-name | all } [ ipv4 { unicast | labeled-unicast } | ipv6 unicast ]] dampened-paths


17.    clear bgp { ipv4 { unicast | multicast | labeled-unicast | all } | ipv6 unicast | all { unicast | multicast | all | labeled-unicast } | vpnv4 unicast | vrf { vrf-name | all } { ipv4 { unicast | labeled-unicast } | ipv6 unicast } } dampening [ ip-address / mask-length ]

RP/0/RSP0/CPU0:router# configure

RP/0/RSP0/CPU0:router(config)# router bgp 120

RP/0/RSP0/CPU0:router(config-vrf)# address-family ipv4 unicast

RP/0/RSP0/CPU0:router(config-bgp-af)# bgp dampening 30 1500 10000 120

RP/0/RSP0/CPU0:router(config-bgp-af)# end

RP/0/RSP0/CPU0:router(config-bgp-af)# commit

RP/0/RSP0/CPU0:router# show bgp flap statistics

RP/0/RSP0/CPU0:router# show bgp flap-statistics regexp _1$

RP/0/RSP0/CPU0:router(config)# show bgp flap-statistics route-policy policy_A

RP/0/RSP0/CPU0:router# show bgp flap-statistics 172.20.1.1

RP/0/RSP0/CPU0:router# show bgp flap-statistics 172.20.1.1 longer-prefixes

RP/0/RSP0/CPU0:router# clear bgp all all flap-statistics 

RP/0/RSP0/CPU0:router# clear bgp ipv4 unicast flap-statistics regexp _1$

RP/0/RSP0/CPU0:router# clear bgp ipv4 unicast flap-statistics route-policy policy_A

RP/0/RSP0/CPU0:router# clear bgp ipv4 unicast flap-statistics 192.168.40.0/24

RP/0/RSP0/CPU0:router# clear bgp ipv4 unicast flap-statistics 172.20.1.1

RP/0/RSP0/CPU0:router# show bgp dampened paths

RP/0/RSP0/CPU0:router# clear bgp dampening