ボーダーゲートウェイプロトコル

ピアリングハンドシェイク中にOPENメッセージが交換されると、BGPスピーカーはセッションのオプション機能^{[ 16 ]}をネゴシエートできます。これにはマルチプロトコル拡張^{[ 17 ]}やさまざまなリカバリモードが含まれます。BGPへのマルチプロトコル拡張が作成時にネゴシエートされた場合、BGPスピーカーは、アドバタイズするネットワーク層到達可能性情報（NLRI）にアドレスファミリプレフィックスを付加できます。これらのファミリには、IPv4（デフォルト）、IPv6、IPv4/IPv6仮想プライベートネットワーク、マルチキャストBGPが含まれます。BGPは、VPNなど、グローバルインターネットの一部ではない可能性のあるルートに関する情報を伝送するための汎用シグナリングプロトコルとしてますます使用されています。^{[ 18 ]}

BGPピアは、ピアとの操作において意思決定を行うために、アイドル、接続、アクティブ、OpenSent、OpenConfirm、確立の6つの状態からなる単純な有限状態機械（FSM）を使用します。各ピアツーピアセッションについて、BGP実装は、セッションがこれらの6つの状態のうちどれにあるかを追跡する状態変数を保持します。BGPは、セッションをある状態から別の状態に変更するために、各ピアが交換すべきメッセージを定義します。

最初の状態はアイドル状態です。アイドル状態では、BGP はすべてのリソースを初期化し、すべての受信 BGP 接続試行を拒否し、ピアへの TCP 接続を開始します。2 番目の状態は接続です。接続状態では、ルータは TCP 接続が完了するまで待機し、成功した場合は OpenSent 状態に移行します。失敗した場合は、ConnectRetry タイマーを開始し、期限切れになると Active 状態に移行します。Active 状態では、ルータは ConnectRetry タイマーをゼロにリセットし、接続状態に戻ります。OpenSent 状態では、ルータは Open メッセージを送信し、OpenConfirm 状態に移行するために返信を待ちます。Keepalive メッセージが交換され、正常に受信されると、ルータは確立状態になります。確立状態では、ルータはピアとの間で Keepalive、Update、Notification メッセージを送受信できます。

• アイドル状態：
  • 着信するすべてのBGP接続を拒否します。
  • イベントトリガーの初期化を開始します。
  • 設定済みのBGPピアとの間でTCP接続を開始します。
  • ピアからのTCP接続を待ち受けます。
  • 状態を「接続中」に変更します。
  • FSMプロセスのどの段階でエラーが発生した場合でも、BGPセッションは直ちに終了し、アイドル状態に戻ります。ルーターがアイドル状態から先に進まない理由としては、以下のようなものが挙げられます。
    • TCPポート179が開いていません。
    • 1023番を超える任意のTCPポートが開いていません。
    • どちらかのルーターでピアアドレスの設定が間違っています。
    • どちらかのルーターでAS番号が正しく設定されていません。
• 接続状態：
  • ピアとのTCPネゴシエーションが成功するまで待機します。
  • TCPセッションが正常に確立された場合、BGPはこの状態に長く留まることはありません。
  • ピアにOpenメッセージを送信し、状態をOpenSentに変更します。
  • エラーが発生すると、BGPはアクティブ状態に移行します。エラーの原因としては、以下のようなものが考えられます。
    • TCPポート179が開いていません。
    • 1023番を超える任意のTCPポートが開いていません。
    • どちらかのルーターでピアアドレスの設定が間違っています。
    • どちらかのルーターでAS番号が正しく設定されていません。
• アクティブ状態：
  • ルーターが正常なTCPセッションを確立できなかった場合、アクティブ状態になります。
  • BGP FSMは、ピアとの別のTCPセッションを再開しようと試み、成功した場合は、ピアにOpenメッセージを送信します。
  • 再度失敗した場合、FSMはアイドル状態にリセットされます。
  • 障害が繰り返されると、ルーターがアイドル状態とアクティブ状態を繰り返すことがあります。その理由としては、以下のようなものが挙げられます。
    • TCPポート179が開いていません。
    • 1023番を超える任意のTCPポートが開いていません。
    • BGP設定エラー。
    • ネットワークの混雑。
    • ネットワークインターフェースが不安定です。
