GCP BYOIP：公開告知はプライベートルートではない

公開ブロックの一部は拠点に残り、一部は Google Cloud へ移る。この一文は一つの計画ではなく二つの計画、すなわちインターネット告知の計画とプライベート転送の計画を述べている。両者を単一のルーティング問題として扱うことこそ、BYOIP 設計が誤る地点である。

関与するオブジェクトはそれぞれ別の問いに答え、パケットが次にどこへ行くかを扱うのはそのうち一つだけだ。

三つのオブジェクト、三つの問い

公開告知プレフィックスは、Google があなたに代わってインターネットへ告知する単位である。公開委任プレフィックスは、取り込んだ空間を対応する Cloud リソースへどう割り当てるかというものだ。VPC ルートは、VPN から Cloud Router 経由で学習したものを含め、プライベートなネクストホップを選ぶ。それぞれに固有の範囲、固有の API、固有の失敗メッセージがある。

表にすると短い。

あなたのネットワーク内部の転送について述べているのは、三行目だけだ。

BYOIP の重複警告が扱う範囲

Google の BYOIP ドキュメント は、告知プレフィックスを告知の単位として扱い、Google の外で告知されるサブプレフィックスを含め、外部告知の重複を警告している。その警告は公開告知の計画についてのものだ。追加しうるあらゆるプライベートルートについての記述ではない。

取り込んだプレフィックスの内部でより小さな割り当てを委任しても、それ自体では、残りを別の起点から告知する許可にはならない。

誰が何を告知するかという形で問いを立てよう。Google が取り込んだプレフィックス全体を告知するなら、サブプレフィックスを告知する第二の起点は、VPC ルートがどれほど整って見えても、ドキュメントが警告する重複をまさに作り出す。

プライベートルートが決めること

VPN 経由で学習したプレフィックスはインターネット告知ではなく、どれだけ BGP を積んでも告知にはならない。それは VPC ルートテーブルの項目であり、その宛先のトラフィックをどのトンネルやゲートウェイが運ぶかを示す。その項目が適格か、選択されるか、利用可能かは、VPC 自身のルート規則によって決まる。

最長プレフィックス一致はルートテーブルの内部で適用されるため、長い VPN ルートが公開側のエッジで何も変えずにローカルで勝つことがある。

プレフィックスの分割：最初に来る判断

ブロックの半分をデータセンターから、半分を Google から告知する必要があるなら、何かを取り込む前に告知の計画を確定させる。Google が告知してよい範囲、他所で告知されたまま残る範囲、そして両者が重複するかどうかを確認する。そのうえで、宛先ごとのプライベート経路と戻り経路を設計する。望む分割をプロバイダーが支えないなら、長い VPN プレフィックスが公開側エッジの判断を覆すと期待するのではなく、分割のほうを変える。

この順序が重要なのは、第二の計画が第一の計画を修復できないからだ。

二つの計画を別々に検証する

公開側は gcloud compute public-advertised-prefixes list で確認し、範囲とその状態を確かめる。プライベート側は gcloud compute routes list と gcloud compute routers get-status で確認すれば、BGP が実際に何を交換したかが分かる。

一方の出力はインターネットに見えるものを教える。もう一方はあなたのトラフィックがどこへ行くかを教える。どちらも他方の代わりにはならない。