RFC7938 - 大規模データセンター内でのルーティングのためのBGPの利用方法

はじめに

この文書は RFC7938 - Use of BGP for Routing in Large-Scale Data Centers の日本語訳です。

翻訳者はデータセンターネットワークの専門家ですが翻訳の専門家ではありません。技術的な意味を維持した上でなるべく読みやすい日本語になるようにしているため、英文の直訳ではなく一部のニュアンスがかけている場合がありますのでご了承ください。オリジナルの目次、謝辞、参考文献等は省略しています。

免責

いつものやつ

目次

概要

一部のネットワーク事業者は10万台を超えるサーバを収容するデータセンターを構築・運用しています。このドキュメントではそのようなデータセンターを「大規模」と呼び、それ以下の小さなインフラと区別します。このスケールの環境では運用のシンプルさとネットワークの安定性に重点を置いた独自のネットワーク要件を必要とします。このドキュメントはそのような大規模データセンタでBGPを唯一のルーティングプロトコルとして利用したときの設計と運用の経験を要約します。実績のある安定したルーティング設計について報告することで、同じ業界の人たちの役に立つことを目的としています。

1. 導入

この文書は大規模データセンタでの実用的なルーティング設計について記述しています。このようなデータセンターは「ハイパースケール」や「ウェアハウススケール」のデータセンターとも呼ばれていて、10万台を超えるサーバを収容するという独特な性質を持っています。このスケールのネットワーク収容するために、運用者たちはこの要求を解決するネットワーク設計とプラットフォームを再検討しています。

この文書で紹介する設計は、検索エンジンなどの大規模で分散されたソフトウェアインフラを収容するデータセンターの運用経験に基づいています。そのような環境における最も重要な要件は運用のシンプルさとネットワークの安定性であり、少人数のチームが大規模なネットワークを効率的に運用するようにできなければなりません。

実験と広範囲の試験によってEBGPが比類ないルーティングプロトコルでありこれらのタイプのデータセンターへの応用に最適であるということが示されています。これは単純な木構造トポロジーを使いL2ドメインを複数のネットワーク機器に延伸することに頼った、より伝統的なデータセンターの設計とは対照的です。このドキュメントではこの設計を選択することに繋がった要件を詳しく述べ、EBGPのルーティング設計の詳細を示すとともに、これからの改善のアイディアを探ります。

この文書ではまずはじめにネットワーク設計の要件と大規模データセンターにおいて考慮すべき項目の概要を示します。次に従来の階層型のデータセンターネットワークのトポロジーは、水平方向にスケールアウトされたClosネットワークと対照的であることを述べます。これにつづいて、ClosトポロジーにとってEBGPが要件を満たすための最も適切なルーティングプロトコルであることを主張し、提案する設計を詳細に述べます。最後に追加で考慮するべき項目や設計の選択肢について論評します。この文書で述べられる設計を計画・デプロイしようとする読者はBGPについて完全に理解しているものだと仮定します。

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

この節では大規模データセンターのためのネットワーク設計の要件について説明して要約します。

2.1 帯域とトラフィックのパターン

大量のサーバーを相互接続するためのネットワークを構築するにあたって最も重要な要件はアプリケーションの帯域とレイテンシーの要求を満たすことです。最近までは大部分のトラフィックがデータセンターから出入りするような一般的にnorth-southトラフィックと呼ばれるものが一般的でした。従来の木構造トポロジーはたとえネットワークレイヤー間のオーバサブ率が高くても、そのようなトラフィックフローを十分に収容できるものでした。もし追加の帯域が必要になれば、例えば機器のラインカードやファブリックをアップグレードしたり、ポート密度の高い機器に置き換えたりして、ネットワーク要素のスケールアップで増やすことができました。

現在の多くの大規模データセンターが収容するアプリケーションは、データセンターの外に出ず、サーバからサーバへ向かうeast-westと呼ばれるトラフィックを大量に生み出しています。例としてはHadoopのような計算機クラスタや、計算機クラスタ間での大量のデータ複製が必要な特定のアプリケーションや、仮想マシンマイグレーションなどが挙げられます。これらの帯域の要件を満たすために従来のトポロジーをスケールさせることは、スイッチのポート密度などの物理的な制約によって非常に高額になるか不可能になります。

2.2 CAPEXの最小化

ネットワークインフラに関連する設備投資(CAPEX)はそれだけでもデータセンターの総費用の10-15%程度を占めます。しかし絶対的なコストは相当なものになるため、個々のネットワーク要素のコストを定常的に引き下げる必要があります。これには2つの方法があります。

  • すべてのネットワーク要素を統一する。できれば同じハードウェアタイプや同じ機器を使う。一括購入でのボリューム価格を可能にするとともに、維持管理コストと在庫コストを減らすことができます。
  • 複数のネットワークベンダーの機器を採用することで競争圧力を利用してコストを下げる。

良いベンダー多様性を実現するには、ネットワーク要素のソフトウェア機能の要件を減らすことが重要です。この戦略はオープンな標準を使用して相互接続性を保ちながら、ベンダー機器の選定の柔軟性を最大化することができます。

2.3 OPEXの最小化

大規模インフラでは、構成要素が大量になればなるほど統計的にも故障の頻度が増えるため、運用のコストが高額になりえます。よりシンプルな設計を行い、限られたソフトウェア機能を利用して運用することで、ソフトウェアの問題に起因する障害を最小化することができます。

OPEXの最小化において重要な観点はネットワークにおける障害ドメインのサイズを小さくすることです。イーサネットのネットワークは、ネットワーク性能と可用性に劇的なインパクトを与えることがあるブロードキャストやユニキャストのトラフィックストームの影響を受けやすいことが知られています。すべてがルーティングだけで構成された設計を取り入れることでデータプレーンの障害ドメインのサイズを劇的に小さくすることができます。つまり障害ドメインをネットワークの階層構造の一番低いレベルに制限することができます。しかしこのような設計は分散型コントロールプレーンの障害の問題を引き起こします。そのためプロトコルの相互作用の問題を軽減し、ネットワークのメルトダウンの可能性を減らすためには、よりシンプルでコントロールプレーンの少ないプロトコルが必要になることがわかります。前節のCAPEXで述べたソフトウェア機能の要件を最小化することは検証や習熟の要件も減らすことにも繋がります。

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

アプリケーションのロードバランスはネットワーク機器によって実現される機能の1つで、どのようなデータセンターでも最重要です。従来ではロードバランサートラフィックの通り道に専用の機器として設置されてきました。問題は増大するトラフィック需要の中でロードバランサーをスケールさせようとする時に生じます。解決策として好ましいのは、同一のノードを追加し、流入するトラフィックをノード間で分散させることで、ロードバランサーのレイヤーを水平にスケールアウトできるようにしておくことです。このような状況においてはネットワークインフラ自体を利用してロードバランサのグループ全体にトラフィックを分散させる選択肢を取ることが理想的でしょう。Anycastプレフィックスの広告と等コストマルチパス(ECMP)の組み合わせによってこの目的が達成できます。より粒度の細かいロードバランスを実現するためには、制御されたホップ単位のトラフィックエンジニアリングを実行する機能をネットワークがサポートしていることが役立ちます。たとえばネットワーク階層構造のどの階層においても、直接AnycastのECMPのネクストホップを制御することが有用です。

2.5 要件の要約

この節では前節で述べた要件のリストを要約します。

  • 要件1(REQ1): ネットワーク要素自体のアップグレードを必要とせずに、同じタイプのリンクとネットワーク機器を追加することで、水平にスケールすることができるトポロジーを選択しましょう
  • 要件2(REQ2): 多数のネットワーク機器ベンダーがサポートしているソフトウェアの機能やプロトコルの狭い集合を定義しましょう
  • 要件3(REQ3): プログラムのコードの複雑さと運用サポートのしやすさを鑑みて、シンプルな実装のルーティングプロトコルを選択しましょう。
  • 要件4(REQ4): 機器の障害ドメインプロトコルの問題をできるだけ最小化しましょう
  • 要件5(REQ5): ある程度のトラフィックエンジニアリングを可能にしましょう。できれば組み込み機能を使うことでルーティングプレフィックスネクストホップを明示的に制御できるようにしましょう。

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