• OpenSentの状態：
  • BGP FSMは、ピアからのOpenメッセージを待機します。
  • メッセージが受信されると、ルーターはOpenメッセージの有効性を確認します。
  • エラーが発生した場合、それはOpenメッセージのフィールドのいずれかがピア間で一致していないことが原因です（例：BGPバージョンの不一致、ピアリングルータが異なるMy ASを期待しているなど）。ルータは、エラーが発生した理由を示す通知メッセージをピアに送信します。
  • エラーが発生しない場合、キープアライブメッセージが送信され、各種タイマーが設定され、状態がOpenConfirmに変更されます。
• OpenConfirmの状態：
  • ピアは、ピアからのキープアライブメッセージを待機しています。
  • キープアライブメッセージを受信し、かつキープアライブメッセージを受信する前にタイマーが期限切れになっていない場合、BGPは確立状態に移行します。
  • キープアライブメッセージを受信する前にタイマーが期限切れになった場合、またはエラー状態が発生した場合、ルーターはアイドル状態に戻ります。
• 設立された州：
  • この状態では、ピアは更新メッセージを送信して、BGPピアにアドバタイズされている各ルートに関する情報を交換します。
  • 更新メッセージにエラーがある場合は、ピアに通知メッセージが送信され、BGPはアイドル状態に戻ります。

最も単純な構成では、単一のAS内にありBGPルーティングに参加するすべてのルータはフルメッシュで構成する必要があります。つまり、各ルータは他のすべてのルータとピアとして構成する必要があります。これは、必要な接続数が関係するルータの数の2乗に比例して増加するため、スケーリングの問題を引き起こします。この問題を軽減するために、BGPはルートリフレクタ（RFC 4456）とBGPコンフェデレーション（RFC 5065）という2つのオプションを実装しています。以下の基本的なアップデート処理の説明では、フルiBGPメッシュを前提としています。

特定のBGPルータは、複数のネイバーからネットワーク層到達可能性情報（NLRI）アップデートを受け入れ、同じネイバー、または異なるネイバー群にNLRIをアドバタイズすることができます。BGPプロセスは、いくつかのルーティング情報ベースを維持します。

• RIB: ルーターのメインルーティング情報ベーステーブル。
• Loc-RIB: ローカルルーティング情報ベース BGP は、ルーターのメインルーティングテーブルとは別に独自のマスタールーティングテーブルを維持します。
• Adj-RIB-In: 各ネイバーに対して、BGP プロセスは、ネイバーから受信した NLRI を含む概念的な隣接ルーティング情報ベース (incoming)を維持します。
• Adj-RIB-Out: 各ネイバーに対して、BGP プロセスは、ネイバーに送信される NLRI を含む概念的な隣接ルーティング情報ベース outgoing を維持します。

これらの概念テーブルの物理的な格納方法と構造は、BGP コードの実装者によって決定されます。これらの構造は他の BGP ルータからは見えませんが、通常はローカルルータの管理コマンドで照会できます。たとえば、Adj-RIB-In、Adj-RIB-Outおよび をLoc-RIB同じデータ構造に格納し、RIB エントリに追加情報を付加することはよくあります。追加情報は、個々のエントリがAdj-RIBs特定のネイバーの に属するかどうか、ピアネイバーのルート選択プロセスによって受信したポリシーが の対象になったかどうか、エントリがローカルルータのルーティング テーブル管理プロセスに送信される資格があるLoc-RIBかどうかなど、Loc-RIBBGP プロセスに情報を提供します。

BGPは、最適と判断したルートをメインルーティングテーブルプロセスに送信します。このプロセスの実装によっては、BGPルートが必ずしも選択されるとは限りません。例えば、ルーター自身のハードウェアから学習した直接接続プレフィックスが通常最も優先されます。その直接接続ルートのインターフェースがアクティブである限り、宛先へのBGPルートはルーティングテーブルに追加されません。インターフェースがダウンし、優先ルートがなくなると、Loc-RIBルートがメインルーティングテーブルに追加されます。

BGPは、BGP対応ルーター内部のルールがポリシー決定を行うために必要な情報を伝達します。ポリシー決定に明示的に使用されることを意図した伝達情報には、以下のようなものがあります。

• コミュニティ
• マルチ出口識別器（MED）。
• 自律システム（AS）

BGP標準では、Loc-RIBに格納するNLRIを選択するための決定要因が多数規定されており、これは他の一般的なルーティングプロセスで使用されるものよりも多い。NLRIを評価する最初の決定ポイントは、そのネクストホップ属性が到達可能（または解決可能）であることだ。ネクストホップが到達可能であることを別の言い方で表現すると、ネクストホップアドレスが到達可能なプレフィックスへのアクティブなルートが、ルータのメインルーティングテーブルに既に存在している必要があるということである。

