Loading article…
| 通信プロトコル | |
 BGP ステートマシン | |
| 略語 | GP-BGP とは |
|---|---|
| 目的 | インターネットプロトコルルーティング情報を交換する |
| 導入 | 1989年6月1日[1] |
| に基づく | インドGP |
| OSI層 | アプリケーション層 |
| ポート | 179番ポート |
| RFC(複数) | § 標準文書 |
ボーダーゲートウェイプロトコル（BGP）は、インターネット上の自律システム（AS）間でルーティングと到達可能性情報を交換するために設計された標準化された外部ゲートウェイプロトコルです。[2] BGPはパスベクトルルーティングプロトコルに分類され、[3]ネットワーク管理者によって設定されたパス、ネットワークポリシー、またはルールセットに基づいてルーティングの決定を行います。
自律システム内のルーティングに使用される BGP は、Interior Border Gateway Protocol ( iBGP ) と呼ばれます。対照的に、このプロトコルのインターネット アプリケーションはExterior Border Gateway Protocol ( EBGP ) と呼ばれます。
歴史
BGP の起源は 1989 年、Kirk Lougheed、Len Bosack、Yakov Rekhter がIETFカンファレンスで食事をしていたときでした。彼らは新しいルーティング プロトコルの概要をナプキンの裏にスケッチしたことで有名で、このことから「2 枚のナプキン プロトコル」と呼ばれることがよくあります。[4] [5] [6]
1989年にRFC 1105で初めて説明され、1994年からインターネットで使用されています。 [7] IPv6 BGPは1994年にRFC 1654で初めて定義され 、1998年にRFC 2283に改良されました。
BGP の現在のバージョンはバージョン 4 (BGP4) で、1994 年に RFC 1654 として最初に公開され、その後 1995 年にRFC 1771、2006年に RFC 4271によって更新されました。 [8] RFC 4271 では、エラーが修正され、あいまいさが明確になり、業界の一般的な慣行に合わせて仕様が更新されました。BGP4 の主な機能強化は、クラスレス ドメイン間ルーティング(CIDR)のサポートと、ルーティング テーブルのサイズを縮小するためのルート集約の使用です。RFC 4271 により、BGP4 はIPv4および IPv6の幅広い「アドレス ファミリ」を伝送できます。これは、マルチプロトコル拡張、つまりマルチプロトコル BGP (MP-BGP)とも呼ばれます。
手術
ピアと呼ばれるBGPネイバーは、ルータ間で手動設定によって確立され、ポート179でTCPセッションを作成します。BGPスピーカーは、接続を維持するために30秒ごとに19バイトのキープアライブメッセージを送信します（プロトコルのデフォルト値、調整可能）。[9]ルーティングプロトコルの中で、BGPはトランスポートプロトコルとしてTCPを使用する点で独特です。
BGP が同じ自律システム(AS) 内の 2 つのピア間で実行される場合、内部 BGP ( iBGPまたはInterior Border Gateway Protocol )と呼ばれます。異なる自律システム間で実行される場合、外部 BGP ( eBGPまたはExterior Border Gateway Protocol )と呼ばれます。ある AS の境界にあるルータが別の AS と情報を交換する場合、境界ルータまたはエッジ ルータ、あるいは単にeBGP ピアと呼ばれ、通常は直接接続されますが、iBGP ピアは他の中間ルータを介して相互接続できます。VPN トンネル内で eBGP ピアリングを実行するなど、他の展開トポロジも可能であり、 2 つのリモート サイトが安全かつ分離された方法でルーティング情報を交換できます。
iBGP ピアリングと eBGP ピアリングの主な違いは、1 つのピアから受信したルートが通常、デフォルトで他のピアに伝播される方法にあります。
- eBGP ピアから学習した新しいルートは、すべての iBGP および eBGP ピアに再アドバタイズされます。
- iBGP ピアから学習した新しいルートは、すべての eBGP ピアにのみ再アドバタイズされます。
これらのルート伝播ルールでは、AS 内のすべての iBGP ピアが iBGP セッションを使用してフル メッシュで相互接続されていることが事実上要求されます。
ルートの伝播方法は、ルートマップメカニズムによって詳細に制御できます。このメカニズムは、一連のルールで構成されています。各ルールは、特定の基準に一致するルートに対して、どのようなアクションを実行するかを説明します。アクションは、ルートを削除することや、ルートをルーティング テーブルに挿入する前にルートの一部の属性を変更することなどです。
延長交渉
ピアリング ハンドシェイク中に OPEN メッセージが交換されると、BGP スピーカーはセッションのオプション機能[10]をネゴシエートできます。これには、マルチプロトコル拡張[11]やさまざまな回復モードが含まれます。作成時に BGP のマルチプロトコル拡張がネゴシエートされると、BGP スピーカーは、アドバタイズするネットワーク層到達可能性情報 (NLRI) にアドレス ファミリ プレフィックスを付加できます。これらのファミリには、IPv4 (デフォルト)、IPv6、IPv4/IPv6 仮想プライベート ネットワーク、マルチキャスト BGP が含まれます。BGP は、VPN など、グローバル インターネットの一部ではない可能性のあるルートに関する情報を運ぶための汎用シグナリング プロトコルとしてますます使用されています。[12]
BGP ピアは、ピアとの操作を決定するために、Idle、Connect、Active、OpenSent、OpenConfirm、Established の 6 つの状態で構成される単純な有限状態マシン(FSM) を使用します。ピアツーピア セッションごとに、BGP 実装は、セッションがこれら 6 つの状態のどれであるかを追跡する状態変数を維持します。BGP は、セッションをある状態から別の状態に変更するために各ピアが交換する必要があるメッセージを定義します。
最初の状態はアイドル状態です。アイドル状態では、BGP はすべてのリソースを初期化し、すべての着信 BGP 接続試行を拒否し、ピアへの TCP 接続を開始します。2 番目の状態は接続です。接続状態では、ルータは TCP 接続が完了するまで待機し、成功した場合は OpenSent 状態に移行します。失敗した場合は、ConnectRetry タイマーを開始し、期限が切れると Active 状態に移行します。Active 状態では、ルータは ConnectRetry タイマーをゼロにリセットし、接続状態に戻ります。OpenSent 状態では、ルータは Open メッセージを送信し、OpenConfirm 状態に移行するために応答を待機します。Keepalive メッセージが交換され、正常に受信されると、ルータは Established 状態になります。Established 状態では、ルータはピアとの間で 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 構成エラー。
- ネットワークの混雑。
- ネットワーク インターフェイスのフラッピング。
- オープン送信状態:
- BGP FSM はピアからの Open メッセージをリッスンします。
- メッセージを受信すると、ルータは Open メッセージの有効性をチェックします。
- エラーが発生した場合、それは Open メッセージ内のフィールドの 1 つがピア間で一致しないためです (例: BGP バージョンの不一致、ピアリング ルータが異なる My AS を期待しているなど)。その後、ルータはエラーが発生した理由を示す通知メッセージをピアに送信します。
- エラーがなければ、Keepalive メッセージが送信され、さまざまなタイマーが設定され、状態が OpenConfirm に変更されます。
- オープン確認状態:
- ピアはピアからの Keepalive メッセージをリッスンしています。
- Keepalive メッセージが受信され、Keepalive の受信前にタイマーが期限切れになっていない場合、BGP は Established 状態に移行します。
- Keepalive メッセージが受信される前にタイマーが期限切れになった場合、またはエラー状態が発生した場合、ルータはアイドル状態に戻ります。
- 設立州:
- この状態では、ピアは更新メッセージを送信して、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保存し、RIB エントリに追加情報を付加することは非常に一般的です。追加情報は、個々のエントリが特定のネイバーのに属するかどうか、ピア ネイバー ルート選択プロセスによって受信ポリシーが に適格になったかどうか、エントリがローカル ルータのルーティング テーブル管理プロセスに送信できる
かどうかなどをBGP プロセスに伝えます。Adj-RIB-OutLoc-RIBAdj-RIBsLoc-RIBLoc-RIB
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 コミュニティは、共通の目標を達成するために着信または発信プレフィックスに適用できる属性タグです。[15] BGP では管理者が ISP によるプレフィックスの処理方法に関するポリシーを設定できるとよく言われますが、厳密に言えば、これは通常不可能です。たとえば、BGP には、ある AS が別の AS にプレフィックスの広告を北米のピアリング顧客のみに制限するように指示することを許可するという概念がネイティブにはありません。代わりに、ISP は通常、よく知られているコミュニティまたは独自のコミュニティのリストをそれぞれの説明とともに公開します。これは基本的に、プレフィックスの扱い方に関する合意になります。
一般的なコミュニティの例は次のとおりです。
- 地域的な嗜好の調整、
- 地理的
- ピアタイプの制限
- サービス拒否攻撃の識別
- AS 先頭付加オプション。
ISP は、顧客から受信したルートを次の例のように記述する場合があります。
- 北米（東海岸）のお客様へ 3491:100
- 北米（西海岸）のお客様へ 3491:200
顧客は各ルートに適切なコミュニティが含まれるように設定を調整するだけでよく、ISPはプレフィックスが誰にアドバタイズされるかを制御する責任を負います。エンドユーザーにはISPが正しい行動を取るように強制する技術的能力はありませんが、この分野での問題は一般的にまれで偶発的です。[17] [18]
エンド カスタマーが BGP コミュニティ (通常は ASN:70、80、90、100) を使用して、ISP が広告ルートに割り当てるローカル プリファレンスを制御するのは一般的な戦術です (効果は同様です)。コミュニティ属性は推移的ですが、カスタマーが適用したコミュニティがネクスト ホップ AS の外部に伝播することはほとんどありません。すべての ISP がコミュニティを公開しているわけではありません。[19]
BGP 拡張コミュニティ属性
BGP 拡張コミュニティ属性は、そのような属性の範囲を拡張し、タイプフィールドによって構造化されたコミュニティ属性を提供するために、2006 年に追加されました[20]。拡張された形式は、タイプフィールド用の 1 または 2 オクテットと、それに続くそれぞれのコミュニティ属性コンテンツ用の 7 または 6 オクテットで構成されます。この拡張コミュニティ属性の定義は、RFC 4360 で文書化されています。IANA は、BGP 拡張コミュニティ タイプのレジストリを管理しています[21]。拡張コミュニティ属性自体は、推移的なオプションの BGP 属性です。属性内のタイプ フィールドのビットによって、エンコードされた拡張コミュニティが推移的か非推移的かが決まります。したがって、IANA レジストリは、属性タイプに異なる数値範囲を提供します。拡張された属性範囲により、その使用法は多岐にわたります。 RFC 4360 では、「2オクテット AS 固有拡張コミュニティ」、「IPv4 アドレス固有拡張コミュニティ」、「不透明拡張コミュニティ」、「ルートターゲットコミュニティ」、および「ルートオリジンコミュニティ」が例示的に定義されています。多くの BGP QoS ドラフトでも、この拡張コミュニティ属性構造がドメイン間 QoS シグナリングに使用されています。[22]
32 ビット AS 番号の導入により、16 ビット ASN フィールドのみを定義するコミュニティ属性にいくつかの問題がすぐに明らかになりました。このため、このフィールドと実際の ASN 値が一致しません。RFC 7153 以降、拡張コミュニティは 32 ビット ASN と互換性があります。RFC 8092 および RFC 8195 では、12 バイトの Large Community 属性が導入され、4 バイトの 3 つのフィールド (AS: 機能: パラメータ) に分割されています。[23]
マルチ出口識別器
メインの BGP 標準で定義されている MED は、もともと、着信トラフィックに複数のリンクのうちどれが優先されるかについて、広告 AS の優先順位を別の隣接 AS に示すことを目的としていました。MED のもう 1 つの用途は、IXPに存在する複数の AS の値を、通常は遅延に基づいて広告し、トラフィックをある宛先に送信することです。
一部のルータ (Juniper など) は、OSPF からのメトリックを使用して MED を設定します。
Juniper SRX 上の BGP にエクスポートされたときに BGP で使用される MED の例
# show ospf routeを実行します。トポロジー デフォルト ルート テーブル:プレフィックス パス ルート 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
プレフィックス ネクストホップ MED Lclpref AS パス* 10.32.37.0/24 自己 16777215 I * 10.32.37.0/26 自己 101 I * 10.32.37.64/26 自己 102 I * 10.32.37.128/26 自己 101 I
パケットフォーマット
メッセージヘッダーの形式
- マーカー: 互換性のために含まれています。すべて 1 に設定する必要があります。
- 長さ: ヘッダーを含むメッセージの合計長（オクテット単位）。
- タイプ: BGP メッセージのタイプ。次の値が定義されています。
- 開く (1)
- アップデート (2)
- 通知 (3)
- キープアライブ (4)
- ルート更新 (5)
注: 例では「マーカー」と「長さ」は省略されています。
パケットを開く
- バージョン（8ビット）
- 使用される BGP のバージョン。
- 私のAS（16ビット）
- 送信者の自律システム番号。
- ホールドタイム（16ビット）
- KeepAlive メッセージの計算に使用されるタイムアウト タイマー。デフォルトは 90 秒です。
- BGP 識別子 (32 ビット)
- 送信者の IP アドレス。
- オプション パラメータの長さ (8 ビット): オプション パラメータ フィールドの合計長さ。
オープンメッセージの例
タイプ: オープンメッセージ (1)
バージョン: 4
私のAS: 64496
ホールド時間: 90
BGP 識別子: 192.0.2.254
オプションパラメータの長さ: 16
オプションパラメータ:
機能: マルチプロトコル拡張機能 (1)
機能: ルート更新機能 (2)
機能: ルート更新機能 (Cisco) (128)
アップデートパケット
変更のみが送信され、最初の交換後は、差異 (追加/変更/削除) のみが送信されます。
UPDATEメッセージの例
タイプ: 更新メッセージ (2) 撤回されたルートの長さ: 0 パス属性の合計長: 25 パス属性 起源: IGP 64500 のパス 次ホップ: 192.0.2.254 マルチエグジットディスク: 0 ネットワーク層到達可能性情報 (NLRI) 192.0.2.0/27 192.0.2.32/27 192.0.2.64/27
通知
エラーが発生した場合、それは OPEN または UPDATE メッセージ内のフィールドの 1 つがピア間で一致しないためです (例: BGP バージョンの不一致、ピアリング ルータが異なる My AS を期待しているなど)。その後、ルータはエラーが発生した理由を示す通知メッセージをピアに送信します。
NOTIFICATIONメッセージの例
タイプ: 通知メッセージ (3) 重大なエラー コード: OPEN メッセージ エラー (2) マイナー エラー コード (オープン メッセージ): 不正なピア AS (2) 不正なピア AS: 65200
キープアライブ
リモート ピアがまだ動作中であることを確認するために、KeepAlive メッセージが定期的に送信されます。keepalive は、時間の 3 分の 1 の間隔で送信する必要がありますholdtime。
KEEPALIVE メッセージの例
タイプ: KEEPALIVE メッセージ (4)
ルート更新
RFC 7313 で定義されています。
接続をリセットせずにのソフトアップデートを可能にしますAdj-RIB-in。
ROUTE-REFRESH メッセージの例
タイプ: ROUTE-REFRESH メッセージ (5) アドレスファミリ識別子（AFI）：IPv4（1） サブタイプ: ORFの有無にかかわらず通常のルート更新要求 [RFC2918] [RFC5291] (0) 後続アドレスファミリ識別子（SAFI）：ユニキャスト（1）
内部スケーラビリティ
BGPは「すべてのルーティングプロトコルの中で最もスケーラブルです。」[25]
内部 BGP (iBGP) を備えた自律システムでは、すべての iBGP ピアがフル メッシュ(全員が全員と直接通信する) で相互に接続している必要があります。このフル メッシュ構成では、各ルータが他のすべてのルータとのセッションを維持する必要があります。大規模なネットワークでは、この数のセッションによって、メモリ不足または CPU プロセス要件の高さにより、ルータのパフォーマンスが低下する可能性があります。
ルートリフレクタ
ルート リフレクタ(RR) は、AS で必要な接続数を削減します。1 台のルータ (または冗長性のために 2 台) を RR にすることができます。AS 内の他のルータは、それらのルータのピアとして設定するだけで済みます。RR は、iBGP の論理的なフル メッシュ要件の代替手段を提供します。RR の目的は集中です。複数の BGP ルータは、フル メッシュ内の他のすべてのルータとピアするのではなく、RR サーバーとして機能する中央ポイントとピアできます。他のすべての iBGP ルータは RR クライアントになります。[26]
このアプローチは、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 ピアに反映されます。
- ルートはルートの発信元に反映されることはありません。
- 非クライアント ピアからルートを受信した場合は、クライアント ピアに反映します。
- クライアント ピアからルートを受信した場合は、クライアント ピアと非クライアント ピアに反映します。
クラスタ
RR とそのクライアントはクラスタを形成します。クラスタ ID は、RR によってクライアントまたは非クライアント ピアにアドバタイズされるすべてのルートに付加されます。クラスタ ID は累積的で非推移的な BGP 属性であり、ルーティング ループを回避するために、すべての RR はクラスタ リストの先頭にローカル クラスタ ID を追加する必要があります。
連合
連合は自律システムの集合です。一般的な慣習では、[27]連合AS番号のうち1つだけがインターネット全体から見えます。連合は、大規模なASが、より小さく管理しやすい内部ASを包含するように構成できる非常に大規模なネットワークで使用されます。
連合 AS は複数の AS で構成されます。連合 AS はそれぞれ単独で iBGP が完全にメッシュ化されており、連合内の他の AS に接続されています。これらの AS は連合内の AS に対して eBGP ピアを持っていますが、AS は iBGP を使用しているかのようにルーティングを交換します。このようにして、連合はネクスト ホップ、メトリック、およびローカル プリファレンス情報を保持します。外部からは、連合は単一の AS のように見えます。このソリューションにより、iBGP ではすべての BGP ルーター間で完全なメッシュが必要になるため、iBGP トランジット AS の問題 (多数の TCP セッションとルーティング トラフィックの不要な重複) を解決できます。[説明が必要]
コンフェデレーションはルートリフレクタと組み合わせて使用できます。コンフェデレーションとルートリフレクタは、BGPと内部ルーティングプロトコルの両方に影響を与える特定の設計ルールに従わない限り、永続的な振動の影響を受ける可能性があります。[28]
これらの代替手段は、次のような独自の問題を引き起こす可能性があります。
- ルート振動
- 最適でないルーティング
- BGP収束時間の増加[29]
さらに、ルート リフレクタと BGP コンフェデレーションは、BGP ルータの設定を容易にするために設計されたものではありません。ただし、これらは経験豊富な BGP ネットワーク アーキテクトにとっては一般的なツールです。これらのツールは、たとえばルート リフレクタの階層として組み合わせることができます。
安定性
BGP 実装によって管理されるルーティング テーブルは、リンクやルータのダウンや復帰など、ネットワークの実際の変更を反映するために継続的に調整されます。ネットワーク全体では、これらの変更がほぼ継続的に発生するのが普通ですが、特定のルータまたはリンクでは、変更は比較的まれであることが予想されます。ルータが誤って構成または管理されている場合、ダウン状態とアップ状態の間を急速に循環する可能性があります。ルート フラッピングと呼ばれるこの繰り返しの撤回と再通知のパターンにより、同じルートがルーティング テーブルに継続的に挿入され、ルーティング テーブルから撤回されるため、循環エンティティを認識している他のすべてのルータで過度のアクティビティが発生する可能性があります。BGP の設計では、ルートの更新中はトラフィックの配信が機能しない可能性があります。インターネットでは、BGP ルーティングの変更により数分間停止することがあります。
ルート フラップ ダンピング( RFC 2439)と呼ばれる機能は 、ルート フラッピングの影響を軽減するために、多くの BGP 実装に組み込まれています。ダンピングがないと、過度のアクティビティによってルータの処理負荷が大きくなり、他のルートの更新が遅れて、ルーティング全体の安定性に影響する可能性があります。ダンピングを使用すると、ルートのフラッピングは指数関数的に減少します。ルートが使用できなくなり、すぐに再出現した最初のインスタンスでは、ダンピングは有効にならないため、BGP の通常のフェイルオーバー時間が維持されます。2 回目の発生では、BGP は一定期間そのプレフィックスを避けます。それ以降の発生は、指数関数的に長く無視されます。異常がなくなり、問題のあるルートに対して適切な時間が経過した後、プレフィックスをクリーンな状態で復元できます。ダンピングは、サービス拒否攻撃を軽減することもできます。
RFC 2439 : セクション 4 では、ルート フラップ ダンピングは、内部ボーダー ゲートウェイ プロトコル セッション (iBGP セッションまたは単に内部ピアと呼ばれる) ではなく、外部ボーダー ゲートウェイ プロトコル セッション (eBGP セッションまたは単に外部ピアと呼ばれる) に実装する方が望ましい機能であるとも示唆されています。このアプローチでは、自律システム内でルート フラップが発生しても、外部 AS には伝播されません。eBGP へのルート フラップにより、バックボーン全体で特定のルートのフラップ チェーンが発生します。この方法は、iBGP セッションのルート フラップ ダンピングのオーバーヘッドもうまく回避します。
その後の研究では、フラップ ダンピングは場合によっては収束時間を長くし、リンクがフラップしていない場合でも接続が中断する可能性があることが示されています。[30] [31]さらに、バックボーン リンクとルーター プロセッサが高速化するにつれて、ルーティング テーブルの変更はルーターによってはるかに高速に処理できるため、フラップ ダンピングは以前ほど重要ではない可能性があると示唆するネットワーク アーキテクトもいます。[32]このため、RIPE ルーティング ワーキング グループは、「現在の BGP フラップ ダンピングの実装では、ISP ネットワークでのフラップ ダンピングの適用は推奨されません。... フラップ ダンピングが実装されると、そのネットワークを運用する ISP は、顧客と、顧客のコンテンツやサービスのインターネット ユーザーに副作用を引き起こします... これらの副作用は、フラップ ダンピングをまったく実行しないことによって引き起こされる影響よりも悪くなる可能性が高いです。」と書いています。 [33]フラップ ダンピングの問題を回避して安定性を向上させることが、現在の研究の主題です。[34] [更新が必要]
ルーティングテーブルの増加
BGP、そしてインターネット インフラストラクチャ全体が直面している最大の問題の 1 つは、インターネット ルーティング テーブルの増加です。グローバル ルーティング テーブルが大きくなり、一部の旧式で能力の低いルーターがテーブルを維持するためのメモリ要件や CPU 負荷に対応できなくなると、これらのルーターは接続先のインターネット部分間の効果的なゲートウェイではなくなります。さらに、おそらくさらに重要な点として、ルーティング テーブルが大きくなると、接続が大幅に変更された後に安定するまでに時間がかかるため、その間、ネットワーク サービスが信頼できない、または利用できない状態になります。
2001 年後半まで、グローバル ルーティング テーブルは急激に増大し、最終的には広範囲にわたる接続の切断を招く恐れがありました。これを防ぐために、ISP は、クラスレス インタードメイン ルーティング(CIDR) とルート集約を使用して、グローバル ルーティング テーブルを可能な限り小さく保つことに協力しました。これにより、ルーティング テーブルの成長は数年間線形プロセスに減速しましたが、エンド ユーザー ネットワークによるマルチホーミングの需要が拡大したため、2004 年半ばまでに成長は再び超線形になりました。
512k日
適切に更新されなかったモデルでは、2014 年に Y2K のようなオーバーフローが発生しまし た。
2014年8月時点[update]（512k日）の完全なIPv4 BGPテーブル[35] [36]は512,000プレフィックスを超えていましたが、[37]多くの古いルーターではルーティングテーブルエントリが512k（512,000〜524,288） [38] [39]に制限されていました。2014年8月12日には、テーブルがいっぱいになったことによる機能停止により、eBay、LastPass、Microsoft Azureなどが影響を受けました。[40]一般的に使用されている多くのCiscoルーターには、BGPアドバタイズされたルートを保存するための高速コンテンツアドレス可能メモリの一種であるTCAMがありました。影響を受けたルーターでは、TCAMはデフォルトで512kのIPv4ルートと256kのIPv6ルートとして割り当てられていました。報告された IPv6 アドバタイズされたルートの数はわずか約 20k でしたが、アドバタイズされた IPv4 ルートの数はデフォルトの制限に達し、ルータが低速のソフトウェア ルーティング (TCAM 経由の高速ハードウェア ルーティングとは対照的) を使用して問題を補おうとしたため、スピルオーバー効果が発生しました。この問題に対処する主な方法は、オペレータが TCAM 割り当てを変更して、IPv6 ルート用に予約されている TCAM の一部を再割り当てすることにより、より多くの IPv4 エントリを許可することです。これには、ほとんどのルータで再起動が必要です。512k 問題は、多くの IT 専門家によって予測されていました。[41] [42] [43]
ルート数が 512k を超える原因となった実際の割り当ては、UTC 07:48 から短期間で約 15,000 の新しいルートが発表されたことでした。これらのルートのほとんどは、より大きなブロックのデアグリゲーションの結果として作成されたVerizon Autonomous Systems 701 および 705 へのルートであり、数千の新しい/ 24ルートが導入され、ルーティング テーブルのエントリが 515,000 に達しました。新しいルートは 5 分以内に再集約されたようですが、インターネット全体の不安定さは数時間続いたようです。[44] 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 ではない) に送り返されます。
AS 番号の枯渇と 32 ビット ASN
RFC 1771 BGP-4仕様では、AS番号を16ビットでコード化し、64,510のパブリックAS番号が可能になりました。[a] 2011年には、利用可能なAS番号は15,000個しかなく、予測[45]では、 2013年9月には利用可能なAS番号が完全に枯渇すると予想されていました。
RFC 6793 は AS コーディングを 16 ビットから 32 ビットに拡張し[b] 、現在では最大 40 億の AS が使用可能です。追加のプライベート AS 範囲も RFC 6996 で定義されています[c]。これらの新しい ASN を管理できないルータ グループのトラバーサルを可能にするために、新しい属性AS4_PATH (オプションの推移的) と特別な 16 ビット ASN AS_TRANS (AS23456) が使用されます[46]。32ビット ASN の割り当ては 2007 年に開始されました。
負荷分散
ルーティング テーブルが大きくなるもう 1 つの要因は、マルチホームネットワークの負荷分散の必要性です。BGP ルート選択プロセスの制限により、マルチホーム ネットワークへの着信トラフィックを複数の着信パスにわたって分散することは簡単な作業ではありません。マルチホーム ネットワークの場合、すべての BGP ピアに同じネットワーク ブロックを通知すると、外部ネットワークがすべてその輻輳したパスのセットを最適として選択したため、1 つまたは複数の着信リンクが輻輳し、他のリンクが十分に活用されないままになる可能性があります。他のほとんどのルーティング プロトコルと同様に、BGP は輻輳を検出しません。
この問題を回避するために、マルチホーム ネットワークの BGP 管理者は、連続した大きな IP アドレス ブロックを小さなブロックに分割し、ルート通知を微調整して、異なるブロックがさまざまなパスで最適に見えるようにし、外部ネットワークがマルチホーム ネットワークのさまざまなブロックに到達するために異なるパスを選択するようにします。このような場合、グローバル BGP テーブルに表示されるルートの数が増加します。
負荷分散に関連するルーティング テーブルの問題に対処する 1 つの方法は、インターネット エクスチェンジ ポイント内にLocator/Identifier Separation Protocol (BGP/LISP) ゲートウェイを導入して、複数のリンクにわたる入力トラフィック エンジニアリングを可能にすることです。この手法では、グローバル BGP テーブルに表示されるルートの数は増加しません。
安全
設計上、BGP を実行するルータは、デフォルトで他の BGP ルータから広告されたルートを受け入れます。これにより、インターネット上のトラフィックの自動的かつ分散的なルーティングが可能になりますが、同時に、インターネットは、BGP ハイジャックと呼ばれる偶発的または悪意のある中断に対して潜在的に脆弱になります。BGP がインターネットのコア システムに組み込まれている範囲と、インターネットを構成するさまざまな組織によって運営されているさまざまなネットワークの数を考えると、この脆弱性を修正することは (BGP ルータの ID を確認するための暗号化キーの使用を導入するなど)、技術的にも経済的にも困難な問題です。[47]
拡張機能
Multiprotocol Extensions for BGP (MBGP) は、マルチプロトコル BGP またはマルチキャスト BGP とも呼ばれ、RFC 4760 で定義されていますが、異なるタイプのアドレス (アドレス ファミリと呼ばれる) を並行して配布できるようにする BGP の拡張機能です。標準 BGP は IPv4 ユニキャスト アドレスのみをサポートしますが、マルチプロトコル BGP は IPv4 と IPv6 アドレスをサポートし、それぞれのユニキャストおよびマルチキャスト バリアントをサポートします。マルチプロトコル BGP を使用すると、IP マルチキャスト対応ルーターのトポロジに関する情報を、通常の IPv4 ユニキャスト ルーターのトポロジとは別に交換できます。したがって、ユニキャスト ルーティング トポロジとは異なるマルチキャスト ルーティング トポロジが可能になります。MBGP を使用するとドメイン間のマルチキャスト ルーティング情報を交換できますが、ツリーを構築してマルチキャスト トラフィックを転送するには、プロトコルに依存しないマルチキャスト ファミリなどの他のプロトコルが必要です。
マルチプロトコル BGP は、 MPLS L3 VPNの場合にも広く導入されており、他の顧客サイトからのトラフィックがルーティングのためにプロバイダー エッジ ルーターに到達したときに、異なる顧客サイトを区別するために、MPLS ネットワークを介して顧客サイトからのルートについて学習した VPN ラベルを交換します。
BGP のもう 1 つの拡張機能は、マルチパス ルーティングです。通常、これには同一の MED、重み、オリジン、および AS パスが必要ですが、一部の実装では、パス内の実際の AS 番号が一致することを期待するのではなく、等しいパス長のみを期待するように AS パス チェックを緩和する機能が提供されています。これは、個々のリンクで設定された帯域幅値に基づいてトラフィック共有の比率を有効にする Cisco の dmzlink-bw などの機能を使用してさらに拡張できます。
用途
BGP4 はインターネット ルーティングの標準であり、ほとんどのインターネット サービス プロバイダー(ISP) が相互にルーティングを確立するために必要とされます。非常に大規模なプライベートIP ネットワークでは、内部的に BGP を使用します。使用例の 1 つは、OSPF だけでは必要なサイズに拡張できない場合に、複数の大規模なOpen Shortest Path First (OSPF) ネットワークを結合することです。BGP を使用するもう 1 つの理由は、ネットワークをマルチホーミングして冗長性を高めることです。これは、複数のアクセス ポイントから単一の ISP または複数の ISP に行うことができます。
実装
ルーター、特に小規模オフィス/ホーム オフィス(SOHO)向けの小型ルーターには、BGP 機能が搭載されていない場合があります。その他の商用ルーターでは、BGP をサポートする特定のソフトウェア実行可能イメージ、または BGP を有効にするライセンスが必要になる場合があります。レイヤー 3 スイッチとして販売されているデバイスは、ルーターとして販売されているデバイスよりも BGP をサポートする可能性は低いですが、多くのハイエンドのレイヤー 3 スイッチは BGP を実行できます。
スイッチとして販売されている製品には、BGP テーブルのサイズ制限があり、インターネット テーブル全体と内部ルートの合計よりもはるかに小さい場合があります。これらのデバイスは、バックボーンの BGP バックボーンによってリンクされているいくつかの小規模企業の 1 つを表すコンフェデレーション AS や、ISP にルートをアナウンスするがデフォルト ルートと少数の集約ルートのみを受け入れる小規模企業など、ネットワークの小規模部分の BGP ルーティングに使用する場合は、まったく妥当で 便利です。
インターネットへの単一のエントリ ポイントを持つネットワークにのみ使用される BGP ルータは、マルチホーム ネットワークよりもルーティング テーブルのサイズがはるかに小さくなる場合があります (したがって、RAM と CPU の要件も小さくなります)。単純なマルチホームでも、ルーティング テーブルのサイズは適度になります。BGP ルータに必要な実際のメモリ量は、他の BGP スピーカーと交換される BGP 情報の量と、特定のルータが BGP 情報を格納する方法によって異なります。ルータは、ルートの複数のコピーを保持する必要がある場合があります。これにより、特定の近隣 AS へのルートのアドバタイズと受け入れに関するさまざまなポリシーを管理できます。ビューという用語は、実行中のルータ上のこれらのさまざまなポリシー関係を表すためによく使用されます。
あるルーターの実装が別の実装よりもルートごとに多くのメモリを必要とする場合、これは処理速度とメモリをトレードオフする正当な設計上の選択である可能性があります。2015 年 8 月の時点で、完全な IPv4 BGP テーブルは[update]590,000 を超えるプレフィックスを持っています。[37]大規模な ISP は、内部ルートと顧客ルートにさらに 50% を追加する場合があります。また、実装によっては、異なるピア AS の各ビューごとに別々のテーブルが保持される場合があります。
BGP の注目すべき無料およびオープンソースの実装には次のものがあります。
- BIRD は、Unix 系システム用のGPLルーティング パッケージです。
- FRRouting 、 Unix 系システム向けの Quagga のフォーク、およびその祖先:
- OpenBGPD は、OpenBSDチームによるBSD ライセンスの実装です。
- XORP は、BSD ライセンスのルーティング プロトコル スイートである eXtensible Open Router Platform です。
BGP の適合性、負荷、またはストレス パフォーマンスをテストするためのシステムは、次のようなベンダーから提供されています。
- アジレントテクノロジー
- GNS3オープンソースネットワーク シミュレーター
- イクシア
- スパイレント
参照
- 2021年のFacebookの障害 – Facebookが運営するすべてのサービスに影響する障害
- AS 7007 インシデント – 1997 年 4 月 25 日のインターネットの大規模な障害
- Internet Assigned Numbers Authority – IP アドレスを管理する標準化団体
- パケット転送 – あるネットワークセグメントから別のネットワークセグメントへのパケットの中継
- プライベートIP
- QPPB – トラフィックエンジニアリングメカニズム
- 地域インターネットレジストリ – ネットワーク番号の管理を担当する組織
- リソース公開鍵インフラストラクチャ – インターネットルーティングセキュリティフレームワーク
- ルートフィルタリング – 特定のネットワークルートを除外するプロセス
- ルーティング アセット データベース – インターネット ネットワークのルーティング レジストリ
注記
- ^ ASN 64512 から 65534 は私的使用のために予約されており、0 と 65535 は禁止されています。
- ^ 16 ビットの AS 範囲 0 ～ 65535 とその予約済み AS 番号は保持されます。
- ^ ASN 4200000000 から 4294967294 はプライベートであり、4294967295 は RFC 7300 によって禁止されています。
参考文献
- ^ 「rfc1105の履歴」。IETF。1989年6月。 2023年12月1日閲覧。
- ^ 「BGP: Border Gateway Protocol の説明」。Orbit -Computer Solutions.Com。2013年 9 月 28 日時点のオリジナルよりアーカイブ。2013 年 10 月 8 日閲覧。
- ^ ソブリーニョ、ジョアン・ルイス (2003)。 「パス ベクター プロトコルを使用したネットワーク ルーティング: 理論と応用」(PDF)。2010 年 7 月 14 日にオリジナルからアーカイブ(PDF)されました。2018 年3 月 16 日に取得。
- ^ Jabloner, Paula (2015-03-04). 「2枚のナプキンプロトコル」.コンピュータ歴史博物館. 2024年10月1日閲覧。
- ^ Jabloner, Paula (2020-07-02). 「2枚のナプキン プロトコル #WeAreCisco」. Cisco . 2024-10-01閲覧。
- ^ 「BGP - 2枚のナプキンの物語」(PDF)。The Packet。1 (2)。Cisco Systems。1989年。2024年10月1日閲覧。
- ^ 「Border Gateway Protocolの歴史」。blog.datapath.io。2020年10月29日時点のオリジナルよりアーカイブ。
- ^ ボーダーゲートウェイプロトコル4 (BGP-4 )。RFC 4271。
- ^ RFC 4274
- ^ R. Chandra; J. Scudder (2000 年 5 月). BGP-4 による機能広告. doi : 10.17487/RFC2842 . RFC 2842.
- ^ T. Bates; et al. (2000 年 6 月). BGP-4 のマルチプロトコル拡張. doi : 10.17487/RFC2858 . RFC 2858.
- ^ E. ローゼン; Y. レクター (2004 年 4 月)。 BGP/MPLS VPN。土井: 10.17487/RFC2547。RFC 2547。
- ^ 「 BGP最適パス選択アルゴリズム」。Cisco .com。
- ^ 「BGP パス選択について」Juniper .com。
- ^ RFC 1997
- ^ 「Border Gateway Protocol (BGP) の既知のコミュニティ」。www.iana.org 。2022 年 12 月 4 日閲覧。
- ^ 「BGP コミュニティ サポート | iFog GmbH」。ifog.ch。2022年 12 月 4 日閲覧。
- ^ 「BGPコミュニティ」。retn.net 。 2022年12月4日閲覧。
- ^ 「BGP コミュニティ ガイド」 。2015年4 月 13 日閲覧。
- ^ RFC 4360
- ^ 「Border Gateway Protocol (BGP) 拡張コミュニティ」www.iana.org . 2022年12月4日閲覧。
- ^ BGP シグナリング QoS に関する IETF ドラフト Archived 2009-02-23 at the Wayback Machine、Thomas Knoll、2008
- ^ 「Large BGP Communities」. 2021年11月27日閲覧。
- ^ Y. Rekhter、T. Li、S. Hares 編 (2006 年 1 月)。ボーダー ゲートウェイ プロトコル 4 (BGP-4)。ネットワーク ワーキング グループ。doi : 10.17487/ RFC4271。RFC 4271 。 ドラフト規格。第4.1項。
- ^ 「ボーダーゲートウェイプロトコル (BGP)」。Cisco .com。
- ^ T. Bates 他 (2006 年 4 月)。BGPルート リフレクション: フル メッシュ内部 BGP ( iBGP ) の代替。RFC 4456。
- ^ 「Info」。www.ietf.org 。 2019年12月17日閲覧。
- ^ 「Info」。www.ietf.org 。 2019年12月17日閲覧。
- ^ 「Info」。www.ietf.org 。 2019年12月17日閲覧。
- ^ 「ルートフラップダンピングがインターネットルーティングの収束を悪化させる」(PDF) 。1998年11月。 2022年10月9日時点のオリジナルよりアーカイブ(PDF) 。
- ^ Zhang, Beichuan; Pei Dan; Daniel Massey; Lixia Zhang (2005 年 6 月)。「ルート フラップ ダンピングにおけるタイマーの相互作用」(PDF)。IEEE 25th International Conference on Distributed Computing Systems。2006年 9 月 26 日取得。
現在のダンピング設計では、ルート フラップが持続する場合にのみ意図した動作が得られることが示されています。フラップの数が少ない場合、グローバル ルーティング ダイナミクスは、収束遅延が長くなり、予想される動作から大幅に逸脱します。
- ^ Villamizar, Curtis; Chandra, Ravi; Govindan, Ramesh (1998 年 11 月)。「BGP ルート フラップ ダンピング」。IETFデータトラッカー。Tools.ietf.org。
- ^ 「RIPE ルーティングワーキンググループによるルートフラップダンピングに関する推奨事項」。RIPE ネットワークコーディネーションセンター。2006 年 5 月 10 日。2013年 12 月 4 日閲覧。
- ^ 「draft-ymbk-rfd-usable-02 - ルートフラップダンピングを使用可能にする」。Ietf Datatracker。Tools.ietf.org 。 2013年12月4日閲覧。
- ^ 「CAT 6500 および 7600 シリーズ ルータおよびスイッチの TCAM 割り当て調整手順」。Cisco。
- ^ Cowie, Jim (2014 年 8 月 13 日). 「インターネットが 50 万ルートに及ぶ: 来週にはサービス停止の可能性も」renesys.com。2014 年 8 月 13 日時点のオリジナルよりアーカイブ。
- ^ ab 「BGP レポート」。potaroo.net。
- ^ 「 CAT 6500 および 7600 シリーズ ルータおよびスイッチの TCAM 割り当て調整手順」。Cisco。2015年 3 月 9 日。
- ^ Jim Cowie. 「インターネットが半百万ルートに到達: 来週にはサービス停止の可能性も」Dyn Research。2014 年 8 月 17 日時点のオリジナルよりアーカイブ。2015年 1 月 2 日閲覧。
- ^ ガーサイド、ジュリエット、ギブス、サミュエル（2014年8月14日）。「インターネットインフラはアップデートが必要、さもなければ停電がさらに増える」。ガーディアン。 2014年8月15日閲覧。
- ^ 「BOFレポート」(PDF) . www.nanog.org. 2022年10月9日時点のオリジナルよりアーカイブ(PDF) . 2019年12月17日閲覧。
- ^ Greg Ferro (2011 年 1 月 26 日). 「TCAM — より詳しい考察と IPv6 の影響」EtherealMind。
- ^ 「IPv4 枯渇サイト」ipv4depletion.com。
- ^ 「今日のインターネットの不具合の原因は何だったのか」bgpmon.net。
- ^ 16 ビット自律システムレポート、Geoff Huston 2011 (オリジナルは https://web.archive.org/web/20110906085724/http://www.potaroo.net/tools/asn16/ にアーカイブされています)
- ^ Vohra , Quaizar; Chen, Enke (2007 年 5 月). 4 オクテット AS 番号空間に対する BGP サポート。IETF。doi : 10.17487 / RFC4893。RFC 4893 。
- ^ Craig Timberg (2015-05-31). 「初期のインターネット問題に対する迅速な解決策は、25年経っても生き続ける」ワシントンポスト。 2015年6月1日閲覧。
- ^ 「Zebra - GNU プロジェクト - フリーソフトウェア財団」。
さらに読む
- 「Border Gateway Protocol (BGP)」、IOS テクノロジー ハンドブック、Cisco Systems、2011 年 7 月 8 日にオリジナルからアーカイブ
標準文書
- RFC 1772、SMIv2 を使用したインターネット プロトコル (BGP-4) でのボーダー ゲートウェイ プロトコルの適用
- RFC 1997、BGP コミュニティ属性
- RFC 2439、BGP ルート フラップ ダンピング
- RFC 2918、BGP-4 のルート更新機能
- RFC 3765、ボーダー ゲートウェイ プロトコル (BGP) ルート スコープ制御の NOPEER コミュニティ
- RFC 4271、ボーダーゲートウェイプロトコル 4 (BGP-4)
- RFC 4272、BGP セキュリティ脆弱性分析
- RFC 4273、BGP-4 の管理オブジェクトの定義
- RFC 4274、BGP-4 プロトコル分析
- RFC 4275、BGP-4 MIB 実装調査
- RFC 4276、BGP-4 実装レポート
- RFC 4277、BGP-4 プロトコルの経験
- RFC 4278、TCP MD5 署名オプション (RFC 2385) と BGP-4 仕様に関する標準の成熟度の差異
- RFC 4360、BGP 拡張コミュニティ属性
- RFC 4456、BGP ルート リフレクション – フル メッシュ内部 BGP (iBGP) の代替
- RFC 4724、BGP のグレースフル リスタート メカニズム
- RFC 4760、BGP-4 のマルチプロトコル拡張
- RFC 5065、BGP の自律システム連合
- RFC 5492、BGP-4 による機能広告
- RFC 5701、IPv6 アドレス固有の BGP 拡張コミュニティ属性
- RFC 6793、4オクテットの自律システム (AS) 番号空間に対する BGP サポート
- RFC 7153、BGP 拡張コミュニティの IANA レジストリ
- RFC 7606、BGP UPDATE メッセージのエラー処理の改訂
- RFC 7911、BGP における複数パスの広告
- RFC 8092、BGP 大規模コミュニティ属性
- RFC 8195、BGP 大規模コミュニティの使用
- RFC 8642、よく知られた BGP コミュニティのポリシー動作
- RFC 8955、フロー仕様ルールの普及
- RFC 9552、BGP を使用したリンク状態およびトラフィック エンジニアリング情報の配布
- BGP カスタム決定プロセス、IETF ドラフト、2017 年 2 月 3 日
- BGP の選択的ルート更新、IETF ドラフト、2015 年 11 月 7 日
- RFC 1105、廃止 – ボーダー ゲートウェイ プロトコル (BGP)
- RFC 1654、廃止 – ボーダー ゲートウェイ プロトコル 4 (BGP-4)
- RFC 1655、廃止 – インターネットにおけるボーダーゲートウェイプロトコルの適用
- RFC 1657、廃止 – ボーダーゲートウェイの第 4 バージョンの管理オブジェクトの定義
- RFC 1771、廃止 – ボーダー ゲートウェイ プロトコル 4 (BGP-4)
- RFC 1965、廃止 – BGP の自律システム連合
- RFC 2796、廃止 – BGP ルート リフレクション – フル メッシュ iBGP の代替
- RFC 2858、廃止 – BGP-4 のマルチプロトコル拡張
- RFC 3065、廃止 – BGP の自律システム連合
- RFC 3392、廃止 – BGP-4 による機能広告
- RFC 4893、廃止 – 4オクテットの AS 番号空間に対する BGP サポート
外部リンク
- BGP ルーティング リソース (BGP と ISP コア セキュリティに関する専用セクションを含む)
- BGP テーブル統計