要約

  • RFC 3277は、再起動したIS-ISルーターがlocal prefixを広告し続けながら、BGP回復中はOverload bitでトランジット計算から外れる運用を示す。空のLSPではiBGPに必要なloopbackまで失われる。
  • さらに、新しい隣接広告が以前のプロセス世代のLSPを再び使える状態にする競合がある。現在のself-LSP、BGP経路集合、FIB、パケット到達は別々に確認しなければならない。

RtrBが停止すると、RtrAは外部宛てのトラフィックをRtrCへ切り替える。RtrCは動き続けていたため、BGPで学んだD.1への到達性もFIBに持っている。RtrBが戻ると、IS-IS隣接とデータベース同期は数秒で進み、低コストのRtrB経由が再び選ばれる。しかしBGPセッションと外部経路の回復はまだ終わっていない。RtrAから届いたパケットをRtrBは捨てる。

2002年4月のInformational RFCであるRFC 3277は、この決定的なblackholeを既存のLSP Overload bitで緩和する。復旧中のRtrBは、自身へ到達するための情報を出しつつ、他のノード間のトランジット経路には使われないようにする。BGP同期、または実装が選んだ別の条件を満たした後、Overloadを消したLSPを出す。

ここで「自身へ到達する情報を出す」ことが重要になる。

loopbackを消すと、BGPを戻す道まで消える

サービスプロバイダー網のiBGPは、物理インターフェースではなくloopbackアドレスをpeer endpointに使うことが多い。ルーターのLSPを空にして完全に隠すと、他のルーターはそのloopbackへ到達できない。安全になるどころか、BGPセッションを再構築する前提を失う。

必要なのは二値のdown/upではない。自分自身は到達可能だが、まだ他者のトラフィックを中継しない状態である。Overload bitは、この限定された権限をドメインへ伝える。

bitが立っていることは障害原因の証明ではない。BGPが何件足りないか、FIBが保持されたか、ハードウェアが正常かを説明しない。「今はこのノードをトランジット計算に使わない」という狭い意味を持つ。

bitを消すことも同様に狭い。次のSPFで中継候補に戻すだけで、必要な経路がすべて存在することや、実際に転送できることを保証しない。

RFC 3137のOSPF Stub Router Advertisementにも、自身の到達性とトランジットを分ける発想がある。既存のBTW記事はMaxLinkMetric、選好とwithdrawalの違い、唯一経路時の挙動を扱っている。本稿の中心はそこではない。IS-ISで新しい隣接が古いself-LSPを作動させる世代競合と、loopbackを残したまま中継権限だけを止める必要である。

新しい隣接が古い自己記録を呼び戻す

RtrBが消えても、以前に生成したLSPは他ノードのデータベースに残り得る。RtrBが再起動し、RtrAやRtrDとの隣接を形成すると、両隣は新しいLSPを生成してその関係を広告する。RtrB自身はまだ同期中で、Overloadを設定した新LSPを出していないかもしれない。

他のノードは、新しい辺と古いノード記録を組み合わせてSPFを実行できる。隣接は現実に存在し、古いLSPも正規の送信元から出たものだった。それでも両者は同じプロセス世代の状態ではない。

RFC 3277は、各隣接が確立した時点でRtrBが直ちに自己LSPを更新し、データベース同期より前に洪水させるよう勧める。新しい隣接広告が旧LSPを利用可能にする前に、Overloadを含む現在の自己記録を行き渡らせるためだ。

これは単なる鮮度の問題ではない。広告順序が権限を作る。隣のLSPは「辺がある」と述べ、RtrBのLSPは「その辺を通過計算に使ってよいか」を制約する。前者だけが先に効くと、過去の状態が現在の隣接に乗って権限を取り戻す。

監査には、boot世代、self-LSPの起源とsequence、隣接確立順、洪水受領、SPFが使ったデータベース世代、選択経路を保存する必要がある。古いオブジェクトを今読んだという時刻は、そのオブジェクトを現在のものにしない。

N秒とN経路は準備完了の近似にすぎない

RFC 3277は、Overloadを設定・解除するtriggerを実装者に委ねる。例として起動後N秒、またはBGP Loc-RIBにN prefixが入った時点を挙げる。

タイマーが証明するのは経過時間である。遅いpeer、欠けたaddress family、誤ったpolicy、未解決next hopは見えない。テーブル規模や制御面負荷が変われば、以前十分だった待ち時間が短すぎることもある。