次に、BGPプロセスは各ネイバーに対して、さまざまな標準および実装依存の基準を適用して、概念的にどのルートをAdj-RIB-Inに含めるべきかを決定します。ネイバーは宛先に対して複数のルートを送信できますが、優先順位の第一段階はネイバーレベルで決定されます。概念的なAdj-RIB-Inには、各宛先に対して1つのルートのみがインストールされます。このプロセスでは、ネイバーによって撤回されたルートもAdj-RIB-Inから削除されます。

概念的な Adj-RIB-In が変更されるたびに、メイン BGP プロセスは、ネイバーの新しいルートが Loc-RIB に既に存在するルートよりも優先されるかどうかを判断します。優先される場合は、それらのルートを置き換えます。ネイバーによって特定のルートが撤回され、その宛先への他のルートがない場合、そのルートは Loc-RIB から削除され、BGP によってメイン ルーティング テーブルマネージャに送信されなくなります。ルータが BGP 以外のソースからその宛先へのルートを持っていない場合、撤回されたルートはメイン ルーティング テーブルから削除されます。

同点の場合は、ルート選択プロセスは次のステップに進みます。

ローカルの優先度、重み、その他の基準は、ローカル設定とソフトウェア機能によって操作できます。このような操作は一般的に使用されていますが、標準の範囲外です。たとえば、コミュニティ属性（下記参照）は、BGP選択プロセスで直接使用されません。BGPネイバープロセスは、ローカル優先度を設定するルール、またはコミュニティ値が何らかのパターンマッチング基準に一致する場合に属性を設定する手動でプログラムされたルールに基づく別の要素を持つことができます。ルートが外部ピアから学習された場合、ネイバーごとのBGPプロセスは、ローカルポリシールールからローカル優先度値を計算し、ネイバーからのすべてのルートのローカル優先度を比較します。

BGPコミュニティは、共通の目的を達成するために受信または送信プレフィックスに適用できる属性タグです。^{[ 21 ]} BGPを使用すると、管理者がISPによるプレフィックスの処理方法に関するポリシーを設定できると言われることが多いですが、厳密に言えば、これは一般的には不可能です。たとえば、BGPには、あるASが別のASにプレフィックスの広告を北米のピアリング顧客のみに制限するように指示できる概念がネイティブにはありません。代わりに、ISPは通常、各コミュニティの説明とともに、よく知られているコミュニティまたは独自のコミュニティのリストを公開し、それが実質的にプレフィックスの処理方法に関する合意となります。

一般的なコミュニティの例としては、以下のようなものがあります。

• 地域ごとの嗜好調整、
• 地理的
• ピアタイプの制限
• サービス拒否攻撃の識別
• AS の先頭オプションを追加します。

ISPは、顧客から受信したルートについて、以下のような例を挙げて説明する場合があります。

• 北米（東海岸）のお客様へ 3491:100
• 北米（西海岸）のお客様へ 3491:200

顧客は各ルートに適切なコミュニティを含めるように設定を調整するだけでよく、ISP はプレフィックスを誰に通知するかを制御する責任を負います。エンド ユーザーはISP が正しいアクションを実行するように強制する技術的な能力はありませんが、この分野の問題は一般的にまれで偶発的なものです。^{[ 23 ] [ 24 ]}

エンドユーザーがMEDを使用する代わりにBGPコミュニティ（通常はASN:70,80,90,100）を使用して、ISPがアドバタイズするルートに割り当てるローカル優先度を制御するのは一般的な戦術です（効果は似ています）。コミュニティ属性は推移的ですが、顧客によって適用されたコミュニティがネクストホップASの外に伝播することは非常にまれです。すべてのISPがコミュニティを一般に公開しているわけではありません。^{[ 25 ]}

主要なBGP標準で定義されているMEDは、元々は、受信トラフィックに対して複数のリンクのうちどれを優先するかという、アドバタイズするASの優先順位を他の隣接ASに示すことを目的としていました。MEDのもう一つの用途は、IXPに存在する複数のASが、特定の宛先にトラフィックを送信する際に課す値（通常は遅延に基づく）をアドバタイズすることです。

Juniperなどの一部のルーターは、OSPFからのメトリックを使用してMEDを設定します。

