要約

  • RFC 9764 は BFD PDU を運ぶトランスポートのペイロードを設定値まで拡大し、追加部分をゼロにする。IPv4 では Don't Fragment を必須とし、そのサイズの制御パケットが最近到達した事実を Up 状態に反映させる。
  • 証拠は送信方向と実際の転送処理に限定される。双方向を述べるなら両端の設定が必要であり、LAG や ECMP では BFD が健全な一メンバーだけを通り、別メンバーの問題を見逃し得る。
  • pdu-size は複数クライアントに効く共有制御である。値を上げると既存の Up セッションが Down になり得るため、実際の MTU 制約、相手の非対応、フィルター、攻撃、メンバー差を分ける前に広い自動処置を行ってはならない。

通常の BFD パケットは小さい。RFC 5880 の状態機械は、この制御交換が一定時間内に続いているかを速く伝える。その情報は経路制御に有用だが、小さな制御が届くことと、大きなアプリケーション・データが届くことは別の命題である。

RFC 9764 はこの隙間に対して、別の大型プロトコルを作らない。Asynchronous mode の BFD をそのまま使い、外側のトランスポート・ペイロードを bfd.PaddedPduSize まで広げる。余分なバイトはゼロでなければならず、受信側はその内容を検査しないことが推奨される。IPv4 では Don't Fragment を立てるため、分割によってテスト条件を満たしたように見せることはできない。

仕組みが小さいからこそ、結論も小さく保つ必要がある。

Up は最大値ではなく、設定した床を示す

例えば 1,512 バイトを設定し、セッションが Up を維持したとする。そこから言えるのは、その BFD 制御フローが観測時点に 1,512 バイトで届いたということだ。Path MTU が正確に 1,512 だとは分からない。もっと大きい可能性がある。経路の容量が後から増えても、セッションはその増加を発見せず Up のままである。

RFC 1191 は、特定の経路に結び付いた Path MTU の推定を、限定された ICMP 証拠に応じて送信側が下げる仕組みを定めた。RFC 8899 はデータグラム転送向けの packetization-layer 探索を定める。RFC 9764 は最大サイズ探索ではない。依存アプリケーションが選んだ最低条件を繰り返し確かめる。

したがってローカル・インターフェースが 9,000 バイトだからといって、その値を機械的にコピーしてはいけない。ローカル容量、経路上の観測、業務が必要とするサイズは三つの異なる事実である。必要以上に大きな値は可用性を下げ、必要より小さな値は緑のまま要求を満たさない。

双方向という名前は、逆方向の測定を代行しない

RFC 9764 は、あるサイズを両方向で検証したい場合、BFD セッションの両側で設定しなければならないと述べる。A から B へ届いた大きな制御パケットは、B から A への同じサイズの到達を証明しない。

往路と復路は別のルーター、トンネル、キュー、フィルターを通り得る。MTU が意図的に非対称な回線もある。正しい記録は、一つの Up 表示ではなく、各方向の送信値、運用値、最終成功時刻、設定世代を残す。

RFC 5881 の single-hop BFD では、直結リンクの MTU 設定が強い手掛かりになる。RFC 5883 の multihop では、最初のインターフェースの容量は先の経路を説明しない。大パケット BFD の価値は増すが、同時に「経路」という言葉の範囲を明示する責任も増える。

最大の要求が共有セッションの意味を変える

同じエンドポイント間の BFD を複数のクライアントが利用できる。一つが 1,400 バイト、別の一つが 1,600 バイトを要求するなら、RFC 9764 は最大値を選ぶことを推奨する。小さい方を使えば、Up でも大きな要求を満たしていないからだ。

しかし最大値を持ち込んだクライアントは、他のクライアントの可用性条件も変える。遠端が通常の BFD は受信できても 1,600 バイトの外側ペイロードを処理できなければ、共有セッションは Down になる。小さいサイズしか必要としないルーティング・クライアントまで反応する可能性がある。

変更記録には要求者、共有クライアント、旧値、新値、両端の能力、Down が起こす動作、戻し方が必要である。最終値だけでは、局所要求がどのように広い制御へ変換されたかを追跡できない。

