要約

  • RFC 9494 の LLST は AFI/SAFI ごとに stale 経路の第二の保持期間を提示するが、その秒数は next hop、FIB、サービスが生きているという証明ではない。
  • 正当な LLGR 運用には、能力交渉とローカル上限だけでなく、コミュニティ、選択、伝播、実パケット、EoR、期限切れ、緊急削除までを一つの証拠系列として残す必要がある。

仕組みを切り分けるための例を考える。ある BGP セッションが途絶え、通常の Graceful Restart の時間も終わった。それでも helper は、より具体的な一つの経路をあと六時間保持する。経路は stale とされ、選択上は最下位になる。別に新鮮な集約経路がある。しかし保持されたプレフィックス宛てのパケットは、最長一致によって古い経路を選び続ける。RIB には行き先が残り、サービスには到着しない。

これは仕様違反を前提とする事故ではない。RFC 9494 は、制御プレーンの復旧が長い場合や、BGP が通常の到達性より設定情報に近い状態を運ぶ場合に、即時撤回を遅らせるための仕組みを定義する。その猶予は再構築の負荷を抑えられる一方、失われた転送先や古いサービス状態も長く残し得る。

したがって論点は「装置が LLGR 対応か」ではない。昨日受け取った情報に今日も転送上の効力を与えるのは誰か。相手が示す時間を誰が短くできるか。そして、時計が満了する前に保持を打ち切るだけの反証を誰が持つかである。

GR の後ろに、別の時間が追加される

RFC 4724 は BGP Graceful Restart の基礎を定める。能力コード 64 には Restart Time とアドレスファミリーごとの状態が含まれる。セッションが切れたとき、受信側は再起動中の speaker から学習済みの経路を一時保持できる。End-of-RIB は AFI/SAFI ごとの初期更新が終わったことを示す。

リセット理由も保持判断の一部である。RFC 8538 の N bit を双方が交換していれば、多くの NOTIFICATION や Hold Time 満了でも graceful な扱いが可能になる。一方、Cease の Hard Reset サブコードは完全な終了を求める。「セッション断」という一行だけでは、経路を残すべき事象だったかを判定できない。

RFC 9494 は能力コード 71 を追加する。値は AFI、SAFI、フラグ、24 bit の Long-Lived Stale Time からなる組を並べる。LLST は秒単位で、標準既定値はない。IP 到達性、Route Target 制約、FlowSpec、発見情報では、安全に古くなれる時間が異なるからである。

LLGR は GR から独立した近道ではない。GR 能力を伴わない LLGR 能力は無視しなければならない。EoR、状態機械、接続リセットの基本動作を GR から再利用するためである。能力 71 が見えたという観測だけでは、適用可能な AFI/SAFI と能力 64 の成立を証明していない。

二つの期間は順番に続く。最初の GR 期間では、GR で保持されたという理由だけで経路の選好は下がらない。次の LLGR 期間では、保持経路は least preferred として扱われる。セッション再確立前の上限は、受信した Restart Time と LLST の合計であり、さらにローカル設定で上限や下限を課せる。

どちらかの期間をゼロにもできる。受信側は相手の LLST を短縮できる。相手が提示する秒数は提案であり、ローカルに作用を生むのは helper の受諾である。広告値と実効値を分けて記録しなければ、リスクを選んだ主体が見えなくなる。

最下位でも、経路は消えていない

LLGR 期間に入ると、helper は対象 AFI/SAFI の timer を開始し、保持経路に LLGR_STALE を付ける。IANA 登録値は 0xFFFF0006、十進表記では 65535:6 である。least preferred でない候補は、stale 経路より優先される。候補がすべて least preferred の場合だけ通常の tie-break が続く。

この規則は新鮮な代替を優先させるが、代替経路を生成はしない。正確なプレフィックスに stale 経路しかなければ、それが best path になり得る。さらに新鮮な less-specific が存在しても、FIB に残る stale more-specific がパケットを引き受ける。RFC 9494 は、通常の到達性でこの状態を使うと接続性を失う可能性を明記する。

hop-by-hop の iBGP コアでは、選択の不一致が別の危険を生む。各ルータは自分のセッション状態を観測する。一方は経路を stale として下げ、もう一方はまだ新鮮と判断することがある。異なる出口を選んだ両者がパケットを送り返し、転送ループを作り得る。仕様はこの種の経路集合に LLGR を推奨していない。

トンネル転送はそのループの一部を抑えられるが、宛先サービスを保証しない。RFC 4271 の解決可能性は変わらず必要で、next hop が解決できなければ経路は使えない。RFC 9494 は BFD を追加の生存観測として挙げるが、BFD はアプリケーションやサービスチェーン全体の成功を測らない。

LLGR が認めるのは撤回の延期である。経路起点の認証でも、プレフィックス権限の確認でも、ハードウェア投入の保証でもない。RIB の継続をパケット配送の継続と読み替えてはならない。

