7. Routing Convergence Properties (ルーティング収束特性)

このセクションでは, 提案された設計におけるルーティング収束特性をレビューします。実装が高速な EBGP ピアリングセッションの非アクティブ化と, 関連するリンクの障害時のタイムリーな RIB および FIB の更新をサポートしている場合, サブ秒の収束が達成可能であることが示されています。

7.1 Fault Detection Timing (障害検出タイミング)

BGP は通常, AS 内のリンク/ノード障害をルーティングするために IGP に依存し, ポーリングベースまたはイベント駆動型メカニズムを実装して IGP 状態変更の更新を取得します。提案されたルーティング設計は IGP を使用しないため, 障害検出に使用できる残りのメカニズムは, BGP キープアライブタイムアウト (または他のタイプのキープアライブメカニズム) とリンク障害トリガーです。

BGP キープアライブパケットのみに依存すると, 複数秒のオーダーでの高い収束遅延が生じる可能性があります (多くの BGP 実装では, 設定可能な最小 BGP ホールドタイマー値は3秒です)。ただし, 多くの BGP 実装は, BGP ピアリングに使用される発信インターフェースの「リンクダウン」イベントに応答して, ローカル EBGP ピアリングセッションをシャットダウンできます。この機能は「fast fallover」と呼ばれることがあります。最新のデータセンターのリンクは主にポイントツーポイントファイバー接続であるため, 物理インターフェースの障害はミリ秒単位で検出されることが多く, その後 BGP 再収束がトリガーされます。

イーサネットリンクは, [IEEE8021Q] で説明されている Connectivity Fault Management (CFM) などの障害シグナリングまたは検出標準をサポートしている場合があります。これにより, 障害検出がより堅牢になる可能性があります。あるいは, 一部のプラットフォームは Bidirectional Forwarding Detection (BFD) [RFC5880] をサポートして, サブ秒の障害検出と BGP プロセスへの障害シグナリングを可能にする場合があります。ただし, これらのいずれかの使用は, ベンダーソフトウェアおよび場合によってはハードウェアに追加の要件を提示し, REQ1 と矛盾する可能性があります。最近の [RFC7130] まで, BFD は LAG 上の単一メンバーリンク障害の検出も許可していませんでした。これにより, 一部の設計での有用性が制限されていました。

7.2 Event Propagation Timing (イベント伝播タイミング)

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

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

7.3 Impact of Clos Topology Fan-Outs (Clos トポロジーファンアウトの影響)

Clos トポロジーには大きなファンアウトがあり, このセクションで説明するように, 場合によっては「Up->Down」収束に影響を与える可能性があります。Tier 3 と Tier 2 デバイス間のリンクが失敗する状況では, Tier 2 デバイスはすべてのアップストリーム Tier 1 デバイスに BGP UPDATE メッセージを送信し, 影響を受けるプレフィックスを撤回します。Tier 1 デバイスは, これらのメッセージをすべてのダウンストリーム Tier 2 デバイス (発信者を除く) に中継します。UPDATE を発信する Tier 2 デバイス以外の Tier 2 デバイスは, 影響を受けるプレフィックスを削除し, 対応する UPDATE をダウンストリームに接続された Tier 3 デバイスに送信する前に, すべてのアップストリーム Tier 1 デバイスが UPDATE メッセージを送信するのを待つ必要があります。元の Tier 2 デバイスまたは中継 Tier 1 デバイスが UPDATE メッセージアナウンスに遅延を導入する場合, 結果は複数秒にもなる UPDATE メッセージ「分散」になる可能性があります。このような動作を回避するために, BGP 実装は「update groups」をサポートする必要があります。「update group」は, 同じアウトバウンドポリシーを共有するネイバーのコレクションとして定義されます -- ローカルスピーカーは, グループのメンバーに BGP 更新を同期的に送信します。

このような「分散」の影響は, トポロジーファンアウトのサイズとともに増加し, ネットワーク収束チャーンの下でも増加する可能性があります。一部のオペレーターは, ベンダーが含む「route flap dampening」タイプの機能を導入して, 急速にフラッピングするプレフィックスのコントロールプレーンへの影響を減らしたくなるかもしれません。ただし, 特にこのような「分散」イベントの下でこれらの実装の誤検出で説明されている問題のため, この設計でこの機能を有効にすることはお勧めしません。「route flap dampening」に関する詳細な背景と問題, およびこれに影響を与える可能性のある実装の変更については, [RFC7196] でよく説明されています。

