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

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

ボーダーゲートウェイプロトコルBGP )は、インターネット上の自律システム(AS)間でルーティングおよび到達可能性情報を交換するために設計された標準化された外部ゲートウェイプロトコルです[2] BGPは、パスベクトルルーティングプロトコル[3]として分類され、ネットワーク管理者によって構成されたパス、ネットワークポリシー、またはルールセットに基づいてルーティングを決定ます

自律システム内のルーティングに使用されるBGPは、Interior Border Gateway ProtocolInternal BGPiBGP)と呼ばれます。対照的に、このプロトコルのインターネットアプリケーションは、Exterior Border Gateway ProtocolExternal BGPeBGP)と呼ばれます。

歴史

ボーダーゲートウェイプロトコルは、1989年にRFC 1105で最初に記述され、1994年からインターネットで使用されています。[4] IPv6 BGPは、1994年にRFC  1654で最初に定義され、1998年に RFC2283に改善されまし た。

BGPの現在のバージョンはバージョン4(BGP4)であり、2006年にRFC4271として公開されました。[5] RFC 4271はエラーを修正し、あいまいさを明確にし、一般的な業界慣行で仕様を更新しました。主な機能強化は、クラスレスドメイン間ルーティング(CIDR)のサポートと、ルーティングテーブルのサイズを減らすためのルート集約の使用でした。新しいRFCにより、BGP4は幅広いIPv4およびIPv6「アドレスファミリ」を伝送できます。マルチプロトコルBGP(MP-BGP)であるマルチプロトコル拡張とも呼ばれます。

操作

ピアと呼ばれるBGPネイバーは、ルータ間の手動設定によって確立され、ポート179でTCPセッションを作成します。BGPスピーカーは、接続を維持するために30秒ごとに19バイトのキープアライブメッセージ(プロトコルのデフォルト値、調整可能)を送信します。[6]ルーティングプロトコルの中で、BGPはトランスポートプロトコルとしてTCPを使用する点で独特です。

BGPが同じ自律システム(AS)内の2つのピア間で実行される場合、内部BGPiBGPまたはInterior Border Gateway Protocol)と呼ばれます。異なる自律システム間で実行される場合、外部BGPeBGPまたはExterior Border Gateway Protocol)と呼ばれます。あるASの境界にある別のASと情報を交換するルーターは、ボーダールーターまたはエッジルーターまたは単にeBGPピアと呼ばれ、通常は直接接続されますが、iBGPピアは他の中間ルーターを介して相互接続できます。その他の展開トポロジVPNトンネル内でeBGPピアリングを実行するなど、2つのリモートサイトが安全で分離された方法でルーティング情報を交換できるようにすることも可能です。

iBGPピアリングとeBGPピアリングの主な違いは、あるピアから受信したルートが、通常、デフォルトで他のピアに伝播される方法にあります。

  • eBGPピアから学習した新しいルートは、すべてのiBGPおよびeBGPピアに再アドバタイズされます。
  • iBGPピアから学習した新しいルートは、すべてのeBGPピアにのみ再アドバタイズされます。

これらのルート伝播ルールでは、AS内のすべてのiBGPピアがiBGPセッションとフルメッシュで相互接続されている必要があります。

ルートの伝播方法は、ルートマップメカニズムを介して詳細に制御できます。このメカニズムは、一連のルールで構成されています。各ルールは、特定の基準に一致するルートについて、実行する必要のあるアクションを記述します。アクションは、ルートを削除することでも、ルーティングテーブルに挿入する前にルートの一部の属性を変更することでもかまいません。

拡張機能のネゴシエーション

BGPステートマシン

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

ピアとの動作を決定するために、BGPピアは6つの状態で構成される単純な有限状態マシン(FSM)を使用します。接続; アクティブ; OpenSent; OpenConfirm; と確立されました。ピアツーピアセッションごとに、BGP実装は、セッションがこれら6つの状態のどれにあるかを追跡する状態変数を維持します。BGPは、セッションをある状態から別の状態に変更するために各ピアが交換する必要があるメッセージを定義します。

最初の状態はアイドル状態です。アイドル状態では、BGPはすべてのリソースを初期化し、すべてのインバウンドBGP接続の試行を拒否し、ピアへのTCP接続を開始します。2番目の状態は接続です。接続状態では、ルーターはTCP接続が完了するのを待ち、成功するとOpenSent状態に移行します。失敗した場合は、ConnectRetryタイマーを開始し、有効期限が切れるとアクティブ状態に移行します。アクティブ状態では、ルータはConnectRetryタイマーをゼロにリセットし、接続状態に戻ります。OpenSent状態では、ルーターはOpenメッセージを送信し、OpenConfirm状態に移行するためにメッセージが返されるのを待ちます。キープアライブメッセージが交換され、正常に受信されると、ルータは確立済み状態になります。確立された状態では、ルータは以下を送受信できます。キープアライブ。アップデート;

  • アイドル状態
    • すべての着信BGP接続を拒否します。
    • イベントトリガーの初期化を開始します。
    • 設定されたBGPピアとのTCP接続を開始します。
    • ピアからのTCP接続をリッスンします。
    • 状態をConnectに変更します。
    • 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メッセージのフィールドの1つがピア間で一致していないためです。たとえば、BGPバージョンの不一致、ピアリングルータは異なるMy ASを予期しているなどです。次に、ルータは通知メッセージをピアに送信します。エラーが発生した理由を示します。
    • エラーがない場合は、キープアライブメッセージが送信され、さまざまなタイマーが設定され、状態がOpenConfirmに変更されます。
  • OpenConfirm状態
    • ピアは、ピアからのキープアライブメッセージをリッスンしています。
    • キープアライブメッセージを受信し、キープアライブを受信する前にタイマーの期限が切れていない場合、BGPは確立済み状態に移行します。
    • キープアライブメッセージを受信する前にタイマーが期限切れになった場合、またはエラー状態が発生した場合、ルータはアイドル状態に戻ります。
  • 確立された状態
    • この状態では、ピアは更新メッセージを送信して、BGPピアにアドバタイズされている各ルートに関する情報を交換します。
    • 更新メッセージにエラーがある場合、通知メッセージがピアに送信され、BGPはアイドル状態に戻ります。

