RFC 7938: 大規模データセンターでのルーティングにBGPを使用

概要

ネットワーク事業者の中には、10万台を超えるサーバを収容するデータセンターを構築・運用しているところもある。本文書では、このようなデータセンターを小規模インフラと区別するために「大規模 (large-scale)」と呼ぶ。この規模の環境では、運用のシンプルさとネットワークの安定性を重視した独自のネットワーク要件を必要とする。本文書では、BGPをルーティング・プロトコルとして使用した大規模データセンターの設計と運用に関する運用経験をまとめる。この文書の目的は、この業界の他のユーザが活用できるような実績のある安定したルーティングの設計について報告することにある。

本文書の位置付け

本文書はインターネット標準化過程の仕様書ではない。情報提供を目的として公開する。

本文書はインターネット・エンジニアリング・タスク・フォース(IETF)の成果物である。IETFコミュニティのコンセンサスを表すものである。文書は公開レビューを受けており、インターネット・エンジニアリング・ステアリング・グループ(IESG)によって公開が承認されている。IESGによって承認されたすべての文書が、あらゆるレベルのインターネット標準の候補となるわけではない。RFC 5741のセクション2を参照のこと。

文書の現在の位置付け、正誤表、フィードバックの提供方法に関する情報は、<http://www.rfc-editor.org/info/rfc7938>で入手できる。

著作権表示

Copyright (c) 2016 IETFトラストおよび文書の著者として特定された人物。無断転載を禁じる。

