BGP の概要

このセクションでは、以下のトピックについて説明します。

• 自律システム
• ASパスと属性
• 外部と内部BGP
• BGPの複数のインスタンス
• セキュリティゾーン内のインターフェイスのプロトコルトラフィックを許可する

外部と内部BGP

BGPは、2種類のルーティング情報のやりとりに対応しています。異なるAS間での交換、および単一AS内での交換です。ASの間で使用される場合、BGPは外部BGP（EBGP）と呼ばれ、BGPセッションはAS間ルーティングを実行します。AS内で使用される場合、BGPは内部BGP（IBGP）と呼ばれ、BGPセッションはAS内ルーティングを実行します。は、AS、IBGP、およびEBGPを図 1示しています。

図 1: AS、EBGP、およびIBGP

BGPシステムは、ネイバーまたはピアと呼ばれる隣接するBGPシステムとネットワーク到達可能性情報を共有します。

BGPシステムは、グループにまとめられています。IBGPグループでは、内部ピアと呼ばれるグループのすべてのピアが、同じASに存在します。内部ピアはローカルAS内のどの場所にも存在でき、相互に直接接続する必要はありません。内部グループは、IGPからのルートを使用して、転送アドレスを解決します。また、それは、他のすべての内部ルーター間で外部ルーターを伝送して、IBGPを実行、ルートで受信したBGPネクストホップを取り入れることでネクストホップを計算、そして、内部ゲートウェイプロトコルの1つからの情報でそれを解決することを行います。

EBGPグループでは、外部ピアと呼ばれるグループのピアが、異なるASに存在し、通常サブネットを共有します。外部グループにおいて、ネクストホップが、外部ピアとローカルルーターの間で共有されるインターフェイスに関して計算されます。

BGP ルートは、IP アドレスのプレフィックスで記述された宛先と、宛先までのルートを記述する情報です。

パス については、次のような情報があります。

• ASパスは、ローカルルーターに到達するまでにルートが通過する複数ASの番号のリストです。パスの最初の番号は、パスの最後の AS（ローカル ルーターに最も近い AS）の番号です。パスの最後の番号は、通常、パスの起点となるローカルルーターからの最も遠いASを示します。

• パス属性には、ルーティングポリシーで使用されるASパスに関する追加情報が含まれます。

BGP ピアは、アップデート メッセージで互いにルートをアドバタイズします。

BGP は、Junos OS のルーティング テーブル（inet.0）にそのルートを保存します。ルーティング テーブルには、BGP ルートに関する次の情報が格納されます。

• ピアから受信したアップデート メッセージから学習したルーティング情報

• ローカル ポリシーのために BGP がルートに適用するローカル ルーティング情報

• BGP がアップデート メッセージで BGP ピアにアドバタイズする情報

ルーティング テーブルの各プレフィックスに対して、ルーティング プロトコル プロセスはアクティブ パスと呼ばれる単一の最良のパスを選択する。同じ宛先への複数のパスを広告するようにBGPを設定しない限り、BGP はアクティブなパスのみを広告します。

最初にルートを広告する BGP ルーターは、ルートの起点を識別するために次のいずれかの値を割り当てます。ルート選択時には、最も低いオリジン値が優先されます。

• 0ルーターはもともと IGP（OSPF、IS-IS、またはスタティックルート）を通じてルートを学習しました。

• 1ルーターはもともと EGP（ほとんどの場合 BGP）を通してルートを学習しました。

• 2ルートの由来は不明です。

リモート BGP ネイバー（プロトコル ネクストホップ）へのネクストホップ アドレスを持つ内部 BGP（IBGP）ルートは、そのネクストホップを他のルートで解決する必要があります。BGP は、ネクストホップ解決のために、 rpd リゾルバーモジュールにこのルートを追加します。RSVP がネットワークで使用されている場合、BGP ネクストホップは RSVP イングレスルートを使用して解決されます。この結果、BGPルートは間接ネクストホップを指し示し、間接ネクストホップは転送ネクストホップを指し示すことになります。転送ネクストホップは、RSVP ルート ネクストホップから派生します。しばしば、同じプロトコル ネクストホップを持つ内部 BGP ルートの大規模なセットが存在します。そのような場合、BGP ルートのセットは同じ間接ネクストホップを参照することになります。