ルーターの接続と学習ルート

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

特定のBGPルーターは、複数のネイバーからのネットワークレイヤー到達可能性情報(NLRI)UPDATEを受け入れ、NLRIを同じまたは異なるネイバーのセットにアドバタイズする場合があります。概念的には、BGPは、ルータのメインルーティングテーブルとは別に、ローカルルーティング情報ベース(Loc-RIB)と呼ばれる独自のマスタールーティングテーブルを維持します。ネイバーごとに、BGPプロセスは、概念的な隣接ルーティング情報ベース、ネイバーから受信したNLRIを含む着信(Adj-RIB-In)、およびNLRIを送信する概念的な発信情報ベース(Adj-RIB-Out)を維持します。隣人。

これらの概念テーブルの物理ストレージと構造は、BGPコードの実装者によって決定されます。それらの構造は他のBGPルーターには表示されませんが、通常はローカルルーターの管理コマンドで問い合わせることができます。たとえば、2つのAdj-RIBとLoc-RIBを同じデータ構造に一緒に格納し、RIBエントリに追加情報を添付することは非常に一般的です。追加情報は、個々のエントリが特定のネイバーのAdj-RIBに属しているかどうか、ピアネイバールート選択プロセスが受信したポリシーをLoc-RIBに適格にするかどうか、Loc-RIBエントリが適格かどうかなどのBGPプロセスに通知します。ローカルルーターのルーティングテーブル管理プロセスに送信されます。

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

最近まで、「BGPにはポリシーがあります」と言うのはよくある間違いでした。BGPは、BGPを話すルーター内のルールがポリシー決定を行うための情報を実際に伝達していました。ポリシーの決定に使用することを明示的に意図した情報の一部は、コミュニティと複数出口弁別子(MED)です。

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以外の送信元からその宛先へのルートがない場合、撤回されたルートはメインルーティングテーブルから削除されます。

ネクストホップが到達可能であることを確認した後、ルートが内部(つまり、iBGP)ピアからのものである場合、標準に従って適用する最初のルールは、LOCAL_PREFERENCE属性を調べることです。ネイバーからのiBGPルートが複数ある場合、同じLOCAL_PREFERENCEを持つルートが複数ない限り、LOCAL_PREFERENCEが最も高いルートが選択されます。後者の場合、ルート選択プロセスは次のタイブレーカーに移動します。LOCAL_PREFERENCEは標準の最初のルールですが、NEXT_HOPの到達可能性が確認されると、シスコと他のいくつかのベンダーは、最初に、ルータにローカルな(つまり、BGPによって送信されない)WEIGHTと呼ばれる決定要因を検討します。重量が最も高いルートが優先されます。

LOCAL_PREFERENCE、WEIGHT、およびその他の基準は、ローカル構成およびソフトウェア機能によって操作できます。このような操作は、一般的に使用されていますが、標準の範囲外です。たとえば、COMMUNITY属性(以下を参照)は、BGP選択プロセスによって直接使用されません。ただし、BGPネイバープロセスには、LOCAL_PREFERENCEを設定するルール、またはCOMMUNITY値がパターン一致基準に一致する場合に属性を設定するために、手動でプログラムされたルールに基づく別の要素を含めることができます。ルートが外部ピアから学習された場合、ネイバーごとのBGPプロセスは、ローカルポリシールールからLOCAL_PREFERENCE値を計算し、ネイバーからのすべてのルートのLOCAL_PREFERENCEを比較します。

ネイバーごとのレベル(実装固有のポリシー修飾子を無視)では、タイブレークルールの順序は次のとおりです。

  1. AS_PATHが最も短いルートを優先します。AS_PATHは、アドバタイズされた宛先に到達するためにトラバースする必要があるAS番号のセットです。AS1-AS2-AS3はAS4-AS5-AS6-AS7よりも短いです。
  2. ORIGIN属性の値が最も低いルートを優先します。
  3. MULTI_EXIT_DISC(複数出口弁別器またはMED)値が最も低いルートを優先します。[a]