本文書は、BCP 78および文書の発行日において有効なIETF文書に関するIETFトラストの法的規定(<https://trustee.ietf.org/license-info>)に従うものとする。これらの文書には、本文書に関するあなたの権利と制限が記載されているため、注意深く確認して欲しい。文書から抽出されたコード・コンポーネントには、トラスト法的条項のセクション4.eに記載されている簡易BSDライセンスのテキストを含まなければならず、簡易BSDライセンスに記載されているように保証なしで提供する。

1. はじめに

本文書では、大規模データセンター(DC)設計で使用できる実用的なルーティングの設計について説明する。このようなデータセンターは、「ハイパースケール」または「ウェアハウス・スケール」のデータセンターとも呼ばれ、10万台を超えるサーバを収容するというユニークな特性を持っている。事業者は、このような規模のネットワークに対応するため、ネットワーク設計とプラットフォームを見直し、このニーズに対応している。

本文書で提示する設計は、ウェブ検索エンジンのような大規模分散ソフトウェア・インフラを収容するために構築されたデータセンターの運用経験に基づいている。大規模なネットワークを少人数で効率的にサポートできるように、このような環境では運用のシンプルさとネットワークの安定性が重要な要件となる。

実験と広範な検証により、外部BGP(EBGP)[RFC4271]が、このようなタイプのデータセンター・アプリケーションのスタンドアロン・ルーティング・プロトコルに最適だということが分かった。これは、複数のネットワーク・デバイスにまたがるレイヤ2(L2)ドメインの拡張に依存する従来のDC設計とは対照的で、単純なツリー・トポロジーを使用している。本文書では、この設計上の選択につながった要件について詳しく説明し、EBGPルーティングの設計の詳細と、さらなる強化のアイデアを検討する。

本文書ではまず、大規模データセンターのネットワークの設計要件と考慮事項の概要を示す。次に、従来の階層型データセンター・ネットワーク・トポロジーと、水平方向にスケールアウトするClosネットワーク[CLOS1953]を比較する。続いて、ClosトポロジーにとってEBGPが要件を満たす最適なルーティング・プロトコルである理由を説明し、提案する設計について詳しく説明する。この文書の最後に、いくつかの追加の考慮事項と設計オプションを確認する。本文書で説明する設計の導入を計画している読者は、BGPを十分に理解していることが前提となる。

2. ネットワーク設計要件

このセクションでは、大規模データセンターのネットワーク設計要件について説明し、要約する。

2.1. 帯域幅とトラフィック・パターン

大量のサーバを相互接続するネットワークを構築する際の主な要件は、アプリケーションの帯域幅とレイテンシの要件に対応することである。最近まで、データセンターに出入りするトラフィックの大部分は、「North-South」トラフィックと呼ばれるものが一般的であった。従来の「ツリー」トポロジーは、ネットワークのレイヤ間のオーバー・サブスクリプションの比率が高くても、このようなフローを収容するには十分だった。帯域幅をさらに増やす必要があれば、デバイスのラインカードやファブリックをアップグレードするか、ポート密度の高いデバイスに交換するなど、ネットワーク・コンポーネントを「スケールアップ」することで対応していた。

今日、多くの大規模データセンターは、一般的に「East-West」トラフィックと呼ばれるDCの外に出ない大量のサーバ間トラフィックを生成するアプリケーションを収容している。このようなアプリケーションの例としては、Hadoop[HADOOP]のようなコンピュータ・クラスタ、特定のアプリケーションで必要とされるクラスタ間の大規模なデータ・レプリケーション、仮想マシンのマイグレーションなどがある。このような帯域幅の需要に合わせて従来のツリー・トポロジーを拡張することは、スイッチのポート密度などの物理的な制約により、コストがかかり過ぎるか、そもそも不可能である。

2.2. CAPEXの最小化

ネットワーク・インフラに関連する設備投資(CAPEX)だけでも、データセンターの総支出の約10～15%を占める([GREENBERG2009]を参照)。しかし、絶対的なコストが大きいため、個々のネットワーク・コンポーネントのコストを継続的に下げる必要がある。それには、以下の2つの方法がある:

• すべてのネットワーク・コンポーネントを統合し、できれば同じハードウェア・タイプや同じデバイスを使用する。こうすることで、一括購入時のボリューム価格が可能になり、メンテナンスや在庫コストを削減できる。

• 複数のネットワーク機器ベンダーを導入することで、競争圧力を利用してコストを削減する。

ベンダーの多様性を確保するには、ネットワーク・コンポーネントのソフトウェア機能要件を最小限に抑えることが重要である。この戦略により、オープン・スタンダードを使用して相互運用性を強化しながら、ベンダー機器の選択の柔軟性を最大限に高めることができる。

2.3. OPEXの最小化

大規模なインフラストラクチャの運用は、コンポーネントの数が多いほど統計的に障害が発生する頻度が高くなるため、コストがかかる可能性がある。設計を簡素化し、限られたソフトウェア機能セットで運用することで、ソフトウェアの問題に関連する障害を最小限に抑えることができる。

運用コスト(OPEX)の最小化の重要な面は、ネットワーク内の障害領域を小さくすることである。イーサネット・ネットワークは、ブロードキャストやユニキャストのトラフィック・ストームの影響を受けやすく、ネットワークの性能や可用性に劇的な影響を与えることが知られている。完全なルーティング設計を使用することで、データ・プレーンの障害領域を大幅に縮小することができる。つまり、ネットワーク階層の最下位レベルに制限される。しかし、このような設計は、分散型コントロール・プレーンの障害という問題を引き起こす。この観察結果から、コントロール・プレーンをより簡素化し、プロトコル相互作用の問題を減らし、ネットワークのメルトダウンの可能性を減らすことが求められる。上記のCAPEXセクションで説明したように、ソフトウェア機能の要件を最小化することで、検証やトレーニングの要件も削減できる。

2.4. トラフィック・エンジニアリング

どのデータセンターでも、アプリケーションの負荷分散はネットワーク・デバイスによって実行される重要な機能である。従来、ロード・バランサはトラフィックのフォーワディング・パスに専用デバイスとして導入される。問題は、増大するトラフィック需要下でロード・バランサを拡張する際に生じる。望ましい解決策は、同一のノードを追加し、これらのノードに着信するトラフィックを分散させることで、負荷分散レイヤを水平方向に拡張する方法である。このような状況では、ネットワーク・インフラストラクチャ自体を利用して、ロード・バランサのグループにトラフィックを分散させることが理想的な選択肢である。この目標を達成するには、エニーキャスト・プレフィックス広告[RFC4786] とイコール・コスト・マルチパス(ECMP)機能の組み合わせを利用することができる。よりきめ細かな負荷分散を可能にするには、ホップ単位に制御されたトラフィック・エンジニアリングを実行する機能を、ネットワークがサポートすることが望ましい。例えば、ネットワーク階層の各レベルで、エニーキャスト・プレフィックスのECMPネクストホップを直接制御することが効果がある。

2.5.要約された要件

このセクションでは、前のセクションで概説した要件リストを要約する:

• REQ1: ネットワークの構成要素自体のアップグレードを必要とせず、同じタイプのリンクやネットワーク・デバイスを追加することで「水平方向」に拡張できるトポロジーを選択する。

• REQ2: 多数のネットワーク機器ベンダーがサポートする限定されたソフトウェア機能/プロトコル一式を定義する。

• REQ3: プログラミング・コードの複雑さと運用サポートの容易さの観点から、実装が簡単なルーティング・プロトコルを選択する。

• REQ4: 機器やプロトコルの問題による障害領域を可能な限り小さくする。

• REQ5: 組み込みのプロトコル・メカニズムを使用してルーティング・プレフィックスのネクストホップを明示的に制御することで、ある程度のトラフィック・エンジニアリングを可能にする。

3. データセンター・トポロジーの概要

このセクションでは、階層型 (「ツリー・ベース」とも呼ぶ)とClosベースのネットワーク設計という2種類の一般的なデータセンター設計の概要を説明する。

3.1.従来のDCトポロジー

ネットワーク業界では、データセンターの一般的な設計で選択されるトポロジーは、冗長化された複数のアップリンクと3階層(コア、集約/分配、アクセス・レイヤ)の(逆三角形)ツリーのように形をしている(図1を参照)。帯域幅の需要に応えるため、サーバからDCの出口やWANに向かう上位レイヤは、コアがツリー・ベースの設計の「トランク」として機能する高密度のポートと帯域幅容量が備わっている。用語の統一と他の設計との比較のため、本文書では、3つのレイヤをコア層、集約層、アクセス層ではなく、Tier 1、Tier 2、Tier3と呼ぶlことにする。

図1: 代表’的なDCネットワーク・トポロジー

残念ながら、前述したように、Tier 2を十分に拡張できるほどのポート密度を持つTier 1デバイスを手にいれることができないため、大規模な設計に対応できるほどツリー・ベースの設計を拡張することはできない。また、導入規模や帯域幅要件が大きくなるにつれて、上位のTierデバイスは継続的なアップグレードや交換が必要になり、運用が煩雑になる。こういった理由から、REQ1が設けられており、このタイプの設計は検討対象から除外する。

3.2. Closネットワーク・トポロジー

本セクションでは、REQ1を満たすため、大規模データセンターにおける水平方向に拡張可能なトポロジーの一般的な設計について説明する。

3.2.1. 概要

水平方向に拡張可能なトポロジーの一般的な選択肢は、「ファット・ツリー」と呼ばれることもある、折り畳みClosトポロジーである([INTERCON]や[ALFARES2008]など)。このトポロジーの特徴は、奇数ステージ(「面 (dimensions)」と呼ばれることもある) を特徴とし、通常は同じポート数を持ったネットワーク・スイッチなど、同一構成要素で構成される。したがって、折り畳みClosトポロジーを選択することで、REQ1を満たし、REQ2を容易にする。折り畳み3ステージClosトポロジ(3ステージはパケット・フローの跡を追うと、Tier2ステージを2回カウントするため)の例については、下図2を参照のこと。

図2: 3ステージ折り畳みClosトポロジー

このトポロジーはしばしば、「リーフ・アンド・スパイン」ネットワークとも呼ばれ、「スパイン」は Closトポロジーの中間ステージ(Tier 1)に付けられた名前で、「リーフ」は入力/出力ステージ(Tier 2)の名前である。統一性を保つため、本文書ではこれらのレイヤを「Tier n」という表記を使う。

3.2.2. Closトポロジーの特性

以下は、Closトポロジーの主要な特性である:

• トポロジーがM >= Nの場合、完全なノンブロッキング、より正確には干渉しない(non-interfering)、それ以外の場合はN/Mの比率に応じてオーバー・サブスクライブとなる。ここで、MとNは図2に示すTier 2スイッチのアップリンクとダウンンクのポート数である。

• このトポロジーを活用するには、M以上のファンアウトを持つECMPに対応するコントロール・プレーンとデータ・プレーンのサポートが必要である。

• このトポロジーのTier 1スイッチは、それぞれのサーバに対するパスを厳密に1つ持つ。これはこのトポロジーにおいて、経路集約を危険なものにする重要な特性である(以下のセクション8.2 を参照)。

• サーバからサーバへのトラフィックは、ECMPを使用して利用可能なすべてのパスで負荷分散する。

3.2.3. Closトポロジーの拡張

Closトポロジーは、ネットワーク要素のポート密度を増やすか、ステージを追加することで拡張できる(例えば、以下の図3に示すように、5ステージのClosに移行する方法がある)。

図3: 5ステージのClosトポロジー

図3の小さなトポロジーの例は、4ポートのデバイスで構成されている。本文書では、直接接続されたTier 2とTier 3デバイス1式と、それらに接続されたサーバを「クラスタ (Cluster)」と呼ぶ。例えば、図3のDEV A、B、C、D、およびDEV AとBに接続するサーバで、クラスタを形成する。クラスタという概念も、トポロジー全体とは異なる頻度で運用できる単一の展開または保守単位としても有用かもしれない。

Errata: 保留

図3のトポロジーの小規模例は、ポート数が4のデバイスで構築されている。追加のTierを導入することで、4ポートのTier 1デバイスには、さらにデバイスを接続するための未使用ポートが2つ残されており、したがって、3ステージClosの最大8台のサーバから、この5ステージClosの最大16台のサーバに拡張できる。本文書では、直接接続されたTier 2およびTier 3デバイスと、それらに接続されたサーバを「クラスタ」と呼ぶ。例えば、図3のDEV A、B、C、D、およびDEV AとBに接続されたサーバは、クラスタを形成している。クラスタの概念は、トポロジー全体とは異なる頻度で操作できる単一の展開またはメンテナンス・ユニットとして、有用な概念である可能性もある。

注記:

このセクションでは、スケーリングがどこで行われるかが適切に説明されていない。また、図示されたトポロジーは依然として8台のサーバ(3ステージClosの場合と同じ台数)のみを接続している。読者は、図を注意深く見なければ、スケーリングを把握できない。

実際には、さまざまなタイプのアプリケーションの帯域幅要件を満たしながら、データセンターにさらに多くのサーバを収容できるようにするため、トップ・オブ・ラック(ToR)スイッチがあるTier 3にオーバー・サブスクリプションが導入される。オーバー・サブスクリプションをネットワークの1つの階層で制限する主な理由は、ラック内(Tier 3)、ラック間(Tier 2)、クラスタ間(Tier 1)など、複数の帯域幅プールを考慮する必要のあるアプリケーション開発を簡素化するためである。なお、オーバー・サブスクリプションは、ルーティング設計に直接関係しないため、本文書ではこれ以上説明しない。

3.2.4. Closトポロジーの階層のサイズ管理

データセンターのネットワークが小規模であれば、ClosトポロジーのTier 1やTier 2のスイッチ数を半分に減らすことができる。どのように行うかを理解するために、Tier 1を例にとってみる。それぞれのTier 2デバイスは、1つのTier 1デバイスのグループに接続される。各Tier 1デバイスの半分のポートが未使用であれば、Tier 1デバイスの数を半分に減らし、Tier 2デバイスの2本のアップリンクのうち、1つのTier 1デバイスに接続されていたものを、別のTier 1デバイスに移し変えることができる。この手法は、帯域幅を維持しながらTier 1の構成要素の数を減らすことができ、CAPEXを節約できる。この例におけるトレードオフは、サーバの総数から見たDCの最大サイズが半分になってしまうことである。

⚠️ 図示すると

この例では、Tier 2デバイスは2本の並列リンクを使用して、Tier 1デバイスに接続している。アップリンクの1本に障害が発生した場合、もう1本のリンクが障害が発生したリンクのトラフィックをすべて拾うことになる。アップストリームのTier 1デバイスの数が2台以上の可能性が高いため、パス決定手順で帯域幅を考慮していなければ、深刻な輻輳とサービス品質の低下が発生する可能性がある。この状況を回避するには、並列リンクをリンク・アグリゲーション・グループ(LAG)(例: [IEEE8023AD])でグループ化し、1つのリンク障害が発生した場合に、「バンドル」全体をダウンさせる広く利用可能な実装の設定を利用する。また、並列リンクに「fate-sharing (運命共有)」を強制する同等の手法をLAGの代わりに使用して、同じ効果を実現できる。このようなfate-sharingの結果、2箇所以上の障害が発生したリンクのトラフィックは、Tier 1デバイスの数に等しい残った多数のパス上で再分散される。この例ではシンプルにするため、2本のリンクを使用しているが、バンドルのリンク数が多ければ多いほど、メンバー・リンクに障害が発生したときの容量への影響が小さくなる。

4. データセンターのルーティングの概要

このセクションでは、データセンターのプロトコル設計の一般的な3つのタイプ(レイヤ2のみ、ハイブリッド・レイヤL2/L3、レイヤ3のみ)の概要を説明する。

4.1. L2のみの設計

ほとんどのデータセンターの設計は、ループフリーのトポロジーを構成するため、[IEEE8021D-1990]で規定されたスパニング・ツリー・プロトコル(STP)を使用していた。通常、セクション3.1で説明した従来のDCトポロジーの変形を利用する。当時、多くのDCスイッチは、レイヤ3ルーティング・プロトコルをサポートしていなかったり、追加のライセンス料金を必要とすることから、設計選択に影響を与えていた。[IEEE8021D-2004]の最新リビジョンにおけるラピッド・スパニング・ツリー・プロトコル(RSTP)や[IEEE8021Q]で規定されたマルチプル・スパニング・ツリー・プロトコル(MST)の導入などによって、大規模なトポロジーでの収束性、安定性、負荷分散を向上させる多くの機能強化が行われてきたが、これらのプロトコルの基本的な機能の多くは、大規模なDCへの適用は制限されていた。STPとその新しいバリアントは、パス選択にアクティブ/スタンバイのアプローチを使用するため、セクション3.2で説明するような水平方向に拡張していくトポロジーでの展開が難しい。さらに、ケーブルの誤配線、設定ミス、デバイス上のソフトウェアの欠陥によって引き起こされる問題で、オペレータは大規模障害を何度も経験している。このような障害は、スパニング・ツリー・ドメイン全体に繰り返し影響を及ぼし、プロトコルの性質上、トラブルシューティングが非常に難しかった。このような理由と、現在ではDCのトラフィックがほぼすべてIPであること、外部接続のためにネットワーク・エッジでレイヤ3ルーティング・プロトコルを必要とすることから、STPを利用した設計は大規模DC事業者の要件を全く満たしていない。[IEEE8023AD]のようなリンク・アグリゲーション・プロトコルのさまざまな機能強化(一般にマルチ・シャーシ・リンク・アグリゲーション(M-LAG)として知られる)により、STPをループ防止のバックアップとして、アクティブ/アクティブ・ネットワーク・パスを備えたレイヤ2の設計が可能になった。このアプローチの主な欠点は、ほとんどの実装で2台以上のリニアな拡張ができないこと、標準に基づいた実装がないこと、そしてデバイス間の状態同期の失敗リスクが増すことである。

[RFC6325]でTransparent Interconnection of Lots of Links(TRILL)プロトコルが導入されたことで、STPを使用せずに大規模で水平に拡張可能なL2のみのネットワークを構築することができるようになった。TRILLは、大規模DCの設計におけるSTPの問題の多くを解決するが、実装数が限られ、多くの場合、TRILLをサポートする特定の機器が必要なことから、その適用範囲が限定される上、TRILLを使用した設計はコストの増大を招く。

最後に、TRILLの基本仕様もM-LAGアプローチも、レイヤ2のイーサネット・ベースのソリューションの運用に非常に悪影響を与える共有ブロードキャスト・ドメイン問題を完全に解消することはできない。その後、この問題の解決のために、[RFC7067]で概説されているアプローチに基づくTRILLの拡張が提案されたが、これによりファブリックの構築に使用できる相互運用可能な実装数がさらに限定されてしまう事になる。したがって、TRILLベースの設計は、REQ2、REQ3、REQ4を満たすのに問題がある。

⚠️ 共有ブロードキャストの問題について

レイヤ2ネットワークにおける「共有ブロードキャスト・ドメインの問題」は、複数のデバイスが同一のブロードキャスト・ドメインにあるときに発生する問題を指す。この問題は、主に以下の要因によって引き起こされる。

1. ブロードキャスト・トラフィックの増加
   同じL2ネットワーク上に多くのデバイスが存在すると、アドレス解決プロトコル(ARP)や他のブロードキャスト・トラフィックが増加する。ブロードキャストは、ネットワーク上のすべてのデバイスに伝播されるため、帯域が使われ、ネットワーク全体の性能が低下する。

2. セキュリティ・リスクの増大
   共有ブロードキャスト・ドメインは、すべてのデバイスが同じネットワークで通信するため、悪意あるユーザがスニッフィング(パケット盗聴)を通じて他のデバイスの通信内容を容易に取得できる危険性がある。

3. ループのリスク
   ブロードキャスト・ドメイン内で誤ってループを形成すると、ブロードキャスト・ストームが発生することがある。これは、同じブロードキャスト・パケットが無限にネットワーク内を循環し続ける事象で、ネットワーク全体を麻痺させてしまう。

4. ネットワークの拡張性
   L2ネットワークは拡張性に限界があり、ネットワーク内のデバイス数が増えると、ブロードキャスト・トラフィックが急激に増加するため、性能が劣化する。大規模ネットワークでは、L2ネットワークを複数のVLANで分割するなどの対策が必要である。

L2ネットワークにおける「共有ブロードキャスト・ドメインの問題」を解決するには、ブロードキャスト・ドメインを分割してトラフィックを制御する必要がある。

4.2. L2/L3ハイブリッドの設計

オペレータは、ネットワークのTier 1やTier 2部分にルーティング・プロトコルを実装し、その上でレイヤ2ドメインを多数の小さなドメインに分割することで、データ・プレーン障害の影響を限定し、大規模トポロジーを構築しようとしてきた。この設計により、データセンターの規模拡大は可能になったが、その代償として、複数のネットワーク・プロトコルを管理する複雑性という新たなコストがかかるようになった。以下の理由から、オペレータはネットワークのアクセス部分(Tier 3)またはアクセスと集約部分(Tier 3とTier 2)の両方でレイヤ2を維持している:

• 直接レイヤ2接続を必要としたり、IPプロトコル以外を使用するレガシー・アプリケーションをサポートするため。

• 仮想マシンが別のTier 3スイッチに移動しても、IPアドレスを維持する必要がある仮想マシンのためのシームレスな移動性のため。

• 簡素化されたIPアドレス指定が、データセンターに必要なIPサブネット数を少なくするため。

• レイヤ2ダイレクト・サーバ・リターン(DSR)のような特定の機能を実行するため、アプリケーションの負荷分散が直接レイヤ2への到達性が必要になる。[L3DSR]を参照のこと。

• L2対応スイッチとL3対応スイッチ間には継続的なCAPEXの差があるため。

4.3. L3のみの設計

IPルーティングをネットワークのTier 3まで活用するネットワーク設計の人気が高まっている。この設計の主な利点は、L2ブロードキャスト・ドメインを限定することで、ネットワークの安定性と拡張性が向上することにある。通常、このような設計では、Open Shortest Path First (OSPF) [RFC2328]のような内部ゲートウェイ・プロトコル(IGP)をルーティング・プロトコルとして利用する。データセンターの規模が大きくなり、サーバ数が数万を超えると、このような完全にルーティングされた設計がより魅力的になってきた。

L3のみの設計を選択することで、ネットワークを大幅に簡素化し、REQ1とREQ2の実現が容易となったため、ネットワークの拡張性や安定性に比べてそれほど重要ではないネットワークで、大規模なレイヤ2の隣接関係や大規模なレイヤ3のサブネットが広く採用されている。アプリケーション・プロバイダやネットワーク事業者は、さまざまなオーバーレイやトンネリング手法を活用することで、これまで大規模なレイヤ2ドメインを必要としていたいくつかの要件を満たす、新しいソリューションを開発し続けている。

5. ルーティング・プロトコルの設計

このセクションでは、レイヤ3プロトコル設計とClosトポロジーを持つデータセンター・ネットワークにおいて、ルーティング・プロトコルとして外部BGP(EBGP)のみを使用する理由について説明する。次に、EBGPベースのネットワークを設計するための実用的なアプローチを示す。

5.1. ルーティング・プロトコルとしてEBGPを選択する

REQ2は、複雑さと相互依存性を軽減するため、シングル・ルーティング・プロトコルを選択することを優先する。このような状況ではIGPを選択するのが一般的で、WANに接するデバイスにEBGPを追加するか内部BGP(IBGP)を全体的に追加することもあるが、この文書ではEBGPのみを利用する設計を提案する。

EBGPはインターネットにおける、ほぼすべてのドメイン間ルーティングに使われているプロトコルで、ベンダーやサービス・プロバイダの両方のコミュニティから幅広い支持を得ているが、いくつかの理由(そのうちいくつかは相互に関連している)で、データセンター内の主要なルーティング・プロトコルとして一般的に導入されていない。

• BGPは「WAN専用、プロトコル専用」と認識されており、企業やデータセンター・アプリケーションに応用できるとは考えられていない。

• BGPはIGPと比較して、ルーティングの収束が「かなり遅い」と考えられている。

• 大規模なBGP導入では、IBGPトポロジー内のすべてのノードが直接接続されていないため、BGPネクストホップの解決にIGPを利用するのが一般的である。

• BGPは設定オーバーヘッドが大きく、ネイバーの自動検出でさえサポートされていないと考えられている。

本文書では、これらの認識のいくつかについて、特に提案された設計に適用可能なものについて説明し、このプロトコルを使用する利点に注目する。例えば:

• プロトコル設計という点では、BGPは複雑性が少ない。内部データ構造やステート・マシンは、OSPFなどのリンク・ステート型IGPと比較してシンプルである。例えば、隣接関係の形成、隣接関係の維持、フロー制御を実装する代わりに、BGPは基礎となるトランスポートにTCPを採用している。これにより、REQ2とREQ3を満たしている。

• BGP情報のフラッディング・オーバーヘッドは、リンク・ステート型IGPと比較して小さい。すべてのBGPルータは選択されたベスト・パスのみを計算して伝播するため、BGPスピーカが代替パスを見つけるとすぐにネットワーク障害を覆い隠すことができる。これは、Closのような高度にシンメトリックなトポロジーがEBGPのみの設計と組み合わさったものでなければ起こり得ない。これに対し、リンク・ステート型IGPのイベント伝播範囲は障害のタイプに関係なく、エリア全体に及ぶ。このように、BGPはREQ3とREQ4をより適切に満たしている。また、広く導入されているリンク・ステート型IGPはすべて、ルーティング情報の定期的な更新機能を必要とするのに対し、BGPはルーティング状態に有効期限はない。しかも、これは最新のルータのコントロール・プレーンにはほとんど影響しない。

• BGPは、サードパーティの(再帰的に解決可能な)ネクストホップをサポートしている。これにより、ルーティング情報をシステムに注入できるアプリケーション「コントローラ」とのピアリング・セッションを確立することで、アプリケーション定義のパスに基づいて、非ECMPやフォワーディング・ベースのマルチパス操作が可能となり、REQ5を満たすことができる。OSPFは、「フォワーディング・アドレス」などの概念を使用して同様の機能を提供するが、実装はより困難で、情報の伝播範囲の制御がはるかに乏しい。

• 明確に定義された自律システム番号(ASN)割り当てスキームと標準のAS_PATHループ検出を使用することで、「BGPパス・ハンティング」([JAKMA2008]を参照)を制御することができ、複雑で不要なパスを無視できる。ASN割り当てスキームの例についてはセクション5.2を参照のこと。リンク・ステート型IGPで同じ目標を達成するには、マルチ・インスタンス/トポロジー/プロセスのサポートが必要だが、通常、すべてのDCデバイスで利用できるわけではなく、設定とトラブルシューティングが非常に複雑になる。ほとんどのDC設計が利用している従来のシングル・フラッディング・ドメインを使用すると、特定の障害条件下では、複数のTier 2デバイスを横断するなど、望まない長いパスを選択してしまう可能性がある。

• 最小限のルーティング・ポリシーで実装されたEBGPの構成は、ネットワーク到達性問題のトラブルシューティングを容易にする。ほとんどの実装では、BGP Loc-RIBの内容を表示して、ルータのルーティング情報ベース(RIB)と比較するのが簡単である。また、ほとんどの実装で、オペレータはすべてのBGPネイバーのAdj-RIB-InとAdj-RIB-Out構造を見ることができるため、BGPセッションの両側で、送受信のネットワーク層到達性情報(NLRI)を簡単に比較することができる。したがって、BGPはREQ3を満たしている。

⚠️ BGPパス・ハンティングについて

BGPパス・ハンティングとは、特定の経路の変更/消失があったとき、各ルータが新しい経路を探そうとして、大量のBGP UPDATEメッセージの交換と最適パスの再計算を行い、経路収束に遅延が発生する現象をいう。また、誤った経路情報が必要以上に長くネットワーク内に伝搬し、トラフィックのロスが発生する可能性もある。

5.2. ClosトポロジーのEBGP構成

5ステージを超えるClosトポロジーは、このような設計で必要となる相互接続数が膨大になるため、非常に稀である。したがって、以下の例は、5ステージのClosトポロジー(折り畳まない状態)を参考にしている。

5.2.1. EBGP設定ガイドラインとASNスキームの例

以下の図は、ASNの割り当てスキームの例を示している。使用できるガイドラインの一覧は以下のとおりである:

• ネットワーク・ノードを相互接続する直接接続のポイント・ツー・ポイント・リンクを介して、シングル・ホップのEBGPセッションが確立される。同じノード・ペア間に複数リンクがある場合でも、マルチホップ・セッションやループバック・セッションは使用しない。

• ASNの競合を避けるため、64512～65534のプライベートASNを使用する。

• ClosトポロジーのすべてのTier 1デバイスに1つのASNを割り当てる。

• Tier 2デバイスはクラスタ単位でユニークなASNを割り当てる。

• トポロジー内のTier 3デバイス(ToRなど)ごとにユニークなASNを割り当てる。

図4: 5ステージClosのBGP ASNレイアウト

5.2.2. プライベートASN

プライベートASNのオリジナルの範囲[RFC6996]は、オペレータがユニークに利用できるASNを1023個に制限していた。ネットワーク・デバイスの数がこの数を超える可能性が極めて高いため、回避策が必要である。1つのアプローチは、異なるクラスタ間でTier 3デバイスに割り当てられたASNを再利用する。例えば、プライベートASN 65001、65002 ... 65032を個々のクラスタ内で使用し、Tier 3デバイスに割り当てることができる。

ASNの再利用に伴うBGPのAS_PATHループ検出メカニズムによる経路抑制を回避するには、Tier 3デバイスのアップストリームEBGPセッションは、受信した経路広告でデバイス自身のASNを受け入れることを許可する「Allowas-in」機能[ALLOWASIN]を設定する必要がある。この機能は標準化されていないが、複数のベンダーの実装で広く利用可能である。この機能を導入しても、AS_PATHは各トポロジー層のルータによって追加され、AS_PATHの長さはBGPパス選択プロセスの始めのタイブレーカとなるため、設計上ルーティング・ループが発生する可能性が高まるわけではない。さらに、Tier 1デバイスでは、自身のASNを含むパスを持つ経路を受け入れない、ループ保護がまだ行われている。また、Tier 2デバイスは互いにダイレクトの接続性を持たない。

⚠️ Allowas-in機能について

Allowas-in機能とは、ASNの再利用で同じASがASパスに繰り返し含まれることを回避するために通常行われる制限を緩和し、自分のAS番号が含まれている経路でも、受け入れるように設定する機能をいう。特定の状況でASパス・ループのチェックを回避するために使われる。

Ciscoルータでは、neighbor allowas-inコマンドで設定できる。

この問題に対する別の解決策は、4オクテットのASN([RFC6793])を使用することである。追加のプライベートASNが利用可能で、[IANA.AS]を参照のこと。4オクテットASNの使用は、BGP実装にプロトコルの複雑さを加えることになり、REQ3とREQ4を検討する際には、再利用のアプローチの複雑さとバランスを取る必要がある。さらに重要なこととして、4オクテットASNはまだすべてのBGP実装でサポートされているわけではないため、DC機器のベンダーの選択を制限する可能性がある。サポートされている場合、これらのASNへの外部接続 (セクション 5.2.4)が必要なときに、展開された実装がプライベートASNを削除できることを確認すること。

5.2.3. プレフィックス広告

Closトポロジーは、多数のポイント・ツー・ポイント・リンクと関連するプレフィックスを特徴とする。これらの経路をすべてBGPに広告すると、ネットワーク・デバイスのフォワーディング情報ベース(FIB)に過負荷をかける可能性がある。また、これらのリンクを広告することで、BGPコントロール・プレーンに追加のパス計算負荷がかかり、メリットはほとんどない。解決策は2つある:

• ポイント・ツー・ポイント・リンクのプレフィックスをBGPに広告しない。EBGPベースの設計では、デバイスごとにネクストホップ・アドレスを変更するため、遠隔ネットワークは自動的に広告しているEBGPピアを経由して到達可能となり、これらのプレフィックスへの到達性は必要ない。しかし、これにより運用や監視が複雑になる可能性がある。例えば、よく使われる「traceroute」ツールを使用すると、到達できないIPアドレスが表示されることになる。

• ポイント・ツー・ポイント・リンクのプレフィックスを広告するが、それぞれのデバイスで集約する。これは、下位レイヤへのポイント・ツー・ポイント・インタフェース・アドレスに使用されるTier 1とTier 2デバイスごとに連続したIPアドレス・ブロックを割り当てるなどのアドレス割り当てスキームが必要となる(Tier 2アップリンクはTier 1アドレス・ブロックから割り当てる、など)。

Tier 3デバイス上のサーバのサブネットは、Tier 2およびTier 1デバイス上で経路集約を使用せずにBGPにアナウンスしなければならない。Closトポロジー内でサブネットを集約すると、Tier 2デバイスとTier 3デバイス間などのリンク障害で経路ブラックホールが発生する原因となり、これは避けなければならない。同じレイヤ内でピア・リンクを使用する「バイパス・パス」を提供することで、ブラックホール問題を解決することは可能だが、ピアリング・メッシュのO(N^2)の複雑さとデバイス上のポートが無駄になるため望ましくない。ピア・リンクのフルメッシュに代わるものとして、より単純なバイパス・トポロジーを使用することもできる。例えば、[FB4POST]で説明している「リング」だが、このようなトポロジーは余分なホップを追加し、帯域幅が制限される。BGPルーティングを機能させるには、各デバイスを独自のASNに分割するなど、特別な調整が必要になるかもしれない。この文書の後のセクション8.2では、Closネットワークで限定的な形の経路集約を実行するための、侵襲性の少ない方法を紹介し、それに伴うトレードオフについて説明する。

⚠️ Unnumbered BGP

BGP Unnumberedとは 「ルータのインタフェースに固定アドレスを割り当てずにBGPピアをUPさせる」機能をいう。Closトポロジーでは、スイッチ間のBGP接続に、IPv6リンクローカル・アドレスを使用して自動的にBGPピアを形成することができる。これにより、Clos内の多数のスイッチ間リンクのアドレス設計や管理が不要となる。なお、IPv6ネットワーク上でIPv4ユニキャストの経路広告を可能にするRFC 5549のサポートも必要となる。

5.2.4. 外部との接続

ワイド・エリア・ネットワーク(WAN)のエッジ・デバイスやWANルータに接続する目的で、Closトポロジーの専用クラスタ(または複数のクラスタ)を使用することができる。このようなクラスタのTier 3デバイスはWANルータに置き換えられ、EBGPピアリングが再び使用されることになるが、インターネット接続が設計上必要な場合、WANはパブリックASNに属する可能性が高い。この文書では、このような専用クラスタのTier 2デバイスを「ボーダー・ルータ」と呼ぶ。これらのデバイスは、いくつかの特別な機能を実行しなければならない。

• WANルータへのパスを広告する際にネットワーク・トポロジー情報を隠蔽する。つまり、AS_PATH属性からプライベートASN[RFC6996]を削除する。これは通常、異なるデータセンター間でASN番号の衝突を回避し、トポロジー内で生成されたエニーキャスト・プレフィックスへのWAN ECMPの目的で、WANに均等なAS_PATH長を提供するために行われる。これを実現するには、通常「プライベートASの削除」と呼ばれる実装固有のBGP機能が使われる。実装によっては、この機能はネイバーへのパスを広告する前に、AS_PATH属性で見つかったプライベートASNの連続したシーケンスを削除する必要がある。これは、データセンター内のナンバリングに使用されるすべてのASNがプライベート使用の範囲内にあることを前提としている。プライベートASNを削除するプロセスは現在標準化されていない。[REMOVAL]を参照のこと。ただし、ほとんどの実装は、少なくともこのベンダーの文書[VENDOR-REMOVE-PRIVATE-AS]に記載されているロジックに従っており、記載されている設計はこれで十分である。

• データセンターのデバイスへのデフォルト経路を生成する。未修正のClosトポロジーでは、経路集約はリスクがあるため、ボーダー・ルータがデフォルト経路を生成できる唯一の場所である。もしくは、ボーダー・ルータは、WANルータから学習したデフォルト経路を中継する方法もある。ボーダー・ルータからデフォルト経路を広告するには、トラフィックのブラックホール化を引き起こす単一リンク障害に対する耐性を提供する必要があり、すべてのボーダー・ルータがアップストリームのWANルータに完全に接続されている必要がある。WANルータへのEBGPセッションが、特定のデバイス上で同時にすべて失敗した場合のブラックホール化を防ぐには、一部の実装 [CONDITIONALROUTE]で提供されている複雑な条件付き経路生成スキームを使用してデフォルト経路を生成するよりは、WANルータからのデフォルト経路を再広告する方が望ましい。

5.2.5. エッジでの経路集約

完全にルーティングだけにしたネットワーク設計において、データセンター内で大量のIPプレフィックスを生成するには、WANネットワークに広告する前にネットワーク到達性情報を集約した方が望ましい場合が多い。例えば、2000台のTier 3デバイスを持つネットワークでは、インフラストラクチャ・プレフィックスと一緒に、少なくとも2000台のサーバ・サブネットがBGPで広告されることになる。ただし、セクション5.2.3で説明したように、提案するネットワーク設計では、各Tierでのピア・リンクが不足しているため、経路集約は許していない。

しかし、ボーダー・ルータに別の接続モデルを考案することで、この制限を解除できる。可能なオプションは2つある:

• フル・メッシュの物理リンクか、リングやハブ・アンド・スポーク型など他の「ピア・メッシュ」トポロジーを使用して、ボーダー・ルータを相互接続する。すべてのボーダー・リーフでBGPを適切に設定して、ネットワーク到達性情報を交換する(例えば、IBGPセッションのメッシュを追加するなど)。相互接続するピア・リンクは、ボーダー・ルータを接続するメッシュ内のデバイスまたはリンクに障害が発生した場合に発生するトラフィックに合わせて適切なサイズにする必要がある。

• Tier 1デバイスは、ボーダー・ルータ(Tier 1の観点からはTier 2デバイス)に対して、追加の物理リンクがプロビジョニングすることができる。具体的には、単一のリンクまたはノードの障害の保護が必要であれば、各Tier 1デバイスは少なくとも2台のボーダー・ルータに接続する必要がある。これにより、Tier 1デバイスとボーダー・ルータのポート数に追加の要件が課せられ、Clos内の他のデバイスと比較して、不均一でポート数の多いデバイスになる可能性がある。また、これにより、「通常の」Tier 2スイッチで利用可能なポート数を減らすことにもなり、Tier 1を介して相互接続できるクラスタの数も減ることになる。

上記のオプションのいずれかが実装されている場合、単一のリンク障害でルーティングのブラックホール化リスクを冒すことなく、ボーダー・ルータでWANネットワーク・コアへの経路集約を行うことができる。いずれのオプションも、一部のネットワーク・デバイスに追加リンクをプロビジョニングする必要があるため、不均一なトポロジーとなってしまう。

6. ECMPに関する考慮事項

このセクションでは、Closトポロジーのイコール・コスト・マルチパス(ECMP)機能を扱い、いくつかの特別な要件について説明する。

6.1. 基本的なECMP

ECMPは、Closトポロジーで使用する基本的な負荷分散メカニズムである。実際には、それぞれの下位層デバイスは、直接接続された上位層デバイスを使って、同じIPプレフィックス宛てのトラフィックを負荷分散する。Closトポロジーにおける任意の2台のTier 3デバイス間のECMPパスの数は、中間ステージ(Tier 1)のデバイスの数に等しくなる。例えば、図5のトポロジーでは、Tier 3デバイスAが、Tier 2デバイスBとCを経由して、それぞれサーバXとYに到達し、次にTier 1デバイス1、2、3、4を経由してサーバXとYに到達する4つのパスを持つ。

図5: AからXおよびYへのECMPファンアウト・ツリー

ECMPの要件は、BGP実装がトポロジーの任意のポイントでアップストリームまたはダウンストリーム方向に直接接続された最大数のデバイスに対して、マルチパス・ファンアウトをサポートしなければならない。通常、この数はトポロジー内のデバイスに搭載されたポート数の半分を超えることはない。例えば、64ポートのデバイスを使用してClosネットワークを構築する場合、32のECMPファンアウトが必要となる。セクション5.2.5で説明したように、ボーダー・ルータ・レベルで経路集約を実装している場合、ボーダー・ルータは、多数のTier 1デバイスに接続できるように、より広いファンアウトが必要になる可能性がある。デバイスのハードウェアがより広範なECMPをサポートしていない場合、論理リンクのグループ化(レイヤ2でのリンク・アグリゲーション)を使用して、ファンアウトの制限を補う「階層型」ECMP(レイヤ3のECMPとレイヤ2のECMPの組み合わせ)を提供することができる。しかし、このアプローチは、ECMPの2 ステージ目で利用できるエントロピーが小さくなるため、フローの偏りが発生するリスクが高まる。

ほとんどのBGP実装は、[RFC4271]のセクション9.1.2.2のステップ(e)まで一致していれば、ECMPの観点からパスが等しいと宣言する。提案されているネットワーク設計では、基本となるIGPが存在しないため、すべてのIGPコストはゼロか、そうでなければ、すべてのパスで同じ値となり、必要に応じてポリシーを適用して、ベンダーのデフォルトで異なるBGP属性(MULTI_EXIT_DISC(MED)属性やオリジン・コードなど)を均一化することもできる。歴史的な理由から、MED値を均等化する際に0を使用しないことも有用である。これと他の有用なBGP情報は、[RFC4277]で入手できる。BGPの最適パス選択プロセス(AS_PATHの長さが短い方が望ましい)によりルーティング・ループが発生する可能性は低く、Tier 1デバイス(パスに自身のASNを許可しない)を介した長いパスが生じることはない。

⚠️ RFC 4271のセクション9.1.2.2

9.1.2.2. タイブレーク (フェーズ 2)

Adj-RIBs-Inにおいて、BGPスピーカーは同じ優先度を持つ同じ宛先への複数の経路を持っているかもしれない。ローカル・スピーカーは、これらの経路のうち1つだけを選択して、関連するLoc-RIBに含めることができる。ローカル・スピーカーは、内部ピアから受信した経路と外部ピアから受信した経路も、同じ優先度を持つすべての経路を考慮する。

以下のタイブレーク手順は、候補経路ごとに自律システム内のすべてのBGPスピーカーが、経路のNEXT_HOP 属性で示されるアドレスへのパスのコスト(内部距離)を確認でき、同じ経路選択アルゴリズムに従うことを前提とする。

タイブレーク・アルゴリズムは、同じ宛先への等しく好ましい経路をすべて考慮することから始まり、次に考慮から除外する経路を選択する。考慮すべき経路が1つだけになると、アルゴリズムは終了する。この基準は、指定された順序で適用しなければならない(MUST)。

いくつかの基準は、擬似コードを使用して説明されている。示された擬似コードは、効率性ではなく、分かりやすさのために選択していることに留意する。これは特定の実装を指定するものではない。BGPの実装は、ここで説明されているものと同じ結果を生成する任意のアルゴリズムを使用できる(MAY)。

a) AS_PATH属性に存在するAS番号の数が最も少ない経路以外をすべて考慮から除外する。この数を数えるとき、AS_SET内のASの数に関係なく、AS_SETは1とカウントされることに留意する。