この節では2種類の一般的なデータセンター設計の概要を説明します。階層型(ツリーベース)とClosベースのネットワーク設計です。

3.1 従来のDCトポロジー

ネットワーク業界において、データセンターのためのネットワーク設計で一般的に選ばれるものは、木構造トポロジーです。典型的には冗長された複数のアップリンクをもつ、コア層、アグリゲーション/ディストリビューション層、アクセス層の3階層の(逆さまの)木のような形をしています。帯域の需要に応えるため、木構造の設計の「幹」のように、サーバからDCの外部やWANに向かう方向で、それぞれの階層が上がるごとにポート密度と帯域容量は増えていきます。用語を統一して他の設計と比べられるように、このドキュメントではこれらの3つのレイヤーを、コア層、アグリゲーション層、アクセス層ではなく、Tier 1, Tier 2, Tier 3のように呼ぶことにします。

             +------+  +------+
             |      |  |      |
             |      |--|      |           Tier 1
             |      |  |      |
             +------+  +------+
               |  |      |  |
     +---------+  |      |  +----------+
     | +-------+--+------+--+-------+  |
     | |       |  |      |  |       |  |
   +----+     +----+    +----+     +----+
   |    |     |    |    |    |     |    |
   |    |-----|    |    |    |-----|    | Tier 2
   |    |     |    |    |    |     |    |
   +----+     +----+    +----+     +----+
      |         |          |         |
      |         |          |         |
      | +-----+ |          | +-----+ |
      +-|     |-+          +-|     |-+    Tier 3
        +-----+              +-----+
         | | |                | | |
     <- Servers ->        <- Servers ->

図1: 典型的なDCネットワークトポロジー

残念ながら前述したように、Tier 2を十分にスケールさせるほどに十分大きなポート密度を持ったTier 1機器を調達することができないため、階層型の設計では大規模設計を扱うほど十分な程度にはスケールすることができません。また、デプロイの規模や帯域幅の要件が増えるに従って、継続的な上位Tierの機器のアップグレードや置き換えが必要になり、運用が複雑化します。こういった理由からREQ1を適用してこの型の設計は考慮から除外します。

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

この節ではREQ1を満たすために、大規模データセンターにおける水平方向にスケーラブルなトポロジーの一般的な設計を紹介します。

3.2.1 概要

水平方向にスケーラブルなトポロジーとして折りたたみClosトポロジーが一般的に選択されます。Fat-Treeトポロジーとも呼ばれることがあります。このトポロジーは奇数のステージ(面とも呼ばれる)を特徴としていて、一般的には同一のポート数を持ったスイッチなど、統一された要素で成り立っています。そのため折りたたみClosトポロジーの選択はREQ1を満たし、REQ2を容易にします。

   +-------+
   |       |----------------------------+
   |       |------------------+         |
   |       |--------+         |         |
   +-------+        |         |         |
   +-------+        |         |         |
   |       |--------+---------+-------+ |
   |       |--------+-------+ |       | |
   |       |------+ |       | |       | |
   +-------+      | |       | |       | |
   +-------+      | |       | |       | |
   |       |------+-+-------+-+-----+ | |
   |       |------+-+-----+ | |     | | |
   |       |----+ | |     | | |     | | |
   +-------+    | | |     | | |   ---------> M links
    Tier 1      | | |     | | |     | | |
              +-------+ +-------+ +-------+
              |       | |       | |       |
              |       | |       | |       | Tier 2
              |       | |       | |       |
              +-------+ +-------+ +-------+
                | | |     | | |     | | |
                | | |     | | |   ---------> N Links
                | | |     | | |     | | |
                O O O     O O O     O O O   Servers

図2: 3-Stage 折りたたみClosトポロジー

このトポロジーはよくLeaf-Spineネットワークとも言われ、Spineという名前はClosトポロジーの中間ステージ(Tier1 )、Leafという名前は入力・出力ステージ(Tier2)につけられています。このドキュメントでは統一のためにTier nの表記を使ってこれらの層を参照します。

3.2.2 Closトポロジーの特性

Closトポロジーの主要な特性は次のようなものが挙げられます

  • トポロジーはM>Nの場合完全なノンブロッキング、もしくはより正確には非干渉であり、それ以外の場合はN/Mの比率に応じてオーバーサブとなります。ここでMとNは図2に示されるTier 2スイッチのアップリンクとダウンリンクのポート数を表しています。
  • このトポロジーを有効活用するためにはコントロールプレーンとデータプレーンにおいてM個以上に分散できるECMPが必要になります。
  • このトポロジーではTier 1スイッチはそれぞれのサーバに対してちょうど1つのパスを持ちます。これはこのトポロジーににおいて経路集約を危険にしてしまう重要な特性です(8.2節を参照)。
  • サーバーからサーバーへ流れるトラフィックはECMPを利用してすべての利用可能なパスにロードバランスされます。

3.2.3 Closトポロジーをスケールさせる

ネットワーク要素の数を増やしたり、ポート密度を上げたり、図3に示すように5-Stage Closに移行するなどステージを追加することによって、Closトポロジーはスケールさせることができます。

                                     Tier 1
                                    +-----+
         Cluster                    |     |
 +----------------------------+   +--|     |--+
 |                            |   |  +-----+  |
 |                    Tier 2  |   |           |   Tier 2
 |                   +-----+  |   |  +-----+  |  +-----+
 |     +-------------| DEV |------+--|     |--+--|     |-------------+
 |     |       +-----|  C  |------+  |     |  +--|     |-----+       |
 |     |       |     +-----+  |      +-----+     +-----+     |       |
 |     |       |              |                              |       |
 |     |       |     +-----+  |      +-----+     +-----+     |       |
 |     | +-----------| DEV |------+  |     |  +--|     |-----------+ |
 |     | |     | +---|  D  |------+--|     |--+--|     |---+ |     | |
 |     | |     | |   +-----+  |   |  +-----+  |  +-----+   | |     | |
 |     | |     | |            |   |           |            | |     | |
 |   +-----+ +-----+          |   |  +-----+  |          +-----+ +-----+
 |   | DEV | | DEV |          |   +--|     |--+          |     | |     |
 |   |  A  | |  B  | Tier 3   |      |     |      Tier 3 |     | |     |
 |   +-----+ +-----+          |      +-----+             +-----+ +-----+
 |     | |     | |            |                            | |     | |
 |     O O     O O            |                            O O     O O
 |       Servers              |                              Servers
 +----------------------------+

図3: 5-Stage Closトポロジー

図3の小さなトポロジーの例は4ポートの機器で構成されています。このドキュメントは1組の直接接続されたTier 2とTier 3の機器とそれらに接続されたサーバを「クラスター」と呼びます。例えば図3のDEV A, B, C, DとDEV A, Bに接続されたサーバです。クラスターの概念は、トポロジー全体とは異なる頻度で作業を実施できるもので、デプロイ単位やメンテナンス単位を考えるときに役に立ちます。

実際にはClosネットワークのTier 3、一般的にTop-of-Rackスイッチ(ToRs)と呼ばれる箇所においては、様々なタイプのアプリケーションの帯域要求を満たしながらより多くのサーバをまとめられるように、オーバーサブが行われます。ネットワークの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を削減することができます。トレードオフとしてこの例では、全体のサーバ数の観点から最大のデータセンターサイズが半分になってしまいます。

