要約

  • RFC 8326 の Graceful Shutdown は EBGP セッションを意図的に閉じる前に経路の優先度を下げる。RFC 4724 の Graceful Restart は BGP 再起動中に転送状態と stale 経路を一時保持する。
  • 変更記録には方式、データプレーンの生存条件、相手側ポリシー、収束の証拠、停止・復旧条件を明記する必要がある。

逃がす処理と残す処理

RFC 8326 が扱うのは、保守によって転送面が影響を受ける場面である。GRACEFUL_SHUTDOWN コミュニティを付けた経路を即座に withdraw するのではなく、低い LOCAL_PREF で一時的に残し、代替経路が選択・伝播されてから EBGP セッションを閉じる。

受信側は事前に、コミュニティを照合してローカル優先度を下げる入力ポリシーを用意する。開始側は送信経路に印を付け、対象セッションから受信した経路の優先度も下げ、再広告と収束を待つ。推奨される LOCAL_PREF は 0 である。目的は、転送が消える前にトラフィックを排出することだ。

RFC 4724 は異なる前提に立つ。BGP の制御状態が再構築される間も転送状態が維持できる場合、Graceful Restart Capability と End-of-RIB を使い、相手は対象経路を stale として期限付きで保持する。セッションが戻り、新しい UPDATE が届けば古い状態を置き換える。

Shutdown は「この道から離れよ」、Restart は「この道を一時的に信頼せよ」という指示である。方式名を省いた graceful には、運用判断としての意味がない。

外部シグナルと内部判断の境界

Graceful Shutdown の値は 65535:0 である。RFC 1997 によれば、コミュニティは optional transitive な属性であり、受信側はローカルポリシーに従って変更できる。開始側が示せるのは意図までで、隣接 AS の選択を強制することはできない。

RFC 4271 の LOCAL_PREF は AS 内部の属性で、高い値が優先され、通常は外部ピアへ送られない。相手 AS が受け取ったコミュニティを内部の優先度へ変換して初めて、排出が始まる。したがって、成功の証拠は設定の存在ではなく、代替経路が RIB と FIB で選ばれた事実である。

また、コミュニティは代替経路の容量を保証しない。保守対象が実際に転送不能になることも証明しない。意図、物理状態、容量を別々に確認する必要がある。

stale 経路を残す条件

Graceful Restart では、保持は無期限ではない。Restart Time までにセッションが戻らなければ、受信側は stale 経路を削除する。再接続後に対象 AFI/SAFI の Forwarding State が確認されなければ、やはり削除する。End-of-RIB の受信後も置き換わらない stale 経路は残せない。

RFC 4724 は、実際には転送状態が保たれていなかった場合や、収束前に経路情報が変わった場合、ループやブラックホールが起こり得ると述べる。BGP セッションの復帰だけでは十分な観測ではない。データプレーン、タイマー、stale 経路、End-of-RIB を同じ変更記録に結び付けるべきだ。

検証可能な変更票

承認前に、方式、転送面の前提、相手が実行するポリシー、代替経路と容量、収束完了イベント、中止条件、ロールバック責任者を確定する。この情報があれば、実行中の観測から続行と中断を判断できる。

準備には自動化、計測、ピアとの調整、待ち時間という費用がかかる。しかし曖昧さを残せば、その費用はパケット損失として利用者へ、証拠の乏しい障害解析として運用担当へ移るだけである。

情報源と限界

根拠は RFC 8326、RFC 4724、RFC 1997、RFC 4271 である。これらは仕様上の要件を示すが、世界的な導入率、ベンダー間の同一動作、特定ネットワークの実装や予備容量を証明しない。