Junos OS リリース 17.2R1 以前は、IBGP 内のルーティング プロトコル プロセス（rpd）解決ルートのリゾルバーモジュールは、以下のような方法でルートを受信しました。

1. 部分的なルート解決 － プロトコル ネクストホップは、RSVP や IGP ルートなどのヘルパー ルートに基づいて解決されます。メトリック値はヘルパールートから派生し、ネクストホップは、ヘルパールートから継承したリゾルバー転送ネクストホップと見なされます。これらのメトリック値は、ルーティング情報ベース（RIB、ルーティング テーブルとも呼ばれる）でルートを選択する際に使われます。

2. 完全なルート解決 — 最終ネクストホップが派生し、転送エクスポート ポリシーに基づいて、カーネル ルーティング テーブル（KRT）転送ネクストホップと呼ばれます。

Junos OS リリース 17.2R1 以降、rpd のリゾルバーモジュールが最適化され、インバウンド処理フローのスループットを増加させ、RIB と FIB の学習速度を向上させました。この機能拡張により、ルート解決は以下のような影響を受けます。

• 部分的および完全なルート解決方法は、各 IBGP ルートに対してトリガーされますが、各ルートは同一の解決済み転送ネクストホップまたは KRT 転送ネクストホップを継承するかもしれません。

• BGP パス選択は、BGP ネイバーから受信したネットワーク層到達可能性情報（NLRI）がルート選択後の RIB で最適なルートではない可能性があるため、それに対して完全なルート解決が実行されるまで延期されます。

rpd リゾルバー最適化には、以下のようなメリットがあります。

• RIB 解決検索コストの低減 — 解決したパスの出力はリゾルバー キャッシュに保存されるため、パスの部分的および完全なルート解決フローの両方を実行する代わりに、同じ派生済みネクストホップとメトリック値を同じパス行動を共有する別のルートセットに継承できます。これにより、深さ制限のあるキャッシュ内で、最も頻繁なリゾルバーの状態のみを維持することで、ルート解決の検索コストを削減します。

• BGP ルート選択の最適化 — BGP ルート選択アルゴリズムは、受信したすべての IBGP ルートに対して 2 回トリガーされます。1 回目のトリガーはネクストホップを使用不可として RIB にルートを追加する間で、2 度目は解決済みネクストホップと共にルートを RIB に追加する間です（ルート解決後）。これにより、最適なルートを 2 回選択することができます。リゾルバーの最適化により、ルート選択プロセスが受信フローでトリガーされるのは、リゾルバーモジュールからネクストホップ情報を取得した後のみになります。

• 頻繁な検索を避けるための内部キャッシュ － リゾルバーキャッシュは、最も頻繁なリゾルバー状態を維持し、その結果、ネクストホップ検索やルート検索などの検索機能はローカルキャッシュから行われます。

• パス等価グループ － 異なるパスが同じ転送状態を共有する、または同じプロトコル ネクストホップから受信された場合、そのパスは、1 つのパス等価グループに属することができます。このアプローチは、そのようなパスに対して完全なルート解決を実行する必要を回避します。新しいパスが完全なルート解決を必要とする場合、まず、間接ネクストホップや転送ネクストホップなどの解決済みパス出力を含む、パス等価グループデータベースを検索します。

このセクションでは、以下のトピックについて説明します。

• オープンメッセージ
• 更新メッセージ
• キープアライブメッセージ
• 通知メッセージ
• ルート更新メッセージ

BGPルートプロセスは通常、アップデートの受信、アップデートの解析、ルートの作成、ネクストホップの解決、BGPピアグループのエクスポートポリシーの適用、ピアごとのアップデート形成およびピアへのアップデート送信など、いくつかのパイプラインステージを備えています。

