5. Routing Protocol Design (ルーティングプロトコル設計)

このセクションでは, レイヤー3プロトコル設計と Clos トポロジーを持つデータセンターネットワークの単一ルーティングプロトコルとして External BGP (EBGP) を使用する動機をレビューします。次に, EBGP ベースのネットワークを設計するための実用的なアプローチを提供します。

5.1 Choosing EBGP as the Routing Protocol (ルーティングプロトコルとしての EBGP の選択)

REQ2 は, 複雑さと相互依存関係を減らすために単一のルーティングプロトコルの選択を優先します。この状況では IGP に依存するのが一般的ですが, WAN に隣接するデバイスで EBGP を追加するか, 全体で Internal BGP (IBGP) を使用することもありますが, このドキュメントでは EBGP のみの設計の使用を提案します。

EBGP はインターネット上のほぼすべてのドメイン間ルーティングで使用されるプロトコルであり, ベンダーとサービスプロバイダーコミュニティの両方から幅広いサポートを受けていますが, 多くの理由 (そのいくつかは相互に関連しています) により, データセンター内の主要なルーティングプロトコルとして一般的に展開されていません:

BGP は「WAN のみのプロトコル」として認識されており, エンタープライズやデータセンターアプリケーションでは考慮されないことがよくあります。
BGP は IGP と比較して「はるかに遅い」ルーティング収束を持っていると考えられています。
大規模な BGP 展開では, IBGP トポロジー内のすべてのノードが直接接続されていないため, 通常 BGP ネクストホップ解決に IGP を利用します。
BGP は重要な設定オーバーヘッドが必要であり, ネイバー自動検出をサポートしていないと認識されています。

このドキュメントでは, 提案された設計に適用される限り, これらの認識のいくつかについて議論し, プロトコルを使用することの利点のいくつかを強調します:

BGP はプロトコル設計の一部で複雑さが少ない -- 内部データ構造とステートマシンは, OSPF などのほとんどのリンクステート IGP と比較して単純です。たとえば, 隣接関係の形成, 隣接関係の維持, フロー制御を実装する代わりに, BGP は単に基礎となるトランスポートとして TCP に依存します。これは REQ2 と REQ3 を満たします。
BGP 情報のフラッディングオーバーヘッドは, リンクステート IGP と比較して少なくなります。すべての BGP ルーターは選択された最適パスのみを計算して伝播するため, BGP スピーカーが代替パスを見つけるとすぐにネットワーク障害がマスクされます。これは, EBGP のみの設計と組み合わせた Clos などの高度に対称的なトポロジーの場合に存在します。対照的に, リンクステート IGP のイベント伝播スコープは, 障害タイプに関係なく, エリア全体です。このように, BGP は REQ3 と REQ4 をよりよく満たします。また, 広く展開されているすべてのリンクステート IGP は, ルーティング情報の定期的な更新を特徴としていますが, BGP はルーティング状態を期限切れにしませんが, これが最新のルーターコントロールプレーンに影響を与えることはめったにありません。
BGP はサードパーティ (再帰的に解決される) ネクストホップをサポートします。これにより, マルチパスを非 ECMP ベースまたは転送ベースにすることができ, アプリケーション定義パスに基づいて, システムにルーティング情報を注入できるアプリケーション「コントローラー」とのピアリングセッションを確立することで, REQ5 を満たします。OSPF は「Forwarding Address」などの概念を使用して同様の機能を提供しますが, 実装がより困難で, 情報伝播スコープの制御がはるかに少なくなります。
明確に定義された Autonomous System Number (ASN) 割り当てスキームと標準の AS_PATH ループ検出を使用して, 「BGP パスハンティング」([JAKMA2008] を参照) を制御でき, 複雑な不要なパスが無視されます。実用的な ASN 割り当てスキームの例については, セクション5.2を参照してください。リンクステート IGP で同じ目標を達成するには, マルチ (インスタンス/トポロジー/プロセス) サポートが必要になりますが, 通常はすべての DC デバイスで利用できず, 設定とトラブルシューティングが非常に複雑です。ほとんどの DC 設計が利用する従来の単一フラッディングドメインを使用すると, 特定の障害条件下で, 複数の Tier 2 デバイスを通過するなど, 不要な長いパスを拾う可能性があります。
最小限のルーティングポリシーで実装される EBGP 設定は, ネットワーク到達可能性の問題のトラブルシューティングが容易です。ほとんどの実装では, BGP Loc-RIB の内容を表示し, ルーターの Routing Information Base (RIB) と比較することは簡単です。また, ほとんどの実装では, オペレーターはすべての BGP ネイバーの Adj-RIB-In および Adj-RIB-Out 構造を表示できるため, 着信および発信 Network Layer Reachability Information (NLRI) 情報を BGP セッションの両側で簡単に相関させることができます。したがって, BGP は REQ3 を満たします。

