要約

  • RFC 9612はMPLS LSP echoにBFD Reverse Path TLVを追加し、入口側からBFD Controlパケットの復路FECを指定できるようにする。要求は明確になるが、往復の失敗が自動的に片方向の故障になるわけではない。
  • 指定復路が見つからないことを示す戻りコード193と、別のIP経路で生きているBFDセッションは同時に成立する。拒否、実経路、サービス結果は別々の証拠である。
  • 運用記録には往路LSP、要求した復路FEC、TLV応答、実際の復路、BFD結果、Reply Path検証、再指定、通知、アプリケーション到達性が必要になる。

最初に届いたのはBFD Downだった。数ミリ秒単位で異常を検出したという意味では、仕組みは期待通りに働いた。しかし、その時点で障害の説明まで完成したわけではない。制御パケットは往路を通り、どこかの復路を戻る。返らなかったという一つの観測だけでは、どちら側が壊れたかを決められない。

運用画面に往路LSPの名前が表示されていると、警報名もそのLSPの障害になりやすい。だが復路FECの解決先が変更された可能性がある。出口装置が指定経路を見つけられなかった可能性もある。ローカル方針に従ってIP経路へ切り替わり、セッションだけが残っている場合もある。画面上の主語は因果関係の証拠ではない。

RFC 9612はExperimentalとして公開された。MPLS LSP echo要求にBFD Reverse Path TLVを入れ、入口側が出口側に対して、周期的なBFD Controlパケットをどの逆方向LSPまたはFECで送り返すかを要求する。復路の意図を、双方が同じ形式で読めるようにする拡張だ。

ここで標準化されるのは最小限の共通部分である。要求、取り消し、変更、正確なエラーは共有する。フォールバックを許すかどうかは出口側のローカル判断に残る。そして実際にどの経路を通ったかは、稼働中の転送状態とパケットで確かめる。この境界を越えて、RFC番号だけで運用結果を保証することはできない。

高速検出が知っている範囲

RFC 5880のBFDは、隣接するシステムや経路の継続性を素早く検出する。RFC 5884のMPLS LSP利用では、往路をLSP、復路を通常のIPルーティングにする構成があり得る。往復が成立することは分かっても、往路だけの正常性は証明できない。

RFC 9612のTLVはType 16384である。中には適切な非マルチキャストTarget FEC StackサブTLVを入れる。マルチキャストFECは対象外で、戻りコード192を返す。既定の最大数は128で、巨大な要求により検索や状態処理を膨らませる攻撃を制限する。

復路を指定すれば、実験条件は改善する。入口側が何を求め、出口側が何を受け入れたかを記録できるからだ。それでもBFDのDownは往復全体の結果である。指定されたFECが変わったのか、往路が落ちたのか、出口側が要求を拒否したのかは、次の確認がなければ分からない。

したがって、警報を自動的に「往路障害」とするのは危険だ。復旧担当を誤った装置へ向かわせ、正常なLSPを切り替え、履歴に誤った原因を残す。正確な初期状態は「BFD往復が成立しない。方向は未確認」である。未知を明示することは弱さではなく、観測を越えた断定を防ぐ制御だ。

193とUpは矛盾しない

出口側が要求された逆方向経路を見つけられない場合、戻りコード193を返さなければならない。193が示すのは、その指定経路が見つからなかったという事実だけである。BFD全体が不可能だとは述べていない。

ローカル設定が許せば、出口側は別の経路、一般にはIPルーティングを使ってBFD Controlを送ることができる。そのため、管理画面に193とBFD Upが並ぶことがある。前者は要求不成立、後者は代替の往復成立を示す。片方を消して一つの状態にまとめると、設計通りの経路と単なる可用性を混同する。

サービスへの影響も別である。フォールバックが制御通信を維持しても、物理的な経路分離という設計条件は失われているかもしれない。反対にBFDがDownでも、アプリケーションは別系統へ切り替わっているかもしれない。要求の成否、実経路、BFD状態、利用者の結果を別の欄で持つ必要がある。

