BGPの概要

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

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

外部および内部BGP

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

図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パス選択は、ルート選択後のRIBで最適なルートではない可能性があるため、BGPネイバーから受信したネットワーク層到達可能性情報(NLRI)に対して完全なBGP解決が実行されるまで延期されます。

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

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

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

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

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

このセクションでは、BGPメッセージタイプについて説明します。

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

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シャーディングと併用することが必須です。BGPシャーディングは、RIBを複数のサブRIBに分割し、別々のRPDスレッドでサービスを提供します。そのため、1つの送信アップデートに含まれるはずのプレフィックスが、異なるシャードに含まれてしまいます。異なるRPDシャードスレッドに属する可能性のある同じ発信属性のプレフィックスでBGPアップデートを構築できるように、すべてのシャードスレッドは、その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ルート状態を作成します。プライマリルーティングエンジンに障害が発生すると、バックアップルーティングエンジンがプライマリルーティングエンジンとなり、ピアとのBGPセッションに影響を与えることなく、スムーズにバックアップRPDがプライマリRPDとなります。

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

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

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

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

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

   非 BGP パスの場合は、 優先度 2 値が最も低いパスを選択します。

4. 累積内部ゲートウェイプロトコル(AIGP)属性が有効な場合、IGPメトリックを追加し、AIGP属性の低いパスを優先します。

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

   コンフェデレーションセグメント(シーケンスまたはセット)のパス長は0です。ASセットのパス長は1です。

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

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

7. Multiple Exit Discriminator(MED)メトリックが最も小さいパスを優先します。

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

   • 非決定的なルーティングテーブルパス選択動作が設定されていない場合(つまり、 path-selection cisco-nondeterministic ステートメントがBGP設定に含まれていない場合)、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つのパスが同じIGPプラスIGPコストを持つ場合でも、IGPコスト・メトリックに基づいて行われます。

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

    • path-selection external-ルーター-id が設定されています。

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

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

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

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

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

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

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

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

BGP更新メッセージに未知のオプション属性が含まれる場合、これらの属性は形式が正しく、推移的である可能性があります。ルーターは異常チェックを実行できないため、これらの不明な属性が他の BGP ピアに転送される可能性があります。不正な属性が拡散すると、ネットワークセキュリティの脅威が発生し、BGPの運用が損なわれる可能性があります。

BGP不明な属性管理は、BGPシステム内の未知のオプションの推移的BGP属性を管理することで、ネットワークのセキュリティと安定性を強化します。BGP システムは、このようなBGP属性を削除するか、これらの属性を持つルートを撤回するように設定することで、BGPピア間で不正な属性または潜在的に有害な属性が伝播するリスクを防ぐことができます。また、例外を指定して、選択された未知のオプションの推移的 BGP 属性のうち、ドロップしたり、ルート取り消しを引き起こしたりしてはならない属性を除外することもできます。これらの設定は、BGPグローバル、グループレベル、または個々のネイバーに適用することができ、BGP運用を包括的に制御することができます。

BGP属性をドロップするか、これらの属性を持つルートを取り消すには、 path-attributes drop (attributes <>) または path-attributes withdraw-routes (attributes <>) コマンドを設定します。

不明なオプションの推移的BGP属性をドロップするか、これらの属性を持つルートを取り消すには、 path-attributes drop (unknown-optional-transitive) または path-attributes withdraw-routes (unknown-optional-transitive) コマンドを設定します。

選択された未知のオプションの推移的BGP属性を除外する例外を定義するには、 path-attributes drop (unknown-optional-transitive [except <>]) または path-attributes withdraw-routes (unknown-optional-transitive [except <>]) コマンドを設定します。

show BGP neighborおよびshow log messagesコマンドは、ルートのドロップまたはルート取り消しのトリガー用に設定された未知のオプションの推移的BGP属性を詳細なログとともに表示します。可視性の向上により、BGPシステム内でのBGP属性関連アクティビティの処理に透明性がもたらされ、効果的なBGP管理とトラブルシューティングが促進されます。

Junos OSは、リストネクストホップ構造を使用するBGPマルチパスヘルパールートへのサービスルート解決を強化します。ルートリゾルバーは、マルチパスルート内のすべての寄与パスの内部依存関係を作成して維持するようになり、寄与ルートがアクティブか非アクティブかに関係なく、間接ネクストホップが変更された場合に正確かつ動的な再解決が可能になります。

この機能により、間接ネクストホップ解決を備えた BGP ECMP を使用して、サービス ルートの安定性が向上し、古い転送パスを防ぐことができます。

• 利点
• 始める前に
• 機能の仕組み
• 運用例
• CLIコマンドリファレンス
• 制限事項