この例では、Tier 2機器は2本の並列したリンクを使用してTier 1機器に接続しています。1本のリンクに障害が発生するともう1本のリンクが障害のあるリンクのトラフィックをすべて拾い上げますが、パスを決める手順が帯域をを考慮に入れていない場合、上流のTier 1機器の数がだいたい2台以上であるため、輻輳が激しくなり品質の劣化に繋がる可能性があります。この状況を回避するためには並列したリンクをLAGにするなどグループ化し、1本のリンクが障害を起こした時バンドル全体がダウンするような広く利用可能な実装の設定などを使うことができます。同等のテクニックとして並列したリンクで「fate-sharing」を設定することでLAGの代わりに同様の効果を得ることができます。このようなfate-sharingの結果として、2本かそれ以上の本数のリンクからのトラフィックは、Tier 1機器の数と同じだけの残った多数のパスの間で再バランスされます。この例では単純のため2本のリンクを使っていますが、それ以上の数のリンクをバンドルすることで、メンバーリンクの障害が起きたときの帯域容量への影響を減らすことができます。

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

この節では3つの一般的なタイプのデータセンタープロトコルの設計を紹介します。L2オンリー、L2/L3のハイブリッド、L3オンリーの3つです。

4.1 L2オンリー設計

もともとほとんどのデータセンターの設計ではループフリーのトポロジーを作るために802.1D(1990年)で規定されたスパニングツリープロトコル(STP)を使っていました。通常3.1節で述べたような従来のDCトポロジーの変種を使っています。当時多くのDCスイッチはL3ルーティングプロコトルをサポートしていなかったり、サポートに追加のライセンス料が必要であったため、設計の選択に影響していました。2004年の802.1Dの最新リビジョンのRapid Spanning Tree Protocol(RSTP)や、802.1Qで規定されているMultiple Spanning Tree Protocol (MST)が導入され、大きなトポロジーでの収束や安定性や負荷分散などについて多くの改善が行われましたが、これらのプロトコルの多くの動作原理は大規模DCへの適用を制限してしまうものです。STPとその変種はパス選択にactive-standbyのアプローチを取っています。それ故に3.2節で述べたような水平方向にスケールアウトするトポロジーを構築しにくいという問題があります。それ以上に運用者は、単体の機器の誤配線や設定ミス、ソフトウェアの欠陥が原因である大規模障害を経験してきました。こうした障害は一般的にスパニングツリーのドメイン全体の障害を引き起こし、これをトラブルシュートすることはそのプロトコルの原理からして困難でした。こうした理由に加えて今やDCトラフィックのほとんどはIPであり、外部接続のネットワークエッジでL3ルーティングを必要とするため、STPを活用した設計は大規模DC事業者の要件にそぐわないものです。マルチシャーシLAG(M-LAG)や802.3adのようなさまざまな改善がリンクアグリゲーションプロトコルに行われ、STPによるループ防止をバックアップとしたactive-activeのネットワークパスを持ったL2設計が可能になりました。このアプローチの欠点としては、大体の実装で2台以上に線形にスケールできないことや標準に基づいた実装がないことやデバイス間での状態の同期という障害ドメインが生じることなどが挙げられます。

一つ述べておかなければならないのは、巨大で水平方向にスケール可能なL2オンリーのネットワークの構築方法としてRFC6325のTransparent Interconnection of Lots of Links (TRILL)を導入することを挙げることができます。TRILLは大規模DC設計に対するSTPの多くの欠点を解決していますが、実装が限られていることと、サポートしている特定の機器を必要とすることから、TRILLの適用可能は範囲は限定され、TRILLを使用した設計も多くのコストがかかります。

最後に、TRILLの基本仕様もM-LAGのアプローチも、L2イーサネットベースのソリューションの運用に害を与える共有ブロードキャストドメインの問題を完全には解決しません。後のTRILL拡張はRFC7067で示されるようなアプローチに基づいてこの問題を解こうとしましたが、これによりファブリックの構築に使用できる相互運用可能な実装の数がさらに限定されてしまう事になりました。それゆえにTRILLベースの設計はREQ2, REQ3, REQ4を満たすには問題があります。

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

運用者は、ネットワークのTier 1またはTier 2の部分においてルーティングプロトコルを実装し、L2ドメインを多数のより小さいドメインに分割することによって、データプレーン障害の影響を限定して大規模トポロジーを構築しようとしてきました。この設計によりデータセンターをスケールアップすることができますが、複数のネットワークプロトコルを管理することの複雑性のコストが生じます。次のような理由から、運用者はネットワークのうちアクセス(Tier3)またはアクセスとアグリゲーションの両方(Tier 3とTier 2)にL2を残してきました。

  • 直接のL2隣接性を要求したり、IPでないプロトコルを使用したりするレガシーなアプリケーションのサポートのため
  • 別のTier 3スイッチの下に移動させたときにIPアドレスを保持したままにする必要がある仮想マシンのためのシームレスなモビリティのため
  • 純化したIPアドレッシング=データセンター使うサブネットの数を少なくするため
  • L2DSRのような特定の機能を実現するために直接のL2接続性が必要なアプリケーションロードバランサのため。
  • L2スイッチとL3スイッチの継続的なCAPEXの違いのため

4.3 L3オンリー設計

IPルーティングをネットワークのTier 3まで利用するネットワーク設計が最近人気を得てきています。こうした設計の主な利点はL2ブロードキャストドメインを限定したことによって安定性とスケーラビリティが向上することです。この設計では軸となるルーティングプロトコルとして一般的にOSPFのようなIGPが使用されます。データセンターが拡大成長し、サーバの数が1万台を超えると、このような完全にL3ルーティングにした設計はもっと魅力的になります。

L3オンリー設計を選択することでネットワークを劇的に単純化することができ、REQ1とREQ2を満たしやすくなります。そしてネットワークのスケーラビリティと安定性に比べて、巨大なL2隣接性や巨大なL3サブネットがそれほど重要ではないようなネットワークにおいて広く採用されています。アプリケーション提供者とネットワーク運用者は、様々なオーバレイやトンネリングの技術を使って、これまで巨大なL2ドメインを必要にしていた要件のうちのいくつかを満たす新しい解決策を開発し続けています。

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

この節ではL3プロトコル設計とClosトポロジーを持つデータセンターネットワークのための単一のルーティングプロトコルとしてのEBGPについて説明します。そしてEBGPベースのネットワークをデザインする実践的なアプローチを示します。

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

REQ2は複雑さと相互依存性を減らすために単一のルーティングプロトコルを選択することを優先するように言っています。このような状況でIGPに頼ることは一般的ではありますが、WANに隣接する機器にEBGPを追加していたり、全体でIBGPを使っていたりします。このドキュメントではEBGPだけを利用する設計を提案します。

EBGPはインターネットのほとんどのインタードメインルーティングで利用されるプロトコルではありますが、ベンダーとサービスプロバイダのコミュニティで広くサポートされています。しかしいくつかの理由により一般的にはデータセンターでのメインのルーティングプロトコルとしては使用されていません。

  • BGPは「WANだけ、プロトコルだけ」と理解されていて、エンタープライズやデータセンターで応用できるものだと考えられていない。
  • BGPはIGPに比べてルーティングの収束が「非常に遅い」と信じられている。
  • 大規模なBGPの利用では一般的に、IBGPトポロジーのすべてのノードが直接接続されていないためIGPによるBGPのネクストホップ解決を利用していた。
  • BGPは設定のオーバヘッドが大きく、ネイバーの自動発見もサポートしていないと考えられている。