空のReverse Path TLVには取り消しの意味がある。以前の指定を解除し、RFC 5884に沿うIP復路など、出口側のローカル方針へ戻す。また、指定後にBFD Discriminator TLVだけを含みReverse Path TLVを含まないLSP pingを受けると、出口側はローカル方針による周期送信へ戻る。省略は記録すべき状態遷移である。

説明の時計は検出の時計より遅い

セッションを作った後もFECの解決結果は変わる。制御プレーンの再収束、保守、ポリシー変更により、同じ識別が別の復路を指す可能性がある。RFC 9612が確立後の逆方向経路変更を要求するのはこのためだ。

障害後、入口側はLSP pingのReply Path TLVを使い、逆方向FECが依然として有効かを確認しなければならない。FECが変わっていれば、別のFECへBFDセッションを向け直し、オペレーターへ通知する。確認、再指定、通知はそれぞれ異なる責任を持つ。

BFD Controlの送信間隔は短い。一方、Reply Pathによる制御プレーンとデータプレーンの検証はかなり遅い。この速度差により、まず障害が分かり、後で原因が分かる。設計通りの時間差であり、最初の警報に原因名を付けて埋めてよい理由にはならない。

計画保守なら、変更前に復路を更新して一部の警報を避けられる。それでも予期しない変更や検証間隔の隙間は残る。良い運用は「検出済み、帰属未完了」という中間状態を表示し、Reply Pathの完了までの時間を測る。

共通要求とローカル判断を混ぜない

入口側は相互運用可能なFEC表現で希望を伝える。だが出口側のフォールバック方針を所有するわけではない。出口側は代替IP経路を許可するか、何個のサブTLVを処理するか、どれだけの資源を使うかを決める。このローカル性が、異なるネットワークの採用を可能にする。

ただし判断は可視でなければならない。静かなフォールバックは、入口側に指定復路が守られているという誤解を与える。ローカル裁量は必要だが、要求経路、応答、実際の選択を運用データに別々に出すことが条件になる。

128という既定上限は、共通仕様が防御の最低線を示す例である。実装はさらに厳しい上限を選べる。マルチキャストFECを192で拒否することも、曖昧な失敗より優れている。相手が何を拒み、何をローカルに選んだかが明確になるからだ。

Experimentalという分類も過大評価してはならない。これは標準化上の位置と学習目的を示す。特定製品の実装、現用網への導入、Standards Trackの成熟度を証明しない。そこは製品試験、設定記録、実パケットで確認する領域だ。

経路の証拠を連鎖させる

障害前から往路LSP、要求した復路FEC、送信TLV、出口側の応答、実際に観測した復路を保存する。BFDの状態と時刻はその上に追加するもので、前の項目を置き換えない。

障害後はReply Pathの結果、現在のFEC解決、代替FEC、再指定の時刻、オペレーター通知を追加する。最後にアプリケーション境界で到達、損失、遅延を測る。制御パケットが戻ったことは、利用者のデータが届いた証明ではない。

試験では成功以外も実行する。有効な復路を指定してパケットを確認し、確立後にFECを変更する。存在しない復路を要求し、フォールバック許可時と禁止時の193を比較する。マルチキャストFECで192を得る。空TLVで取り消し、判別子だけでローカル方針へ戻し、上限超過が有限の拒否になることも確かめる。

管理API、制御プレーン、転送表、パケット捕捉を突き合わせる必要がある。ソフトウェアは新経路を選んだと表示しながら、ハードウェアが旧経路を使う場合がある。IPフォールバックが動作しても管理モデルに現れない場合もある。複数の現実層が一致して初めて、経路の同一性が証明される。

有用な事後報告は赤か緑だけではない。「指定した逆方向FECが消え、193が返り、IPフォールバックでBFDは継続し、サービス配送は維持された。Reply Pathで代替FECを確認し、再指定と通知を完了した」と書ける。それぞれが独立して検証可能な受領書になる。

情報源