Juniper SRXでBGPにエクスポートされる際にBGPで使用されるMEDの例

# show ospf routeを実行トポロジ default ルート テーブル:プレフィックス パス ルート NH メトリック ネクストホップ ネクストホップ  タイプ タイプ タイプ インターフェイス アドレス/LSP 10.32.37.0/24 インターネットワーク ディスカード IP 16777215 10.32.37.0/26 イントラネットワーク IP 101 ge-0/0/1.0 10.32.37.241 10.32.37.64/26 イントラネットワーク IP 102 ge-0/0/1.0 10.32.37.241 10.32.37.128/26 イントラネットワーク IP 101 ge-0/0/1.0 10.32.37.241# show route advertising-protocol bgp 10 .32.94.169  Prefix Nexthop MED Lclpref AS path * 10.32.37.0/24 Self 16777215 I * 10.32.37.0/26 Self 101 I * 10.32.37.64/26 Self 102 I * 10.32.37.128/26 Self 101 I

すべてのBGPメッセージは、以下のヘッダーレイアウトを共有します。

マーカー： 128ビット

互換性のために含まれています。すべて1に設定する必要があります。

長さ： 16ビット

ヘッダーを含めたメッセージ全体の長さ（オクテット単位）。

タイプ： 8ビット

BGPメッセージの種類。以下の値が定義されています。

• 開く（１）
• 更新（2）
• 通知（３）
• キープアライブ（4）
• ルート更新 (5)

Openパケットによって、BGPセッションが開始される可能性があります。

バージョン： 8ビット

使用されているBGPのバージョン。

私のAS : 16ビット

送信者の自律システム番号。

保持時間： 16ビット

タイムアウトタイマー。KeepAliveメッセージの計算に使用されます。デフォルト値は90秒です。

BGP識別子： 32ビット

送信者のIPアドレスを保持します。

パラメータの長さ： 8ビット

パラメータフィールドの全長（オクテット単位）。この（必須）^{[ 11 ]： §4.2}フィールドがゼロの場合、メッセージにパラメータはありません。

パラメータ：変数

オプションのパラメータ。このフィールドは、このパケットの送信者がピアに対して持つ機能を伝えるために使用されます。^{[ 33 ]}すべての機能のリストはIANAによって管理されています。

オープンメッセージの例

タイプ: オープンメッセージ (1) バージョン: 4 私のAS番号：64496 保持時間：90 BGP識別子: 192.0.2.254 オプションパラメータの長さ: 16 オプションパラメータ： 機能：マルチプロトコル拡張機能（1） 機能：ルート更新機能（2） 機能：ルート更新機能の強化（70）

変更点のみが送信されます。最初のやり取りの後は、相違点（追加／変更／削除）のみが送信されます。

取り下げられたルートの長さ： 16ビット

廃止されたルートの長さ。廃止されたルートがない場合はゼロになります。

撤回されたルート：変数

取り下げられたルートのリスト。<長さ、プレフィックス>のタプルのシリーズとして指定されます。

パス属性の合計長： 16ビット

後続のパス属性の長さ。属性がない場合はゼロになります。

パス属性：変数

パス属性のリスト。一連のTLV構造として指定されます。

ネットワーク層到達可能性情報 （NLRI）：変数

到達可能性情報は、<長さ、プレフィックス> タプルのシリーズとして指定されます。このフィールドの長さは、次のように計算できます。長さ- 23 -撤回されたルートの長さ-パス属性の合計長さ。

更新メッセージの例

タイプ: 更新メッセージ (2) 撤回されたルートの長さ: 0 パス属性の合計長: 25 パス属性 原産国: IGP AS_PATH: 64500 ネクストホップ: 192.0.2.254 マルチ出口ディスク: 0 ネットワーク層到達可能性情報（NLRI） 192.0.2.0/27 192.0.2.32/27 192.0.2.64/27

エラーが発生した場合、OPEN または UPDATE メッセージのいずれかのフィールドがピア間で一致しないことが原因です。たとえば、BGP バージョンの不一致、またはピアリング ルータが異なる「My AS」を期待している場合などです。ルータは、エラーが発生した理由を示す通知メッセージをピアに送信します。通信エラーは通常、BGP セッションの切断につながります。機能が制限されたルータを使用した複雑なシナリオでは、単一のエラーによってセッションが連鎖的に終了する可能性があるため、これを避けるために、問題を分離してほとんどのセッションを継続するための特別な努力が払われます。^{[ 34 ]}

