要約

  • treat-as-withdraw は、異常な UPDATE に含まれる解析可能な全経路を撤回扱いにする。メッセージを修復する機能でも、単に無視する機能でもない。
  • セッションが Established のままでも、対象経路は Adj-RIB-In から消え、到達不能や次善経路が生じ得る。成功判定には経路単位の観測が必要になる。
  • 原 PDU、エラー分類、選択した処置、全 NLRI、RIB、FIB、パケットをつなぎ、送信側の訂正後に古い状態と内部差異が残っていないことまで確認する。

最初に保存すべきもの

調査担当が欲しいのは「BGP エラーがあった」という要約ではない。どのバイト列を、どのピアから、どの方向と AFI/SAFI で受け、どの属性のフラグや長さを異常と判定したかである。この情報が失われると、後から狭い封じ込めが正しかったか検証できない。

説明のため、複数の通常経路と一つの不正なパス属性を同じ UPDATE が運んだと仮定する。実在の事業者、プレフィックス、経路数、障害、実装不具合を示す例ではない。RFC 4271 の基本手順では UPDATE Message Error の NOTIFICATION、セッション終了、同じピアから学んだ全経路の除去につながり得る。一つの属性異常が別の正常経路まで巻き込む。

RFC 7606 の treat-as-withdraw ならセッションを維持しつつ、問題 UPDATE に含まれる全経路を撤回として扱い、Adj-RIB-In から除く。監視画面のピアは緑のままでも、そのメッセージに入っていた宛先は消える。代替経路のある宛先と、他に候補がない宛先の結果は同じではない。

従って「悪い一経路だけを捨てた」という説明は成立しない。共有属性を持つ UPDATE の封じ込め単位は、その中で特定できる全 NLRI である。セッション維持は無関係な UPDATE や他の経路を守り得るが、当該 UPDATE 内の到達性を保存する保証ではない。

強さの違う四つの処置

RFC 7606 は、セッションリセット、AFI/SAFI 無効化、treat-as-withdraw、attribute discard を強い順に並べる。リセットは影響が広い一方、解析境界を特定できない場合に明確な状態を取り戻す手段となる。狭い処置が常に安全なのではなく、狭く処置できるだけの情報が必要なのだ。

RFC 4760 第 7 節 のアドレスファミリー別処置では、誤った MP_REACH_NLRI または MP_UNREACH_NLRI と同じ AFI/SAFI の既受信経路をすべて削除し、そのセッション中の後続経路を無視し得る。セッション終了も選択肢に残る。これは一個の UPDATE の撤回より大きな範囲である。

treat-as-withdraw には、NLRI フィールドを位置付けて最後まで正しく解析できるという条件がある。どの経路が入っていたか分からないのに、選択的に撤回したとは言えない。その場合、RFC 4271 のリセットや RFC 4760 のファミリー単位処置が必要になり得る。

attribute discard は異常属性だけを除き、残りの UPDATE を処理する。RFC 7606 が想定するのは、選択やインストールへ影響しない属性である。ただし、通常は参考情報でもローカルポリシーが参照すれば意味が変わる。安全性は属性名だけでなく、実際に稼働しているポリシーで評価する。

複数の異常が同時に存在し、異なる処置を要求するなら、適用可能な最強の処置を採る。一つ目の軽いエラーで解析を止め、attribute discard だけを記録する実装や運用説明では不十分だ。すべての分類と最終処置の根拠を保存したい。

なぜ「UPDATE を捨てる」と同じではないのか

BGP UPDATE は増分情報である。問題メッセージを黙って無視すると、以前の経路が Loc-RIB や FIB に残り続ける可能性がある。treat-as-withdraw は当該 NLRI を撤回状態へ進めることで、古い情報を使い続ける危険を避ける。どちらもセッションが落ちないため、隣接状態だけを見れば差が見えない。

処置は属性の意味と能力交渉にも依存する。RFC 6793 は、4 オクテット ASN の移行に使う AS4_PATH と AS4_AGGREGATOR の異常や文脈不適合について、属性破棄とローカル記録を定める。情報を捨てて処理を続けられる理由は、その属性が持つ限定的な役割にある。

RFC 7607 では AS 0 が AS_PATH または AGGREGATOR にあれば RFC 7606、AS4_PATH または AS4_AGGREGATOR なら RFC 6793 の手順へ渡す。AS 0 自体が本稿の主題ではない。同じ不正値でも、所在する属性が処置権限を変えることを示す例である。

RFC 8092 は Large Communities の値長がゼロでない 12 オクテットの倍数でない場合を treat-as-withdraw とし、重複値だけなら異常とせず除去する。外見上「変な値がある」だけでは処置を決められない。形式条件を対応する仕様までたどる必要がある。

