要約

  • RFC 9494は、通常のGraceful Restartを超えてrouteを保持できるが、対象は交渉済みのAFI/SAFIと有限のLong-Lived Stale Timeに限られる。LLGR_STALEを付け、freshなrouteより必ず低く評価する。
  • Enke ChenはRFC 4724とRFC 9494の共著者である。後者は古い経路の健全性を保証しない。受信側の時間上限、NO_LLGR、End-of-RIBによる同期、期限切れ削除と転送上の警告が、継続を条件付きのものにする。

「まだ使える」と「まだ正しい」の間

制御processが落ちても、ASICに書き込まれたnext hopやlabelは残ることがある。tunnelの内部転送も動き続けるかもしれない。このときrouteを即座にすべてwithdrawすれば、局所的な制御障害が利用者の停止へ拡大する。一方、古い状態を無期限に残せば、実際には壊れた経路を静かなまま使い続ける。

BGPが運ぶ情報の種類も一様ではない。通常のunicast reachabilityはpacketのnext hopと近い。VPNの発見情報やsignal、設定に近いNLRIは、session停止と同じ速度で価値を失うとは限らない。ひとつの保持時間をすべてに当てはめれば、違うfailure domainを同じものとして扱ってしまう。

したがって問うべきなのは、stale routeを残すべきか否かという二択ではない。どのaddress familyについて、誰が、何秒、どんな転送証拠をもとに残し、何が起きれば終わらせるのか。LLGRは、その決定をprotocolの外へ隠さず、状態として表現する。

最初の猶予は12 bit

RFC 4724は2007年に発行され、Srihari Sangli、Enke Chen、Ramachandra Fernando、John Scudder、Yakov Rekhterが著者として記録されている。BGP Graceful Restart capabilityとEnd-of-RIB markerを定義し、restarting speakerが転送状態を保ったまま制御を再構築できるようにした。receiving speakerは、そのpeerから学んだrouteをstaleとして一時保持する。

通常のRestart Timeは12 bitで、表現できる上限は4,095秒である。RFC 4724はdefaultをOPENのHOLDTIME以下にするよう勧める。時間内にsessionが戻らなければ、保持中のrouteは削除される。また、BFDなどからpeerの転送が生きていないと分かれば、満了を待たずに消せる。

この短い期間、staleであることはroute preferenceに反映されない。大きなwithdrawalと再収束を避け、すぐ同期が戻ることに賭ける設計だ。RFC 8538は後に、GRを使えるsession終了条件を広げ、完全な再起動を求めるHard Resetも定めた。しかし、猶予が転送の証明ではない点は変わらない。

長期保持は別の状態である

RFC 9494は2023年11月のStandards Track文書で、James Uttaro、Enke Chen、Bruno Decraene、John G. Scudderが著者である。Chenが基礎のRFC 4724と長期拡張の双方に名を連ねることは、IETFの共同成果への継続した貢献を示す。個人による発明や特定製品の実装を証明するものではない。

LLGR capabilityのcodeは71で、<AFI, SAFI, Flags, LLST>を0個以上含む。Long-Lived Stale Timeはaddress familyごとに設定される。RFCは推奨defaultを置いていない。利用形態によって危険が大きく違うからである。受信側は上限、下限、または両方をlocalに課すことができ、相手が示したLLSTを短くできる。

LLGRだけを単独で広告することはできない。通常のGR capabilityが伴わなければ無視される。両方が有効なら、最初に通常GRが走り、その後にLLGRへ移る。Restart Timeを0にすれば最初の段階を省ける。ここで変わるのは時間だけではない。routeが持つ信頼の順位が変わる。

通常GRでは、短時間にfreshな状態へ戻るとの想定が残る。LLGRでは、その想定を弱めなければならない。古い情報を使える余地は残すが、新しい情報と同じ発言力は与えない。

staleという印を消さない

LLGR periodに入ると、helperはAFI/SAFIごとのLLST timerを開始し、well-known community LLGR_STALE、値0xFFFF0006を付ける。そのrouteは、least preferredでないあらゆるrouteより低く選ばれなければならない。候補がすべてleast preferredなら、通常のtie-breakが使われる。

freshな代替経路があれば、それが古いrouteを追い出す。代替がなければ、stale routeがbest pathのままpacketを運ぶことはある。この違いがLLGRの中心だ。利用可能性を最後の手段として残すが、健全性を認定しない。