エラーコード： 8ビット

エラーの種類または発生源を示す値。

エラーサブコード： 8ビット

発生したエラーの種類を示す値。

データ：変数

問題の診断に役立つオプションデータ。

通知メッセージの例

タイプ：通知メッセージ（3） 重大なエラーコード：OPENメッセージエラー（2） 軽微なエラーコード（オープンメッセージ）：不正なピアAS（2） 不良ピアAS: 65200

KeepAlive メッセージは、リモート ピアがまだアクティブであることを確認するために、セッションの両方のピアによって定期的に送信されます。これらは、セッションの 3 分の 1 の間隔で送信する必要がありますholdtime。

キープアライブパケットにはデータコンテンツは含まれません。

Adj-RIB-in初期の BGP メッセージ タイプに追加されたのが route-refresh で、接続をリセットせずにルートをソフトに更新できます。 ^{[ 35 ]}

この機能を使用する前に、「Open」メッセージで「ルート更新機能（2）」を指定する必要があります。「拡張ルート更新機能（70）」も指定すると、より詳細なルーティング更新を取得できます。

アドレスファミリ識別子 （AFI）： 16ビット

アドレスファミリー（IPv4、IPv6、IPX、AppleTalkなど）の識別子。このリストはIANAによって管理されています。

メッセージサブタイプ： 8ビット

このフィールドは、これがどのようなルート更新メッセージであるかを示します。^{[ 36 ]}

後続アドレスファミリ識別子： 8ビット

このフィールドは、属性に含まれるネットワーク層到達可能性情報（NLRI）の種類に関する追加情報を提供します。値：1（ユニキャスト）、2（マルチキャスト）、3（両方）。

ネットワーク層到達可能性情報 （NLRI）：変数

到達可能性情報は、<長さ、接頭辞>のタプルの系列として指定されます。

ROUTE-REFRESHメッセージの例

タイプ: ルート更新メッセージ (5) アドレスファミリ識別子（AFI）：IPv4（1） サブタイプ：通常のルート更新リクエスト（0） 後続アドレスファミリ識別子 (SAFI):ユニキャスト(1)

ルートリフレクタ（RR）は、AS で必要な接続数を削減します。単一のルータ（冗長性のために 2 つ）を RR にすることができます。AS 内の他のルータは、RR に対してピアとして構成するだけで済みます。RR は、iBGP の論理的なフルメッシュ要件の代替手段を提供します。RR の目的は集中です。複数の BGP ルータは、フルメッシュ内の他のすべてのルータとピアする代わりに、RR サーバとして機能する中央ポイントであるRRとピアすることができます。他のすべての iBGP ルータは RR クライアントになります。^{[ 38 ]}  

OSPFのDR/BDR機能と同様に、このアプローチは大規模ネットワークにiBGPのスケーラビリティを向上させます。10台のルーターで構成されるフルメッシュ型のiBGPネットワークでは、各ピアのリモートASを定義するためだけに、トポロジー内のすべてのルーターに分散された90個のCLIステートメントが必要になります。これはすぐに管理上の大きな負担となります。RRトポロジーでは、これらの90個のステートメントを18個に削減できるため、ISPが管理する大規模ネットワークにとって実行可能なソリューションとなります。

RRは単一障害点であるため、冗長性を確保するために少なくとも2台目のRRを設定する必要があります。これは他の10台のルータにとって追加のピアとなるため、CLIステートメントの数がほぼ2倍になり、この場合は11 × 2 − 2 = 20個のステートメントを追加で入力する必要があります。BGPマルチパス環境では、RRが専用のRRサーバの役割ではなく従来のルータとして動作する場合、追加のRRによってローカルルーティングのスループットが向上し、ネットワークにメリットをもたらすこともあります。

RRとコンフェデレーションはどちらも、各ルータへのiBGPピア数を削減し、処理オーバーヘッドを低減します。RRは純粋にパフォーマンス向上を目的とした手法ですが、コンフェデレーションはよりきめ細かなポリシーを実装するためにも使用できます。

ルール

RRサーバーは、以下のルールに基づいてAS内部でルートを伝播します。

• ルートは常にeBGPピアに反映されます。
• 経路情報は、経路の発信者には一切反映されません。
• 非クライアントピアからルートを受信した場合は、クライアントピアに反映させる。
• クライアントピアから経路を受信した場合は、クライアントピアと非クライアントピアの両方に反映させる。