候補ルートがネイバーから受信されると、Loc-RIBソフトウェアは、同じ宛先へのルートに追加のタイブレーカーを適用します。

  1. 少なくとも1つのルートが外部ネイバーから学習された場合(つまり、ルートがeBGPから学習された場合)、iBGPから学習されたすべてのルートをドロップします。
  2. メインのルーティングテーブルによると、内部コストが最も低いルートをNEXT_HOPよりも優先します。2つのネイバーが同じルートをアドバタイズしたが、一方のネイバーは低ビットレートリンクを介して到達可能であり、もう一方は高ビットレートリンクを介して到達可能であり、内部ルーティングプロトコルが最高ビットレートに基づいて最低コストを計算する場合、高ビットレートリンクを経由するルート優先され、他のルートは削除されます。
この時点でまだ複数のルートが結び付けられている場合、いくつかのBGP実装は、ルート間でロードシェアするための構成可能なオプションを提供し、すべて(またはすべてをいくつかまで)受け入れます。
  1. 数値的に最小のBGP識別子を持つBGPスピーカーから学習したルートを優先します
  2. ピアIPアドレスが最も低いBGPスピーカーから学習したルートを優先します

コミュニティ

BGPコミュニティは、いくつかの共通の目標を達成するために着信または発信プレフィックスに適用できる属性タグです。[10]BGPを使用すると、管理者はISPによるプレフィックスの処理方法に関するポリシーを設定できるとよく言われますが、厳密に言えば、これは一般的に不可能です。たとえば、BGPには、あるASが別のASにプレフィックスのアドバタイズメントを北米のピアリング顧客のみに制限するように指示できるようにするという概念がネイティブにありません。代わりに、ISPは通常、よく知られているコミュニティまたは独自のコミュニティのリストを、それぞれの説明とともに公開します。これは、基本的に、プレフィックスの処理方法に関する合意になります。RFC 1997は、グローバルに重要な3つの有名なコミュニティを定義しています。NO_EXPORT、NO_ADVERTISE、およびNO_EXPORT_SUBCONFED。RFC 7611は、ACCEPT_OWNを定義しています。一般的なコミュニティの例には、地域の好みの調整、地理的またはピアタイプの制限、サービス拒否攻撃が含まれます識別、およびAS付加オプション。ISPは、コミュニティXXX:500の顧客から受信したルートはすべてのピアにアドバタイズされ(デフォルト)、コミュニティXXX:501は北米にのみアドバタイズされると述べている場合があります。カスタマーは、ルートごとに正しいコミュニティを含めるように構成を調整するだけで、ISPはプレフィックスのアドバタイズ先を制御する責任があります。エンドユーザーには、ISPによって実行されている正しいアクションを強制する技術的能力はありませんが、この領域での問題は一般にまれで偶発的です。

エンドカスタマーがBGPコミュニティ(通常はASN:70,80,90,100)を使用して、MEDを使用する代わりにISPがアドバタイズされたルートに割り当てるローカルプリファレンスを制御することは一般的な戦術です(効果は同様です)。コミュニティ属性は推移的ですが、顧客によって適用されたコミュニティがネクストホップASの外部に伝播することはめったにありません。すべてのISPがコミュニティを一般に公開しているわけではありません。[11]

このような属性の範囲を拡張し、タイプフィールドを使用してコミュニティ属性の構造化を提供するために、BGP拡張コミュニティ属性が2006年に追加されました。拡張フォーマットは、タイプフィールド用の1つまたは2つのオクテットと、それに続くそれぞれのコミュニティ属性コンテンツ用の7つまたは6つのオクテットで構成されます。この拡張コミュニティ属性の定義はRFC4360に文書化されています。IANAはBGP拡張コミュニティタイプのレジストリを管理します。[12]拡張コミュニティ属性自体は、推移的なオプションのBGP属性です。ただし、属性内のtypeフィールドのビットによって、エンコードされた拡張コミュニティが推移的であるか非推移的であるかが決まります。したがって、IANAレジストリは、属性タイプに対して異なる番号範囲を提供します。属性範囲が拡張されているため、その使用法は多岐にわたる可能性があります。RFC 4360は、「2オクテットAS固有の拡張コミュニティ」、「IPv4アドレス固有の拡張コミュニティ」、「不透明な拡張コミュニティ」、「ルートターゲットコミュニティ」、および「ルートオリジンコミュニティ」を例示的に定義しています。多くのBGPQoSドラフトも、ドメイン間QoSシグナリングにこの拡張コミュニティ属性構造を使用しています。[13]

32ビットAS番号の導入により、16ビットASNフィールドのみを定義するコミュニティ属性でいくつかの問題がすぐに明らかになりました。これにより、このフィールドと実際のASN値との一致が妨げられます。RFC 7153以降、拡張コミュニティは32ビットASNと互換性があります。RFC8092およびRFC8195は、それぞれ4バイトの3つのフィールド(AS:function:parameter)に分割された12バイトのLargeCommunity属性を導入しています。[14]

複数出口弁別器

メインのBGP標準で定義されているMEDは、元々、いくつかのリンクのどれがインバウンドトラフィックに優先されるかについて、アドバタイズするASの優先順位を別のネイバーASに示すことを目的としていました。MEDの別のアプリケーションは、 IXPに存在する複数のASの値を、通常は遅延に基づいてアドバタイズすることです。これらのASは、トラフィックを特定の宛先に送信するために課します。

メッセージヘッダー形式