印は伝播中も保持される。LLGR capabilityを広告していないneighborへは、限定されたIBGPまたはconfederation内の手続きを除き、LLGR_STALE routeを送るべきではない。送る場合もcommunityを外してはならない。上流で分かっていた不確実性を、下流で普通のreachabilityに洗い替えることを防ぐ。

NO_LLGR、値0xFFFF0007は逆方向の意思を表す。このcommunityを持つrouteは長期保持せず、通常のBGP手順で削除する。送信側は長期化してはいけない情報を指定でき、受信側もlocal policyで同じ判断を加えられる。capabilityを理解することと、すべてのrouteを受け入れることは別である。

session再開だけでは時計は止まらない

TCP/BGP sessionが再確立しても、各AFI/SAFIの情報が更新済みとは限らない。同期はEnd-of-RIBを受けるか、selection deferralの境界に達して初めて区切られる。LLSTはその間も進み、満了時にまだstaleのrouteは消される。

連続restartでも、古い証拠へ新しい全期間を機械的に与えてはならない。再接続後に必要なGR/LLGR capabilityがない、対象address familyがない、必要なForwarding Stateが示されない場合も保持は終了する。「話せるようになった」と「以前の状態が更新された」を分離している。

RFC 9494の例では、通常のRestart Timeを1秒、LLSTを3,600秒とする。1秒後、routeにLLGR_STALEが付き、優先度が下がる。backupがなければborder routerは使い続け、能力を持つexternal peerへ印付きで再広告する。期限が来ればrouteを削除しwithdrawする。180秒で同期が終われば、freshなrouteから印を外す。external peerがLLGRを広告していなければ、長期段階の開始時点でwithdrawする。

BGPの低優先度よりlongest prefixが先に働く

危険のひとつは、二つの選択規則の順序にある。LLGR_STALEは同一prefixのBGP path比較で効く。しかしIP forwardingでは、よりspecificなprefixが先に選ばれる。古いmore-specificは、freshだが範囲の広いless-specificよりpacketを強く引き付ける。BGP上で最下位にしても、blackholeを避けられない場合がある。

もうひとつはAS内部の不一致だ。RFC 9494は、あるrouterがstale化した出口を捨てて別の出口へ向かう一方、隣のrouterが旧出口を選び続ける例を示す。二台は互いにpacketを渡し、loopを作り得る。通常GRにも短い不整合はあり得るが、長いLLSTはその寿命を大幅に延ばす。

このため文書のcardinal ruleは明確だ。AS内部でhop-by-hop forwardingに用いるrouteへLLGRを有効化することは推奨されない。MPLSなどのtunnelや、直接の転送と距離のあるBGP情報では懸念が減る。それでも、F bitとForwarding Stateは実際に残った状態を正しく表さなければならない。

VPNではlabel再利用も問題になる。withdrawされた古いrouteのlabelが別のcontextへ割り当てられた後もstale routeが残れば、同じ値が異なる意味を持つ。VPN familyでLLGRを使う前に、label再利用の最小待ち時間をLLSTの最大上限より長くする必要がある。ここではtimerがtenant隔離を支える。

共通なのは状態の意味、採用はlocal

Lu Hengの最小初期仕様、将来判断の局所化、自発的採用という後年の整理を当てると、共通層は小さく保てる。capability、family単位のscope、劣化と拒否のmarker、least-preferred選択、確定したexpiryである。どのpeerとfamilyを認め、何秒受け入れ、どの転送方式なら安全か、何を早期終了条件とするかは、損失を負うoperatorが決める。

共通protocolは保持を命令する中央権限ではない。一方、local policyもLLGR_STALEを消して古い情報をfreshに見せる権利は持たない。互換性は状態の意味を揃え、採用はriskの所在に残る。

Running-Code Primacyの検証では、設定画面やEstablished表示では足りない。交渉されたAFI/SAFI、受信LLSTとlocal cap、LLGRに入ったroute数、best path変更、非対応peerへのwithdraw、End-of-RIB進行、packet loss、loop兆候、最後の削除を観測する必要がある。これはLu Hengの後年の原則をSofia Renが分析に用いたもので、ChenやRFC著者の私的意図を述べるものではない。

RFC 9494が守るべき一線は、残したrouteを最後までstaleと呼ぶことだ。過去の転送状態から時間を借りても、現在の事実へ書き換えない。利用価値は低い順位と期限の内側にだけ存在する。

出典