BGP RIBシャーディングは、統合されたBGP RIBを複数のサブRIBに分割し、各サブRIBがBGPルートのサブセットを処理します。BGPシャードスレッドと呼ばれる別のRPDスレッドが各サブRIBに対応し、並行処理を実現します。BGPシャードスレッドは、ピアごとのアップデートの形成とピアへのアップデートの送信を除いた、すべてのBGPルート処理パイプライン段階に対する責任を担います。BGPシャードスレッドは、ピアから送信されたアップデートをBGPアップデートIOスレッドから受信し、BGPアップデートIOスレッドがアップデート内のプレフィックスをハッシュ化して、ハッシュ計算に基づいて、該当するBGPシャードスレッドにアップデートを送信します。BGPシャードスレッドはRPDメインスレッドと類似した方法で設定を処理し、ピア、グループ、ルートテーブルを作成して、その設定情報をBGPルート処理に使用します。

BGPアップデートIOスレッドは、BGPパイプラインの最後尾を担当し、個々のBGPグループのピアごとのアップデートを作成してピアに送信します。1つの更新スレッドが1つまたは複数のBGPグループに対応する場合があります。BGPアップデートIOスレッドは、他のアップデートスレッドによって処理されている他のグループから独立して、並行してグループのアップデートを構築します。これは、多くのグループに分散する数多くのピアにアドバタイズするような、書き込み量が膨大な作業負荷において、大幅なコンバージェンスの改善をもたらすかもしれません。BGPアップデートIOスレッドは、これまでBGPIOスレッドによって提供されていたBGPピアのTCPソケットへの書き込みと読み込みも担当します（そのため、BGPアップデートIOの接尾辞はIOとなっています）。

BGPアップデートIOスレッドは、RIBシャーディング機能とは無関係に設定できますが、RIBシャーディングと併用することが必須です。これは、送信するBGPアップデートメッセージのプレフィックス・パッキング効率を向上させるためです。BGPシャーディングは、RIBを複数のサブRIBに分割し、別々のRPDスレッドでサービスを提供します。そのため、1つの送信アップデートに含まれるはずのプレフィックスが、異なるシャードに含まれてしまいます。異なるRPDシャードスレッドに属するかもしれない同じ発信属性のプレフィックスで、BGPアップデートを構築できるように、すべてのシャードスレッドは、そのBGPピアグループを提供するアップデートスレッドにアドバタイズされるプレフィックス用のコンパクトなアドバタイズ情報を送信します。これにより、このBGPピアグループにサービスを提供するアップデートスレッドは、異なるシャードに属する可能性のある同じ属性を持つプレフィックスを、同じ送信アップデートメッセージにパックすることができます。これにより、アドバタイズされるアップデートの数を最小限に抑えることができ、コンバージェンスを高めることができます。アップデートIOスレッドは、ピア、グループ、プレフィックス、TSIおよびRIBコンテナのローカルキャッシュを管理します。

BGPアップデートスレッドとBGP RIBシャーディングは、デフォルトで無効になっています。ルーティングエンジンでupdate-threadingとrib-shardingを設定すると、RPDはアップデートスレッドを作成します。デフォルトでは、作成されるアップデートスレッドとシャードスレッドの数は、ルーティングエンジンのCPUコアの数と同じです。アップデートのスレッドは、64ビットのルーティングプロトコルプロセス（rpd）でのみサポートされています。オプションで、作成するスレッドの数は、[edit system processes routing bgp]階層レベルのset update-threading <number-of-threads>ステートメントとset rib-sharding <number-of-threads>ステートメントで指定することができます。BGPアップデートスレッドの範囲は現在1～128、BGP RIBシャーディングの範囲は現在1～31です。

BGP RIBシャーディングおよびBGPアップデートIO機能にNSRを設定すると、バックアップRPDがバックアップルーティングエンジンに同じ数のBGPシャーディングとBGPアップデートIOスレッドを作成します。バックアップRPD BGPアップデートIOスレッドは、レプリケートされたBGPアップデート、ピアとレプリケートされたBGPアップデートから受信したその他のメッセージ、およびピアに送信されたその他のメッセージを読み取ります。プレフィックスのハッシュに基づいて、バックアップRPD BGPアップデートIOスレッドは、該当するBGPシャードおよびRPDメインスレッドに、これらのBGPメッセージを送信します。バックアップRPDのBGPシャードとRPDメインスレッドは、これらのレプリケートされたBGPメッセージを使用して、受信してアドバタイズされたルート状態を作成します。プライマリルーティングエンジンに障害が発生すると、バックアップルーティングエンジンがプライマリルーティングエンジンとなり、ピアとのBGPセッションに影響を与えることなくスムーズに、バックアップRPDがプライマリRPDとなります。