b) Origin属性のOrigin番号が最も小さい経路以外をすべて考慮から除外する。

c) 優先されないMULTI_EXIT_DISC属性を持つ経路を考慮から除外する。MULTI_EXIT_DISCは、同じ隣接ASから学習した経路間でのみ比較できる(隣接ASはAS_PATH属性から決定する)。MULTI_EXIT_DISC属性を持たない経路は、可能な限り低いMULTI_EXIT_DISC値を持つと見なされる。

これについては、以下の手順でも説明する。

for m = すべての経路がまだ検討中
    for n = すべての経路がまだ検討中
        if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m))
            経路mを検討対象から除外

上記の疑似コードでは、MED(n)は経路nのMULTI_EXIT_DISC属性の値を返す関数である。経路nにMULTI_EXIT_DISC属性がない場合、関数は可能な限り低いMULTI_EXIT_DISC値(つまり0)を返す。

同様に、neighborAS(n)は経路を受信した隣接ASを返す関数である。経路がIBGP経由で学習し、他のIBGPスピーカーが経路を生成していない場合、これは他のIBGPスピーカーが経路を学習した隣接ASとなる。経路がIBGP経由で学習され、他のIBGPスピーカーが (a) 経路を生成したか、(b) 集約によって経路を作成し、集約経路のAS_PATH属性が空かAS_SETで始まる場合、それはローカルASである。