7.4 Failure Impact Scope (障害影響範囲)

ネットワークは, 障害影響範囲内のすべてのデバイスがイベントの通知を受け, RIB を再計算し, その結果 FIB を更新すると, 障害に応答して収束したと宣言されます。より大きな障害影響範囲は通常, より遅い収束を意味します。これは, より多くのデバイスに通知する必要があり, ネットワークの安定性が低下するためです。このセクションでは, Clos トポロジーの障害影響範囲を減らす際の BGP のリンクステートルーティングプロトコルに対する利点について説明します。

BGP は, ローカルルーターの観点からの最適パスのみがネイバーに送信されるという意味で, ディスタンスベクトルプロトコルのように動作します。そのため, ローカルノードがすぐにバックアップパスを見つけることができ, さらに更新を送信する必要がない場合, 一部の障害はマスクされます。最悪の場合, データセンタートポロジー内のすべてのデバイスがプレフィックスを完全に撤回するか, FIB 内の ECMP グループを更新する必要があることに注意してください。ただし, 多くの障害はそのような広い影響をもたらしません。影響範囲が削減される主な障害タイプは2つあります:

Tier 2 と Tier 1 デバイス間のリンクの障害: この場合, Tier 2 デバイスは影響を受ける ECMP グループを更新し, 障害が発生したリンクを削除します。パスが BGP プロセスによってベストとして選択されていない限り, ダウンストリーム Tier 3 デバイスに新しい情報を送信する必要はありません。その場合, 「暗黙的な撤回」のみを送信する必要があり, これは転送に影響を与えないはずです。影響を受けた 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 デバイス上の単一の ECMP グループを共有していることは注目に値します。したがって, 階層的な FIB を持つ実装の場合, FIB に対して単一の変更のみを行う必要があります。ここでの「階層的 FIB」とは, ネクストホップ転送情報がプレフィックス検索テーブルとは別に保存される FIB 構造を意味し, 後者はそれぞれの転送情報へのポインタのみを保存します。FIB 階層と高速収束についての議論については, [BGP-PIC] を参照してください。

BGP が一部のケースで障害スコープの削減を提供しているにもかかわらず, 集約を使用した障害ドメインのさらなる削減は, 以前に述べたようにこの手法がルーティングブラックホールを作成する可能性があるため, 提案された設計では常に可能ではありません。したがって, コントロールプレーン上の最悪の障害影響範囲はネットワーク全体です -- 例えば, Tier 2 と Tier 3 デバイス間のリンク障害の場合。この場合の影響を受けるプレフィックスの量は, Clos ネットワークトポロジーの上位層での障害の場合よりもはるかに少なくなります。このような大きな障害範囲を持つプロパティは, 設計で EBGP を選択した結果ではなく, Clos トポロジーを使用した結果です。

7.5 Routing Micro-Loops (ルーティングマイクロループ)

ダウンストリームデバイス (例: Tier 2 デバイス) がプレフィックスのすべてのパスを失うと, 通常はアップストリームデバイス (この場合は Tier 1 デバイス) を指すデフォルトルートを持ちます。その結果, Tier 2 スイッチがプレフィックスを失ったが, Tier 1 スイッチがまだ Tier 2 デバイスを指すパスを持っている状況になる可能性があります。これにより, Tier 1 スイッチが影響を受けるプレフィックスへのパケットを Tier 2 デバイスに渡し続け, Tier 2 がデフォルトルートを使用してそれらを再びバウンスバックするため, 一時的なマイクロループが発生します。このマイクロループは, アップストリームデバイスが転送テーブルを完全に更新するまでの時間続きます。

このようなマイクロループの影響を最小限に抑えるために, Tier 2 および Tier 1 スイッチを静的な「discard」または「null」ルートで設定できます。これは, ネットワーク収束中に欠落しているプレフィックスのデフォルトルートよりも具体的になります。Tier 2 スイッチの場合, 破棄ルートは, 基礎となる Tier 3 デバイスのすべてのサーバーサブネットをカバーする要約ルートである必要があります。Tier 1 デバイスの場合, 破棄ルートは, データセンター全体に割り当てられたサーバー IP アドレスサブネットをカバーする要約である必要があります。これらの破棄ルートは, デバイスが新しいパスを介してより具体的なプレフィックスを学習するまで, ネットワーク収束の期間中のみ優先されます。