Junos OSは、IPバージョン4(IPv4)BGPの標準を定義する以下のRFCとインターネットドラフトを実質的にサポートしています。

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

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

• RFC 1745、 IP向けBGP4/IDRP—OSPF相互作用

• RFC 1772、 インターネットにおける境界ゲートウェイプロトコルの適用

• 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、 境界ゲートウェイプロトコル(BGP)永続ルートの変動条件

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

• RFC 4271、 BGP-4(境界ゲートウェイプロトコル)

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

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

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

• RFC 4456、 BGPルートリフレクション:フルメッシュ内部BGP(IBGP)の代替

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

• RFC 4576、 BGP/MPLS IP仮想プライベートネットワーク(VPN)のループを防止するためのLink State Advertisement(LSA)オプションビットの使用

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

• RFC 4632、 クラスレスドメイン間ルーティング(CIDR):インターネットアドレス割り当てとアグリゲーションプラン

• RFC 4684、 境界ゲートウェイプロトコル/マルチプロトコルラベルスイッチング(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カプセル化後続アドレスファミリー識別子(SAFI)およびBGPトンネルのカプセル化属性

• RFC 5549、 IPv6ネクストホップによるIPv4ネットワーク層到達可能性情報のアドバタイズ

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

• RFC 8956、 IPv6用フロー仕様ルールの普及

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

• RFC 5701、 IPv6アドレス固有のBGP拡張コミュニティ属性

• RFC 5925、 TCP認証オプション

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

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

• RFC 6774、 多様なBGPパスの分布

• RFC 6793、 4オクテット自律システム(AS)番号スペースのBGPサポート

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

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

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

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

• RFC 7311、 BGPの累積IGPメトリック属性

• RFC 7404、 IPv6ネットワーク内でのリンクローカルアドレッシングのみの使用

• RFC 7432、 BGP MPLSベースのイーサネットVPN(eVPN)

• RFC 7606、 BGP UPDATEメッセージの改訂されたエラー処理

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

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

• RFC 7752、 BGPを使用したリンクステートおよびトラフィック制御(TE)情報の北回り配信

• RFC 7854、 BGP監視プロトコル(BMP)

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

• RFC 8097、 BGPプレフィックス起点検証状態拡張コミュニティ

• RFC 8210、 リソース公開キーインフラストラクチャ(RPKI)からルーターへのプロトコル、バージョン1

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

  例外:

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

• RFC 8277、 BGPを使用してMPLSラベルをアドレスプレフィックスにバインド

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

• RFC 8481、 リソース公開鍵基盤(RPKI)に基づくBGPの起点検証の明確化

• RFC 8538、 BGPグレースフルリスタートの通知メッセージサポート

• RFC 8571、 BGP - IGPトラフィック制御パフォーマンスメトリック拡張のリンク状態(BGP-LS)アドバタイズメント

• RFC 8584、 イーサネットVPN指定フォワーダー選択の拡張性のフレームワーク

• RFC 8642、 周知のBGPコミュニティのポリシー動作

• RFC 8669、 BGPのセグメントルーティングプレフィックスセグメント識別子拡張

• RFC 8810、 機能コードの登録手順の改訂

• RFC 8814、 境界ゲートウェイプロトコル - リンク状態を使用したシグナリング最大SID深さ(MSD)(部分サポート)

• RFC 8950、 IPv6ネクストホップによるIPv4ネットワーク層到達可能性情報(NLRI)のアドバタイズ

• RFC 8955

• RFC 8956

• RFC 9003、 拡張BGP管理シャットダウン通信

• RFC 9012、 BGPトンネルのカプセル化属性

• RFC 9029、境界 ゲートウェイプロトコル - リンク状態(BGP-LS)パラメータレジストリの割り当てポリシーの更新

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

• RFC 9085、セグメント ルーティング用の境界ゲートウェイプロトコル - リンク状態(BGP-LS)拡張

• RFC 9117、 BGPフロー仕様の普及のための改訂された検証手順。これにより、フロー仕様は、検証を実行する BGPピアと同じ自律システム内で発生させることができます。

• RFC 9234、 UPDATEおよびOPENメッセージのロールを使用したルート漏洩防止と検出

• RFC 9384、 双方向フォワーディング検出(BFD)用のBGP停止通知サブコード

• インターネットドラフト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、 AS 0処理の複合 (2013年2月終了)

• インターネットドラフトdraft-ietf-idr-link-bandwidth-06.txt、 BGP Link Bandwidth Extended Community (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の使用

• RFC 3345、 境界ゲートウェイプロトコル(BGP)永続ルートの変動条件

• RFC 3562、 TCP MD5署名オプションのキーマネージメントに関する考慮事項

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