要約

  • BGPセッションがEstablishedに戻った後も、ルーターBではIPv4とIPv6のプレフィックスが121秒間ゼロだった。
  • Marian Rychteckýは、End-of-RIBの遅れを、TCPリセットを招いた切り詰め済みIPv6ピアアドレスまで突き止めた。

セッション表示はEstablished、ルーティングテーブルは空。Marian RychteckýがNANOG 98で報告した障害は、その食い違いから始まる。ファイアウォールの冗長構成を更新すると切り替えが起き、BGPセッションは戻ったが経路は戻らなかった。ルーターBはIPv4とIPv6のプレフィックスをRIBに121秒間持たず、トラフィックは期待した経路を持たないファイアウォールへ向かい続けた。結果は約2分のブラックホールだった。

チームは切り替えの影響を抑えるため、BGP Graceful Restartを有効にしていた。この機能は、転送状態を維持できる場合に古い経路を一時保持し、新しい更新で置き換えるための仕組みだ。End-of-RIBはアドレスファミリーごとの初期更新完了を示す。だが、こうした制御プレーンの印は、ファイアウォールが今届いたパケットを転送できるという証明ではない。

時間が手掛かりになった。Rychteckýによると、切り替えからほぼ2分後にEnd-of-RIBが届いた。約120秒の再接続タイマーに近い。発表の診断では、待ち続けていたのはIPv6のBGPセッションだった。必要なマーカーが来るまで経路選択が保留され、IPv4の経路まで解放されなかった。接続は成立しているのに、RIBは空のままだった。

パケットキャプチャは、新しい接続でTCP RSTが発生したことを示した。スライドの最終診断では、本来のIPv6ピアアドレス 2001:db8:1::2 が 2001:db8:1: として保存されていた。末尾が欠けたため正しいVRF/BGPコンテキストを特定できず、未知のVRF ID 0に落ちてリセットを送った。BIRDを使った小規模なラボ試験が、プロトコルの意図と実装上の不具合を切り分けた。Rychteckýはこの環境での回避策として、接続タイマーを1秒にする設定を示している。

Graceful Restartが経路を保てるのは、前提となる転送状態が実際に残っているときだ。この事例ではピアアドレスの解析ミスが経路交換を遅らせる一方、サービス経路はすでに途切れていた。BGPの状態表示が語ったのは接続の成立、RIBとパケットが語ったのは停止だった。

発表資料にはキャプチャファイルもベンダー名もない。匿名化したトレースか公式の障害記録があれば、解析の連鎖を独立に検証できる。NANOGのセッションページはRychteckýをNIX.CZのCTOと紹介する。事例の詳細は公式スライド、仕組みの定義はRFC 4724にある。NANOG公式写真を人物肖像の参照にした。