コンフェデレーションは自律システムの集合です。一般的な運用では、^{[ 40 ]}コンフェデレーションのAS番号のうち1つだけがインターネット全体から認識されます。コンフェデレーションは、大規模なASが、より小さく管理しやすい内部ASを包含するように構成できる非常に大規模なネットワークで使用されます。

連合ASは複数のASで構成されます。各連合ASは単独でiBGPフルメッシュ接続を持ち、連合内の他のASと接続しています。これらのASは連合内のASとeBGPピア接続を持っていますが、ルーティング情報はiBGPを使用しているかのように交換されます。このようにして、連合はネクストホップ、メトリック、およびローカルプリファレンス情報を保持します。外部からは、連合は単一のASのように見えます。このソリューションにより、iBGPがすべてのBGPルータ間でフルメッシュ接続を必要とするために発生する、多数のTCPセッションとルーティングトラフィックの不要な重複といったiBGPトランジットASの問題を解決できます。

コンフェデレーションはルートリフレクタと組み合わせて使用​​できます。コンフェデレーションとルートリフレクタの両方は、BGPと内部ルーティングプロトコルの両方に影響を与える特定の設計ルールに従わない限り、継続的な振動の影響を受ける可能性があります。^{[ 41 ]}

これらの代替案には、以下のような独自の問題が生じる可能性がある。

• 経路振動
• 最適ではないルーティング
• BGP収束時間の増加^{[ 42 ]}

さらに、ルートリフレクタとBGPコンフェデレーションは、BGPルータの設定を容易にするために設計されたものではありません。しかしながら、これらは経験豊富なBGPネットワークアーキテクトにとって一般的なツールです。これらのツールは、例えばルートリフレクタの階層構造として組み合わせることができます。

2014年には、適切にアップデートされなかったモデルにおいて、Y2K問題に似たデータオーバーフローが発生した。

2014年8月時点の完全なIPv4 BGPテーブルでは(512k 日) ^{[ 47 ] [ 48 ]}は 512,000 プレフィックスを超えており、^{[ 49 ]多くの古いルーターには 512k (512,000–524,288) [ 50 ] [ 51 ]}ルーティング テーブル エントリの制限がありました。2014 年 8 月 12 日、テーブルがいっぱいになったことが原因で、eBay、LastPass、Microsoft Azureなどが障害に見舞われました。^{[ 52 ]}一般的に使用されている Cisco ルーターの多くは、BGP アドバタイズされたルートを保存するための、高速コンテンツ アドレス指定可能メモリの一種であるTCAM を備えていました。影響を受けたルーターでは、TCAM はデフォルトで 512k IPv4 ルートと 256k IPv6 ルートとして割り当てられていました。報告された IPv6 アドバタイズド ルートの数は約 20k に過ぎなかったが、アドバタイズされた IPv4 ルートの数はデフォルトの制限に達し、ルーターが (TCAM を介した高速なハードウェア ルーティングではなく) 低速なソフトウェア ルーティングを使用してこの問題を補償しようとしたため、スピルオーバー効果が発生した。この問題に対処する主な方法は、オペレーターが TCAM 割り当てを変更して、IPv6 ルート用に予約されている TCAM の一部を再割り当てすることで、より多くの IPv4 エントリを許可することであり、ほとんどのルーターで再起動が必要となる。512k の問題は、多くの IT プロフェッショナルによって予測されていた。^{[ 53 ] [ 54 ] [ 55 ]}

実際にルート数を 512k 以上に押し上げた割り当ては、UTC 7:48 から始まった約 15,000 の新しいルートの発表でした。これらのルートのほぼすべては、より大きなブロックのデアグリゲーションの結果として作成されたVerizon Autonomous Systems 701 と 705 宛てで、数千の新しい/ 24ルートが導入され、ルーティング テーブルが 515,000 エントリに達しました。新しいルートは 5 分以内に再集約されたようですが、インターネット全体で不安定な状態が数時間続いたようです。^{[ 56 ]} Verizon が短時間の急増でルーティング テーブルを 512k エントリ以上にしなかったとしても、自然な成長によってすぐにそうなったでしょう。

