要約

  • 多地点 BFD では、受信側の障害検出と送信側の把握は同じ機能ではない。RFC 9780 は能動的な通知を具体化するが、戻り経路の依存関係まで消してくれるわけではない。
  • 通知への確認応答、通知の停止、利用者のサービス復旧を別々に記録しなければ、正しく動く装置が誤った復旧判断につながる。

障害を最初に見つけた拠点と、対応を決める拠点が異なる。大規模な配信ネットワークでは珍しくない構図だ。現場の装置は受信が途絶えたことを把握しているのに、中央の担当者は正常時と変わらない画面を見ているかもしれない。このとき必要なのは、検出をさらに速くすることとは限らない。知っている側から判断する側へ、何が引き継がれているのかを確かめることだ。

たとえば、一つの入口から複数の出口へ流すサービスを考える。ある出口で連続性の監視が途絶える。出口の装置は規定どおり障害を検出した。それでも入口に通知が届かなければ、中央の判断は始まらない。これは説明のための仮定であり、特定の事業者で起きた事故を示すものではない。

RFC 8562 の多地点 BFD は、受信側が障害を検出しても送信元には通知しない構成を認めている。全受信点から常時応答を返す負担を避けるための、有用な設計である。BFD という名称だけから、送信元が全受信点の状態を把握していると考えるのは適切ではない。

通知しない設計にも責任の置き場所がある

中央で把握しないことは、何もしないことを意味しない。受信側に保護動作を任せる運用もあり得る。RFC 9026 は、マルチキャスト VPN で下流側がトンネル状態を上流選択に用いる方法を扱う。ただし、状態を知る方法だけでは完全な高速切替の仕組みにならないことも明記している。

ここから得られる運用上の示唆は、中央集約か分散かを一律に決めることではない。受信側にどの動作を任せ、どの条件で中央へ引き継ぎ、切替後のサービスを誰が確認するかを定めることだ。装置の機能一覧より先に、意思決定の配置を記述する必要がある。

RFC 9780 は、P2MP MPLS と関連する SR-MPLS の多地点 BFD において、能動的な受信端が障害を知らせる手順を具体化した。2025 年 5 月の規格であり、今回新たに公表された実装結果ではない。通知を採用するなら、送信側と受信側の設定を含めて確認しなければならない。「監視対象に入っている」と「中央へ通知する」は同じ条件ではない。

戻り道が失われると何が分からなくなるか

RFC 8563 は、マルチキャストの配信経路、送信元から受信端へのユニキャスト経路、受信端から送信元へのユニキャスト経路を分けて検討している。ポーリングを行わない通知では、配信経路と逆方向の経路が同時に失われると、受信端が障害を検出しても送信元はその事実を知らないままになり得る。

ポーリングを増やせば観測は増える。しかし応答がないという結果には、観測のための経路が失われた可能性も残る。受信端ごとの状態を保持する費用を払っても、あらゆる不明状態が一意の障害箇所へ変わるわけではない。RFC 9780 の通知手順を、RFC 8563 にあるすべてのポーリング方式の実装証明として扱ってはならない。

調達時に問うべきなのは、戻り経路が図上に存在するかだけではない。配信と同じ電源、拠点、処理資源に依存していないか。依存するなら、その共通障害時には誰が別の観測を持つのか。論理的に分離した線を描くことと、障害領域を分離することは違う。これらは現地の構成資料と承認された試験で確かめる事項であり、規格本文から個別ネットワークの答えを推測することはできない。

確認応答で復旧を宣言しない

RFC 9780 では、障害を検出した受信端が会話の対象を識別できる情報とともに通知を送る。BFD の基本仕様 に基づく状態や診断情報は、調査を始めるために役立つ。一方、それだけで物理的な原因が一つに特定されるわけでも、全利用者の影響が確定するわけでもない。

とりわけ重要なのが反復通知の停止条件だ。有効な当該セッションの制御パケットで Final ビットを受け取るか、欠陥が解消すれば、規定の周期通知は止まる。前者は通知交換への応答であり、後者と同じ意味ではない。

仮に中央が通知を直ちに確認し、サービスの復旧には時間を要するとする。通知件数は先に落ち着く。運用画面がこの変化を復旧と解釈すれば、正しい確認処理が誤った業務判断を促す。通知が止まった理由を保存することは、装置の内部状態を過剰に集めることではなく、終了判断の根拠を残すことだ。

反対に、中央が通知を受けても確認が戻らなければ、受信端は報告を続け得る。重複通知の増加をそのまま新規被害の増加と数えるのも誤りである。重複をまとめる処理には、最初の検出時刻、対象セッション、確認の状態を保持する役割がある。サービス障害まで一緒に消してよいわけではない。

集中障害で初めて見える調達費用

木構造の根元付近で故障すれば、多くの受信端が同時に通知する可能性がある。RFC 9780 は反復通知の送信時刻をずらし、送信元の制御処理へ渡す通知に制限を設けることを考慮している。通知は監視対象のマルチキャスト流へ割り当てた資源を使わなくても、他の流れや制御処理には負荷を与え得る。

RFC 4687 は、規模拡大への対策が監視の運用価値や応答性を壊さないことも要求している。ここには、受入試験の評価軸が二つある。装置を守れたか。そして、判断に必要な情報を残せたか。CPU が安定したという一つの数字では、後者を評価できない。

試験では受信端集合と設定を固定し、限定した障害に対して、最初の検出、送信元での受理、制限による破棄、確認応答、保護動作、サービス確認までを追うとよい。これは本稿の提案であって、RFC が示した実測値ではない。処理能力の具体的な数値や適切な上限は、装置、構成、他サービスとの関係によって検証する必要がある。

速い検出以前に、観測対象の対応関係も確かめたい。P2MP LSP Ping と MPLS データプレーン検証 は、意図した転送対象との整合を調べる文脈を与える。古い木構造に結び付いたセッションから速く届く結果は、現在のサービスを正しく表すとは限らない。

正式な公開記録 が裏付けるのは規格の存在と位置付けであり、普及率やベンダー性能ではない。Lu Heng の実行可能な力と象徴的な力を分ける議論 を本稿の視点として借りれば、監視機能という説明を、判断できる経路と担当者へ落とし込む作業が残っている。規格はその作業を明確にするが、代行はしない。