Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

BGP の概要

BGPを理解する

BGPは、異なる自律システム(AS)内のルーター間でルーティング情報を交換するために使用される外部ゲートウェイプロトコル(EGP)です。BGPルーティング情報には、各宛先への完全ルートが含まれてます。BGPは、ルーティング情報を使用して、他のBGPシステムとやりとりするネットワーク到達可能性情報のデータベースを維持管理します。BGPは、ネットワークの到達可能性情報を使用してAS接続のグラフを構築します。これにより、BGPがルーティングループを削除して、ASレベルでポリシー決定を適用することが可能になります。

マルチプロトコルBGP(MBGP)拡張は、BGPがIPバージョン6(IPv6)に対応することを可能にします。MBGPは、IPv6到達可能性情報の伝送に使用される属性MP_REACH_NLRIとMP_UNREACH_NLRIを定義します。ネットワーク層到達可能性情報(NLRI)更新メッセージは、使用可能ルートのIPv6アドレスプレフィックスを伝達します。

BGPは、ポリシーベースルーティングを可能にします。ルーティングポリシーを使用して、宛先に向かう複数のパスから選択し、ルーティング情報の再分配を管理することができます。

BGPは、確立した接続をするためのポート179で、TCPをそのトランスポートプロトコルとして使用します。信頼性の高いトランスポートプロトコル上で実行することにより、GBPが、更新されたフラグメンテーション、再送信、確認、配列を実施する必要性を取り除きます。

Junos OSルーティングプロトコルソフトウェアは、BGPバージョン4に対応しています。このBGPのバージョンは、ネットワーククラスの概念を取り除く、クラスレスインタードメインルーティング(CIDR)への対応を追加します。最初のオクテットを見ることで、アドレスのどのビットがネットワークを表すのかを推測する代わりに、CIDRを使うことで、ネットワークアドレスのビット数を明確に特定することができ、ルーティングテーブルのサイズを減少させる手段がもたらされます。また、BGPバージョン4は、ASパスのアグリゲーションを含む、ルートのアグリゲーションに対応しています。

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

自律システム

自律システム(AS)は、単一の技術管理下にある一連のルーターであり、通常、単一の内部ゲートウェイプロトコルと共通の一連メトリックを使用し、一連のルーター内においてルーティング情報を伝達します。他のASについては、ASには、単一で一貫性のある内部ルーティングプランがあるようで、どの宛先がそれを通して到達可能なのかという一貫性のある状況を表しています。

ASパスと属性

BGPシステムがやりとりするルーティング情報には、各宛先への完全ルートと、ルートに関する追加情報があります。ASパスは、通過ルートパスと追加ルートがパス属性に含まれる一連の自律システムです。BGPは、ASパスとパス属性を使用して、ネットワークトポロジーを完全に決定します。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、およびIBGPAS、EBGP、およびIBGP

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

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

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

BGPの複数のインスタンス

以下の階層レベルで、BGPの複数のインスタンスを設定できます。

  • [edit routing-instances routing-instance-name protocols]

  • [edit logical-systems logical-system-name routing-instances routing-instance-name protocols]

BGPの複数のインスタンスは、主にレイヤー3 VPN対応に使用されます。

IGPピアと外部BGP(EBGP)ピア(非マルチホップとマルチホップの双方)は、ルーティングインスタンスに対応されています。BGPピアリングは、階routing-instances層で設定されたインターフェイスの1つに確立しています。

注:

BGPネイバーがBGPメッセージをローカルルーティングデバイスに送信する際、そのメッセージが受信された着信インターフェイスは、BGPネイバー設定が存在する同じルーティングインスタンスで設定されなければなりません。これは、単一ホップ、または複数ホップ離れているネイバーにも当てはまります。

BGPピアから学習されたルートは、デフォルトルでinstance-name.inet.0テーブルに追加されます。インポートおよびエクスポートポリシーを設定して、インスタンスルーティングテーブル内外への情報フローを制御することができます。

レイヤー3 VPN対応については、プロバイダエッジ(PE)ルーター上にBGPを設定して、カスタマーエッジ(CE)ルーターからルートを受信し、必要に応じて、CEルーターにインスタンスのルートを送信します。BGPの複数のインスタンスを使用することで、PEルーター上でVPNトラフィックの分離を維持するために、別個のサイトごとの転送テーブルの維持管理を可能にします。

インポートとエクスポートポリシーを設定することで、サービスプロバイダは、顧客との相互トラフィックを管理し、レート制限することができます。

VRFルーティングインスタンスに対して、EBGPマルチホップセッションを設定できます。また、インターフェイスアドレスの代わりに、CEルーターのループバックアドレスを使用することで、PEとCEルーター間でEBGPピアを設定できます。

セキュリティゾーン内のインターフェイスのプロトコルトラフィックを許可する

SRXシリーズファイアウォールでは、指定されたインターフェイスまたはゾーンのインターフェイスすべてで、予期されるホストインバウンドトラトラフィックを有効にする必要があります。そうしないと、このデバイスを宛先とするインバウンドトラフィックはデフォルトで破棄されます。