このドキュメントではこれらの認識について特に提案する設計に適用可能であるかどうかを議論し、次のようなプロトコルを使う利点について注目します。

  • プロトコル設計という点においてBGPは複雑性が少ない。内部のデータ構造やステートマシンがOSPFのようなほとんどのリンクステート型のIGPと比べると単純である。例えば隣接関係の構築や隣接関係の維持、フロー制御を実装する代わりに、BGPはトランスポート層として単純にTCPに依存しています。これはREQ2とREQ3を満たします。
  • BGPの情報を伝達するオーバーヘッドはリンクステート型のIGPと比べると小さいです。それぞれのBGPルータが選ばれたベストパスを計算して伝達するため、ネットワーク障害が起きてもBGPスピーカが代替パスを見つけ次第すぐに障害を隠すことができます。これはClosなどの対称性の高いトポロジーがEBGPのみと結合されているような設計でないと起こりえません。対象的にリンクステート型のIGPのイベント伝達のスコープは、障害のタイプに関係なく、エリア全体に及びます。このようにしてBGPはREQ3とREQ4をよりよく満たします。また、BGPがルーティング状態を期限切れにしない一方で、広く導入されているすべてのリンクステート型IGPは定期的なルーティング情報の更新を特徴としていますが、最近のルータのコントロールプレーンにはほとんど影響しないということは言っておく価値があるでしょう。
  • BGPはサードパーティの(再帰的に解決可能な)ネクストホップをサポートしています。アプリケーション「コントローラ」とピアリングセッションを確立して、ルーティング情報をシステムに挿入することで、マルチパスを操作してアプリケーション定義のパスを非ECMPベースにしたり転送ベースにしたりできます。これはREQ5を満たします。OSPFも「フォワーディングアドレス」という概念を使って似たような機能を提供していますが、実装がより困難になって、情報伝達のスコープの制御がさらにできなくなります。
  • 明確に定義されたAS番号(ASN)の割当スキームと標準のAS_PATHループ検出を使うことで、BGPパスハンティングを制御することができ、複雑で望ましくないパスを無視することができます。ASNの割当スキームの例については5.2節を参照してください。リンクステート型のIGPで同様の目的を達成するためには、マルチインスタンス、マルチトポロジー、マルチプロセスのサポートを必要とすることになるでしょう。しかしこれらは一般的にはDC機器の全てで利用可能でないし、設定やトラブルシュートを考えると複雑すぎるものです。ほとんどのDC設計が利用しているような従来の単一のフラッディングドメインを利用することは、特定の障害条件下において、複数のTier 2機器を通過するような望ましくない長いパスを選択してしまうことになるでしょう。
  • 最小のルーティングポリシーで実装されたEBGPの構成は、ネットワークの到達性の問題が生じた時にでもトラブルシュートがしやすいです。殆どの実装で、BGPのLoc-RIBの内容を見てルータのRIBと比較することは簡単ですし、運用者はそれぞれのBGPネイバーのAdj-RIB-InとAdj-RIB-Outを見ることができるし、それ故に、送受信したNLRIをBGPセッションの両側において簡単に関連付けることができます。そのためBGPはREQ3を満たします。

5.2 ClosトポロジーのためのEBGPの構成

5より多いステージを持つClosトポロジーは非常にまれです。これは必要な相互接続の本数が巨大になるからです。そのため、この例では5-stageのClosトポロージについて(折りたたまない状態で)説明します。

5.2.1 EBGP構成ガイドラインとASNの割当スキームの例

図はASNの割当スキームの例を図示しています。ガイドラインのリストを以下に示します。

  • ネットワークノード間を相互接続するダイレクトのP2Pリンクで、シングルホップのEBGPセッションを確立します。マルチホップやループバックを利用したEBGPセッションは使いません。これは同じノードの間に複数のリンクがあったとしても同様です。
  • ASNの衝突を避けるためにプライベート用途のASN (64512-65534) を使います。
  • ClosトポロジーのすべてのTier 1機器には単一のASNを割り当てます。
  • 同じクラスターに属するTier 2機器にはそれぞれ一意のASNを割り当てます。
  • それぞれのTier 3機器には一意のASNを割り当てます。
                                ASN 65534
                               +---------+
                               | +-----+ |
                               | |     | |
                             +-|-|     |-|-+
                             | | +-----+ | |
                  ASN 646XX  | |         | |  ASN 646XX
                 +---------+ | |         | | +---------+
                 | +-----+ | | | +-----+ | | | +-----+ |
     +-----------|-|     |-|-+-|-|     |-|-+-|-|     |-|-----------+
     |       +---|-|     |-|-+ | |     | | +-|-|     |-|---+       |
     |       |   | +-----+ |   | +-----+ |   | +-----+ |   |       |
     |       |   |         |   |         |   |         |   |       |
     |       |   |         |   |         |   |         |   |       |
     |       |   | +-----+ |   | +-----+ |   | +-----+ |   |       |
     | +-----+---|-|     |-|-+ | |     | | +-|-|     |-|---+-----+ |
     | |     | +-|-|     |-|-+-|-|     |-|-+-|-|     |-|-+ |     | |
     | |     | | | +-----+ | | | +-----+ | | | +-----+ | | |     | |
     | |     | | +---------+ | |         | | +---------+ | |     | |
     | |     | |             | |         | |             | |     | |
   +-----+ +-----+           | | +-----+ | |           +-----+ +-----+
   | ASN | |     |           +-|-|     |-|-+           |     | |     |
   |65YYY| | ... |             | |     | |             | ... | | ... |
   +-----+ +-----+             | +-----+ |             +-----+ +-----+
     | |     | |               +---------+               | |     | |
     O O     O O              <- Servers ->              O O     O O

図4: 5-Stage ClosのためのBGP AS番号レイアウト

5.2.2 プライベート用途のAS番号

RFC6996にあるプライベート用途のAS番号のもともとの範囲は1023個の一意のAS番号に限られています。ネットワーク機器の台数がこの値を超えてしまうことはよくあるので、ワークアラウンドが必要です。アプローチの1つは違うクラスタのTier 3機器にAS番号を再利用することです。たとえば65001, 60552 ... 65032をそれぞれのクラスタ内で利用し、Tier 3機器に割り当てます。

BGPのAS_PATHループ検出メカニズムによるroute suppressionを避けるために、Tier 3機器の上流のEBGPセッションでは Allowas-in 機能を設定する必要があります。この機能は受信した経路広告に機器自身のAS番号が含まれていることを受け入れるものです。この機能は標準化されていませんが、複数のベンダの実装で広く利用可能になっています。この機能を導入することがこの設計においてルーティングループを引き起こしやすくすることはありません。それはAS_PATHがトポロジーのそれぞれのTierのルータによって追加され、AS_PATH長がBGPパス選択の上位のタイブレーカーであるためです。さらなるループ防止機構はTier 1機器にまだあります。自身のAS番号を含むパスを受け付けないことです。Tier 2機器はお互いに直接の接続性を持ちません。

この問題に対する他の解決策は4バイトAS番号を使うことでしょう。追加のプライベート用途AS番号があるのでIANAのサイトを見てください。4バイトAS番号の利用はBGPの実装においてプロトコルの複雑性を増加させます。そのためREQ3とREQ4を考慮しながら、AS番号の再利用のアプローチの複雑性と比べてバランスを取る必要があります。おそらくより重要なことには4バイトAS番号はすべての実装で未だにサポートされているわけではないということです。これはDC設備のベンダー選ぶときの制約となります。もしサポートされていれば、これらのプライベート用途AS番号への外部接続が必要な時に、プライベート用途AS番号を取り除くことが可能で実装であるかどうかを確かめてください。

5.2.3 プレフィックス広告

Closトポロジーの特徴として多数のpoint-to-pointリンクとそれに関連するプレフィックスが挙げられます。BGPでこれらのすべての経路を広告することはネットワーク機器のFIBに過負荷を発生させる可能性があります。またBGPのコントロールプレーンにパス計算の負荷を与えるためほとんどメリットがありません。これには2つの解決案があります:

  • point-to-pointリンクのプレフィックスはBGPに広告しない。EBGPベースの設計はネクストホップのアドレスをそれぞれの機器で変更するため、遠方にあるネットワークはその経路広告を行っているBGPピアを介して自動的に到達可能になります。そのためこれらのプレフィックスへの到達性は必要ありません。
  • point-to-pointリンクのプレフィックスは広告するが、それぞれの機器で集約する。これを実現するにはアドレス割当を工夫する必要があり、たとえば連続したIPアドレスブロックをTier 1、Tier 2機器ごとに割り当てて、下位の機器へのpoint-to-pointリンクのインターフェイスのアドレスに使う(Tier 2のアップリンクはTier 1のアドレスブロックから割当るなど)ようなことが必要です。