BGPバージョン4メッセージヘッダーフォーマット[15]
ビットオフセット 0〜15 16〜23 24〜31
0 マーカー
32
64
96
128 長さ タイプ
  • マーカー:互換性のために含まれています。すべてのものに設定する必要があります。
  • 長さ:ヘッダーを含む、オクテット単位のメッセージの全長。
  • タイプ:BGPメッセージのタイプ。次の値が定義されています。
    • 開く(1)
    • アップデート(2)
    • 通知(3)
    • キープアライブ(4)
    • ルートリフレッシュ(5)

内部スケーラビリティ

BGPは、「すべてのルーティングプロトコルの中で最もスケーラブル」です。[16]

内部BGP(iBGP)を備えた自律システムでは、すべてのiBGPピアがフルメッシュで相互に接続されている必要があります(全員が直接全員と話します)。このフルメッシュ構成では、各ルーターが他のすべてのルーターとのセッションを維持する必要があります。大規模なネットワークでは、この数のセッションは、メモリの不足または高いCPUプロセス要件のために、ルーターのパフォーマンスを低下させる可能性があります。

ルートリフレクター

ルートリフレクター[17]は、ASで必要な接続の数を減らします。単一のルーター(または冗長性のために2つ)をルートリフレクターにすることができます。AS内の他のルーターは、それらのピアとして構成するだけで済みます。ルートリフレクタは、内部ボーダーゲートウェイプロトコル(IBGP)の論理的なフルメッシュ要件に代わるものを提供します。RRは、IBGPセッションのフォーカルポイントとして機能します[明確化] 。RRの目的は集中力です。複数のBGPルーターは、フルメッシュ内の他のすべてのルーターとピアリングするのではなく、ルートリフレクターサーバーとして機能する中央ポイントであるRRとピアリングできます。他のすべてのIBGPルーターは、ルートリフレクタークライアントになります。

このアプローチは、OSPFのDR / BDR機能と同様に、大規模ネットワークにIBGPスケーラビリティを追加します。10台のルーターからなる完全にメッシュ化されたIBGPネットワークでは、各ピアのリモートASを定義するためだけに、90個の個別のCLIステートメント(トポロジ内のすべてのルーターに分散)が必要です。これはすぐに管理の頭痛の種になります。RRトポロジでは、これらの90のステートメントを18に削減でき、ISPが管理する大規模なネットワークに実行可能なソリューションを提供します。

ルートリフレクターは単一障害点であるため、冗長性を提供するために、少なくとも2番目のルートリフレクターを構成できます。これは他の10台のルーターの追加ピアであるため、単一のルートリフレクターセットアップのマイナス2を2倍にする追加のステートメントカウントが付属しています。この場合、ルーターが追加されたため、11 * 2-2 = 20ステートメントが追加されました。さらに、BGPマルチパス環境では、RRが専用のRoute Reflector Serverの役割ではなく、従来のルーターとして機能している場合、ローカルスイッチング/ルーティングスループットを追加することでメリットが得られます。

ルール

セクション6、RFC 4456で提案されている、BGPルートリフレクタ展開の一般的な構成。

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

  • ルートが非クライアントピアから受信された場合は、クライアントのみとEBGPピアに反映します。
  • ルートがクライアントピアから受信された場合は、ルートの発信元を除くすべての非クライアントピアとクライアントピアにリフレクトし、EBGPピアにリフレクトします。

クラスター

RRとそのクライアントは「クラスター」を形成します。次に、「Cluster-ID」は、RRによってクライアントまたは非クライアントピアにアドバタイズされるすべてのルートに付加されます。Cluster-IDは累積的で非推移的なBGP属性であり、ルーティングループを回避するために、すべてのRRはローカルCLUSTER_IDをCLUSTER_LISTの前に追加する必要があります。ルートリフレクタとコンフェデレーションはどちらも、各ルータへのiBGPピアの数を減らし、処理のオーバーヘッドを減らします。ルートリフレクターは純粋なパフォーマンス向上手法ですが、コンフェデレーションを使用してよりきめ細かいポリシーを実装することもできます。

BGPコンフェデレーション

コンフェデレーションは、自律システムのセットです。一般的な慣行では、[18]コンフェデレーションAS番号の1つだけがインターネット全体で見られます。コンフェデレーションは、非常に大規模なネットワークで使用されます。このネットワークでは、大規模なASを構成して、より小規模で管理しやすい内部ASを含めることができます。

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

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

ただし、これらの代替案は、次のような独自の問題を引き起こす可能性があります。

  • ルート発振
  • 最適ではないルーティング
  • BGPコンバージェンス時間の増加[20]

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

安定性

BGP実装によって管理されるルーティングテーブルは、リンクの切断と復元、ルーターのダウンと復帰など、ネットワークの実際の変更を反映するように継続的に調整されます。ネットワーク全体では、これらの変更がほぼ継続的に発生するのは正常ですが、特定のルーターまたはリンクでは、変更は比較的まれであると想定されています。ルータの設定や管理が間違っていると、ダウン状態とアップ状態の間で急速なサイクルが発生する可能性があります。ルートフラッピングとして知られるこの繰り返しの撤退と再発表のパターン同じルートが継続的に注入され、ルーティングテーブルから引き出されるため、リンク切れを認識している他のすべてのルーターで過度のアクティビティが発生する可能性があります。BGPの設計では、ルートの更新中にトラフィックの配信が機能しない場合があります。インターネットでは、BGPルーティングを変更すると、数分間停止する場合があります。

