メインコンテンツまでスキップ

6. ECMP Considerations (ECMP の考慮事項)

6. ECMP Considerations (ECMP の考慮事項)

このセクションでは, Clos トポロジーの Equal Cost Multipath (ECMP) 機能について説明し, いくつかの特別な要件について議論します。

6.1 Basic ECMP (基本 ECMP)

ECMP は, Clos トポロジーで使用される基本的な負荷共有メカニズムです。実質的に, すべての下位層デバイスは, 直接接続されたすべての上位層デバイスを使用して, 同じ IP プレフィックス宛てのトラフィックを負荷分散します。Clos トポロジーの任意の2つの 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の ECMP ファンアウトが必要になります。Border Router は, セクション5.2.5で説明されているように Border Router レベルでルート集約が実装されている場合, 多数の Tier 1 デバイスに接続できるように, より広いファンアウトが必要になる場合があります。デバイスのハードウェアがより広い ECMP をサポートしていない場合, 論理リンクグループ化 (レイヤー2でのリンク集約) を使用して「階層的」ECMP (レイヤー3 ECMP とレイヤー2 ECMP を組み合わせたもの) を提供し, ファンアウトの制限を補償できます。ただし, このアプローチは, ECMP の第2段階で利用可能なエントロピーが少なくなるため, フロー偏極のリスクを高めます。

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

6.2 BGP ECMP over Multiple ASNs (複数の ASN にわたる BGP ECMP)

アプリケーション負荷分散の目的で, 複数の Tier 3 デバイスから同じプレフィックスをアドバタイズすることが望ましいです。他のデバイスの観点から, そのようなプレフィックスは, AS_PATH 属性の長さは同じですが, 異なる AS_PATH 属性値を持つ BGP パスを持ちます。したがって, BGP 実装は, 上記のパス上での負荷分散をサポートする必要があります。この機能は, 「multipath relax」または「multipath multiple-AS」として知られることがあり, 前のセクションですでに説明したように他のすべての属性が等しい場合, 実質的に異なる隣接 ASN 間で ECMP を実行できるようにします。

6.3 Weighted ECMP (重み付き ECMP)

ネットワークデバイスが「重み付き」ECMP を実装して, ECMP ファンアウトの一部のパスにより多くのトラフィックを送信できるようにすることが望ましい場合があります。これは, ネットワークの障害を補償し, より多くの容量を持つパス上により多くのトラフィックを送信するのに役立ちます。重み付き ECMP が必要なプレフィックスは, セクション8.1でさらに説明されているように, マルチホップセッションを介してリモート BGP スピーカー (中央エージェント) を使用して注入する必要があります。実装でサポートが利用可能な場合, 複数の BGP パスの重み分布は, [LINK] で説明されている手法を使用してシグナリングできます。

6.4 Consistent Hashing (一貫したハッシュ)

ECMP に使用されるハッシュ関数が一貫している ([CONS-HASH] を参照) ことが望ましい場合がよくあります。これにより, ネクストホップが ECMP グループに追加または削除されたときのフローからネクストホップへの親和性変更の影響を最小限に抑えることができます。これは, ネットワークデバイスが複数の宛先へのフローをマッピングするロードバランサーとして使用される場合に使用できます。この場合, 宛先を失ったり追加したりしても, 現在確立されているフローに悪影響を与えません。一貫したハッシュの実装に関する特定の推奨事項は [RFC2992] で提供されていますが, 他の実装も可能です。この機能は重み付き ECMP と自然に組み合わせることができ, ネクストホップ変更の影響は特定のネクストホップの重みに比例します。一貫したハッシュの欠点は, ハードウェアリソース使用率の負荷が増加することです。通常, 一貫したハッシュ関数を実装するためにより多くのリソース (例: Ternary Content-Addressable Memory (TCAM) スペース) が必要になるためです。