ルーティング・テーブルの各プレフィックスに対して、ルーティング・プロトコル・プロセスは単一の最良パスを選択します。最適なパスが選択された後、そのパスがルーティング・テーブルにインストールされます。管理距離とも呼ばれるグローバル・プリファレンス値がより低い（より好ましい）プロトコルによって同じプレフィックスが学習されない場合、最良のパスがアクティブなルートとなります。アクティブ・ルートを決定するアルゴリズムは以下の通りです：

1. ネクスト・ホップが解決可能であることを検証します。

2. プリファレンス値（ルーティング・プロトコル・プロセス・プリファレンス）が最も低いパスを選択します。

   転送の対象とならないルート（例えば、ルーティング・ポリシーで拒否されたり、ネクスト・ホップにアクセスできないという理由で）は、プリファレンスが－1になり、決して選択されません。

3. ローカル・プリファレンスの高いパスを優先します。

   preference2BGP以外のパスの場合は、値が最も小さいパスを選択します。

4. accumulated interior gateway protocol（AIGP）属性が有効になっている場合、IGPメトリックを追加し、より低いAIGP属性のパスを優先します。

5. 自律システム（AS）パス値が、最短のパスを優先します（ステートas-path-ignoreメントが設定されている場合はスキップします）。

   コンフェデレーション・セグメント（シーケンスまたはセット）のパス長は0です。ASセットのパス長は1となります。

6. 起点コードの小さいルートを優先します。

   IGPから学習したルートは、外部ゲートウェイ・プロトコル（EGP）から学習したルートよりも起点コードが低く、どちらも不完全なルート（起点が不明なルート）よりも起点コードが低くなっています。

7. Multiple Exit Discriminator（MED）が、最も小さいパスを優先します。

   非決定的なルーティング・テーブルのパス選択動作が設定されているか否かにより、次の2つのケースが考えられます：

   • 非決定的ルーティング・テーブルのパス選択動作が設定されていない場合（つまり、BGPの設定にステートpath-selection cisco-nondeterministicメントが含まれていない場合）、ASパスの先頭に同じ隣接AS番号を持つパスについては，MEDメトリックが最も小さいパスを優先します。比較されたルートのピアASが同じか否かにかかわらず、常に MED を比較するためには、ステートpath-selection always-compare-medメントを含めるようにします。

   • 非決定的ルーティング・テーブル・パス選択動作が設定されている（つまり，BGPの設定にステートpath-selection cisco-nondeterministicメントが含まれている）場合、MEDメトリックが最小のパスを優先します。

   隣接ASを決定する際、コンフェデレーションは考慮されません。MEDメトリックが消失した場合、MEDは存在するもののゼロであるかのように扱われます。

   注:

   MED比較は、AS内の単一パス選択（ルートがASパスを含まない場合）でも機能しますが、この使用法は一般的ではありません。

   デフォルトでは，同じピアの自律システム（AS）を持つルートのMEDだけが比較されます。異なる動作を得るために、ルーティング・テーブルのパス選択オプションを設定することができます。

8. IGPルートとローカルに生成されたルート（スタティック、ダイレクト、ローカルなど）を含む、厳密な内部パスを優先します。

9. 内部BGP（IBGP）セッションで学習した外部パスよりも、厳密な外部BGP（EBGP）パスを優先します。

10. ネクスト・ホップが最もメトリックの低い IGP ルートを通じて解決されるパスを優先します。IGPを通じて解決されるBGPルートは、到達不能または拒否されたルートよりも優先されます。

    注:

    前のステップの後にタイブレークが行われた場合、パスはBGPイコールコスト・パスとみなされます（そして転送に使用されます）。マルチパス対応のBGPネイバーによって学習された、同一のネイバーASを持つすべてのパスが考慮されます。

    BGPマルチパスは，MED-plus-IGPコストが同じで，IGPコストが未だ異なるパスには適用されません。マルチパスのパス選択は、2つのパスが同じMED-plus-IGPコストを持つ場合でも、IGPコスト・メトリックに基づいて行われます。