ルートフラッピングの影響を軽減するために、ルートフラップダンピングRFC 2439 )と呼ばれる機能が多くのBGP実装に組み込まれています。ダンピングを行わないと、過度のアクティビティによってルータの処理負荷が大きくなり、他のルートの更新が遅れて、全体的なルーティングの安定性に影響を与える可能性があります。ダンピングを使用すると、ルートのフラッピングは指数関数的に減衰しますルートが使用できなくなり、すぐに再表示された最初のインスタンスでは、BGPの通常のフェイルオーバー時間を維持するために、ダンピングは有効になりません。2回目の発生では、BGPはそのプレフィックスを一定時間回避します。その後の発生は指数関数的にタイムアウトします。異常がなくなり、問題のあるルートに適切な時間が経過した後、プレフィックスを元に戻し、そのスレートをきれいに拭き取ることができます。ダンピングは、サービス拒否攻撃を軽減することもできます。ダンピングタイミングは高度にカスタマイズ可能です。

また、RFC 2439(「設計の選択->ルートアドバタイズメントの安定性に敏感な抑制」の下)では、ルートフラップダンピングは、外部ボーダーゲートウェイプロトコルセッション(eBGPセッションまたは単に外部ピアと呼ばれる)に実装された場合、より望ましい機能であることが提案されています。内部ボーダーゲートウェイプロトコルセッション(iBGPセッションまたは単に内部ピアと呼ばれる)。このアプローチでは、ルートが自律システム内でフラッピングする場合、外部ASに伝播されません。eBGPへのルートのフラッピングには、バックボーン全体の特定のルートのフラッピングのチェーンがあります。この方法は、iBGPセッションのルートフラップダンピングのオーバーヘッドも回避できます。

ただし、その後の調査では、フラップダンピングによって実際に収束時間が長くなる場合があり、リンクがフラップしていない場合でも接続が中断される可能性があることが示されています。[21] [22]さらに、バックボーンリンクとルータープロセッサが高速化するにつれて、一部のネットワークアーキテクトは、ルーティングテーブルへの変更はルーターによってはるかに高速に処理できるため、フラップダンピングは以前ほど重要ではない可能性があると示唆しています。 。[23]これにより、RIPEルーティングワーキンググループは、「BGPフラップダンピングの現在の実装では、ISPネットワークでのフラップダンピングの適用は推奨されません。...フラップダンピングが実装されている場合、そのネットワークを運用しているISPはサイドを引き起こします。 -顧客および顧客のコンテンツとサービスのインターネットユーザーへの影響....これらの副作用は、フラップダンピングをまったく実行しないことによって引き起こされる影響よりもかなり悪い可能性があります。」[24]フラップ減衰の問題なしに安定性を改善することは、現在の研究の主題です。[25]

ルーティングテーブルの拡大

インターネットでのBGPテーブルの増加
インターネット上のASの数と登録されたASの数

BGP、そして実際にインターネットインフラストラクチャ全体が直面する最大の問題の1つは、インターネットルーティングテーブルの拡大です。グローバルルーティングテーブルが大きくなり、一部の古い、機能の劣るルーターがメモリ要件やテーブルを維持するためのCPU負荷に対応できなくなると、これらのルーターは、接続するインターネットの部分間の効果的なゲートウェイではなくなります。さらに、おそらくさらに重要なことに、大きなルーティングテーブルは、接続が大幅に変更された後、安定するまでに時間がかかり(上記を参照)、その間、ネットワークサービスの信頼性が低下したり、利用できなくなったりします。

2001年後半まで、グローバルルーティングテーブルは指数関数的に増加し、接続の最終的な広範囲にわたる故障を脅かしていました。これを防ぐために、ISPは、クラスレスドメイン間ルーティング(CIDR)とルート集約を使用して、グローバルルーティングテーブルを可能な限り小さく保つことに協力しました。これにより、ルーティングテーブルの成長が数年間線形プロセスに減速しましたが、エンドユーザーネットワークによるマルチホーミングの需要が拡大したため、2004年半ばまでに成長は再び超線形になりました。

512k日

適切に更新されなかったモデルに対して、2014年にY2Kのようなオーバーフローがトリガーされました。

2014年8月(512k日)の時点で完全なIPv4 BGPテーブル[26] [27]は512,000プレフィックスを超えていましたが、[28]多くの古いルーターには512k(512,000–524,288)[29] [30]ルーティングの制限がありましたテーブルエントリ。2014年8月12日、フルテーブルによる停止がeBayLastPassMicrosoftAzureなどに発生しました。[31]一般的に使用されている多くのCiscoルーターには、高速連想メモリの一種であるTCAMが搭載されていました。、BGPアドバタイズされたルートを保存するため。影響を受けるルーターでは、TCAMはデフォルトで512kIPv4ルートと256kIPv6ルートとして割り当てられていました。報告されたIPv6アドバタイズされたルートの数はわずか約20kでしたが、アドバタイズされたIPv4ルートの数はデフォルトの制限に達し、ルーターが低速のソフトウェアルーティングを使用して問題を補おうとしたため(TCAMを介した高速ハードウェアルーティングとは対照的に) 、波及効果が発生しました。 )。この問題に対処するための主な方法は、ほとんどのルーターで再起動が必要なIPv6ルート用に予約されたTCAMの一部を再割り当てすることにより、オペレーターがTCAM割り当てを変更してより多くのIPv4エントリを許可することです。512kの問題は、多くのIT専門家によって予測されました。[32] [33] [34]

