要約

  • grace-LSAはbounded grace periodとrestart reasonを示す依頼である。隣接はlocal policyにより拒否、時間制限、理由制限を選べるため、受信や送信だけではhelper acceptanceにならない。
  • 各segmentの判断と終了理由に加え、LSA IDとprefix、Interface IDと実体interfaceの対応、保持FIBとpacket結果を結び付けて初めて継続性を説明できる。

変更記録には「grace-LSA送信成功」とあり、オーケストレーターは全隣接がhelperになったと表示した。実際には一台が、upgrade以外を助けないlocal policyによって要求を拒否していた。

再起動が始まると、その隣接は通常どおり関係を落とした。他のsegmentはhelperを続けた。単一の緑色ステータスは、異なるローカル判断を一つの架空の合意へ変えていた。

要求と受理の境界

RFC 5187はOSPFv2のRFC 3623をOSPFv3へ適用する。再起動ルーターはlink-local scopeのgrace-LSAを発行し、指定期間だけFULLとして広告を続けるよう求める。LS typeは0x000b、function codeは11である。

必須TLVはgrace periodとreasonであり、理由はunknown、software restart、reload/upgrade、redundant control processorへの切替である。Link State IDは送信interfaceのInterface IDとなる。OSPFv3は全linkでRouter IDによりneighborを識別するため、OSPFv2のrouter-address TLVは不要である。

しかし要求は分散した権限を消さない。neighborはhelperを常に拒否でき、最大時間を制限し、理由を選び、自身のrestart中は拒める。helping relationshipはsegment単位である。

acceptanceを観測可能なobjectにする

必要な記録は、送信時刻だけではない。neighbor Router ID、interface、受信したgrace-LSAのageとsequence、local policy version、accept/reject、実効deadline、helper開始時刻、終了時刻と理由を保存する。

同じrouterが複数segmentで異なる結果を持ち得る。aggregate statusは、その集合から導出されなければならない。一つでも拒否があり、そこを通る転送が重要なら「一部保護」を「graceful」と短縮してはいけない。

この境界は高速な自動化と矛盾しない。判断をローカルに残したまま、その判断をreceiptとして共有すればよい。

helperは前提が崩れれば退出する

graceful restartはtopologyが安定し、restart前のforwarding tableが保持されるときに安全である。helperは成功、grace period expiry、または関連topology changeで終了する。strict LSA checkingはさらに保守的な退出を選べる。

退出は協調の失敗ではない。restart中のrouterが保持FIBを迅速に修正できないとき、通常OSPF convergenceへ戻す安全弁である。元のtimerが残っていても、helper authorityはすでに終わっている。

dashboardは各helperの状態を追跡し、最後に送ったgrace periodを唯一の真実にしてはならない。

LSA IDはprefixとの対応を保つ

OSPFv3のinter-area-prefixおよびexternal LSA IDは、prefixそのものではなく32-bit integerである。RFC 5187はrestartをまたいでID-to-prefix correspondenceを保存するようMUSTで要求する。

同じIDが別prefixを指せば、数字は継続しても意味は変わる。同じprefixが別IDになれば、不要なchurnを起こす。IDの集合や件数だけでなく、完全なkey-value mapを比較する必要がある。

Interface IDも隣接状態の意味を固定する

Link-LSA、Network-LSA、Router-LSAのlink descriptionはInterface IDに依存する。restartで変わるとpre-restart LSAとneighbor adjacency stateが一致せず、graceful restartは早期終了する。

多くの実装はIfIndexを利用する。interface labelが同じでも再初期化後の値が同じとは限らない。physical port、ifName、IfIndex、OSPF Interface ID、link-local address、neighbor Router IDをbefore/afterで保存する。

RFCが再起動側に保存責任を置くのは、neighbors間で変化を同期するよりrobust、deterministic、simpleだからである。小さな共通仕様が将来の実装判断を局所化している。

forwarding continuityは別の証拠

planned restartでは事前にFIBがcurrentで保持可能と確かめる。unplanned crashにはその準備がない。いずれもFULL広告だけでpacket deliveryを証明できない。

FIB fingerprint、next-hop reachability、interface counter、active probe、loss、pathを保存する。保持tableが古いnext hopを向いている場合、完全に保存されたこと自体が正しさを改善しない。

本篇の中心は一般的な「保存状態は真実ではない」ではない。OSPFv3固有の二つのsemantic mapと、helper受理という分散判断が、保存状態を同じobjectへ結び付ける条件である。

replayはfreshnessを問い直す

古いLink-Update内のgrace-LSAをreplayすれば、停止したrouterをrestart中に見せられる可能性がある。RFC 5187は、Hello replayの方がadjacencyを維持しやすいと説明し、新しいsecurity categoryとはしていない。

正確な運用判断は、リスクを誇張も消去もしない。authentication、sequence、age、anti-replayと実際のneighbor/forwarding observationを別々に残す。

受理を推測しないreceipt

change ID、planned/unplanned、buildとprocessor、Router ID、grace-LSA、reason、period、全helperのpolicy/decision/exit、FIB、packet、LSA-ID/prefix map、port/IfIndex/Interface-ID map、adjacency、LSDB/RIB/FIB、topology change、security、fallback、rollbackを保存する。

Heng Luのreality layersで考えると、送信済みmessageはsymbolic action、helper acceptanceは別主体のdecision、FIBはrunning code、packetはoutcomeである。Grace-LSAを受理へ昇格させないことが、分散制御のclarityを守る。

情報源

  1. RFC 5187 HTML
  2. RFC 5187 text
  3. RFC Editor情報
  4. IETF Datatracker
  5. 履歴
  6. 参照
  7. RFC 5187 errata
  8. RFC 3623 Graceful OSPF Restart
  9. RFC 3623情報
  10. RFC 5340 OSPFv3
  11. RFC 5340情報
  12. RFC 2740 初期OSPFv3
  13. RFC 2863 Interfaces Group MIB
  14. RFC 1213 MIB-II
  15. RFC 4552 OSPFv3認証
  16. RFC 7166 Authentication Trailer
  17. IANA OSPFv3 Parameters
  18. Heng Lu：現実の層
  19. Heng Lu：最小仕様と自発的採用
  20. Heng Lu：稼働コードの優先