たとえば、SRXシリーズファイアウォールにおける特定のゾーンでBGPトラトラフィックを許可するには、次のステップを使用します。

(すべてのインターフェイス) (指定されたインターフェイス)

BGP ルートの概要

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 ネイバー(プロトコル ネクストホップ)へのネクストホップ アドレスを持つ内部 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メッセージには、同じ固定サイズヘッダーがあり、それには同期と認証に使用されるマーカーフィールド、パケットの長さを示す長さフィールド、メッセージタイプを示すタイプフィールド(例として、オープン、更新、通知、キープアライブなど)があります。

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

オープンメッセージ

2つのBGPシステム間でTCP接続が確立された後、両者はBGPオープンメッセージを交換し、両者間にBGP接続を作成します。接続が確立すると、2つのシステムはBGPメッセージとデータトラフィックを交換できるようになります。

オープンメッセージは、BGPヘッダーに加えて、以下のフィールドで構成されています。

  • バージョン—現在のBGPバージョン番号は4です。

  • ローカルAS番号—[edit routing-options]もしくは[edit logical-systems logical-system-name routing-options]階層レベルのautonomous-systemステートメントを含めてこれを設定します。

  • 保持時間—提示された保持時間値。BGPhold-timeステートメントでローカル保持時間を設定します。

  • BGP識別子—BGPシステムのIPアドレス。このアドレスは、システムが起動する際に決定され、すべてのローカルインターフェイスおよびすべてのBGPピアに対して同じです。も[edit routing-options]しくは階[edit logical-systems logical-system-name routing-options]層レベルのステートrouter-idメントを含めてBGP識別子を設定します。デフォルトでは、BGP はルーターで検出した最初のインターフェイス の IPアドレスを使用します。

  • パラメーターフィールド長とパラメーター自体—これはオプションのフィールドです。

更新メッセージ

BGPシステムは、ネットワーク到達可能性情報を交換するために更新メッセージを送信します。BGPシステムは、この情報を使用して、すべての既知ASの関係を説明するグラフを構築します。

更新メッセージは、BGPヘッダーに加えて、以下のオプションフィールドで構成されています。

  • 使用不能ルート長—取り下げルートフィールドの長さ

  • 取り下げルート—すでに到達可能ではなくなったとみなされ、サービスから取り下げられたルートに対するIPアドレスプレフィックス

  • パス属性全長—パス属性フィールドの長さで、宛先への実現可能なルートに対するパス属性を一覧表示します

  • パス属性—パス送信元、複数出口弁別子(MED)、送信元システムのルートに対する優先傾向、アグリゲーション、コミュニティー、コンフェデレーション、ルートリフレクションの情報を含むルートのプロパティ

  • ネットワークレイヤー到達可能性情報(NLRI)—更新メッセージでアドバタイズされる使用可能なルートのIPアドレスプレフィックス

キープアライブメッセージ

BGPシステムは、キープアライブメッセージを交換し、リンクもしくはホストが障害を起こしたか、利用不可能かを判断します。キープアライブメッセージが十分な頻度で交換されるので、保持時間が終了することはありません。このメッセージは、BGPヘッダーのみで構成されています。

通知メッセージ

BGPシステムは、エラーが検出された場合、通知メッセージを送信します。メッセージが送信された後、BGPセッションとBGPシステム間のTCP接続は終了します。通知メッセージは、BGPヘッダーに加えて、エラーコードとサブコード、またエラーを記述するデータで構成されています。

ルート更新メッセージ

BGPシステムは、ピアからルート更新機能のアドバタイズメントを受けた場合のみに、ルート更新メッセージを送信します。BGPシステムは、ルート更新メッセージを受信を希望する場合、BGP機能のアドバタイズを用いて、そのピアにルート更新機能をアドバタイズしなければなりません。このオプションメッセージは、動的、受信、BGPルート更新をBGPピアからリクエストするか、送信ルート更新をBGPピアに送信するために送られます。

ルート更新メッセージは、以下のフィールドで構成されています。

  • AFI—アドレスファミリー識別子(16ビット)

  • Res—予約(8ビット)フィールドは、送信側は0 に設定、受信側は無視する必要があります。

  • SAFI—後続アドレスファミリー識別子(8ビット)

ルート更新機能のなピアがリモート ピアからルート更新リクエストメッセージを受信した場合、受信側はメッセージを無視します。

BGP RIBシャーディングとBBGPアップデートIOスレッドの理解

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となります。

BGPパス選択について

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

  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アドレスが、最も小さいピアからのパスを優先します。

ルーティング・テーブルのパス選択

アルゴリズムの最短ASパスのステップは、デフォルトによって、ASパスの長さを評価し、アクティブなパスを決定します。as-path-ignoreオプションを含めることで、Junos OSがアルゴリズムのこのステップをスキップできるように設定することができます。

注:

Junos OS Release 14.1R8、14.2R7、15.1R4、15.1F6、および16.1R1以降では、ルーティング・インスタンスでこのas-path-ignoreオプションがサポートされています。

ルーティング・プロセスのパス選択は、BGPがルーティング・テーブルにパスを手渡し、決定を下す前に行われます。ルーティング・テーブルのパス選択動作を設定するためには、ステートpath-selectionメントを含めます:

このステートメントを含めることができる階層レベルの一覧は、このステートメントのステートメント概要のセクションを参照してください。

ルーティング・テーブルのパス選択は、次のいずれかの方法で設定することができます:

  • Cisco IOSのデフォルト動作( cisco-non-deterministic)をエミュレートします。このモードでは、ルートを受け取った順に評価し、ネイバーのASに応じてそのルートをグループ化しません。モーcisco-non-deterministicドでは、アクティブなパスが常に優先されます。非アクティブながら適格なパスは、すべてアクティブなパスに続き、受信した順番に維持され、最新のパスが優先されます。対象外のパスは、リストの末尾に残されています。

    例として、192.168.1.0 /24 ルートに対して3つのパス広告があるとします:

    • パス1-EBGPで学習;ASパスは65010;MEDは200

    • パス2-IBGPで学習;ASパスは65020;MEDは150;IGPコストは5

    • パス3-IBGPで学習;ASパスは65010;MEDは100;IGPコストは10

    これらのアドバタイズは、記載された順番に1秒以内に次々と受信されます。パス3は、最も最近に受信したものなので、ルーティング・デバイスは次に新しいアドバタイズであるパス2に対して比較します。IBGPピアへのコストは、パス2の方が良いので、ルーティング・デバイスは、パス3をコンテンションから除外します。パス1とパス2を比較した場合、パス1はEBGPピアからの受信となるため、ルーティング・デバイスはパス1を優先します。これにより,ルーティング・デバイスは、パス1をルートのアクティブ・パスとしてインストールすることを承認します。

    注:

    この設定オプションをネットワークで使用することは、お勧めしません。ネットワーク上のすべてのルーティング・デバイスが一貫したルート選択を行えるようにするため、相互運用性のみを目的として提供されています。

  • 比較するルートのピアASが同じ( always-compare-med)か否かにかかわらず、常にMEDを比較します。

  • 両方のパスが外部にある場合、現在アクティブなパスを優先する( external-router-id)というルールを無効にします。次のステップ(Step  12)に進み、パス選択作業を行います。

  • パス選択( med-plus-igp)に関するMED値を比較する前に、ネクストホップ宛先までのIGPコストをMED値に追加します。

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

BGPテーブルのパス選択

BGPのパス選択では、以下のパラメータに従います:

  1. ローカルプリファレンス値が最も高いものを優先します。

  2. 最短のASパス長を優先します。

  3. 起点値が最も小さいものを優先します。

  4. MEDの値が最も小さいものを優先します。

  5. EBGPピアから学習したルートをIBGPピアよりも優先します。

  6. ASからの最適な出口を優先します。

  7. EBGP受信ルートの場合、現在のアクティブなルートを優先します。

  8. ルータIDが最も小さいピアからのルートを優先します。

  9. クラスタ長の最も短いパスを優先します。

  10. ピアIPアドレスが最も小さいピアからのルートを優先します。ステップ2、6および12がRPDの基準です。

宛先までの複数のパスをアドバタイズすることによる効果

BGPは、宛先への複数のパスをアドバタイズするようにBGPを設定しない限り、アクティブなパスのみをアドバタイズします。

ルーティング・デバイスのルーティング・テーブルに宛先への4つのパスがあり、最大3つのパス( add-path send path-count 3)をアドバタイズするように設定されているとします。3つのパスは、パス選択基準に基づいて選択されます。つまり、最適な3つのパスがパス選択順に選択されます。最適なパスは、アクティブなパスです。このパスは検討から外され、新たな最適パスが選択されます。この処理は、指定されたパス数に達するまで繰り返されます。

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 4576、BGP/MPLS IP仮想プライベートネットワーク(VPN)のループを防止するためのリンク状態広告(LSA)オプションビットを使用

  • 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 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 Graceful Restartの通知メッセージサポート

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

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

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

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

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

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

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

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

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

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

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

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

  • 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、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の使用

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

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

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

変更履歴

サポートされる機能は、使用しているプラットフォームとリリースによって決まります。 特定の機能がお使いのプラットフォームでサポートされているかどうかを確認するには、 Feature Explorer をご利用ください。

リリース
説明
17.2R1
Junos OS リリース 17.2R1 以降、rpd のリゾルバーモジュールが最適化され、インバウンド処理フローのスループットを増加させ、RIB と FIB の学習速度を向上させました。
14.1R8
Junos OS Release 14.1R8、14.2R7、15.1R4、15.1F6、および16.1R1以降では、ルーティング・インスタンスでこのas-path-ignoreオプションがサポートされています。