ルート数を512k以上に押し上げた実際の割り当ては、UTC 07:48から始まる、短い順序で約15,000の新しいルートの発表でした。これらのルートのほとんどすべては、Verizon Autonomous Systems 701および705へのルートであり、より大きなブロックの分解、数千の新しい/ 24ルートの導入、およびルーティングテーブルの515,000エントリへの到達の結果として作成されました。新しいルートは5分以内に再集約されたように見えますが、インターネット全体の不安定性は明らかに数時間続いたようです。[35]ベライゾンが短いスパイクでルーティングテーブルを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これはすべて、4つのルートをアナウンスするAS1としてカウントされます。

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

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つのルートを認識し、AS2のルーティングポリシーに応じて、3つのルートのコピーを保存するか、プレフィックスの172.16.0.0/18および172.16.64.0/18172.16.0.0/ 17集約して削減します。 AS2が格納するルートの数は172.16.0.0/17172.16.128.0 / 18

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

AS番号の枯渇と32ビットASN

RFC 1771(A Border Gateway Protocol 4(BGP-4))は、ASN 64512から65534が私的使用のために予約されていたため(0と65535は禁止されている)、64510の可能なパブリックASに対して16ビットでのAS番号のコーディングを計画しました。2011年にはまだ15000のAS番号しか利用できず、予測[36]は、2013年9月に利用可能なAS番号が完全に枯渇することを想定していました。

RFC 6793は、ASコーディングを16ビットから32ビットに拡張し(16ビットのAS範囲0から65535、およびその予約済みAS番号を維持)、最大40億のASを使用できるようになりました。追加のプライベートAS範囲もRFC6996で定義されています(4200000000から4294967294、4294967295はRFC 7300で禁止されています)。

これらの新しいASNを管理できないルータグループのトラバーサルを許可するために、新しい属性OTAS4_PATHが使用されます。

32ビットASN割り当ては2007年に開始されました。

負荷分散

ルーティングテーブルのこの成長を引き起こす別の要因は、マルチホームネットワークの負荷分散の必要性です。BGPルート選択プロセスの制限により、複数のインバウンドパスを介してマルチホームネットワークへのインバウンドトラフィックのバランスをとるのは簡単な作業ではありません。マルチホームネットワークの場合、すべてのBGPピアで同じネットワークブロックをアナウンスすると、外部ネットワークがすべてそれを選択したため、1つまたは複数のインバウンドリンクが混雑し、他のリンクは十分に活用されないままになる可能性があります。最適な混雑したパスのセット。他のほとんどのルーティングプロトコルと同様に、BGPは輻輳を検出しません。

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

負荷分散の問題に対処するために人気が高まっている方法の1つは、インターネットエクスチェンジポイント内にBGP / LISP(ロケーター/識別子分離プロトコル)ゲートウェイを展開して、複数のリンクにまたがる入力トラフィックエンジニアリングを可能にすることです。この手法では、グローバルBGPテーブルに表示されるルートの数は増えません。

セキュリティ

設計上、BGPを実行しているルーターは、デフォルトで他のBGPルーターからのアドバタイズされたルートを受け入れます。これにより、インターネットを介したトラフィックの自動および分散ルーティングが可能になりますが、 BGPハイジャックと呼ばれる偶発的または悪意のある中断に対してインターネットが脆弱になる可能性もありますBGPがインターネットのコアシステムに組み込まれている範囲、およびインターネットを集合的に構成する多くの異なる組織によって運用されているさまざまなネットワークの数により、この脆弱性を修正します(検証に暗号化キーの使用を導入するなど)。 BGPルーターのID)は、技術的および経済的に困難な問題です。[37]

拡張機能

BGPの拡張は、マルチパスの使用です。これには通常、同一のMED、重み、起点、およびASパスが必要ですが、一部の実装では、実際のAS番号ではなく、等しいパス長のみを期待するようにASパスチェックを緩和する機能が提供されます。一致することが期待されるパスでも。これは、個々のリンクに設定された帯域幅の値に基づいてトラフィック共有の比率を有効にするCiscoのdmzlink-bwなどの機能でさらに拡張できます。

マルチプロトコルBGPまたはマルチキャストBGPと呼ばれることもあり、IETF RFC 4760で定義されているBGPのマルチプロトコル拡張(MBGP)は、(BGP)の拡張であり、さまざまなタイプのアドレス(アドレスファミリと呼ばれる)を並列に配布できます。標準のBGPはIPv4ユニキャストアドレスのみをサポートしますが、マルチプロトコルBGPはIPv4およびIPv6アドレスをサポートし、それぞれのユニキャストおよびマルチキャストバリアントをサポートします。マルチプロトコルBGPを使用すると、IPマルチキャスト対応ルーターのトポロジーに関する情報を、通常のIPv4ユニキャストルーターのトポロジーとは別に交換できます。したがって、ユニキャストルーティングトポロジとは異なるマルチキャストルーティングトポロジが可能になります。MBGPはドメイン間マルチキャストルーティング情報の交換を可能にしますが、