5.2 EBGP Configuration for Clos Topology (Clos トポロジーの EBGP 設定)

5段階を超える Clos トポロジーは, そのような設計で必要な大量の相互接続のため, 非常にまれです。したがって, 以下の例は, 5段階 Clos トポロジー (展開されていない状態) を参照して作成されています。

5.2.1 EBGP Configuration Guidelines and Example ASN Scheme (EBGP 設定ガイドラインと ASN スキームの例)

以下の図は, ASN 割り当てスキームの例を示しています。使用できるガイドラインのリストは次のとおりです:

EBGP シングルホップセッションは, 同じノードペア間に複数のリンクがある場合でも, ネットワークノードを相互接続する直接ポイントツーポイントリンク上で確立され, マルチホップまたはループバックセッションは使用されません。
ASN の競合を回避するために, 64512-65534 の範囲のプライベート使用 ASN が使用されます。
単一の ASN がすべての Clos トポロジーの Tier 1 デバイスに割り当てられます。
一意の ASN が同じクラスター内の Tier 2 デバイスの各セットに割り当てられます。
一意の ASN がこのトポロジーのすべての Tier 3 デバイス (例: ToR) に割り当てられます。

                          ASN 65534
                         +---------+
                         | +-----+ |
                         | |     | |
                       +-|-|     |-|-+
                       | | +-----+ | |
            ASN 646XX  | |         | |  ASN 646XX
           +---------+ | |         | | +---------+
           | +-----+ | | | +-----+ | | | +-----+ |
+-----------|-|     |-|-+-|-|     |-|-+-|-|     |-|-----------+
|       +---|-|     |-|-+ | |     | | +-|-|     |-|---+       |
|       |   | +-----+ |   | +-----+ |   | +-----+ |   |       |
|       |   |         |   |         |   |         |   |       |
|       |   |         |   |         |   |         |   |       |
|       |   | +-----+ |   | +-----+ |   | +-----+ |   |       |
|| +-----+---|-|     |-|-+ | |     | | +-|-|     |-|---+-----+ |
|| |     | +-|-|     |-|-+-|-|     |-|-+-|-|     |-|-+ |     | |
|| |     | | | +-----+ | | | +-----+ | | | +-----+ | | |     | |
|| |     | | +---------+ | |         | | +---------+ | |     | |
|| |     | |             | |         | |             | |     | |
|+-----+ +-----+         | | +-----+ | |           +-----+ +-----+
|| ASN | |     |         +-|-|     |-|-+           |     | |     |
||65YYY| | ... |           | |     | |             | ... | | ... |
|+-----+ +-----+           | +-----+ |             +-----+ +-----+
|  | |     | |             +---------+               | |     | |
|  O O     O O            <- Servers ->              O O     O O

           図4: 5段階 Clos の BGP ASN レイアウト

5.2.2 Private Use ASNs (プライベート使用 ASN)

プライベート使用 ASN の元の範囲 [RFC6996] により, オペレーターは1023個の一意の ASN に制限されていました。ネットワークデバイスの数がこの数を超える可能性が高いため, 回避策が必要です。1つのアプローチは, 異なるクラスター間で Tier 3 デバイスに割り当てられた ASN を再利用することです。たとえば, プライベート使用 ASN 65001, 65002 ... 65032 をすべての個別クラスター内で使用し, Tier 3 デバイスに割り当てることができます。

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

この問題の別の解決策は, Four-Octet ASN ([RFC6793]) を使用することです。ここでは, 追加のプライベート使用 ASN が利用可能です。[IANA.AS] を参照してください。Four-Octet ASN の使用は, BGP 実装に追加のプロトコル複雑性をもたらし, REQ3 と REQ4 を考慮する際に再利用の複雑さとバランスを取る必要があります。おそらくもっと重要なことに, それらはまだすべての BGP 実装でサポートされておらず, DC 機器のベンダー選択を制限する可能性があります。サポートされている場合, これらの ASN への外部接続 (セクション5.2.4) が必要な場合に, 展開された実装がプライベート使用 ASN を削除できることを確認してください。

5.2.3 Prefix Advertisement (プレフィックスアドバタイズメント)