11. 両方のパスが外部にある場合、最も古いパス、つまり最初に学習されたパスが優先されます。これは、ルートフラップを最小化するために行われます。このルールは、次の条件のいずれかに該当する場合は使用されません：

    • path-selection external-router-id設定されます。

    • どちらのピアも同じルータ IDを保持しています。

    • どちらかのピアが、コンフェデレーション・ピアとなります。

    • どちらのパスも、現在アクティブなパスではありません。

12. 二次ルートよりも一次ルートを優先します。一次ルートは、ルーティング・テーブルに属するルートです。二次ルートとは、エクスポート・ポリシーによってルーティング・テーブルに追加されるルートのことです。

13. ルータIDが最も小さいピアからのパスを優先します。オリジネーターID属性を持つパスに関しては、ルーターID比較時にオリジネーターIDをルーターIDに置き換えてください。

14. クラスタ・リストの長さが、最も短いパスを優先します。リストがない場合、長さは0になります。

15. ピアIPアドレスが、最も小さいピアからのパスを優先します。

• ルーティング・テーブルのパス選択
• BGPテーブルのパス選択
• 宛先までの複数のパスをアドバタイズすることによる効果

Junos OSは、IPバージョン4（IPv4）BGPの標準を定義する次のようなRFCとインターネット・ドラフトを実質的にサポートしています。

サポートされているIPバージョン6（IPv6）BGP標準のリストについては、サポートされているIPv6標準を参照してください。

Junos OS BGPは、プロトコル交換（MD5認証）の認証をサポートします。

• RPC1745、IPに対するBGP4/IDRP—OSPFインターフェイス

• RFC 1772、インターネットのBorder Gateway Protocolのアプリケーション

• RFC 1997、BGPコミュニティ属性

• RFC 2283、BGP-4のマルチプロトコル拡張

• RFC 2385、TCP MD5シグネチャオプションによるBGPセッションの保護

• RFC 2439、BGPルートフラップダンピング

• RFC 2545、IPv6ドメイン間ルーティングのBGP-4マルチプロトコル拡張の使用

• RFC 2796、BGPルートリフレクション — フルメッシュIBGPへの代替

• RFC 2858、BGP-4のマルチプロトコル拡張

• RFC 2918、BGP-4のルート更新機能

• RFC 3065、BGPの自律システムコンフェデレーション

• RFC 3107、BGP-4のラベル情報の運搬

• RFC 3345、Border Gateway Protocol (BGP) 永続ルート発振条件

• RFC 3392、BGP-4の機能アドバタイズ

• RFC 4271、Border Gateway Protocol 4（BGP-4）

• RFC 4273、BGP-4の管理対象オブジェクトの定義

• RFC 4360、BGP拡張コミュニティ属性

• RFC 4364、BGP/MPLS IP仮想プライベートネットワーク（VPN）

• RFC 4456、BGPルートリフレクション：An Alternative to Full Mesh Internal BGP（IBGP）

• RFC 4486、BGP和解通知メッセージのサブコード

• RFC 4659、IPv6 VPN向けBGP-MPLS IP仮想プライベートネットワーク（VPN）拡張

• RFC 4632、クラスレスドメイン間ルーティング（CIDR）：インターネットアドレス割り当ておよびアグリゲーションプラン

• RFC 4684、Border Gateway Protocol/マルチプロトコルラベルスイッチング（BGP/MPLS）インターネットプロトコル（IP）仮想プライベートネットワーク（VPN）の制約されたルート配分

• RFC 4724、BGPの正常再起動メカニズム

• RFC 4760、BGP-4のマルチプロトコル拡張

• RFC 4781、MPLSを使ったBGPの正常再起動メカニズム

• RFC 4798、IPv6プロバイダエッジルーター（6PE）を使用したIPv4 MPLS上のIPv6 Islandの接続

  オプション4b（ASから隣接するASへのラベル付きIPv6ルートのeBGPの再配分）はサポートされていません。

• RFC 4893、4オクテットAS番号スペースに対するBGPサポート

• RFC 5004、外部から他へのBGP最適パス移行を回避

• RFC 5065、BGPの自律システムコンフェデレーション