Tier 3機器のサーバのサブネットは、Tier 1, 2の機器で経路集約を行わずにBGPに広告しなくてはなりません。Closトポロジーにおいてサブネット経路を集約することは、例えばTier 2 - Tier 3間のリンクなどのリンクの単一障害によって経路ブラックホールが発生する原因になります。これは避けなくてはなりません。同一Tier内でピアリンクを使うことでバイパスパスを提供し、ブラックホール問題を解くことは可能ですが、O(N2)の複雑性を持ったピアリングメッシュが発生する上にポートを無駄遣いしてしまうので望ましくありません。ピアリンクのフルメッシュ化の代替としてFB4POSTで述べられているような「ring」などの、より簡単なトポロジーを使うことが挙げられます。しかしこのようなトポロジーは余計なホップを追加し帯域を制限してしまいます。またこの方法はBGPルーティングを動作させるために、例えばそれぞれの機器を独自のAS番号に分割するなどの、特別な調整を必要とするかもしれません。このドキュメントの後の方の8.2節で、Closネットワークで限定した形で経路集約を行うもっと簡単な方法を紹介し、そのトレードオフについて議論します。

5.2.4 外部接続

WANのエッジ機器やルータに接続する目的でClosトポロジークラスタを専用に割り当てることができます。このクラスタのTier 3機器はWANルータに置き換えられ、EBPピアリングが再び使用されますが、インターネット接続が必要な設計であればWANルータはパブリックAS番号に所属しているかもしれません。この専用クラスタのTier 2機器はこのドキュメントにおいて「ボーダールータ」と呼びます。これらの機器はいくつかの特別な機能を実現する必要があります。

  • WANルータに経路広告をする時にネットワークのトポロジー情報を隠蔽する。たとえばプライベートAS番号をAS_PATHから取り除いたりすることです。これは一般的にはAS番号の番号衝突が別のデータセンターとの間で起きないようにするために行われます。そして均一なAS_PATH長をWANに広告することで、トポロジー内で生成されたエニーキャストのプレフィックスのWAN ECMPを実現することができます。これらを実現するために「Remove Private AS」と一般的に呼ばれるBGPの実装固有の機能を使うことができます。実装によりますがこの機能はAS_PATH中の連続したプライベートAS番号のシーケンスを見つけて、ネイバーに広告する前にそれらを取り除きます。
  • データセンター機器に対してデフォルトルートを生成する。修正を行っていないClosトポロジーでは経路集約が危険なため、ボーダールータはデフォルトルートが生成可能な唯一の場所です。もしくは、ボーダールータは、WANルータが生成したデフォルトルートを学習して単に中継するだけの方法もあります。ボーダールータからデフォルトルートを広告するためには、ボーダールータは上流のWANルータに完全に接続されている必要があります。単一のリンク障害でトラフィックブラックホールを起こさないようにするためです。ボーダールータにおいてWANルータへのすべてのEBGPセッションが同時に落ちた場合にブラックホールを防ぐためには、一部の実装で提供されている複雑な条件の経路生成手法によってデフォルトルートを生成するよりは、デフォルトルートを再広告することの方が望ましいです。

5.2.5 エッジでの経路集約

完全にルーティングだけにしたネットワーク設計においては、データセンターの内部から大量のIPプレフィックスが生成されるために、それらをWANに広告する前にネットワーク到達生情報を集約したほうが良いことがあります。たとえば2000台のTier 3機器があるネットワークでは少なくとも2000個のサーバ用サブネットがインフラのプレフィックスと共にBGPに広告されます。しかし5.2.3節で議論したように、提案するネットワーク設計では各Tierでのピアリンクが無いことから経路集約を許していません。

しかしボーダールータに異なる接続性のモデルを考え出すことによって、この制約を解除することが可能です。それには2つの案が考えられます。

  • ボーダールータをフルメッシュの物理線もしくはリングやハブ・アンド・スポークなどの「peer-mesh」のトポロジーを利用して相互接続する。IBGPセッションのメッシュを追加するなどの方法によって、ネットワーク到達生情報を交換するためにすべてのボーダーリーフにおいてBGPを適切に設定します。相互接続するピアリンクは、ボーダールータを接続するメッシュにおいて、機器やリンクの障害の際に流れるトラフィックに合わせて、適切なサイズにする必要があります。
  • 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で使われる基本的な負荷分散メカニズムです。実際にはそれぞれの下位のTierの機器はすべての直接続された上位Tierの機器を使って1つのIPプレフィックスに対するトラフィックの負荷を分散します。Tier 3機器同士のECMPパスの数は中間ステージ(Tier 1)機器の数と等しくなります。たとえば図5のトポロジーではTier 3機器AがサーバXとYに到達する4つのパスを持っていて、これらはそれぞれTier 2機器BとCとTier 1機器 1, 2, 3, 4を経由します。

                                Tier 1
                               +-----+
                               | DEV |
                            +->|  1  |--+
                            |  +-----+  |
                    Tier 2  |           |   Tier 2
                   +-----+  |  +-----+  |  +-----+
     +------------>| DEV |--+->| DEV |--+--|     |-------------+
     |       +-----|  B  |--+  |  2  |  +--|     |-----+       |
     |       |     +-----+     +-----+     +-----+     |       |
     |       |                                         |       |
     |       |     +-----+     +-----+     +-----+     |       |
     | +-----+---->| DEV |--+  | DEV |  +--|     |-----+-----+ |
     | |     | +---|  C  |--+->|  3  |--+--|     |---+ |     | |
     | |     | |   +-----+  |  +-----+  |  +-----+   | |     | |
     | |     | |            |           |            | |     | |
   +-----+ +-----+          |  +-----+  |          +-----+ +-----+
   | DEV | |     | Tier 3   +->| DEV |--+   Tier 3 |     | |     |
   |  A  | |     |             |  4  |             |     | |     |
   +-----+ +-----+             +-----+             +-----+ +-----+
     | |     | |                                     | |     | |
     O O     O O            <- Servers ->            X Y     O O

図5: AからXとYへのECMPファンアウト木

ECMPの要件は、トポロジーの任意の場所において上流または下流の方向に直接接続された機器の最大数以上のマルチパスのファンアウトを、BGP実装がサポートしている必要があることを意味しています。たとえば64ポートの機器を使ったClosネットワークを作るときには32個のECPMのファンアウトが要求されます。5.2.5節で説明したようなボーダルータでの経路集約が実行されている場合には、ボーダールータは多数のTier 1と接続可能にするため、より広いファンアウトを必要とするかもしれません。機器のハードウェアがwider ECMPをサポートしていない場合は、論理リンクグループ(L2でのリンクアグリゲーション)を使うことで階層的なECMP(L3 ECMPをL2 ECMPと組み合わせる)を実現し、ファンアウトの制約を解消することができるかもしれません。しかしこのアプローチはECMPの2番目のステージで利用できるエントロピーがすくなるなるため、フローの局所化のリスクを増加させることになります。

複数のパスがRFC4271の9.1.2.2節にあるステップ(e)の適用対象になり、その結果に含まれる場合、ほとんどのBGP実装ではそれらのパスはECMPの観点から等しいものとして扱われます。提案しているネットワーク設計においてはIGPを利用しないため、すべてのパスのIGPコストはゼロまたは同じ値になります。ベンダーごとのデフォルト値はバラバラですがMEDやオリジンコードなどのBGPアトリビュートを等しくするようなポリシーが必要に応じて適用されるでしょう。歴史的な理由によって、0を統一したMED値として利用しないことも便利です。これやその他の役に立つBGPの情報はRFC4277に記載されています。ルーティングループはBGPのベストパス選択(短いAS_PATH長を優先する)で起こるものではないですし、Tier 1機器(ASパスに自身のAS番号を許可しない)を通じてより長いパスが生じるのも不可能です。