IBGPに経路を再広告する前にMULTI_EXIT_DISC属性が削除された場合でも、受信したEBGP MULTI_EXIT_DISC属性に基づく比較は実行できる(MAY)。実装でMULTI_EXIT_DISCを削除することを選択した場合、MULTI_EXIT_DISCに関するオプションの比較(実行する場合)は、EBGPで学習した経路間でのみ実行しなければならない(MUST)。MULTI_EXIT_DISC属性を削除した後、EBGPで学習した最適な経路をIBGPで学習した経路と比較することができる。EBGP学習済み経路のサブセットから MULTI_EXIT_DISCが削除され、選択された「最適な」EBGP学習済み経路から MULTI_EXIT_DISCが削除されない場合は、IBGP学習済み経路との比較でMULTI_EXIT_DISCを使用しなければならない(MUST)。IBGP学習済み経路の場合、決定プロセスのこのステップに到達する経路比較でMULTI_EXIT_DISCを使用しなければならない(MUST)。IBGP学習済み経路との比較にEBGP学習済み経路のMULTI_EXIT_DISCを含め、その後MULTI_EXIT_DISC属性を削除して経路を広告すると、経路ループが発生することが証明されている。

d) 候補経路の少なくとも1つがEBGP経由で受信した場合、IBGP経由で受信したすべての経路を考慮から除外する。

