GCP BYOIP：公网通告不等于私网路由
把一个 BYOIP 前缀分给本地和云端需要两套方案。把公网通告、委派和私网下一跳分开处理。
公网地址块的一部分留在本地，另一部分迁入 Google Cloud。这句话描述的是两套方案，而不是一套：一套是对外通告方案，一套是私网转发方案。把它们当成同一个路由问题，正是 BYOIP 设计出错的地方。
涉及的对象回答的是不同的问题，其中只有一个关乎报文下一步去哪里。
三个对象，三个问题
公网通告前缀是 Google 代表你向互联网通告的单位。公网委派前缀描述的是导入的地址空间如何分配给受支持的 Cloud 资源。VPC 路由（包括从 VPN 经 Cloud Router 学到的路由）选择的是私网下一跳。三者各有各的范围、各自的 API 和各自的报错信息。
用表格说更短。
| Object | Question it answers |
|---|---|
| Public advertised prefix | Which authorized range Google announces publicly |
| Public delegated prefix | How imported space is allocated to Cloud resources |
| VPN or Cloud Router route | Which private next hop carries a destination |
只有第三行讲的是你网络内部的转发。
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 实际交换了什么。
一组输出告诉你互联网看到什么。另一组告诉你流量去了哪里。两者谁也替代不了谁。