長期保持を断るための属性

もう一つの well-known community は NO_LLGR で、値は 0xFFFF0007、65535:7 である。この community が付く経路は LLGR 期間に保持してはならない。広告側が付けることも、helper のローカルポリシーが付けることもできる。

これは経路ごとの拒否経路だが、署名ではない。RFC 1997 の Communities 属性はポリシー情報を運ぶ。値そのものは誰が付与したかを認証しない。途中のポリシーが削除、置換、追加する可能性があるため、重要境界では received と advertised の両方を保存する必要がある。

伝播にも境界がある。LLGR_STALE 経路は、LLGR 能力を広告していない隣接へ送るべきではない。最下位選好を理解する speaker の範囲に stale 状態を閉じ込めるためである。ローカルで保持する判断と、別のネットワーク要素へ再広告する判断は同一ではない。

段階導入には狭い例外がある。LLGR 非対応の iBGP または confederation 内部隣接に stale 経路を出す場合、NO_EXPORT を付け、LOCAL_PREF をゼロにしなければならない。AS 全体で同じゼロを使うべきだと RFC は述べる。必要なのは表示上のマークではなく、一貫した選択である。

セッションが戻っても、期限は止まらない

LLGR の F bit は、前回の再起動で対象 AFI/SAFI の状態が実際に保存されたかを示す。一般的な正常性フラグではない。再確立セッションでその family が欠ける、F bit が立たない、または必要な GR/LLGR 能力がなくなる場合、helper は該当 stale 経路を直ちに削除する。

連続リセットで時間を無制限に延ばすこともできない。手動介入を除き、動作中の LLST timer は、新しいセッションが established かつ synchronized になるまで更新されない。同期は AFI/SAFI ごとで、EoR 受信または Selection_Deferral_Timer 満了によって成立する。

セッションが Established に戻ったあとも、該当 EoR までは LLST が進む。同期中に期限が来れば、相手が refresh しなかった stale 経路を除去する。緑のセッション表示と、消えつつある古い経路集合は同時に存在する。確認すべき対象は「peer が戻ったか」ではなく、「保持した各経路が期限内に更新されたか」である。

EoR は一つの family の初期広告が終わったことを示すだけである。再広告された経路でも next hop 解決、FIB、ラベル、サービスのどこかで失敗し得る。制御プレーンの同期完了と、利用者が受け取る結果は別々に検証する。

長い猶予が合理的な状態

BGP が運ぶ NLRI の一部は、通常のパケット到達性より分散設定に近い。Route Target 制約、FlowSpec、各種 discovery、VPN 制御情報は再構築に時間がかかり、即時撤回が大きな churn や設定消失を招くことがある。下位状態が保たれていれば、長い保持には合理性がある。

それでも RFC 9494 は AFI/SAFI ごとの明示設定を要求し、既定有効化を禁止する。この要件は LLGR が一般的な「可用性向上」ではないことを示す。情報の意味、転送方式、依存状態の安全寿命を個別に判断する例外である。

依存状態が MPLS label の場合、誤りは隔離境界に及ぶ。stale VPN 経路が古い label を参照している間に egress PE がその label を別 VPN へ再利用すると、旧 ingress からのトラフィックが別の文脈に入る可能性がある。RFC 9494 は、label 再利用の下限を LLST 上限より長くするよう求める。

Cisco、Juniper、Nokia の実装文書も、製品と release を証拠に含める必要性を示す。Cisco は send と accept の stale time を分ける。Juniper は receiver、restarter、family、ポリシー除外、手動 clear を分離する。Nokia は SR OS 固有の family と表示状態を示す。ある装置の既定値を BGP 全体の規則にしてはならない。

stale 期間を再現する証拠

第一に交渉を保存する。双方の OPEN または信頼できる neighbor 出力で、GR、LLGR、AFI/SAFI、Restart Time、LLST、N/F bit を記録する。相手の広告値とローカルの受入上限を別フィールドにする。それぞれ決定主体が違う。

第二に開始点を保存する。reset の理由、subcode、時刻、GR 終了、LLGR 開始を記録する。各経路について LLGR_STALE 付与、NO_LLGR 除外、選択結果、再広告先を追う。community が表示されただけでは、選択と伝播に作用したことを証明しない。

第三に転送を保存する。recursive next hop、FIB またはサービス状態、必要なら label と encapsulation、そして stale 期間中の packet や application probe を残す。Loc-RIB の best path は制御上の意図であり、配送結果ではない。

第四に終了を保存する。EoR、LLST 満了、手動 clear のいずれかと、未更新経路の除去を対応させる。サービスが戻れば clean な再広告を、戻らなければ重要境界までの withdrawal を確認する。時間を短縮し rollback できる担当者は事前に決めておく。

出典