6.2 複数のAS番号をまたがるBGP ECMP

アプリケーションのロードバランスを実現するために、複数のTier 3機器から同一のプレフィックスを広告できるようにすることが望ましいです。他の機器から見て、このようなプレフィックスはAS_PATH長は同じなのに異なるAS_PATHを持ったBGPパスに見えます。そのためBGP実装は、このようなパスに対するロードバランスをサポートしている必要があります。この機能は「multipath relax」や「multipath multiple-AS」という名前で知られていて、前節で述べたその他のすべてのアトリビュートが同じであれば、異なる隣接AS番号をまたがったECMPを効果的に実現することができます。

6.3 重み付けされたECMP

ECMPのファンアウトの中のいくつかのパスにより多くのトラフィックを流すことができるようにするために、「重み付けされた」ECMPをネットワーク機器が実装していることが望ましいかもしれません。この機能はネットワークの障害を補うことやより容量の大きいパスンにより多くのトラフィックを流すことに役に立ちます。重み付けされたECMPが必要なプレフィックスは、リモートBGPスピーカ(セントラルエージェント)を使って、8.1節でより詳しく説明されるマルチホップセッションを通じて注入される必要があります。もし実装がサポートしている場合、複数のBGPパスの重み付けの分散は、「LINK」に記述されているようなテクニックを用いて伝達されるでしょう。

6.4 コンシステントハッシュ法

ECMPに用いられるハッシュ関数は一貫している(CONS-HASHを参照)ことが望ましいことが多いです。これはECMPグループでネクストホップが追加・削除されたときに、フローのネクストホップのアフィニティが変化することに対する影響を最小化するためです。これを使うことができるのは、ネットワーク機器がロードバランサーとして利用される時でしょう。フローを複数の宛先に対してマッピングします。このようなケースでは宛先が失われたり追加したりしても確立されたフローに対しては決定的な影響はありません。コンシステントハッシュを実装するにあたって特別な推奨がRFC2992に記載されていますが、その他の実装でも可能です。この機能は重み付けECMPと自然に組み合わせることができるでしょう。与えられたネクストホップの重みに比例してネクストホップ変化の影響が生じます。コンシステントハッシュの欠点はハードウェアリソースの使用量を増加させてしまうことです。コンシステントハッシュを実装するためにより多くのTCAMのリソースを必要とすることが多いです。

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

この節では提案する設計におけるルーティング収束の特定について見ていきます。あるケースにおいて関連するリンクの障害時にfast EBGP peering session deactivationとRIB and FIB updatesが実装されていれば1秒未満での収束が達成可能です。

7.1 障害検知のタイミング

BGPではAS内部におけるリンクやノードの障害時の経路計算をIGPに頼っていることがほとんどです。pollingベースまたはイベントドリブンなメカニズムによってIGPの状態変化を受け取る実装になっています。提案するルーティング設計ではIGPを使用しないため、障害検知のためのメカニズムの選択肢として残されているのはBGP keep-aliveのタイムアウト(またはその他のkeep-aliveのメカニズム)とリンク障害がトリガーになるものだけになるでしょう。

ただ単にBGP keep-aliveパケットに頼ることは収束時間の増大を招きます。これは短くても数秒のオーダーになるでしょう(ほとんどのBGP実装では設定可能なhold timerの最小値は3秒になっています)。しかし多くのBGP実装では、BGPピアリングに使用するインターフェイスのリンクダウンのイベントに反応して、ローカルのEBGPピアのセッションをシャットダウンすることが出来ます。この機能は「fast fallover」と呼ばれます。モダンなデータセンターにおけるリンクはpoint-to-pointなファイバの接続であるため、ミリセカンド単位で物理インターフェイスの故障を検知することができ、BGPの再収束を開始させます。

イーサネットのリンクはIEEE802.1Qに記載されているConnectivity Fault Management (CFM)のような障害シグナリングや障害検知の標準をサポートしているかもしれません。これは障害検知をより確実にするでしょう。あるいはいくつかのプラットフォームではRFC5880のBidirectional Forwarding Detection (BFD)をサポートしているかもしれません。これにより1秒未満での障害検知とBGPプロセスへのシグナリングが可能になります。しかしいずれの機能もベンダーのソフトウェアや、場合によってはハードウェアに対しても要件を追加してしまうことになります。これはREQ1に相反します。RFC7130が出た最近になるまで、BFDはLAGの中の単一リンクの障害を検知することが出来なかったため、設計によっては便利さが制限されることがありました。

7.2 イベント伝搬のタイミング

提案する設計においては、RFC4271の9.2.1.1節で定義されているBGPのMinRouteAdvertisementIntervalTimer (MRAI timer)の影響を考慮するべきです。標準では、連続したBGP UPDATEメッセージを送信する時に少なくともMRAIで指定された秒数の間隔を空けることをBGP実装に要求しており、殆どの場合これは設定可能な値になっています。経路のwithdrawのイベントの後の最初のBGP UPDATEメッセージはこのタイマーには影響されません。しかしBGPスピーカがローカルのバックアップパスを持っておらず、ピアから新しいパスを学習するのを「待つ」場合に、MRAIタイマーが大きな収束遅延を引き起こします。

ClosトポロジーにおいてそれぞれのEBGPスピーカは1つのプレフィックスに対して1個のパス(Tier 2機器は同じクラスタの他のTier 2からは同一AS番号のためパスを受け取らないため)またはN個のパスを持っています。Nは例えば32などの大きな数字です(次のTierへのECMPファンアウトの数)。そのためパスを受信した対向機器へのリンクがダウンした場合、全くパスがなくなる(Tier 2機器がTier 3機器へのリンクを失った場合)か、バックアップパスがすでにBGPのLoc-RIBで利用可能になっている場合(Tier 2機器が1台のTier 1機器へのリンクを失った場合)があります。前者のケースではBGPのwithdrawの広告は遅延なしに伝搬され影響を受ける機器での再収束が始まります。後者のケースではベストパスが再評価され、新しいネクストホップに対応したローカルのECPMグループが変更されます。もしそのBGPパスが以前にベストパスとして選ばれていた場合、「暗黙のwithdraw」がBGP UPDATEメッセージで送信されます。これはRFC4271の3.1節にOption bとして記載されていて、AS_PATH属性の変更によって引き起こされます。

7.3 Closトポロジーのファンアウトの効果

Closトポロジーでは巨大なファンアウトが存在しますが、これはいくつかのケースではUp→Down時の収束に影響を与えます。この節ではこの影響について説明します。Tier 3機器とTier 2機器の間のリンクで障害が発生したような状況では、Tier 2機器はBGP UPDATEメッセージをすべての上流のTier 1機器に対して送信し、影響するプレフィックスをwithdrawします。そのTier 1機器は今度はこれらのメッセージをすべての下流のTier 2機器(元のメッセージの生成元を除く)にリレーします。UPDATEメッセージを生成したものを除く他のTier 2機器は「すべての」上流Tier 1機器がUPDATEメッセージを送信するのを待つべきであり、その後影響を受けるプレフィックスを削除し、対応するUPDATEを下流の接続されたTier 3機器に送信します。もしもとのTier 2機器やそれを中継するTier 1機器がUPDATEメッセージの広告に遅延を含ませていた場合、UPDATEメッセージは数秒程度の長さの「分散」となるでしょう。このような動作を防ぐためには、BGPの実装が「update groups」の機能をサポートしている必要があります。「update group」は同一の外向けのポリシーを共有しているネイバーの集合として定義されます。そしてローカルのスピーカはBGPアップデートをグループのメンバーに同時に送信します。

