8. Additional Options for Design (設計の追加オプション)

8.1 Third-Party Route Injection (サードパーティルート注入)

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

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

8.2 Route Summarization within Clos Topology (Clos トポロジー内のルート集約)

前述のように, ルート集約は, 単一のリンク障害の下でルートブラックホールにネットワークを影響を受けやすくするため, 提案された Clos トポロジー内では不可能です。主な問題は, ネットワーク要素間の冗長パスの数が限られていることです。例えば, 任意の Tier 1 と Tier 3 デバイスのペア間には単一のパスしかありません。ただし, 一部のオペレーターは, コントロールプレーンの安定性を改善するためにルート集約が望ましいと考える場合があります。

トポロジー内で集約する手法が計画されている場合, ルーティング動作とブラックホールの可能性のモデリングは, 単一または複数のリンク障害だけでなく, トポロジーが物理的な場所を超えて拡張される場合のファイバーパスウェイ障害または光ドメイン障害についても行う必要があります。単純なモデリングは, すべての層のデバイスセット間のリンクまたはパスウェイ障害の条件下で, および外部接続が存在する場合は WAN ルーターへの到達可能性をチェックすることで行うことができます。

ルート集約は, ネットワークトポロジーを少し変更することで可能になりますが, トレードオフはネットワークの総サイズの削減と, 特定の障害下でのネットワークの輻輳です。このアプローチは, 上記で説明した技術と非常に似ており, Border Router がデータセンター全体のアドレススペースを集約できるようにします。

8.2.1 Collapsing Tier 1 Devices Layer (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 デバイスグループに接続していました。

              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段階 Clos トポロジー

この設計を配置すると, Tier 2 デバイスは, Tier 3 デバイスにダウンへのデフォルトルートのみをアドバタイズするように設定できます。Tier 2 と Tier 3 間のリンクが失敗した場合, トラフィックは Tier 2 スイッチに知られている2番目の利用可能なパスを介して再ルーティングされます。各デバイスがこのプレフィックスへの単一のパスのみを持っているため, 単一のクラスターのプレフィックスをカバーする要約ルートを Tier 2 デバイスからアドバタイズすることは依然として不可能です。それを達成するにはデュアルホームサーバーが必要です。また, この設計は単一のリンク障害に対してのみ回復力があることに注意してください。二重のリンク障害により, Tier 2 デバイスが特定の Tier 3 デバイスへのすべてのパスから分離され, ルーティングブラックホールが発生する可能性があります。

提案されたトポロジー変更の結果は, Tier 1 デバイスのポート容量の削減です。これにより, 接続される Tier 2 デバイスの最大数が制限され, したがって最大 DC ネットワークサイズが制限されます。より大きなネットワークには, この変更を実装するためにより高いポート密度を持つ異なる Tier 1 デバイスが必要になります。

もう1つの問題は, リンク障害下でのトラフィックの再バランシングです。Tier 1 から Tier 3 への2つのパスがあるため, Tier 1 と Tier 2 スイッチ間のリンクの障害により, 障害したリンクを経由していたすべてのトラフィックが残りのパスに切り替わります。これにより, 残りのリンクのリンク使用率が2倍になります。

8.2.2 Simple Virtual Aggregation (シンプル仮想集約)

ルート集約への完全に異なるアプローチが可能です。主な目標が 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 Unreachable Message Masquerading (ICMP 到達不能メッセージマスカレード)

このセクションでは, セクション5.2.3で以前にオプションとして識別された, ポイントツーポイントリンクサブネットを BGP にアドバタイズしないことの運用上の側面について議論します。この決定の運用上の影響は, よく知られた「traceroute」ツールを使用する際に見ることができます。具体的には, ツールによって表示される IP アドレスはリンクのポイントツーポイントアドレスであり, したがって管理接続には到達できません。これにより, 一部のトラブルシューティングがより複雑になります。

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

もう1つのオプションは, ネットワークデバイスに IP アドレスマスカレードを実行させることです。つまり, デバイスによって送信される適切な ICMP メッセージのソース IP アドレスをデバイスの「プライマリ」IP アドレスで書き換えます。具体的には, 「traceroute」ツールの正しい動作には, ICMP Destination Unreachable Message (type 3) code 3 (port unreachable) および ICMP Time Exceeded (type 11) code 0 が必要です。この変更により, デバイスに送信される「traceroute」プローブは常にソースとして「プライマリ」IP アドレスで送り返され, オペレーターがボックスの「到達可能な」IP アドレスを発見できるようにします。これには, デバイスへの「エントリポイント」のアドレスを隠すという欠点があります。デバイスが [RFC5837] をサポートしている場合, これにより, 戻りアドレスが「プライマリ」IP アドレスであっても, 着信インターフェースに関する情報を提供することで, 両方の長所を提供できる可能性があります。