要約

  • RFC 5286 の LFA は、機能を有効にしただけでは生まれない。候補隣接は、特定の宛先と想定障害について厳密な距離条件を満たしたときだけ無ループ代替になる。
  • 障害手順書には有効化状態ではなく、未保護宛先、計算時のトポロジー、式の各項、保護種別、選択・FIB 実装・発動の証拠が必要である。

手順書の一行目が遅すぎた

障害時の手順書に「対象ルートの LFA を確認する」と書かれているなら、確認の時点が遅い。答えは平常時に作れる。むしろ障害中に初めて調べると、現在のトポロジーと故障直前のトポロジーを混同しやすい。

計算ルーターを S、候補隣接を N、宛先を D とする。RFC 5286 の基本条件は次だ。

Distance_opt(N,D) < Distance_opt(N,S) + Distance_opt(S,D)

左辺が 20、右辺が 7 + 13 なら等しい。等号では合格しない。S は、N から D への最短路が自分へ戻らないことを保証できないからだ。式が厳密な小なりであることは細かな表記ではない。ループを避けるための許可境界そのものである。

メトリック変更後に左辺が 19 になれば合格する。同じ隣接でも、別のトポロジー版では別の結論になる。したがって「N は LFA」という出力だけを保存しても監査には足りない。どの LSDB、どの時刻、どの宛先、どの障害想定、どの三つの値から得た結論かを残す必要がある。

装置全体ではなく宛先単位

RFC 5286 は、分散ルーティングが再収束するまでの損失を減らすため、代替ネクストホップを事前計算する。主ネクストホップの障害を検知すると一時的に代替へ送り、新しい SPF がインストールされた後に通常状態へ戻る。代替の計算は通常の主 SPF を書き換えない。

重要なのは、代替が宛先ごとに計算される点だ。同じ N があるプレフィックスには合格し、別のプレフィックスには不合格になり得る。複数ルーターから広告されるプレフィックスでは、起点と広告コストも結果に入る。RFC 8518 は RFC 5286 のマルチホーム部分を更新し、OSPF 外部経路についても ASBR や経路種別を含む選択条件を詳しくした。

このため「LFA カバレッジ 99%」には分母が欠かせない。リンク数なのか、ノード数なのか、プレフィックス数なのか、主ネクストホップなのか、トラフィック量なのか。残り 1% が重要な制御系プレフィックスなら、数字の印象は逆転する。さらにリンク保護とノード保護を同じ分子に入れれば、障害モデルまで消えてしまう。

RFC 6571 はサービスプロバイダのトポロジーで LFA の適用範囲を扱う。RFC 7490 が remote LFA を導入したのは、リングなどで適切な物理隣接が見つからない場合があるからだ。通常 LFA に空欄が生じることは、機能停止ではなくトポロジーから得られる正当な結果である。

「無ループ」だけでは保護対象が分からない

基本式への合格は、モデル化したリンク障害で N がトラフィックを S に返さないという主張である。下流条件はさらに厳しい。

Distance_opt(N,D) < Distance_opt(S,D)

N が S より宛先に近いことを要求するため、想定より広い故障で一部のマイクロループを避けやすい。その代わり候補が減る。より安全な選択規則が、より多くの未保護宛先を生む場合がある。

ノード保護には、候補経路が主隣接 E を避けるという別の証明が必要だ。N が等コスト経路を複数持ち、その一つだけが E を通る場合、S は安全な方を強制できない。したがって「避ける経路もある」を「ノード保護」とは呼べない。

ブロードキャストと NBMA では IGP の疑似ノードも考慮する。候補が主隣接を避けても、同じ障害セグメントを使う可能性がある。ローカル SRLG は同一ポート、ラインカードなどの相関故障を加える。出力が単に LFA=true なら、この区別は失われる。

実際の故障が計算対象より大きい場合も同じだ。リンク保護しかないのに隣接ノード全体が消える、あるいは同時故障が起きると、事前証明の範囲外になる。保護結果には必ず「何の故障を避ける計算だったか」を付けるべきだ。

障害前に用意すべき七つの受領書

実務上の状態遷移は次のように分けられる。

設定済み -> 計算合格 -> 選択済み -> 実装済み -> 発動済み -> 転送確認 -> 収束確認

設定済みは計算を許す。計算合格はトポロジー版と式に結び付く。選択済みはポリシーの結果である。実装済みは FIB やハードウェアの読戻しが必要だ。発動済みは検知イベントとの対応が必要で、転送確認はカウンターやトレースで確かめる。最後に通常 SPF へ戻ったことを確認する。

BFD は検知時刻を与えられるが、候補の資格や実装を証明しない。計算済みでも、資源不足、プログラミング失敗、隠れたポリシーで FIB に入らないことがある。手順書はこれらを一つの「FRR 状態」にまとめてはいけない。

保存項目は、計算ルーター、エリアまたはレベル、LSDB の版・ハッシュ、時刻、宛先、経路種別、全起点、主ネクストホップ、保護資源、候補隣接、三つの距離、追加条件、候補除外理由、保護種別、選択ポリシー、FIB 世代である。RFC 7916 が扱う per-prefix と per-next-hop の粒度も明記する。粗い集約は一つの例外を隠せるからだ。

後発方式を暗黙の救済にしない

remote LFA、TI-LFA、Segment Routing、RSVP-TE FRR は別の仕組みと前提を持つ。通常 LFA が不合格だったからといって、それらが設定済み・計算済み・実装済みだとは言えない。正しい運用表示は「この条件では代替なし」である。

また本稿は、TI-LFA の局所修復とサービス復旧を分けた既存記事を繰り返さない。ここで問うのは発動より前、通常隣接がその宛先の代替として認可された根拠が存在したかどうかである。

RFC 群は特定事業者の実装、製品品質、実測カバレッジ、収束時間、障害結果を証明しない。式に不合格でも欠陥とは限らず、合格しても FIB 実装やパケット転送を証明しない。この限界を明記することが、手順書を宣伝資料から運用証拠へ変える。