非対応と狭い経路は同じ沈黙を作る

RFC 9764 は BFD PDU 自体を変えない。それでも古い実装が大きなトランスポート・ペイロードを受け付けなかったり、長さ検査で誤って破棄したりすることがある。状態機械から見れば、物理的な MTU 制約も受信実装の拒否も「制御を受け取らなかった」という同じ事象になる。

中間フィルターや、BFD を選択的に落とせるオンパス攻撃者も Down を作れる。ゼロ・パディングは未初期化メモリーの漏えいを防ぐが、障害原因を認証するものではない。

観測、診断、決定を混ぜてはならない。「このサイズの BFD がセッションを維持しなかった」は観測である。「Path MTU が不足した」は診断仮説である。「経路を全撤回する」は権限を伴う決定である。二端のパケット記録、受信カウンター、小さい値との比較、フィルター・ログ、業務 canary が仮説を狭める。

ECMP の外れメンバーは緑の背後に残る

LAG や ECMP は複数メンバーを一つの論理経路として見せる。BFD のフローが健全なメンバーに固定され、顧客フローが小さい MTU の別メンバーへハッシュされることがある。このとき BFD Up と業務失敗は同時に正しい。

RFC 7130 は LAG メンバー向け BFD を扱う。一方 RFC 9764 は、multihop ECMP の全リンクを一般的に試す標準 BFD 機構はないと明記する。内部の forwarding 情報を使って範囲を広げる実装はあり得るが、製品固有の動作であり、標準から自動的には得られない。

したがって「この BFD フローが通った」は正しい。「すべてのエントロピーとメンバーが通る」は未確認である。メンバーごとに MTU が違えば、実効 Path MTU はフロー依存になる。

RFC 9978 に関する既存 BTW 記事は、失われた BFD 制御パケットのカウントをデータ面損失の証明にしてはならないと論じた。本稿は別の境界を扱う。大きな制御が通ることを、すべての大きな業務データの成功へ昇格させてはならない。

YANG の一行は観測対象であり、原因にもなる

ietf-bfd-large は RFC 9314 の BFD YANG モデルを拡張し、RFC 8342 の NMDA に従う。single-hop、multihop、LAG、MPLS の各構造に padding feature と書き込み可能な pdu-size を加える。

datastore に値があることは設定意図の証拠であり、両端で実際に動作した証拠ではない。意図、適用状態、ソフトウェア版、相手能力、要求クライアント、実パケットを一つの時系列に置く必要がある。Up 中の値変更が Down を起こし、複数クライアントへ影響する可能性を RFC 自身が警告している。

RFC 7880 の S-BFD にも本手法を適用できる。しかし適用可能性は、異なるモードの経路、方向、識別子、責任を一つにするものではない。

反復は鮮度を上げるが、未来を所有しない

RFC 9869 は UDP Options の REQ/RES トークンで特定のサイズ・プローブを確認する。その BTW 記事が所有する論点は、一度成功したプローブと将来のデータグラムの分離である。RFC 9764 は BFD の反復によって観測の古さを減らす。

それでも次の業務パケットは別の ECMP メンバー、別のカプセル化、別のキューを使うかもしれない。反復は不確実性を狭めるが、標本を全集合へ変えない。

監査可能な表現には時刻と範囲が入る。「この設定世代、この方向で、X バイトの BFD を最近受信し Up を維持した」。この文は更新も反証もできる。「ネットワークは X バイト対応」は観測主体を消してしまう。

出典と証拠範囲

凍結した資料は RFC 9764、BFD の RFC 5880、RFC 5881、RFC 5883、RFC 7130、RFC 7880、管理モデルの RFC 9314 と RFC 8342、サイズ証拠の RFC 1191、RFC 8899、RFC 9869、隣接する安定性論点の RFC 9978 である。

統治上の読み方には Heng Lu の Minimum Initial Specification、Running-Code Primacy、On Reality Layers を用いた。共通仕様は局所検証できる小さな事実にとどまり、その後の判断は結果を引き受ける運用者に残る。