IANA BGP Parameters はパス属性タイプと UPDATE エラーサブコードの現在の登録簿である。登録番号は分類を共有するために役立つが、特定属性を破棄してよいという独立の許可にはならない。参照仕様とローカルポリシーが処置を決める。

内部で同じ結果になるとは限らない

RFC 7606 は、iBGP で treat-as-withdraw を使うと AS 内の経路が不整合になり、長時間の転送ループやブラックホールを起こし得ると警告する。不整合がなくても、対象宛先は完全に到達不能または次善経路になり得る。容錯は正しい UPDATE を作るわけではない。

ルートリフレクター環境では、あるクライアントが経路を撤回扱いにし、別の経路を見ているクライアントが維持する場合がある。警告を出した一台の hidden route だけを確認しても、下流広告とパケットの整合は分からない。反射器、複数クライアント、異なる入口で状態を比較する必要がある。

送信側の訂正後も注意が要る。クリーンな置換 UPDATE が全地点へ届き、Adj-RIB-In、Loc-RIB、FIB が再構成されなければ復旧は完了しない。古い経路の残留、異常 UPDATE の再発、ノード間の差異を探すことが、単なる再受信ログより強い証拠になる。

証拠の欠落を隠さない

RFC 7606 は、関係する NLRI を識別し、異常な UPDATE 全体を保持するデバッグ機能を求める。完全な受信 PDU が理想だが、実際には保存容量やミラー設定に限界がある。欠落した場合は欠落を記録し、後から生成した要約を原 PDU と同等に扱わない。

RFC 7854 の BMP Route Mirroring は受信メッセージをそのまま運び、treat-as-withdraw された Errored PDU も示せる。一方で Messages Lost も定義し、バッファ不足などによる欠落を明示する。BMP は任意で、サンプリングや損失、資源消費があり得るため、万能の証拠保管庫ではない。

証拠列は PDU の次に、ピア、方向、AFI/SAFI、属性コード、フラグ、長さ、全 NLRI を置く。さらにソフトウェアとリリース、グループ継承後の実効設定、選んだ処置を記録する。前後の Adj-RIB-In、hidden/rejected 状態、Loc-RIB、下流広告を比較し、FIB と重要な宛先クラスのパケットで締める。

影響しなかった対象も保存する。単一 UPDATE の撤回を主張するなら、同じピアから別メッセージで学んだ経路が残ったことを確認する。AFI/SAFI 単位の処置なら、別ファミリーが正常であることを確認する。この対照がなければ、同時に起きたセッション変動や次ホップ障害を処置の結果と取り違えやすい。

時刻の整合も必要だ。PDU、ログ、RIB、FIB、プローブが異なる収束段階を記録しているのに、一枚の状態として並べると、実在しなかった因果関係が生まれる。時計精度、収集遅延、処置の開始と終了を共通時間軸に載せ、短いブラックホールを平均値で消さない。

ログのレート制限も証拠条件になる。一件の表示が一件の異常 UPDATE と対応するとは限らない。抑制数、最初と最後の時刻、PDU ミラーと経路変化を突き合わせる。情報がなければ、少なくとも一回発生したとは言えても、頻度や規模を推測で埋めない。

実装例を共通規則にしない

Cisco IOS XR 24.x の BGP 文書 は TreatAsWithdraw と DiscardAttr などの分類、隣接、メッセージ長、属性、ファミリー、NLRI を含むレート制限付きログ例を示す。これは IOS XR の観測手段であり、全製品共通のログ形式や既定値ではない。

Junos の BGP Error Messages はリセット、treat-as-withdraw、属性破棄、hidden route と診断ログを説明し、複数異常では最も厳しい処置を採る。keep と既定動作はリリースおよびプラットフォームの範囲に留めて評価する。

Nokia SR OS 26.4 の BGP 文書 は update-fault-tolerance と旧来処理を比較し、非重大エラーに対する撤回扱いまたは属性破棄を説明する。階層、既定値、対象エラーを他社機器へ一般化できない。共通にできるのは、仕様の意味と観測すべき結果である。

実効設定には全体、グループ、隣接、アドレスファミリーの継承も含まれる。テンプレートを読んだだけでは最終処置を証明できない。アップグレード前後に隔離環境で管理された異常メッセージを使い、同じ分類になるか確認する。運用中の隣接へ異常を投入する理由にはならない。

属性フィルターの台帳には、捨てられる根拠と、その属性を参照する全ポリシーを対応させる。後から選択条件が追加されれば、フィルター設定が不変でも安全性は変わる。意味の依存関係も変更審査へ含めたい。

セッションを落とさずに済んだことは中間結果にすぎない。送信側が原因を修正し、クリーンな UPDATE を送信し、全 NLRI の行方が説明され、内部の RIB と FIB とパケットが一致して初めて閉じられる。エラー封じ込めの価値は異常を見えなくすることではなく、調査に必要な証拠を失わずに被害を限定することにある。