要約

  • revision 19 は両 peer の capability 74 を条件に strict mode を negotiated とし、ローカル BFD Up まで BGP の進行を保留する。
  • remote 側が先に BFD Up となって KEEPALIVE を送る race を、OpenSentConfirmedBfdUpPending が明示的に保持する。
  • 「BFD Up」や「KEEPALIVE received」を単独の成功証跡にせず、両端の順序、pending state、timer と最終 route outcome を結び付ける必要がある。

Router B の BFD は Up になった。B の BGP は条件を満たし、KEEPALIVE を送った。Router A はその KEEPALIVE を受け取ったが、A 自身の BFD はまだ Down だった。A が通常の OpenSent と同じ規則で処理すれば、予期しない KEEPALIVE を FSM error として TCP を切る可能性がある。

どの packet も単独では間違っていない。順序だけが、二つの automaton の間で非対称だった。

draft-ietf-idr-bgp-bfd-strict-mode-19 は、この順序を仕様上の状態として扱う。文書は 2026 年 8 月 26 日付の active IDR Working Group Internet-Draft であり、RFC 4271 を update する Standards Track 文書を目指すが、現時点で RFC ではない。Datatracker はまだ I-D Exists を示し、early review は運用・security・FSM の検討を続けている。

strict mode は BGP と BFD を一つにしない

通常の BFD/BGP 連携では、BGP session が先に Established となり、その後 BFD failure が session を落とす場合がある。strict mode の目的は順序を変え、BFD が利用可能で安定する前に BGP が route を交換する事態を避けることにある。

両 speaker が OPEN に capability 74 を含めると、BfdStrictNegotiated が true になる。BGP FSM は KEEPALIVE の送信と OpenConfirm/Established への遷移をローカル BFD Up まで待つ。ここで重要なのは「ローカル」である。capability は両側の採用を示すが、BFD の event が同時に届くことまでは保証しない。

BFD packet の scheduling、forwarding path、control-plane load、authentication、detection interval は両端で異なり得る。従って一方が Up を観測した時刻と、他方が Up を観測する時刻の間には正当な差がある。仕様はその差を error として消すのではなく、状態として保持しなければならない。

一枚の pending state が race の証人になる

revision 18 に対する BGP Directorate review は、OpenSent で BFD を待っている間に remote KEEPALIVE が到着する問題を指摘した。remote BFD が先に Up なら、remote BGP が進むのは自然である。一方、local FSM がまだ従来の OpenSent 処理だけを使えば、その KEEPALIVE は許されない event になり得る。

revision 19 の OpenSentConfirmedBfdUpPending は、その矛盾を分解する。remote KEEPALIVE は受け取った。local BFD 条件はまだ満たしていない。次の local BfdUp では OpenConfirm ではなく Established へ進むべきである。この substate は成功でも失敗でもなく、次の正しい遷移に必要な memory である。

ConnectDelayOpenBfdUpPending、ActiveDelayOpenBfdUpPending、OpenSentBfdUpPending も同じ役割を持つ。どの経路で待ち状態に入ったかを残す。運用画面がそれらをすべて BGP Connect に丸めると、仕様が保存した causality を UI が捨てる。

state 名が長いことは欠点ではない。説明できない短い status より、次に待つ event を示す長い status の方が運用価値は高い。

timer は race を timeout に変換する

非対称が永遠に続かないよう、文書は BGP holdtime と BFD 側の待ち時間を関係付ける。BGP holdtime がゼロの場合には BfdHoldTimer を使い、BfdHoldTime の default は 30 秒である。BFD hold-down を使う場合は、BFD が Up のまま一定時間続いてから BGP を Established に進める。

しかし hold-down は peer 間で値を negotiation しない。文書は似た値を推奨する。片側の hold-down が長く、他側の BGP holdtime が短いと、早く Established になった側が KEEPALIVE を待ち切れず session を閉じる。片側では Hold Timer Expired、他側では BFD stability 待ちと記録される。

Juniper の現行文書は、peer の設定が一致しないと indefinite Idle になり得る事例を記録している。Cisco の現行文書は negotiated mode と unilateral/override の違いを明示する。これらは vendor の優劣を示す資料ではない。race を理解するには command 名の外側にある起動条件を見る必要があることを示す。

BFD Down は原因分類の入口にすぎない

strict mode で BFD が Down になると、Established 前なら Cease / BFD Down を送り、TCP を閉じ、resource を解放して Idle に戻る。Established 後なら、その connection で学習した route も削除する。RFC 9384 の subcode は、BFD interaction が closure を動かしたと operator に知らせる。

だが、BFD Down の背後には複数の mechanism がある。forwarding path が本当に切れた、authentication が一致しない、packet suppression が起きた、control-plane congestion が detection を遅らせた、peer が異なる strict semantics を使った、という場合を subcode 一つでは区別できない。

Security review は、capability stripping による downgrade、optional で legacy algorithm に依存する BFD authentication、on-path packet suppression、そして繰り返し BGP を落とす availability attack を挙げる。GTSM や authentication が守る範囲と、packet delivery を保証できない範囲を分けなければならない。

試験は順序を変える

interoperability test は正常系一回では足りない。A の BFD を遅らせ、B を先に Up にする。remote KEEPALIVE を local BFD Up より先に届ける。hold-down を非対称にする。BGP holdtime を境界まで短くする。capability 74 を片側だけにする。Established 後に configuration を変える。BFD packet だけを drop する。

各 sequence で、両端の OPEN、capability、BFD state、BGP substate、timer、notification、route deletion と traffic を一つの timeline に置く。test の合格条件は「最後に上がった」ではなく、「途中の非対称を両端が同じ意味で扱い、失敗時に同じ mechanism を説明できる」である。

rollback は session 単位で設計する。local strict mode を無効化しても remote override が残れば gate は消えない。Established 中の変更が次回 restart まで有効にならない場合もある。望ましい configuration と現在有効な semantics を別々に確認する。

Running-Code Primacy はこのような race で具体性を持つ。紙上の state diagram だけでも、単独装置の successful demo だけでも足りない。二つの implementation が同じ event sequence を互換に処理するところで初めて、共通仕様が running network の事実になる。

BFD が Up になったことは重要な receipt である。相手が Established であること、route が install されたこと、traffic が届いたことは別の receipt だ。その間を pending state がつないでいる。見えないようにするべき中間状態ではなく、最も失われてはならない証拠である。

出典