要約

  • RFC 9978 は通常の BFD Up/Down 状態では現れない、セッションごとの制御パケット欠落を Experimental として数える。
  • この数値は限定した調査を始める根拠にはなるが、データ損失、FIB 不良、LAG メンバー障害、または安全な自動切替を単独で証明しない。

カウンターは議論を終わらせるように見える。セッションは Up、lost-packet-count は上昇、そこで「受信列に不連続がある」という観測はすぐに「リンクが壊れている」という断定へ変わりやすい。細かい数値であることと、広い因果関係を知っていることは別である。

RFC 9978 は 2026 年 6 月に Experimental Protocol として公開された。対象はBFD 制御パケットである。基礎 BFD は Detection Time 内に一つの制御パケットを受ければ Up を維持できる。RFC 9978 は同じ時間内に落ちた他の制御パケットを可視化する。一方で、リンクやトンネル上のデータトラフィック損失または遅延を測る拡張ではないと明記する。

つまり、この値が目撃するのは特定受信側の制御ストリームであって、サービスの結末ではない。

数えられるものと数えられないもの

安定性測定には meticulous な BFD 認証タイプが必要で、新しい制御パケットごとにシーケンス番号が一つ進む。stability を有効にすると ietf-bfd-stability の YANG 拡張が lost-packet-count を公開する。受信側は有効な連続パケットの番号を比べ、不連続を数えられる。最初に受け入れた非ゼロ番号は観測を始めるためだけのもので、過去を復元しない。

ここで確立する事実は狭い。このセッション、この設定世代、この受信側で、制御列に間隔が見えたという事実である。Down の前に悪化を示唆できるが、原因を名指ししない。

LAG や ECMP はパケットを失わずに順序だけを変えることがある。RFC 9978 は厳密な連続比較が乱順を損失として数え得ると警告し、予想されたパケットが順不同で届いた場合を扱う実装を許す。配送文脈がなければ、増えた数値は物理メンバー、キュー、遠隔プロセス、顧客経路のどれが悪いかを示さない。

また、これはアプリケーション流量を測らない。BFD 制御パケットと顧客フローでは、カプセル化、QoS、ハッシュ、フィルター、障害ドメインが異なり得る。カウンター上昇中にサービスが健全であることも、BFD がきれいなままサービスが失敗することもある。矛盾ではなく、層の違いである。

NULL を認証と呼ばない

RFC 9978 は、認証しないセッションにもシーケンスを運ばせるため、BFD auth type 6 の NULL を登録した。これは望まれる認証性を一切持たない。注入されたパケットはセッションをリセットせず高い損失に見え得るし、未認証 BFD のリセット脆弱性も残る。

したがって、カウンターには完全性条件を添える必要がある。限定された信頼面では明示的な診断トリガーとして使える。マルチホップ、トンネル、注入が意味を持つ面で自動迂回の命令にするなら、測定が与えていない結論を足すことになる。RFC 9986 の meticulous は各送信ごとの番号増分を意味するだけで、サービスの真正性や原因帰属を生まない。

カウンターを調査開始にする

セッション ID、相手、パス種別、認証方式、リセット文脈、設定版、受信者、時刻を保存する。まず乱順で説明できるかを調べ、BFD client 状態と制御面イベントを比較する。その後にだけ、確認したいリスクと同じ面を測る。RFC 6374 の MPLS 損失・遅延測定は別のデータ面測定であり、ここで損失があった証明ではない。しかし BFD 数値がその結論を借りられないことを明確にする。

保護または経路変更の前には、ローカル RIB/FIB、実際の転送範囲、LAG/ECMP の証拠、サービス canary を結ぶ。「BFD 安定性異常を観測」は正確なアラートである。「顧客に影響」「自動切替は安全」は別の証拠を要する。