ルート集約は、BGP グローバルルーティングテーブルの集約を改善し、AS のルーターに必要なテーブルサイズを削減するためによく使用されます。AS1 に172.16.0.0 / 16という大きなアドレス空間が割り当てられているとします。これはテーブル内で 1 つのルートとしてカウントされますが、顧客の要件またはトラフィックエンジニアリングの目的で、AS1 は172.16.0.0 / 18、172.16.64.0 / 18、および172.16.128.0 / 18というより小さく具体的なルートをアナウンスしたいと考えています。プレフィックス172.16.192.0 / 18にはホストがないため、AS1 は特定のルート172.16.192.0 / 18をアナウンスしません。これらすべては、 AS1 が 4 つのルートをアナウンスしていることになります。

AS2 は AS1 からの 4 つのルート ( 172.16.0.0 / 16、172.16.0.0 / 18、172.16.64.0 / 18、および172.16.128.0 / 18 ) を認識し、4 つのルートのコピーを取得するか、または172.16.0.0 / 16が他のすべての特定のルートと重複するため、要約である 172.16.0.0 / 16 を保存するかは、AS2のルーティング ポリシーによって決定されます。

AS2がプレフィックス172.16.192.0/18宛てにデータを送信しようとする場合、データは経路172.16.0.0/16を経由してAS1のルーターに送信されます。AS1では、AS1のルーターの設定に応じて、データが破棄されるか、宛先到達不能ICMPメッセージが返送されます。

AS1 が後でルート172.16.0.0 / 16を削除し、172.16.0.0 / 18、172.16.64.0 / 18、および172.16.128.0 / 18を残すと、AS1 がアナウンスするルートの数は 3 つに減ります。AS2 のルーティング ポリシーによっては、3 つのルートのコピーを保存するか、172.16.0.0 / 18と172.16.64.0 / 18を172.16.0.0 / 17に集約し、AS2 が保存するルートの数を 2 つ ( 172.16.0.0 / 17と172.16.128.0 / 18 ) に減らします。

AS2 がプレフィックス172.16.192.0 / 18にデータを送信しようとすると、 172.16.192.0 / 18がルーティング テーブルに存在しないため、データは破棄されるか、宛先到達不能 ICMP メッセージが AS2 のルーター (以前のように AS1 ではなく) に返送されます。

1995年、最初のBGP-4仕様では、64,510個のパブリックAS番号を16ビットで符号化しました^{[ 10 ] 。 [ a ]} 2011年には、利用可能なAS番号はわずか15,000個しか残っておらず、予測^{[ 57 ]}では、2013年9月には利用可能なAS番号が完全に枯渇すると見込まれていました。

2007年には既にASコーディングが16ビットから32ビットに拡張され^{[ 58 ]} 、 16ビットAS範囲（0～65535）とその予約済みAS番号は維持されました。これにより、最大40億個のAS番号が使用可能になりました。追加のプライベートAS範囲も定義されています^{[ 59 ] [ b ]}これらの新しいASNを管理できないルータグループのトラバーサルを可能にするために、新しい属性AS4_PATH（オプションの推移的）と特別な16ビットASN AS_TRANS（AS23456）が使用されます^{[ 61 ]} 32ビットASNの割り当ては2007年に開始されました。

ルーティングテーブルの増加に寄与するもう1つの要因は、マルチホームネットワークの負荷分散の必要性です。BGPルート選択プロセスの制限により、マルチホームネットワークへの受信トラフィックを複数の受信パスに分散させることは容易ではありません。マルチホームネットワークがすべてのBGPピアに同じネットワークブロックを通知すると、外部ネットワークがすべてその混雑したパスのセットを最適として選択するため、受信リンクの1つまたは複数が混雑し、他のリンクは十分に利用されないままになる可能性があります。他のほとんどのルーティングプロトコルと同様に、BGPは混雑を検出しません。

この問題を回避するために、マルチホームネットワークのBGP管理者は、大きな連続IPアドレスブロックをより小さなブロックに分割し、ルートアナウンスを調整して、異なるブロックが異なるパス上で最適に見えるようにすることで、外部ネットワークがそのマルチホームネットワークの異なるブロックに到達するために異なるパスを選択するようにすることができます。このような場合、グローバルBGPテーブルに表示されるルートの数が増加します。

負荷分散に伴うルーティングテーブルの問題を解決する一つの方法は、インターネットエクスチェンジポイント内にBGP/LISP（Locator/Identifier Separation Protocol ）ゲートウェイを配置し、複数のリンク間で受信トラフィックのエンジニアリングを可能にすることです。この手法では、グローバルBGPテーブルに表示されるルート数は増加しません。