このような「分散」の影響はトポロジーのファンアウトの大きさに伴って大きくなるとともに、ネットワーク収束の撹拌の中でも大きくなりえます。高速でフラップするプレフィックスが及ぼすコントロールプレーンへの影響を軽減するために「route flap dampening」方式の機能の導入を試みた事業者もいるかも知れません。しかし特にこのような「分散」の下においては、これらの実装には偽陽性の問題があるため、この設計に対してはこの機能を有効にすることは推奨されません。RFC7196に「route flap dampening」の背景と問題や、取りうる実装の変更についてよく記述されています。

7.4 罹障範囲

障害が発生した時に、障害の影響範囲にある全ての機器に対してイベントが通知され、それぞれのRIBの再計算が完了し、つづいてFIBの更新が終わった時に、ネットワークは収束したと言うことが出来ます。大きな罹障範囲は収束が遅くなると言われています。これはより多くの機器が通知を受けなくてはならないからであり、結果としてネットワークの安定性が低下します。この節ではClosトポロジーの罹障範囲を小さくする点において、リンクステート型のルーティングプロトコルよりもBGPが有利であることを説明します。

BGPはローカルルータから見たときのベストパスだけがネイバーに送信されるという点においてディスタンスベクタ型のプロトコルのように動作します。そのためローカルノードが即座にバックアップパスを確保することができ、経路の更新情報を送信する必要がないような場合は、一部の障害を隠蔽することが出来ます。最悪のケースではデータセンタートポロジー内のすべての機器がプレフィックスを完全にwithdrawするか、FIBのECMPグループを更新する必要があることに注意してください。しかし多くの障害はこのような広範囲に影響を及ぼすものではありません。罹障範囲が小さくなるような障害のタイプが2つあります。

  • Tier 2とTier 1の間の機器のリンクの障害:このケースではTier 2機器は影響を受けるECMPグループを更新し、障害が起きたリンクを削除します。BGPのプロセスによってベストパスに選択されたパスでない限りは、下流のTier 3機器に対して新たな情報を送信する必要はありません。このケースであっても「暗黙のwithdraw」が送信される必要がありますがフォワーディングには影響しません。影響を受けるTier 1機器は、特定のクラスタに到達できるパスだけを失うことになり、関連するプレフィックスをwithdrawする必要があります。このようなプレフィックスのwithdrawの過程はそのTier 1機器に直接接続されたTier 2機器だけに影響します。それらのTier 2機器はプレフィックスをwithdrawするBGP UPDATEメッセージを受信して、単純にECMPグループを更新するだけです。Tier 3機器はこの再収束のプロセスには巻き込まれません。
  • Tier 1機器の障害: このケースでは障害が起きた機器に直接接続していたすべてのTier 2機器は、自身のクラスタ以外のすべてのIPプレフィックスに対して、それぞれのECMPグループを更新する必要があります。Tier 3機器はここでも再収束のプロセスには巻き込まれませんが上で説明したように「暗黙のwithdraw」を受け取るかもしません。

このような複数のIPプレフィックスがFIBで再プログラムされないといけないような障害のケースであっても、すべてのプレフィックスがTier 2機器において単一のECMPグループに所属していることには価値があります。これにより階層的FIBの実装を使用している場合はFIBに対して行われる変更は1つだけになります。ここで「階層的FIB」とは、ネクストホップの転送情報がプレフィックスの参照テーブルとは別に個別に保存され、参照テーブルではそれぞれの転送情報のポインタだけを保存しているようなFIBの構造を意味しています。FIBの階層化と高速な収束についての議論は「BGP-PIC」を参照してください。

BGPを用いることでいくつかの場合において罹障範囲を小さくすることが可能ですが、集約によってさらに障害ドメインを小さくすることは提案する設計においては常に可能というわけではありません。これは前にも述べたようにルーティングブラックホールを作ってしまう可能性があるからです。そのためコントロールプレーンの最悪の罹障範囲はネットワーク全体となります。例えばTier 2とTier 3の間の機器のリンクの障害です。このケースで影響を受けるプレフィックスの量はClosトポロジーの上位のTier の障害に比べると少なくなるでしょう。このような巨大な罹障範囲を生じてしまう原因は設計においてEBGPを選択したことによるものではなく、Closトポロジーを選択したことによるものです。

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

下流の機器(たとえばTier 2)があるプレフィックスに対するパスをすべて失ったとき、上流機器(この場合はTier 1)へのデフォルトルートを持っていることが通常です。その結果、Tier 2スイッチがあるプレフィックスを失う一方で、Tier 1スイッチはそのTier 2機器に向いたプレフィックスを持ったままである状況が発生する可能性があります。これが一時的なマイクロループを引き起こします。Tier 1スイッチはそのプレフィックスに対するパケットをTier 2機器に戻し続けますが、Tier 2はデフォルトルートを使ってそのパケットを跳ね返すからです。このマイクロループは上流の機器がフォワーディングテーブルを完全に更新するのにかかる時間だけ続きます。

このようなマイクロループの影響を最小限に抑えるためには、ネットワークの収束中に消失するプレフィックスに対してデフォルトルートよりもmore specificになるdiscardかnullの経路をTier 2とTier 1のスイッチで設定することが有効です。Tier 2スイッチにおいてdiscard経路はすべての下流のTier 3機器のサブネットをカバーする集約経路であるべきです。Tier 1機器においてdiscard経路はデータセンター全体のIPサブネットをカバーする集約経路であるべきです。これらのdiscard経路はそれぞれの機器がmore specificなプレフィックスを新しい経路から学習するまでのネットワーク収束の期間だけ優先されるものです。

8. 設計の追加の選択肢

8.1 サードパーティ・ルート・インジェクション

BGPでは「サードパーティ」(直接接続されたBGPスピーカ)がネットワーク・トポロジーの任意の場所に経路を注入することが可能です。これはREQ5を満たします。トポロジー内の一部または全ての機器とマルチホップBGPセッションを張ることで実現できます。それに加えて、BGP diverse path distribution (RFC6774)を使うことで、同一のプレフィックスに対して複数のBGPネクストホップを注入し、ロードバランスをやりやすくしたり、実装がサポートしていればBGP ADD-PATH機能を使うことが出来るようになりますます。残念ながら多くの実装ではADD-PATHは、最初に最適化されたユースケースにおいてのみIBGPで適切にサポートしていることがわかっています。これによって「サードパーティ」のピアリングはIBGPのみに限定されています。

提案する設計で経路注入を実装するためには、サードパーティのBGPスピーカはTier 3スイッチとTier 1スイッチとピアし、同一のプレフィックスを注入するかもしれませんが、Tier 1機器には特別なBGPネクストホップを使います。このネクストホップはBGPで再帰的に解決されるものであり、例えばTier 3機器のIPアドレスが該当します。異なるクラスタの中で望ましいトラフィックの比率を実現するフォワーディングテーブルを構築することが出来ます。

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

前に述べたとおり、提案したClosトポロジーでは経路集約を行うことは出来ません。単一リンクの障害で経路ブラックホールを起こしやすいネットワークにしてしまうからです。最も大きな問題はネットワーク機器間の限られた数の冗長パスです。たとえば任意のTier 1とTier 3の機器ペアの間には単一のパスしかありません。しかし一部の事業者は経路集約をコントロールプレーンの安定性を高めるために望ましいものだと考えています。

Closトポロジーで経路集約を行うテクニックを考える場合、単一または複数のリンクの障害に対してだけではなく、物理的に離れた場所にトポロジーを拡張しているときのファイバーの物理経路や光ドメインの障害についても考慮に入れて、ルーティング動作とブラックホールの可能性のモデル化を行う必要があります。外部接続性がある状態でのWANルータやそれぞれのTierの機器の間にあるリンクや物理経路の障害の状況において集約を行っている機器で、到達性を確認すれば簡単なモデル化を行うことが出来ます。