e) 優先順位の低い内部コストを持つルートを考慮から除外する。経路の内部コストは、ルーティング・テーブルを使用して経路のNEXT_HOPへのメトリックを計算することによって決定する。経路のNEXT_HOPホップで到達可能だが、コストを決定できない場合は、この手順をスキップする必要がある(つまり、すべての経路のコストが等しいと見なす)。

これは、以下の手順でも説明する。

for m = すべてのルートがまだ検討中
    for n = すべてのルートがまだ検討中
        if (cost(n)がcost(m)より低い)
            mを考慮から除外する

上記の疑似コードにおいて、cost(n)は、経路のNEXT_HOP属性で指定されたアドレスまでのパスのコスト(内部距離)を返す関数である。

f) BGP識別子の値が最も低いBGPスピーカーから広告された経路以外のすべての経路を考慮から除外する。

g) 最も低いピア・アドレスから受信した経路を優先する。

6.2. 複数のASNを介したBGP ECMP

アプリケーションの負荷分散を目的とする場合、複数のTier 3デバイスから同じプレフィックスを広告することが望ましい。他のデバイスの観点からは、このようなプレフィックスはAS_PATH属性の長さは同じだが、異なるAS_PATH属性値を持つBGPパスを持つことになる。したがって、BGP実装は、このようなパスに対する負荷分散をサポートする必要がある。この機能は、「マルチパス・リラックス」または「マルチパス・マルチAS」と呼ばれることもあり、前のセクションですでに説明したように、他の属性がすべて同じであれば、異なるネイバーASN間でECMPを効果的に実行できる。

⚠️ マルチパス・リラックス

マルチパス・リラックスとは、異なるASから学習した経路情報を使用してECMPを実現する機能をいう。Ciscoの場合、bgp bestpath as-path multipath-relaxコマンドを使用する。

6.3. 重み付けECMP

ECMPファンアウトの中の一部のパスに多くのトラフィックを送信できるように、ネットワーク・デバイスに「重み付け」ECMPの実装が望ましい場合がある。これは、ネットワークの障害を保障し、容量の大きいパスに多くのトラフィックを送信するのに役立つ可能性がある。重み付けECMPを必要とするプレフィックスは、セクション8.1でさらに詳しく説明しているように、マルチホップ・セッションを介してリモートBGPスピーカ(中央エージェント)を通じて注入しなければならない。実装がサポートしていれば、[LINK]で説明されている技術を使用して、複数のBGPパスに対する重み付けを通知することができる。

⚠️ BGPリンク帯域幅拡張コミュニティ

重み付けECMPに関連し、負荷分散を行う複数リンクが必ずしも同じ帯域幅とは限らない。そこで、ルータに帯域幅を通知して帯域幅に応じて負荷分散させるためのBGP拡張コミュニティーがIETFドラフトで提案されている。

6.4. 一貫性のあるハッシュ法

