要約

  • ファイアウォールのHA更新後、Router Bは121秒間BGPプレフィックスを受信しなかった。セッションはEstablishedのままで、トラフィックはファイアウォールへ送られていた。
  • 発表者のパケットキャプチャとラボ再現は、IPv6ピア・コンテキストの解析エラーとTCP Resetを示した。IPv6のEnd-of-RIB待ちがIPv4の経路インストールも遅らせた。

Establishedは安心できる表示だった。経路表の答えはもっと率直で、121秒間ゼロプレフィックスだった。

この障害をNANOG 98で発表したのは、NIX.CZのMarian Rychteckýだ。高可用性を組んだファイアウォールを更新すると、BGPセッションはEstablishedに戻ったが、Router Bには経路が届かなかった。トラフィックはファイアウォールへ流れ続けた。期待された経路をまだ導入していないファイアウォールがその先にあり、パケットは約2分間ブラックホールに落ちた。

決め手は121秒という長さだ。End-of-RIBは120秒の再接続タイマーに近い時点で届いた。ただしタイマーは手掛かりであって、障害の全容ではない。調査では、IPv4の復旧が特定のIPv6 BGPセッションを待っていた。Graceful Restartは、ネゴシエート済みのピア状態がEnd-of-RIBマーカーを受け取るまで完了しない。一方のアドレスファミリーで止まったセッションが、もう一方の経路まで足止めした。

パケットキャプチャでは、新しいセッションにTCP Resetが返っていた。ラボ再現では、想定されたIPv6ピアアドレス2001:db8:1::2が2001:db8:1:として保存されていた。OSは接続を正しいVRFとBGPコンテキストに割り当てられず、Resetを返した。切替の一部では古いTCP接続がまだ有効に見えており、新しい接続が古い状態と衝突した。

この記録の要点は「Graceful Restartも失敗する」ではない。BGPの状態表示が緑でも経路表に経路があるとは限らず、制御プレーンが復旧しても転送が戻ったとは限らない。発端はファイアウォール更新。仕組みは、ピア情報の誤解析とアドレスファミリーをまたぐ待ち合わせ。影響は空のRIBと破棄されたパケットだった。

発表者によれば、この事例では接続タイマーを短縮すると再接続とEnd-of-RIB交換が速くなった。これは当該構成で報告された回避策で、普遍的な設定値ではない。一つの待ち時間を縮めれば、別の障害窓ができることもある。恒久的な検証では、TCP再接続からアドレスファミリー別のEnd-of-RIB、経路導入、実際のパケット配送までを一続きで試す必要がある。

公開スライドには機器型番、ファームウェア版、顧客トラフィックの損失量がない。その記録があれば単独の実装不具合か、複数環境に広がる問題かを判定できる。

出典