Clos トポロジーには, 多数のポイントツーポイントリンクと関連するプレフィックスがあります。これらのすべてのルートを BGP にアドバタイズすると, ネットワークデバイスで Forwarding Information Base (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 ネットワークで限定された形式のルート集約を実行するための侵襲性の低い方法を紹介し, 関連するトレードオフについて説明します。

5.2.4 External Connectivity (外部接続)

Clos トポロジーの専用クラスター (または複数のクラスター) は, Wide Area Network (WAN) エッジデバイス, または WAN ルーターに接続する目的で使用できます。このようなクラスターの Tier 3 デバイスは WAN ルーターに置き換えられ, EBGP ピアリングが再度使用されますが, 設計でインターネット接続が必要な場合, WAN ルーターはパブリック ASN に属している可能性があります。このような専用クラスターの Tier 2 デバイスは, このドキュメントでは「Border Router」と呼ばれます。これらのデバイスは, いくつかの特別な機能を実行する必要があります:

WAN ルーターにパスをアドバタイズするときにネットワークトポロジー情報を隠す, つまり AS_PATH 属性からプライベート使用 ASN [RFC6996] を削除します。これは通常, 異なるデータセンター間の ASN 番号の衝突を回避し, トポロジーで発生するエニーキャストプレフィックスへの WAN ECMP の目的で WAN に均一な AS_PATH 長を提供するために行われます。「Remove Private AS」と通常呼ばれる実装固有の BGP 機能が通常これを達成するために使用されます。実装によっては, この機能はネイバーにパスをアドバタイズする前に AS_PATH 属性で見つかったプライベート使用 ASN の連続シーケンスを削除する必要があります。これは, データセンター内の番号付けに使用されるすべての ASN がプライベート使用範囲からのものであることを前提としています。プライベート使用 ASN を削除するプロセスは現在標準化されていません。[REMOVAL] を参照してください。ただし, ほとんどの実装は少なくともこのベンダーのドキュメント [VENDOR-REMOVE-PRIVATE-AS] で説明されているロジックに従っており, これは指定された設計に十分です。
データセンターデバイスにデフォルトルートを発信します。これは, ルート集約が変更されていない Clos トポロジーにとって危険であるため, デフォルトルートを発信できる唯一の場所です。あるいは, Border Router は単に WAN ルーターから学習したデフォルトルートを中継する場合があります。Border Router からデフォルトルートをアドバタイズするには, すべての Border Router が上流の WAN ルーターに完全に接続されている必要があり, トラフィックのブラックホールを引き起こす単一のリンク障害に対する耐性を提供します。特定のデバイスですべての WAN ルーターへの EBGP セッションが同時に失敗する状況でブラックホールを防ぐために, 一部の実装 [CONDITIONALROUTE] によって提供される複雑な条件付きルート発信スキームを介してデフォルトルートを発信するよりも, デフォルトルートを再アドバタイズする方が望ましいです。

5.2.5 Route Summarization at the Edge (エッジでのルート集約)

完全にルーティングされたネットワーク設計では, データセンター内から発信される IP プレフィックスの量が多いため, WAN ネットワークにアドバタイズする前にネットワーク到達可能性情報を集約することが望ましい場合がよくあります。たとえば, 2000台の Tier 3 デバイスを持つネットワークには, インフラストラクチャプレフィックスとともに BGP にアドバタイズされる少なくとも2000のサーバーサブネットがあります。ただし, セクション5.2.3で説明したように, 提案されたネットワーク設計では, すべての層内でピアリンクがないため, ルート集約が許可されません。

ただし, これらのデバイスに異なる接続モデルを考案することにより, Border Router に対してこの制限を解除することができます。2つのオプションが可能です:

物理リンクの完全メッシュまたはリングやハブアンドスポークなどの他の「ピアメッシュ」トポロジーを使用して Border Router を相互接続します。ネットワーク到達可能性情報を交換するために, すべての Border Leaf で BGP を適切に設定します。例えば, IBGP セッションのメッシュを追加します。相互接続するピアリンクは, Border Router を接続するメッシュでデバイスまたはリンク障害が発生した場合に存在するトラフィックに適切なサイズにする必要があります。
Tier 1 デバイスには, Border Router (Tier 1 の観点からは Tier 2 デバイス) に向けて追加の物理リンクがプロビジョニングされている場合があります。具体的には, 単一のリンクまたはノード障害からの保護が必要な場合, 各 Tier 1 デバイスは少なくとも2つの Border Router に接続する必要があります。これにより, Tier 1 デバイスと Border Router のポート数に追加の要件が課せられ, Clos 内の他のデバイスと比較して不均一で大きなポート数のデバイスになる可能性があります。これにより, 「通常の」Tier 2 スイッチで利用可能なポート数が削減され, したがって Tier 1 を介して相互接続できるクラスターの数が削減されます。

上記のいずれかのオプションが実装されている場合, 単一のリンク障害の下でルーティングブラックホール条件のリスクなしに, Border Router で WAN ネットワークコアに向けてルート集約を実行することができます。両方のオプションは, 追加のリンクを一部のネットワークデバイスにプロビジョニングする必要があるため, 不均一なトポロジーになります。