ECMPに用いられるハッシュ関数を一貫性のあるものにすることが望ましい場合が多くある([CONS-HASH]を参照)。これは、ECMPグループにネクストホップが追加または削除された際に、ネクストホップの親和性(アフィニティ)の変更によるフローへの影響を最小限に抑えるためである。ネットワーク・デバイスがロード・バランサとして使用され、複数の宛先へのフローをマッピングしている場合に使用できる。この場合、宛先が失われたり追加されたりしても、現在確立されているフローに悪影響を及ぼさない。一貫性のあるハッシュ法の実装に関する推奨事項は[RFC2992]に記載されているが、他の実装でも可能である。この機能は、ネクストホップの重みに比例して、ネクストホップの変化の影響が大きくなる重み付けECMPと自然に組み合わせることができる。一貫性のあるハッシュ法の欠点は、一貫性のあるハッシュ関数を実装するには通常、より多くのリソース(例えば、三値連想メモリ(TCAM)空間など)が必要になるため、ハードウェア・リソースの負荷が増大することである。

7. ルーティングの収束特性

このセクションでは、提案した設計におけるルーティングの収束特性を説明する。実装が高速なEBGPピアリング・セッションの非アクティブ化と、関連リンクの障害発生時のタイムリーなRIBおよびFIBの更新をサポートしている場合、1秒未満の収束(コンバージェンス)が実現可能であることを示す。

7.1. 障害検出のタイミング

BGPは通常、AS内のリンク/ノード障害を回避する経路選択でIGPを頼りにしており、IGPの状態変化に関する更新情報を取得するために、ポーリング・ベースまたはイベント駆動型のメカニズムを実装している。提案しているルーティング設計ではIGPを使用しないため、障害検出に利用できるメカニズムは、BGPのキープアライブ・タイムアウト(またはその他のタイプのキープアライブ・メカニズム)とリンク障害トリガーのみとなる。

BGPキープアライブ・パケットだけに頼ると、収束時間が数秒単位で大きくなる可能性がある(多くのBGP実装では、設定可能なBGPホールド・タイマーの最小値は3秒である)。しかし、多くのBGP実装では、BGPピアリングに使用される発信インタフェースの「リンク・ダウン」イベントに反応して、ローカルのEBGPピアリング・セッションをシャットダウンできる。この機能は、「高速フォールオーバー」と呼ばれることもある。最新のデータセンターのリンクは主にポイント・ツー・ポイントの光ファイバ接続であるため、物理インタフェースの障害はミリ秒単位で検出され、BGPの再収束のトリガーとなる。

イーサネット・リンクは、[IEEE8021Q]で説明されている接続障害管理(CFM)のような障害信号や障害検出の標準をサポートしている場合がある。これにより、障害検出がより確実になる。また、プラットフォームによっては、双方向フォワーディング検出(BFD)[RFC5880]をサポートし、1秒未満の障害検出とBGPプロセスへの障害通知を可能にしているものもある。しかし、これらのいずれの機能も、ベンダーのソフトウェアや、場合によってはハードウェアに追加の要件が課せられ、REQ1と相反する可能性がある。[RFC7130]が公開されるまでは、BFDはLAG上の単一メンバー・リンクの障害を検出することができなかったため、一部の設計ではその有用性が制限されていた。

7.2. イベント伝播のタイミング

提案する設計では、[RFC4271]のセクション9.2.1.1で規定しているように、BGPのMinRouteAdvertisementIntervalTimer (MRAIタイマー)の影響を考慮する必要がある。標準によると、連続するBGP UPDATEメッセージの間隔を少なくともMRAI秒空けることをBGPの実装に要求しており、多くの場合、この値は設定可能である。撤回経路を伝播するイベント後の最初のBGP UPDATEメッセージは通常、このタイマーの影響を受けない。MRAIタイマーは、BGPスピーカーがピアから新しいパスを学習するのを「待機」し、ローカルにバックアップ・パス情報がない場合に、収束に大きな遅延を引き起こす可能性がある。

⚠️ MRAIタイマーについて

BGPには，無駄な経路計算を減らすためのMRAI(最小経路広告インターバル)という仕組みがある。BGP Updateを送信する前に一定時間待機し、ネットワークの拡張や障害などでBGP経路の変化が短時間に大量に発生する可能性があるため、ピアへの経路計算負荷を軽減する。MRAIを設定することで、経路収束が遅くなったり、一時的にブラックホール化が発生するリスクがある。

	IBGP	EBGP
Cisco	5s	30s
Junos	0s	0s
Quagga	5s	30s

Closトポロジーでは、各EBGPスピーカーは通常、同じプレフィックスに対して1つのパス(Tier 2デバイスは同じASNの同じクラスタ内の他のTier 2からのパスを受け入れない)、またはN個のパス(Nは非常に大きな数で、例えばN=32 (次のTierへのECMPファンアウト))を持っている。そのため、パスを受信した対向デバイスへのリンクに障害が発生した場合、バックアップ・パスがまったくないか(例えば、Tier 2スイッチがTier 3デバイスへのリンクを失った場合)、BGP Loc-RIBでバックアップがすぐに利用可能になっている(例えば、Tier 2デバイスがTier 1スイッチへのリンクを失った場合)。前者の場合、BGP撤回アナウンスは遅延なく伝播し、影響を受けるデバイスで再収束のトリガーとなる。後者の場合、最適パスが再評価され、新しいネクストホップに対応するローカルECMPグループが変更される。BGPパスが前に選択した最適パスだった場合、BGP AS_PATH属性が変更されるため、[RFC4271]のセクション3.1のオプションbで説明しているように、BGP UPDATEメッセージによって「暗黙の撤回 (implicit withdraw)」が送信される。

7.3. Closトポロジー・ファンアウトの影響

Closトポロジーには巨大なファンアウトが存在し、このセクションで説明するように、場合によっては「アップ→ダウン」時の収束に影響を与える可能性がある。Tier 3デバイスとTier 2デバイス間のリンクに障害が発生した場合、Tier 2デバイスはすべてのアップストリームのTier 1デバイスにBGP UPDATEメッセージを送信し、影響を受けるプレフィックスを撤回する。Tier 1デバイスは、これらのメッセージをすべてのダウンストリームのTier 2デバイス(発信元を除く)に中継する。その後、UPDATEを発信したデバイス以外のTier 2デバイスは、影響を受けるプレフィックスを削除し、接続されているTier 3デバイスに対応するUPDATEをダウンストリームに送信する前に、すべてのアップストリームのTier 1デバイスがUPDATEメッセージを送信するのを待つ必要がある。元のTier 2デバイスや中継するTier 1デバイスがUPDATEメッセージのアナウンスに遅延を発生させた場合、結果としてUPDATEメッセージを「撒き散らす(dispersion)」可能性がある。これは数秒に及ぶ可能性がある。このような動作を回避するには、BGPの実装で「更新グループ (update groups)」をサポートしなければならない。「更新グループ」は、同じアウトバウンド・ポリシーを共有するネイバーの集合を定義し、ローカル・スピーカーはグループのメンバーにBGP更新を同時に送信する。

このような「撒き散らし」の影響は、トポロジーのファンアウトのサイズに応じて大きくなり、ネットワークの収束がチャーンする(激しくなる)につれて大きくなる可能性がある。オペレータの中には、プレフィックスが急速にフラッピングすることによるコントロール・プレーンへの影響を軽減するため、ベンダーが搭載している「経路フラップ・ダンピング」機能を導入したくなるかもしれない。しかし、このような「撒き散らし」事象において、これらの実装の誤検知問題があるため、この設計でこの機能を有効にすることは推奨しない。「経路フラップ・ダンピング」に関する詳細な背景と問題点、およびこれに影響を与える可能性のある実装変更については、[RFC7196] で詳しく説明している。

7.4. 障害の影響範囲

障害が発生した時に、障害の影響範囲内にあるすべてのデバイスに対してイベントが通知され、RIBが再計算され、その結果FIBが更新されると、ネットワークは障害に対応して収束したと宣言する。障害の影響範囲が大きいと、通知するデバイスが増えるため、収束が遅くなり、ネットワークの安定性が低下する。このセクションでは、BGPがリンク・ステート型ルーティング・プロトコルに比べて、Closトポロジーの障害影響範囲を小さくできる点で有利なことを説明する。

BGPは、ローカル・ルータから見た時の最適パスだけがネイバーに送信されるという点で、距離ベクトル・プロトコルのように動作する。そのため、ローカル・ノードがすぐにバックアップ・パスを見つけ、それ以上の更新を送信する必要がない場合、一部の障害は隠蔽される。最悪の場合、データセンターのトポロジー上のすべてのデバイスがプレフィックスを完全に撤回するか、FIB内のECMPグループを更新しなければならないことに留意すること。しかし、多くの障害は、それほど広範囲に影響を及ぼすことはない。影響範囲が小さくなる障害のタイプが2つある。

• Tier 2とTier 1デバイス間のリンクの障害: この場合、Tier 2デバイスは影響を受けたECMPグループを更新し、障害が発生したリンクを削除する。BGPのプロセスで最適パスとして選択していない限りは、ダウンストリームのTier 3デバイスに新しい情報を送信する必要はない。その場合、「暗黙の撤回 (implicit withdraw)」のみを送信する必要があるが、フォワーディングに影響しない。影響を受けたTier 1デバイスは、特定のクラスタに到達するパスだけを失い、関連するプレフィックスを撤回しなければならなくなる。このようなプレフィックス撤回プロセスは、影響を受けたTier 1デバイスに直接接続されているTier 2デバイスにのみ影響を受ける。プレフィックスの撤回を通知するBGP UPDATEメッセージを受信したTier 2デバイスは、ECMPグループを更新するだけでよい。Tier 3デバイスは再収束プロセスには関与しない。

• Tier 1デバイスの障害: この場合、障害が発生したノードに直接接続しているすべてのTier 2デバイスは、ローカル・クラスタ以外のすべてのIPプレフィックスに対して、ECMPグループを更新する必要がある。Tier 3デバイスは、再収束プロセスには関与しないが、前述の「暗黙の撤回」を受け取る可能性がある。

このような障害が発生し、複数のIPプレフィックスをFIBで再プログラムしなければならなくても、これらのプレフィックスはすべて、Tier 2デバイス上の1つのECMPグループを共有していることに留意する必要がある。したがって、階層型FIBを使用する実装の場合、FIBに対して1回の変更を加えるだけで済む。ここでの「階層型FIB」とは、ネクストホップのフォワーディング情報がプレフィックス・ルックアップ・テーブルとは別に格納され、後者はそれぞれのフォワーディング情報へのポインタのみを格納するFIB構造を意味する。FIB階層と高速コンバージェンスについては、[BGP-PIC]を参照のこと。