prefix数はBGPに近いが、集合の同一性を示さない。再起動前後で件数が同じでも、default routeや重要なinfrastructure prefixが欠け、別の経路が数を埋めているかもしれない。Loc-RIBの存在はFIBへの書き込みを意味せず、FIBの行はパケット到達を意味しない。

これらのtriggerを捨てる必要はない。権限を限定すればよい。どのpeerとAFI/SAFIを期待するか、必須経路は何か、集合digestやversionを比較するか、next hopとFIBをどう確認するか、どのprobeが失敗したらOverloadを戻すかを決める。

標準が全ネットワークに同じ条件を課さないのは妥当である。だからこそ、ローカルな選択を「RFC準拠だから安全」と置き換えてはならない。

代替経路がない場合の保守性

RFC 3277のOverload動作では、そのルーターを経由するトランジット経路を計算しない。RtrBしか下流へ行く道がなければ、bitを立てることで唯一の経路がなくなる。冗長構成でblackholeを防ぐ動作が、非冗長構成では到達不能を作る。

代替経路がトポロジーに見えるだけでも足りない。必要な容量、独立した障害領域、現在のpolicy、完全なFIBを持つか確認する。RFCのRtrCは長く稼働し完全な転送情報を持つと仮定されるが、実ネットワークでは測定対象である。

ドメイン内でOverloadの解釈が不統一ならloopが起こり得るという警告もある。認証されたLSPは発信元を確認できても、すべての実装が同じ計算結果をハードウェアへ入れることは証明しない。

したがって復旧方針は、戻るルーターの準備度と、待っている間の周囲の耐久性を同時に扱わなければならない。

RFC 8706は辺の広告を待たせる

RFC 5306は2008年にIS-IS restart signalingを標準化し、2020年のRFC 8706が置き換えた。後者は、forwarding stateを保ったrestartと、保持しなかったstartを区別する。

startでは、前の世代のLSPがネットワークに残り、新プロセスでsequence numberが初期化されたために、新しい最初のLSPより「新しく」見える場合がある。過去の記録と現在の隣接が組み合わさる問題が、より明示的になる。

Restart TLVのSA bitを使うと、starting routerは隣に自分との隣接広告を抑制するよう求められる。SAがclearされたIIHを受けるまで、隣は自分のLSPにその隣接を載せず、ローカルSPFにも使わない。

RFC 3277は、現在のOverload LSPを急いで洪水させて競争に勝つ。RFC 8706は、古いLSPを活性化する新しい辺を先に止められる。どちらも、単なるUP判定では世代整合性を作れないことを示す。

計画restartの信号は、実際にforwardingを保持している場合に限って意味を持つ。保持していないのに使えば大きな損失につながるため、RFC 8706は認めない。制御メッセージは失ったFIBを作り直さない。

もちろん、RFCの存在は全装置の対応、設定、混在時の安全性を証明しない。実装とrunning stateの確認が必要だ。

復旧機能ごとに証拠を分ける

BGP Graceful Restartは制御面復旧中に一部forwardingを保持できる。IP Fast Rerouteは局所故障後にrepair pathへ切り替えられる。Ordered FIB convergenceは変更の適用順を整える。

それぞれ有用だが、他の証明を引き継がない。BGPのstale routeは現在のIS-IS LSP世代を示さない。repair pathは戻ったノードの外部経路集合を完成させない。正しい順序でも、届かなかった経路はインストールできない。

Restart TLV、Overload、SPF結果、BGP集合、RIB、FIB readback、packet probeを別々に残し、関係づけるべきである。一つのgreen statusへ圧縮すると、どこで権限が途切れたか分からなくなる。

Heng Luの資料が示す薄い共通層は、ここでは「トランジットに使うな」という限定的な相互運用意味に対応する。BGPの完全性やservice outcomeまでbitに背負わせない。running codeを重視するとは、最後の表だけを見ることではなく、その表を作った世代、policy、実行、観測を結ぶことだ。

必要な鎖は、process incarnation、forwarding保持、隣接、current self-LSP、洪水、Overload解釈、IS-IS同期、必要BGP集合、next-hop解決、FIB、限定的なtransit admission、packet observation、service result、rollbackである。

不確実性

本稿はprotocol textの分析であり、特定の障害、vendor、現在の導入率を示さない。RFC 3277は複数の大規模IS-IS網で使われたと述べるが、名称や測定を示していない。RFC 8706の対応、混在実装、trigger、FIB programming、代替容量は各環境で検証が必要であり、損失量や改善率は主張しない。

出典