マルチプロトコルBGPは、MPLS L3 VPNの場合にも広く展開されており、MPLSネットワークを介して顧客サイトからのルートについて学習したVPNラベルを交換し、他の顧客サイトからのトラフィックがプロバイダーに到達したときに異なる顧客サイトを区別します。ルーティング用のエッジルーター(PEルーター)。

を使用します

BGP4はインターネットルーティングの標準であり、ほとんどのインターネットサービスプロバイダー(ISP)が相互にルーティングを確立するために必要です。非常に大規模なプライベートIPネットワークは、内部でBGPを使用します。例としては、OSPF自体が必要なサイズに拡張できない場合に、多数の大規模なOpen Shortest Path First (OSPF)ネットワークに参加することがあります。BGPを使用するもう1つの理由は、単一のISPの複数のアクセスポイントまたは複数のISPのいずれかに、冗長性を高めるためにネットワークをマルチホーミングすることです。

実装

ルーター、特にスモールオフィス/ホームオフィス(SOHO)での使用を目的とした小さなルーターには、BGPソフトウェアが含まれていない場合があります。一部のSOHOルーターは、BGPを実行したり、任意のサイズのBGPルーティングテーブルを使用したりすることができません。他の商用ルーターには、BGPを含む特定のソフトウェア実行可能イメージ、またはそれを有効にするライセンスが必要な場合があります。BGPを実行するオープンソースパッケージには、GNU ZebraQuaggaOpenBGPDBIRDXORP、およびVyattaが含まれます。レイヤ3スイッチとして販売されているデバイスは、ルーターとして販売されているデバイスよりもBGPをサポートする可能性は低くなりますが、通常、ハイエンドのレイヤ3スイッチはBGPを実行できます。

スイッチとして販売されている製品には、完全なインターネットテーブルと内部ルートよりもはるかに小さい20,000ルートなど、BGPテーブルのサイズ制限がある場合とない場合があります。ただし、これらのデバイスは、バックボーンのBGPバックボーン、または小規模な企業によってリンクされているいくつかの小規模企業の1つを表すコンフェデレーションASなど、ネットワークの一部の小規模な部分のBGPルーティングに使用する場合に完全に合理的で有用な場合があります。 ISPへのルートをアナウンスするが、デフォルトルートとおそらく少数の集約ルート のみを受け入れる企業。

インターネットへの単一のエントリポイントを持つネットワークにのみ使用されるBGPルーターは、マルチホームネットワークよりもルーティングテーブルのサイズ(したがってRAMとCPUの要件)がはるかに小さい場合があります。単純なマルチホーミングでさえ、適度なルーティングテーブルサイズを持つことができます。コントロールプレーンでのシングルBGPルータコンバージェンスのベンダーに依存しないパフォーマンスパラメータについては、RFC4098を参照してください。BGPルータに必要な実際のメモリ量は、他のBGPスピーカーと交換されるBGP情報の量と、特定のルータがBGP情報を格納する方法によって異なります。ルータは、ルートの複数のコピーを保持する必要がある場合があるため、特定の隣接ASへのルートアドバタイズメントと受け入れに関するさまざまなポリシーを管理できます。ビューという用語は、実行中のルータでのこれらのさまざまなポリシー関係によく使用されます。

あるルーターの実装が別の実装よりもルートごとにより多くのメモリを使用する場合、これは正当な設計上の選択であり、処理速度をメモリと交換します。2015年8月の時点での完全なIPv4BGPテーブルは、590,000プレフィックスを超えています。[28]大規模なISPは、内部ルートと顧客ルートにさらに50%を追加する場合があります。この場合も、実装によっては、異なるピアASのビューごとに個別のテーブルが保持される場合があります。

BGPの注目すべきフリーでオープンソースの実装には次のものがあります。

BGPの適合性、負荷、またはストレスのパフォーマンスをテストするためのシステムは、次のようなベンダーから提供されています。

標準文書

  • 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-4MIB実装調査
  • 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  5575、フロー仕様ルールの普及
  • RFC  5701、IPv6アドレス固有のBGP拡張コミュニティ属性
  • RFC  6793、4オクテット自律システム(AS)番号スペースのBGPサポート
  • RFC  7153、BGP拡張コミュニティのIANAレジストリ
  • RFC  7606、BGPUPDATEメッセージのエラー処理の改訂
  • RFC  7752、BGPを使用したリンクステートおよびトラフィックエンジニアリング情報のノースバウンド配布
  • RFC  7911、BGPでの複数のパスのアドバタイズメント
  • RFC  8092、BGPラージコミュニティ属性
  • RFC  8195、BGP大規模コミュニティの使用
  • RFC  8642、よく知られているBGPコミュニティのポリシー動作
  • draft-ietf-idr-custom-decision-08  – BGPカスタム決定プロセス、2017年2月3日
  • BGPの選択的ルート更新、IETFドラフト
  • 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サポート

も参照してください

メモ

  1. ^ BGP標準の最新版より前は、UPDATEにMULTI_EXIT_DISC値がなかった場合、いくつかの実装で可能な限り高い値のMEDが作成されていました。ただし、現在の標準では、欠落しているMEDを可能な限り低い値として扱うように指定されています。現在のルールはベンダーの解釈とは異なる動作を引き起こす可能性があるため、非標準のデフォルト値を使用したBGP実装には、古いルールまたは標準のルールを選択できる構成機能があります。