ネットワークトポロジに小さな変更を加えるだけで経路集約は可能になるかもしれませんが、特定の障害時のネットワーク輻輳や最大のネットワークサイズが縮小することがトレードオフになります。このアプローチは上で述べたボーダールータにデータセンターのアドレス空間全体を集約させるテクニックに非常に似ています。

8.2.1 Tier 1機器レイヤーの集約

Tier 1機器とTier 3機器の間により多くのパスを追加するためには、Tier 2機器をペアにまとめて、そのペアを同じTier 1機器のグループに接続します。これは論理的には「集約される」機器のリンクをマージしてTier 1機器を半分の大きさのグループに「集約」することと同等です。その結果を図6に示します。たとえばDEV CとDは、今までのトポロジーでは異なるTier 1の機器の組に接続されていましたが、この例では同じ組のTier 1機器(DEV 1と2)に接続されています。

                    Tier 2       Tier 1       Tier 2
                   +-----+      +-----+      +-----+
     +-------------| DEV |------| DEV |------|     |-------------+
     |       +-----|  C  |--++--|  1  |--++--|     |-----+       |
     |       |     +-----+  ||  +-----+  ||  +-----+     |       |
     |       |              ||           ||              |       |
     |       |     +-----+  ||  +-----+  ||  +-----+     |       |
     | +-----+-----| DEV |--++--| DEV |--++--|     |-----+-----+ |
     | |     | +---|  D  |------|  2  |------|     |---+ |     | |
     | |     | |   +-----+      +-----+      +-----+   | |     | |
     | |     | |                                       | |     | |
   +-----+ +-----+                                   +-----+ +-----+
   | DEV | | DEV |                                   |     | |     |
   |  A  | |  B  | Tier 3                     Tier 3 |     | |     |
   +-----+ +-----+                                   +-----+ +-----+
     | |     | |                                       | |     | |
     O O     O O             <- Servers ->             O O     O O

図6: 5-Stage Closトポロジー

この設計を行うためには、Tier 2機器はデフォルトルートだけをTier 3機器に対して広告するように設定します。もしTier 2とTier 3の間のリンクの1本がダウンした場合、トラフィックはTier 2スイッチにとって既知であるもう1本のリンクに送られるようになります。1つのクラスタの経路をカバーするような集約経路をTier 2機器から広告することはまだ出来ません。なぜならそれぞれのTier 2機器はこのプレフィックスに対して単一のパスしか持っていないからです。これを達成するにはサーバをデュアルホームにする必要があるでしょう。この設計は単一リンクの障害に対してだけ耐性があることは覚えておいてください。リンクの二重障害によってTier 2機器が特定のTier 3機器から孤立し、ルーティングブラックホールを生じる可能性があります。

提案したトポロジー修正の結果としてTier 1機器で利用できるポートの数が減ってしまうことになるでしょう。つまり接続できるTier 2機器の最大数が制限されます。それはデータセンターのネットワーク全体の大きさも制限されるということです。この修正を行いながらより大きなネットワークにしたい場合は、よりポート密度の高い別の機器をTier 1機器に採用する必要があるでしょう。

その他の問題にリンク障害時のトラフィックの再バランスがあります。Tier 1からTier 3に向かって2本のパスが存在するため、Tier 1スイッチとTier 2スイッチの間のリンクで障害が発生すると障害が起こったリンクに載っていたすべてのトラフィックが残ったもう1本のパスに移ることになります。これは残ったリンクの使用率が2倍になるということです。

8.2.2 単純な仮想アグリゲーション

コントロールプレーンが完全なルーティング情報を広報できるようにしながらFIBのサイズを小さくするということが一番の目的であるならば、経路集約について先ほどとは全く違うアプローチを行うこともできます。まず複数のプレフィックス(そのうちいくつかはless specific)がネクストホップの集合を共有している、つまり同じECMPグループに所属しているようなケースでは簡単です。たとえば、Tier 3機器において、上流のTier 2機器から学習したデフォルトルートを含むすべての経路は、ネットワークに障害が起きてない限り同じBGPネクストホップになっています。この状況ではRFC6769で紹介されているものと似たテクニックを使うことが可能です。同じネクストホップを持っている場合は、最もless specificな経路だけをFIBにインストールして、その他のmore specificな経路を無視するというテクニックです。例えば通常のネットワークの状態においてはデフォルトルートだけがFIBにインストールされます。

それに加えてTier 2機器が接続しているTier 3機器のプレフィックスをすべてカバーするような集約経路を設定している場合は、同じロジックをTier 1機器に、そして帰納的に異なるクラスタに属するTier 2/Tier 3スイッチにも適用することが可能でしょう。特定のリンク障害時にネクストホップの集合のミスマッチを検出して、特定のプレフィックスネクストホップを変更することを可能にするために、これらの集約経路に対してTier 1機器がmore specificな経路をリークできるようにしておくべきです。

もう一度言い直すと、このテクニックはコントロールプレーンの状態の量(BGP UPDATEの数やBGP Loc-RIBのサイズ)を減らすためのものではなく、同じネクストホップの集合を持つmore specificなプレフィックスを検出してless specificなプレフィックスに組み込むことで、より効率的にFIBを使うためのものです。

8.3 ICMP Unreachableメッセージのマスカレード

この節では、5.2.3節でオプションとしたpoint-to-pointリンクのサブネットをBGPに広告しないことの運用面について議論します。広告しない場合の運用上の影響は traceroute ツールを使う時に現れます。特にこのツールによって表示されるIPアドレスはリンクのpoint-to-pointのアドレスであるため管理用ネットワークからの到達性がないものになることです。このためトラブルシューティングが複雑になります。

この制約を克服する一つの方法はこれらのpoint-to-pointのIPアドレスに対して、その機器のループバックアドレスと同じ逆引きのエントリーをDNSに設定することです。機器への接続性はその機器への「プライマリー」IPアドレス(例えば常にBGPに広告されているループバックアドレス)に名前解決することで実現することが出来ます。しかしこの方法は障害時には使えなくなる可能性があるDNSに依存しています。

もう一つの方法はネットワーク機器がIPアドレスのマスカレードをするようにすることです。つまり機器が送信する適切なICMPメッセージの送信元IPアドレスをその機器の「プライマリー」IPアドレスに書き換えるということです。特にtracerouteツールを正しく運用するためには、ICMP Destination Unreachableメッセージ(type 3)のコード3(port unreachable)とICMP Time Exceeded(type 11)のコード0が必要です。この修正を行うことで、機器に送信されるtracerouteのプローブは、「プライマリー」IPアドレスを送信元として送り返されるようになり、運用者が機器に到達可能なIPアドレスを知ることができるようになります。これには機器への「エントリーポイント」のアドレスを隠してしまうという欠点があります。機器がRFC5873をサポートしている場合、「プライマリー」IPアドレスが返ってきたとしても入力インターフェイスの情報を知ることができるようになり両方の世界で最良の方法を実現することが出来ます。

9. セキュリティの懸念事項

この設計にはいかなるセキュリティの考慮も取り入れていません。一般的なBGPのセキュリティについてはRFC4271とRFC4272で議論されています。データセンターは単一の事業者のドメインであるため、この文書では、データセンターの外部からのBGPセッションそのものに対する攻撃はエッジでのフィルタリングによって防がれます。RFC2385に記述されているTCP MD5の鍵管理を行ったり、この文書が発行される時点では利用可能であるRFC5925のTCP認証オプションの実装が無いことに対処したりすることにくらべれば、この方法はほとんどの環境に対して実現可能である選択肢でしょう。Generalized TTL Security Mechanism (RFC5082)を使うことでBGPセッションのspoofingのリスクを減らすことが可能でしょう。