提案する設計では、BGPを使用することで、場合によっては障害の影響範囲を小さくすることはできるが、集約を使用して障害領域をさらに縮小することが常に可能というわけではない。なぜなら、この手法を使用すると、前述の通りルーティング・ブラックホールが生じる可能性があるからだ。したがって、コントロール・プレーンにおける最悪の障害影響範囲は、ネットワーク全体となる。例えば、Tier 2とTier 3デバイス間のリンク障害の場合などだ。この場合の影響を受けるプレフィックスの数は、Closネットワーク・トポロジーの 上位レイヤで障害が発生した場合よりもはるかに少ない。このような広範囲にわたる障害が発生する特性は、EBGPを選択した設計の結果ではなく、むしろClosトポロジーを選択した結果である。

7.5. ルーティング・マイクロループ

ダウンストリームのデバイス(例えば、Tier 2デバイス)がプレフィックスに対するすべてのパスを失ったときのために、通常はアップストリームのデバイス(この場合、Tier 1デバイス)へのデフォルト経路を持つ。その結果、Tier 2スイッチはプレフィックスを失うが、Tier 1スイッチは依然としてTier 2デバイスを指すパスを持ったままという状況が発生する可能性がある。この状況は一時的なマイクロループで、Tier 1スイッチは影響を受けたプレフィックスのパケットをTier 2デバイスに送り続け、Tier 2はデフォルト経路を使用してパケットを再び送り返す。マイクロループは、アップストリームのデバイスがフォワーディング・テーブルを完全に更新するまで継続する。

このようなマイクロループの影響を最小限に抑えるために、ネットワークの収束中に失われたプレフィックスのデフォルト経路よりもモア・スペシフィックな静的な「破棄 (discard)」または「null」経路を、Tier 2およびTier 1 スイッチに設定することが有効である。Tier 2スイッチの場合、破棄経路は、基盤となるTier 3デバイスのすべてのサーバ・サブネットをカバーするサマリー経路であるべきだ。Tier 1デバイスの場合、破棄経路は、データセンター全体に割り当てられたサーバのIPアドレス・サブネットをカバーするサマリー経路であるべきだ。これらの破棄経路は、デバイスが新しいパスを介してモア・スペシフィックなプレフィックスを学習するまで、ネットワーク収束中だけ優先される。

8. 設計の追加オプション

8.1. サードパーティ経路の注入

BGPでは、「サードパーティ」、つまり直接接続されたBGPスピーカーが、ネットワーク・トポロジーの任意の場所に経路を注入することができ、REQ5を満たすことができる。これは、トポロジー内の一部またはすべてのデバイスとのマルチホップBGPセッションを介したピアリングによって実現できる。それに加えて、負荷分散を容易にするため、同じプレフィックスに対して複数のBGPネクストホップを注入し、BGP diverse path distribution[RFC6774]を使うことで、実装がサポートされていればBGP ADD-PATH機能[RFC7911]を使用することができる。残念ながら、多くの実装で、ADD-PATHはもともと最適化されていたユースケースおいてのみIBGPを適切にサポートすることが分かっている。そのため、「サードパーティ」のピアリングはIBGPのみに制限される。

提案する設計で経路注入を実装するには、サードパーティのBGPスピーカーがTier 3およびTier 1スイッチとピアリングし、同じプレフィックスを注入するが、Tier 1デバイスには特別なBGPネクストホップを使用する。これらのネクストホップはBGPで再帰的に解決されると想定され、例えばTier 3デバイスのIPアドレスの可能性がある。その結果、フォワーディング・テーブルのプログラミングにより、異なるクラスタ間で必要となるトラフィック比率の分散が提供できる。

8.2. Closトポロジー内での経路集約

前述の通り、提案するClosトポロジーでは、単一リンク障害時にネットワークがブラックホール化の影響を受けやすくなるため、経路集約はできない。主な問題は、ネットワークの構成要素間の冗長パスの数が限られることである。例えば、Tier 1とTier 3のデバイスの任意のペア間には、1つのパスしかない。しかし、一部のオペレータは経路集約をコントロール・プレーンの安定性を向上させるために望ましいと考えている。

トポロジーで経路集約する手法を考える場合、単一または複数のリンク障害に対してだけでなく、物理的に離れた場所にトポロジーを拡張する場合の光ファイバのパスウェイ障害や光学的ドメインの障害についても、ルーティング動作とブラックホール化の可能性をモデル化する必要がある。外部接続が存在する場合にはWANルータだけでなく、各階層のデバイス間のリンクまたはパスウェイ障害が発生した場合に、集約を行うデバイスの到達性を確認することで簡単なモデル化を行うことができる。

ネットワーク・トポロジーに若干の修正を加えれば、経路集約は可能になるが、その代償として、特定の障害が発生した場合に、ネットワーク全体のサイズが縮小するだけでなく、ネットワークの輻輳も発生する。このアプローチは、ボーダー・ルータがデータセンターのアドレス空間全体を集約できるようにする上述の手法と非常によく似ている。

8.2.1. Tier 1デバイスの階層縮小

Tier 1とTier 3デバイス間のパスをさらに追加し、Tier 2デバイスをペアにグループ化し、そのペアを同じTier 1デバイスのグループに接続する。これは論理的には、Tier 1デバイスを半分のサイズに「縮小」し、「縮小」したデバイス上のリンクを統合することと同等である。その結果を図6に示す。例えば、このトポロジーでは、DEV CとDEV Dは同じTier 1 デバイス(DEV 1とDEV 2)に接続しているが、以前は異なるTier 1デバイスのグループに接続していた。

図6: 5ステージClosトポロジー

この設計を行うには、Tier 2デバイスはTier 3デバイスにデフォルト経路のみを広告するように設定する。Tier 2とTier 3の間のリンクに障害が発生した場合、トラフィックはTier 2スイッチが認識している2番目の利用可能なパスを経由して再ルーティングされる。Tier 2デバイスから1つのクラスタのプレフィックスをカバーする集約経路を広告することはまだできない。なぜなら、各デバイスにはこのプレフィックスへの単一パスしかないからだ。これを実現するには、デュアル・ホーム・サーバが必要となる。また、この設計は単一のリンク障害に対してのみ耐性があることにも留意する。二重リンク障害により、特定のTier 3デバイスへのすべてのパスからTier 2デバイスが分離され、ルーティング・ブラックホールが発生する可能性がある。

提案したトポロジーの変更の結果、Tier 1デバイスのポート容量が減少することになる。これにより、接続可能なTier 2デバイスの最大数が制限され、したがってDCネットワークの最大サイズも制限される。この修正を実装し、ネットワークを大規模にしたい場合は、よりポート密度の高い別のTier 1デバイスが必要となる。

もう1つの問題は、リンク障害時のトラフィックの再調整である。Tier 1からTier 3へのパスが2つあるため、Tier 1とTier 2スイッチ間のリンクに障害が発生すると、障害が発生したリンクを経由していたすべてのトラフィックが残りのパスに切り替わる。これにより、残ったリンクの利用率が2倍になる。

8.2.2. シンプルな仮想集約

コントロール・プレーンが完全なルーティング情報を伝達できるようにしながら、FIBサイズを小さくすることが主な目的なら、経路集約に対するまったく異なるアプローチが可能である。まず、多くの場合、複数のプレフィックス(その一部はレス・スペシフィック)が、同じネクストホップを共有している、つまり同じECMPグループに所属していることが簡単に分かる。例えば、Tier 3デバイスの観点からは、ネットワークに障害が発生していなければ、デフォルト経路を含むアップストリームのTier 2デバイスから学習したすべての経路は、同じBGPネクストホップを共有することになる。これにより、[RFC6769]で説明している場合と同様の手法を使用することが可能になり、モア・スペシフィックな経路が同じネクストホップを共有している場合は、それらを無視して、最もレス・スペシフィックな経路のみをFIBにインストールする。例えば、通常のネットワーク環境では、デフォルト経路のみをFIBにプログラムする必要がある。

それに加えて、Tier 2デバイスが、接続されているすべてのTier 3デバイスのプレフィックスをカバーする集約プレフィックスを設定している場合、同じロジックをTier 1デバイスにも適用でき、異なるクラスタのTier 2/Tier 3スイッチにも適用できる。これらの集約経路は、特定のリンクに障害が発生した場合にネクストホップの不一致を検出できるように、モア・スペシフィックなプレフィックスをTier 1デバイスにリークする必要がある。これにより、特定のプレフィックスのネクストホップが変更される。

もう一度繰り返すと、この手法はコントロール・プレーンの状態の量(つまり、BGP UPDATE、BGP Loc-RIBサイズ)を削減するためのものではなく、モア・スペシフィックなプレフィックスを検出し、モア・スペシフィックなプレフィックスにネクストホップを共有する包括的なプレフィックスを特定することで、より効率的なFIBの利用を可能にするだけのことである。

8.3. ICMP到達不能メッセージの偽装

このセクションでは、セクション5.2.3でオプションとして挙げられた、ポイント・ツー・ポイント・リンクのサブネットをBGPに広告しないことの運用面について説明する。この決定による運用上の影響は、よく知られた「traceroute」ツールを使用すると確認できる。具体的には、ツールによって表示されるIPアドレスはリンクのポイント・ツー・ポイント・アドレスになるため、管理用ネットワークから到達できない。そのため、一部のトラブルシューティングが複雑になる。

この制限を克服する1つの方法は、DNSサブシステムを使用して、これらのポイント・ツー・ポイントのIPアドレスの「逆引き」エントリを作成し、ループバック・アドレスと同じ名前を指すようにすることである。これにより、この名前をデバイスの「プライマリ」IPアドレス(例えば、常にBGPに広告されるループバック・インタフェース)に解決することで接続を確立できる。ただし、この方法ではDNSサブシステムへの依存関係が作られ、障害中に利用できなくなる可能性がある。

もう一つのオプションは、ネットワーク・デバイスにIPアドレスをマスカレードさせる。つまり、デバイスが送信する適切なICMPメッセージのソースIPアドレスを、デバイスの「プライマリ」IP アドレスに書き換える。具体的には、「traceroute」ツールを正しく動作させるには、ICMP宛先到達不能メッセージ(タイプ3)コード3(ポート到達不能)とICMP時間超過(タイプ11)コード0の変換が必要である。この修正を行うことで、デバイスに送信された「traceroute」プローブは常に「プライマリ」IPアドレスを送信元として返送されるため、オペレータはボックスへの「到達可能な」IPアドレスを知ることができるようになる。この手法には、デバイスへの「エントリ・ポイント」のアドレスが隠されてしまうという欠点がある。デバイスが[RFC5837]をサポートしている場合、戻りアドレスが「プライマリ」IPアドレスであっても、着信インタフェースに関する情報を提供することで、両方の長所を最大限に活かすことができる。