参考文献

  1. ^ W. Richard Stevens、 TCP / IP Illustrated、Volume 1:The Protocols、Addison Wesley、1994、ISBN0-201-63346-9。
  2. ^ 「BGP:ボーダーゲートウェイプロトコルの説明」Orbit-ComputerSolutions.Com2013年9月28日にオリジナルからアーカイブされまし2013年10月8日取得
  3. ^ Sobrinho、JoãoLuís(2003)。「パスベクトルプロトコルを使用したネットワークルーティング:理論とアプリケーション」(PDF)2018年3月16日取得
  4. ^ 「ボーダーゲートウェイプロトコルの歴史」blog.datapath.io2020年10月20日にオリジナルからアーカイブされました。
  5. ^ ボーダーゲートウェイプロトコル4(BGP-4)RFC4271_ 
  6. ^ RFC 4274
  7. ^ R。チャンドラ; J. Scudder(2000年5月)。BGP-4を使用した機能アドバタイズメント土井10.17487 / RFC2842RFC2842_
  8. ^ T。ベイツ; etal。(2000年6月)。BGP-4のマルチプロトコル拡張土井10.17487 / RFC2858RFC2858_
  9. ^ E。ローゼン; Y. Rekhter(2004年4月)。BGP / MPLSVPN土井10.17487 / RFC2547RFC2547_
  10. ^ RFC 1997 
  11. ^ 「BGPコミュニティガイド」2015年4月13日取得
  12. ^ BGP拡張コミュニティタイプのIANAレジストリ、IANA、2008
  13. ^ ウェイバックマシンで2009年2月23日にアーカイブされたBGPシグナリングQoSに関するIETFドラフト 、Thomas Knoll、2008年
  14. ^ 「大規模なBGPコミュニティ」2021-11-27を取得しました。
  15. ^ Y. Rekhter; T.リー; S.ハレス編 (2006年1月)。ボーダーゲートウェイプロトコル4(BGP-4)ネットワークワーキンググループ。土井10.17487 / RFC4271RFC4271_ 4.1。
  16. ^ 「ボーダーゲートウェイプロトコル(BGP)」Cisco.com_
  17. ^ BGPルートリフレクション:フルメッシュ内部BGP(iBGP)の代替、RFC 4456、T。Batesetal、2006年4月
  18. ^ 「情報」www.ietf.org 2019年12月17日取得
  19. ^ 「情報」www.ietf.org 2019年12月17日取得
  20. ^ 「情報」www.ietf.org 2019年12月17日取得
  21. ^ 「ルートフラップダンピングはインターネットルーティングコンバージェンスを悪化させる」(PDF)1998年11月。
  22. ^ 張、北川; ペイダン; ダニエルマッセイ; Lixia Zhang(2005年6月)。「ルートフラップダンピングにおけるタイマーの相互作用」(PDF)IEEE 25th International Conference on Distributed ComputingSystems2006年9月26日取得現在の減衰設計が、持続的なルートフラッピングの下で​​のみ意図された動作につながることを示します。フラップの数が少ない場合、グローバルルーティングダイナミクスは、収束遅延が長くなり、予想される動作から大幅に逸脱します。
  23. ^ Villamizar、Curtis; チャンドラ、ラヴィ; ゴビンダン、ラメッシュ(1998年11月)。「BGPルートフラップダンピング」Tools.ietf.org。
  24. ^ 「ルートフラップダンピングに関するRIPEルーティングワーキンググループの推奨事項」RIPEネットワークコーディネーションセンター。2006-05-10 2013年12月4日取得
  25. ^ "draft-ymbk-rfd-usable-02-ルートフラップダンピングを使用可能にする"Tools.ietf.org 2013年12月4日取得
  26. ^ 2014年8月12日の時点で、 Ciscoおよび他のベンダーによって製造された複数のインターネットルーターで、デフォルトのソフトウェア制限512K(512,000〜524,288)「Ciscoスイッチの問題」が発生しました。
  27. ^ 「Renesys512kグローバルルート」
  28. ^ a b "BGPレポート"potaroo.net
  29. ^ 「CAT6500および7600シリーズルータおよびスイッチのTCAM割り当て調整手順」シスコ2015年3月9日。
  30. ^ ジムカウイ。「インターネットは50万のルートに接触します:来週停止の可能性があります」DynResearch
  31. ^ ガーサイド、ジュリエット; ギブス、サミュエル(2014年8月14日)。「インターネットインフラストラクチャは更新が必要であるか、より多くの停電が発生します」"ガーディアン。 2014年8月15日取得
  32. ^ 「BOFレポート」(PDF)www.nanog.org 2019年12月17日取得
  33. ^ グレッグフェロ(2011年1月26日)。「TCAM—詳細な調査とIPv6の影響」EtherealMind
  34. ^ 「IPv4枯渇サイト」ipv4depletion.com
  35. ^ 「今日のインターネットの一時的な中断の原因」bgpmon.net
  36. ^ 16ビットAutonomusシステムレポート、Geoff Huston 2011(元のアーカイブはhttps://web.archive.org/web/20110906085724/http://www.potaroo.net/tools/asn16/
  37. ^ クレイグ・ティンバーグ(2015-05-31)。「初期のインターネット問題の迅速な修正は、四半世紀後のことです」ワシントンポスト2015年6月1日取得
  38. ^ 「GNUゼブラ」

さらに読む

外部リンク