• RFC 5082、一般化されたTTLセキュリティメカニズム（GTSM）

• RFC 5291、BGP-4のアウトバウンドルートフィルタリング機能（部分サポート）

• RFC 5292、BGP-4のアドレスプレフィックスベースのアウトバウンドルートフィルタ（部分サポート）

  Junos OSを実行するデバイスは、プレフィックスベースのORFメッセージを受信できます。

• RFC 5396、自律システム（AS）番号のテキスト表現

• RFC 5492、BGP-4の機能アドバタイズ

• RFC 5512、BGPカプセル化後続アドレスファミリー識別子（SFI）、BGPトンネルのカプセル化属性

• RFC 5549、IPv6 Next Hopを使ったIPv4 ネットワーク層の到達可能性情報のアドバタイズ

• RFC 5575、フロー仕様ルールの普及

• RFC 5668、4オクテットAS特定のBGP拡張コミュニティー

• RFC 6286、BGP-4完全準拠の自律システム全体固有BGP識別子

• RFC 6368、BGP/MPLS IP仮想プライベートネットワーク（VPN）のプロバイダ/カスタマーエッジプロトコルとしての内部BGP

• RFC 6810、ルータープロトコルへのリソース公開キーインフラストラクチャ（RPKI）

• RFC 6811、BGPプレフィックス原点の検証

• RFC 6996、プライベート使用の自律システム（AS）予約

• RFC 7300、最終自律システム（AS）番号の予約

• RFC 7611、BGP ACCEPT_OWNコミュニティ属性

  ジュニパールーターがコミュニaccept-ownティ値のルートリフレクタから受信したルートを受信できるようにすることで、RFC をサポートします。

• RFC 7752、BGPを使用したリンクステートおよびトラフィックエンジニアリング（TE）情報の北回り配信

• RFC 7854、BGPモニタリングプロトコル（BMP）

• RFC 7911、BGPにおける複数パスのアドバタイズ

• RFC 8212、ポリシーのない外部BGP（EBGP）ルート伝搬の動作 - 完全準拠

  例外：

  RFC 8212に記載されている動作は、既存の顧客設定を崩さないようにするため、デフォルトで実装されていません。デフォルト動作は、EBGPピアに関するすべてのルートを受信およびアドバタイズする状態が保持されます。

• RFC 8326、正常BGPセッションのシャットダウン

• RFC 9069、BGPモニタリングプロトコル（BMP）でのローカルRIB用サポート

• インターネットドラフトdraft-idr-rfc8203bis-00、BGP管理シャットダウン通信（2018年10月終了）

• インターネットドラフトdraft-ietf-grow-bmp-adj-rib-out-01、BGPモニタリングプロトコル（BMP）のAdj-RIB-Outのサポート（2018年9月3日終了）

• インターネットドラフトdraft-ietf-idr-aigp-06、BGPの累積IGPメトリック属性（2011年12月終了）

• インターネットドラフトdraft-ietf-idr-as0-06、AS0処理の複合（2013年2月終了）

• インターネットドラフトdraft-ietf-idr-link-bandwidth-06.txt、BGPリンク帯域幅拡張コミュニティー（2013年7月終了）

• インターネットドラフトdraft-ietf-sidr-origin-validation-signaling-00、BGPプレフィックス起点検証ステートメント（部分サポート）（2011年5月終了）

  拡張コミュニティー（起点検証状態）は、Junos OSルーティングポリシーでサポートされています。ルート選択手順の指定変更はサポートされていません。

• インターネットドラフトdraft-kato-bgp-ipv6-link-local-00.txt、IPv6リンクローカルアドレスを使用したBGP4+ピアリング

以下のRFCとインターネットドラフトは、標準は定義しませんが、BGPと関連技術の情報を提供します。IETFは、「実験」または「情報」として別に分類されます。

• RFC 1965、BGPの自律システムコンフェデレーション

• RFC 1966、BGPルートリフレクション—フルメッシュIBGPの代替

• RFC 2270、単一プロバイダにホーミングされたサイトの専用ASの使用

• インターネットドラフトdraft-ietf-ngtrans-bgp-tunnel-04.txt、BGPを使ってIPv4 Clouds全体にIPv6 Islandを接続する（2002年7月終了）