9. セキュリティに関する考慮事項

この設計によって、セキュリティ上の新たな懸念が生じることはない。一般的なBGPセキュリティに関する考慮事項については、[RFC4271]および[RFC4272]で説明している。DCは単一のオペレータが管理する領域であるため、この文書では、DCの境界外からのBGPセッション自体に対する攻撃を防ぐためにエッジ・フィルタリングが実装されていることを前提としている。これは、[RFC2385]で説明されているTCP MD5の鍵管理に対処したり、本文書の公開時点で利用可能なTCP認証オプション[RFC5925]の実装不足に対処するよりも、ほとんどの展開において、より現実的な選択肢である可能性がある。また、一般化されたTTLセキュリティ・メカニズム[RFC5082]を使用することで、BGPセッションのスプーフィングのリスクをさらに軽減できる可能性がある。

10. 参考文献

10.1. 引用規格

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>.

[RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for Private Use", BCP 6, RFC 6996, DOI 10.17487/RFC6996, July 2013, <http://www.rfc-editor.org/info/rfc6996>.

10.2. 参考規格

[ALFARES2008] Al-Fares, M., Loukissas, A., and A. Vahdat, "A Scalable, Commodity Data Center Network Architecture", DOI 10.1145/1402958.1402967, August 2008, <http://dl.acm.org/citation.cfm?id=1402967>.

[ALLOWASIN] Cisco Systems, "Allowas-in Feature in BGP Configuration Example", February 2015, <http://www.cisco.com/c/en/us/support/docs/ip/ border-gateway-protocol-bgp/112236-allowas-in-bgp-config-example.html>.

[BGP-PIC] Bashandy, A., Ed., Filsfils, C., and P. Mohapatra, "BGP Prefix Independent Convergence", Work in Progress, draft-ietf-rtgwg-bgp-pic-02, August 2016.

[CLOS1953] Clos, C., "A Study of Non-Blocking Switching Networks", The Bell System Technical Journal, Vol. 32(2), DOI 10.1002/j.1538-7305.1953.tb01433.x, March 1953.

[CONDITIONALROUTE] Cisco Systems, "Configuring and Verifying the BGP Conditional Advertisement Feature", August 2005, <http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/16137-cond-adv.html>.

[CONS-HASH] Wikipedia, "Consistent Hashing", July 2016, <https://en.wikipedia.org/w/index.php?title=Consistent_hashing&oldid=728825684>.

[FB4POST] Farrington, N. and A. Andreyev, "Facebook's Data Center Network Architecture", May 2013, <http://nathanfarrington.com/papers/facebook-oic13.pdf>.

[GREENBERG2009] Greenberg, A., Hamilton, J., and D. Maltz, "The Cost of a Cloud: Research Problems in Data Center Networks", DOI 10.1145/1496091.1496103, January 2009, <http://dl.acm.org/citation.cfm?id=1496103>.

[HADOOP] Apache, "Apache Hadoop", April 2016, <https://hadoop.apache.org/>.

[IANA.AS] IANA, "Autonomous System (AS) Numbers", <http://www.iana.org/assignments/as-numbers>.

[IEEE8021D-1990] IEEE, "IEEE Standard for Local and Metropolitan Area Networks: Media Access Control (MAC) Bridges", IEEE Std 802.1D, DOI 10.1109/IEEESTD.1991.101050, 1991, <http://ieeexplore.ieee.org/servlet/opac?punumber=2255>.

[IEEE8021D-2004] IEEE, "IEEE Standard for Local and Metropolitan Area Networks: Media Access Control (MAC) Bridges", IEEE Std 802.1D, DOI 10.1109/IEEESTD.2004.94569, June 2004, <http://ieeexplore.ieee.org/servlet/opac?punumber=9155>.

[IEEE8021Q] IEEE, "IEEE Standard for Local and Metropolitan Area Networks: Bridges and Bridged Networks", IEEE Std 802.1Q, DOI 10.1109/IEEESTD.2014.6991462, <http://ieeexplore.ieee.org/servlet/opac?punumber=6991460>.

[IEEE8023AD] IEEE, "Amendment to Carrier Sense Multiple Access With Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications - Aggregation of Multiple Link Segments", IEEE Std 802.3ad, DOI 10.1109/IEEESTD.2000.91610, October 2000, <http://ieeexplore.ieee.org/servlet/opac?punumber=6867>.

[INTERCON] Dally, W. and B. Towles, "Principles and Practices of Interconnection Networks", ISBN 978-0122007514, January 2004, <http://dl.acm.org/citation.cfm?id=995703>.

[JAKMA2008] Jakma, P., "BGP Path Hunting", 2008, <https://blogs.oracle.com/paulj/entry/bgp_path_hunting>.

[L3DSR] Schaumann, J., "L3DSR - Overcoming Layer 2 Limitations of Direct Server Return Load Balancing", 2011, <https://www.nanog.org/meetings/nanog51/presentations/Monday/NANOG51.Talk45.nanog51-Schaumann.pdf>.

[LINK] Mohapatra, P. and R. Fernando, "BGP Link Bandwidth Extended Community", Work in Progress, draft-ietf-idr-link-bandwidth-06, January 2013.

[REMOVAL] Mitchell, J., Rao, D., and R. Raszuk, "Private Autonomous System (AS) Removal Requirements", Work in Progress, draft-mitchell-grow-remove-private-as-04, April 2015.

[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <http://www.rfc-editor.org/info/rfc2328>.

[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 1998, <http://www.rfc-editor.org/info/rfc2385>.

[RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path Algorithm", RFC 2992, DOI 10.17487/RFC2992, November 2000, <http://www.rfc-editor.org/info/rfc2992>.

[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, DOI 10.17487/RFC4272, January 2006, <http://www.rfc-editor.org/info/rfc4272>.

[RFC4277] McPherson, D. and K. Patel, "Experience with the BGP-4 Protocol", RFC 4277, DOI 10.17487/RFC4277, January 2006, <http://www.rfc-editor.org/info/rfc4277>.

[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, December 2006, <http://www.rfc-editor.org/info/rfc4786>.

[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, <http://www.rfc-editor.org/info/rfc5082>.

[RFC5837] Atlas, A., Ed., Bonica, R., Ed., Pignataro, C., Ed., Shen, N., and JR. Rivers, "Extending ICMP for Interface and Next-Hop Identification", RFC 5837, DOI 10.17487/RFC5837, April 2010, <http://www.rfc-editor.org/info/rfc5837>.

[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, <http://www.rfc-editor.org/info/rfc5880>.

[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <http://www.rfc-editor.org/info/rfc5925>.

[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. Ghanwani, "Routing Bridges (RBridges): Base Protocol Specification", RFC 6325, DOI 10.17487/RFC6325, July 2011, <http://www.rfc-editor.org/info/rfc6325>.

[RFC6769] Raszuk, R., Heitz, J., Lo, A., Zhang, L., and X. Xu, "Simple Virtual Aggregation (S-VA)", RFC 6769, DOI 10.17487/RFC6769, October 2012, <http://www.rfc-editor.org/info/rfc6769>.

[RFC6774] Raszuk, R., Ed., Fernando, R., Patel, K., McPherson, D., and K. Kumaki, "Distribution of Diverse BGP Paths", RFC 6774, DOI 10.17487/RFC6774, November 2012, <http://www.rfc-editor.org/info/rfc6774>.

[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, DOI 10.17487/RFC6793, December 2012, <http://www.rfc-editor.org/info/rfc6793>.

[RFC7067] Dunbar, L., Eastlake 3rd, D., Perlman, R., and I. Gashinsky, "Directory Assistance Problem and High-Level Design Proposal", RFC 7067, DOI 10.17487/RFC7067, November 2013, <http://www.rfc-editor.org/info/rfc7067>.

[RFC7130] Bhatia, M., Ed., Chen, M., Ed., Boutros, S., Ed., Binderberger, M., Ed., and J. Haas, Ed., "Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces", RFC 7130, DOI 10.17487/RFC7130, February 2014, <http://www.rfc-editor.org/info/rfc7130>.

[RFC7196] Pelsser, C., Bush, R., Patel, K., Mohapatra, P., and O. Maennel, "Making Route Flap Damping Usable", RFC 7196, DOI 10.17487/RFC7196, May 2014, <http://www.rfc-editor.org/info/rfc7196>.

[RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, "Advertisement of Multiple Paths in BGP", RFC 7911, DOI 10.17487/RFC7911, July 2016, <http://www.rfc-editor.org/info/rfc7911>.

[VENDOR-REMOVE-PRIVATE-AS] Cisco Systems, "Removing Private Autonomous System Numbers in BGP", August 2005, <http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080093f27.shtml>.

謝辞

本文書は、提案されたネットワーク設計の開発、テスト、展開に参加した多くの人々の作業をまとめたものである。その中には、ジョージ・チェン、パランタップ・ラヒリ、デイブ・モルツ、エデト・ンクポソン、ロバート・トゥーミー、リーファ・ユエンなどがいる。著者は、本文書のレビューし、貴重なフィードバックを提供してくれたリンダ・ダンバー、アヌープ・ガンワニ、スーザン・ハリス、ダニー・マクファーソン、ロバート・ラスズク、ラス・ホワイトに感謝したい。また、文法とスタイルに関する初期の提案をしてくれたメアリー・ミッチェルにも感謝する。

著者のアドレス

ペトル・ラプホフ
Facebook
1 Hacker Way
Menlo Park, CA 94025
アメリカ合衆国
Eメール: [e-mail]

アリフ・プレムジー
Arista Networks
5453 Great America Parkway
Santa Clara, CA 95054
アメリカ合衆国
Eメール: [e-mail]
URI : <http://arista.com/>

ジョン・ミッチェル (編集者)
Eメール: [e-mail]

更新履歴

• 2024.10.27
• 2024.11.3
• 2024.11.9