要約
MinRouteAdvertisementIntervalTimerは、同じ宛先の変更を一つのpeerへ広告できる頻度を制限する。待機中もローカルのDecision Processは止まらない。- 区間内で最良経路が複数回変われば、RFC 4271は満了時に最後に選ばれた経路を送るよう求める。隣接網が知るのは現在の結果であり、ローカルな経緯のすべてではない。
- 短い区間は鮮度を高めるがUPDATEと分散計算を増やす。長い区間は揺れをまとめるが、障害、代替、復旧の有用な情報まで遅らせ得る。
一つのプレフィックスを考える。10時00分00秒に経路Aが選ばれ、peerへ伝えられた。4秒後にAが失われてBが最良になる。さらに5秒後、ローカルポリシーによってCが最良になる。ローカルRIBは三つの選択を記録し、FIBも複数の状態を使ったかもしれない。しかしpeerが聞くのはAとCだけである。Bは架空ではない。外へ話すことを許された時間の間に消えたのである。
この時間圧縮がMinimum Route Advertisement Interval、MRAIの中核である。RFC 4271は、共通する宛先集合について一つのpeerへ送る連続UPDATEの最小間隔として定義する。値はpeerごとに設定され、制限の意味は宛先ごとに働く。一つの関係に一つの周期があることと、無関係な全プレフィックスを一列に並べることは同じではない。
仕様は宛先ごとに文字どおりのタイマーオブジェクトを持つよう要求しない。それ自体が過大な状態になるからだ。別のスケジューラーでも、最小間隔を保証し、遅延に一定の上限を与えるならよい。共通契約が定めるのは外から観測できる時間動作であり、内部データ構造ではない。
待っている間にもBGPの経路選択は進む。受信UPDATEはポリシーで評価され、best pathは変わり、転送も追従できる。保留されるのは、影響する宛先について特定の隣接網へ出す次の発言である。何度も選び直したなら、満了時には最後の結果を広告する。受信側は許可時点の最新回答を得るが、その回答を生んだ全履歴は得ない。
節約される費用は実在する。すぐ消える中間状態のために、各下流ルーターがメッセージを受け取り選択をやり直す必要がなくなる。RFC 4271もMRAIをルーティングトラフィックのオーバーヘッド制御に置き、UPDATEの帯域とDecision Processの計算量を挙げる。一台が即時開示を望めば、その費用は多数の他者へ広がる。
1997年SIGCOMMのルーティング不安定性研究は、交換点の観測で、持続的なトポロジー変化だけでは説明しにくい大量の病的UPDATEを記録した。当時の数値を2026年のインターネットへそのまま移すことはできない。それでも、BGPメッセージが安定した到達性知識を増やさずに大きな作業を生むことがあるという問題は明確である。
2000年SIGCOMMの収束研究は反対側の費用を示した。受動計測と制御した障害注入では、AS間の障害、フェイルオーバー、修復が分単位になることがあった。独立した経路選択とpath explorationが一時的な損失と遅延を生んだ。MRAIだけが原因ではないが、メッセージを減らす仕組みが分散知識の確定時間と無関係だとは言えない。
したがって短ければ常に良いわけではない。妥当な代替経路を早く示す一方、path explorationの途中をすべて外部へ運び、受信側ごとに計算させることがある。peerの周期がそろえばUPDATEとCPUのピークができる。このためRFC 4271はMRAIを含む複数タイマーにjitterを推奨する。平均量だけでなく同時性がリスクになる。
長ければ安全というわけでもない。短命な選択をまとめられるが、修復した経路を隣接網が必要とする時間より長く隠すこともある。送信側はすでにCを使い、受信側はA、古いwithdrawal、あるいは経路なしで動く。鮮度予算なしの制御面保護は、ローカルな節約を相手の損失へ変える。
最初の広告とwithdrawalについても断定を避けるべきである。RFC 4271が定めるのは関連する連続UPDATEの間隔であり、すべての初回広告が必ず一周期待つという規則ではない。直前の広告、実行中のスケジューラー、製品実装で結果が変わる。すべてのwithdrawalが即時、あるいはすべて遅延という主張は、稼働中の証拠なしには成立しない。
AS内部と外部では目的も異なる。RFC 4271はAS内部に速い収束が必要だとし、iBGPでは短い間隔、または内部peerへの適用省略を推奨する。全iBGPをゼロにせよという命令ではない。新しいローカル判断を自組織の配布層が不必要に隠せば、AS全体が整合して行動できないという境界を示している。
eBGPに30秒、iBGPに5秒という推奨値は、しばしば普遍的な既定値のように扱われる。しかしそうではない。RFC 4273はpeerごとの管理対象を示して同じ推奨を繰り返す一方、製品は文脈ごとに異なる。引用したCisco IOS文書は、該当系列で通常eBGPを30秒、iBGPをゼロ、VRF内eBGPをゼロとしている。別製品、別版には別の実装があり得る。
設定階層も証拠を曖昧にする。address family、neighbor、peer group、neighbor group、session groupから値が継承され、優先順位で見た行とは違う値が動く場合がある。IOS XRの運用表示が示すpeerの最小広告実行間隔のように、稼働状態は親テンプレートの意図より強い証拠になる。
それでも実効値だけでは結果を説明できない。同じNLRIについて、best pathの時刻、Adj-RIB-Outの変化、MRAIキュー、UPDATE送信、peer受信、FIBと到達性イベントを結ぶ必要がある。一通に何回の選択が圧縮され、その中間状態が損失を避けたかを判断するためだ。UPDATEが減ったという統計だけでは健全性を証明できない。
MRAIはRoute Flap Dampingではない。dampingは過去の不安定さを減衰するpenaltyとして記憶し、経路を抑止することがある。MRAIは経路の履歴を評価せず、peerへの発言間隔を決めるだけだ。待機中も経路がローカルで選択され転送に使われ得る。抑止されたわけではない。
生存判定タイマーでもない。HoldTimerとKeepaliveはBGPセッションの存続を決め、BFDは転送障害を早く検出できる。速い検出はローカル選択を早めても、結果のUPDATEが出力周期を飛び越えることを保証しない。RFC 7938がデータセンターのイベント伝播時間にMRAIを含めるのは、この分離があるためだ。
ADD-PATHが変えるのは何を言えるかであり、いつでも言えるという意味ではない。一つのNLRIに複数path identifierを持たせ、best-only広告が隠した代替を見せられる。しかし全中間選択を価値ある情報に変えず、出力スケジューリングも廃止しない。可視性と周期は別の制御面である。
BGP関係には非対称な時間委任がある。送信側が変化を公開する頻度を決め、受信側が知識の古さを負担する。受信側は区間途中のUPDATEを強制できないが、到着間隔を測り、サービス期待を合意し、上流を多様化し、どの程度の陳腐化を許すか決められる。
Heng Luの最小初期仕様の原則はこの境界に合う。共通プロトコルは相互運用と有限の負荷に必要な時間意味を定めるべきだが、処理能力、トポロジー、peerの役割、利用者影響が異なる全ネットワークに単一値を課すべきではない。費用がローカルだから選択もローカルに残る。ただし、その影響を負担する者が観測できなければならない。
running codeの優先は責任の検査方法になる。設定値は意図にすぎない。実際の継承、スケジューラー、UPDATE trace、相手側の観測、パケット配送がシステムである。「保護」するタイマーが顧客損失を延ばしたなら、commit成功はその判断を正当化しない。
三度の選択が一通になることは欺瞞でも真実の精製でもない。時間を割り当てる決定である。最後の経路は許可時点の最新ローカル回答であって、将来の安定を保証しない。指導者の仕事は交換条件を明示することから始まる。制御作業を減らす代わりに、分散知識を古くするのである。
出典
- RFC 4271: A Border Gateway Protocol 4
- RFC 4273: Definitions of Managed Objects for BGP-4
- RFC 1771: A Border Gateway Protocol 4
- RFC 2914: Congestion Control Principles
- RFC 2439: BGP Route Flap Damping
- RFC 7938: Use of BGP for Routing in Large-Scale Data Centers
- RFC 7911: Advertisement of Multiple Paths in BGP
- SIGCOMM 2000: An Experimental Study of Delayed Internet Routing Convergence
- SIGCOMM 1997: Internet Routing Instability
- Cisco IOS: neighbor advertisement-interval
- Cisco ASR 9000: advertisement-interval
- Heng Lu: Running-Code Primacy
- Heng Lu: Minimum Initial Specification
- Heng Lu: On Data Sovereignty
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
