GCP BYOIP: Public Advertisement Is Not a Private Route
Splitting a BYOIP prefix between site and cloud needs two plans. Separate the public announcement, the delegation and the private next hop.
Part of a public block stays on site and part moves into Google Cloud. That sentence describes two plans, not one: an internet announcement plan and a private forwarding plan. Treating them as a single routing problem is where BYOIP designs go wrong.
The objects involved answer different questions, and only one of them is about where packets go next.
Three objects, three questions
A public advertised prefix is the unit Google announces to the internet on your behalf. A public delegated prefix is how imported space gets assigned to supported Cloud resources. A VPC route, including one learned over Cloud Router from a VPN, selects a private next hop. Each has its own scope, its own API and its own failure message.
The table version is shorter.
| 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 |
Only the third row is about forwarding inside your network.
What the BYOIP overlap warning covers
Google's BYOIP documentation treats the advertised prefix as an advertisement unit and warns about overlapping external announcements, including a subprefix announced outside Google. That warning is about the public advertisement plan. It is not a statement about every private route you might add.
Delegating a smaller allocation inside an imported prefix does not, by itself, give you permission to announce the remainder from another origin.
Ask the question in terms of who announces what. If Google announces the whole imported prefix, a second origin announcing a subprefix creates exactly the overlap the documentation warns about, however tidy your VPC routes look.
What a private route decides
A prefix learned over a VPN is not an internet advertisement, and no amount of BGP will make it one. It is an entry in a VPC route table saying which tunnel or gateway should carry traffic for that destination. Whether that entry is eligible, selected or usable depends on the VPC's own route rules.
Longest prefix match applies inside the route table, so a longer VPN route can win locally without changing anything at the public edge.
Splitting a prefix: the decision that comes first
If the architecture needs half the block announced from a datacentre and half from Google, settle the announcement plan before importing anything. Confirm which ranges Google may announce, which remain announced elsewhere, and whether the two overlap. Then design the private path for each destination and its return path. If the providers do not support the split you want, change the split rather than hoping a longer VPN prefix overrides a public-edge decision.
That order matters because the second plan cannot repair the first.
Verify both plans separately
Check the public side with gcloud compute public-advertised-prefixes list and confirm the ranges and their status. Check the private side with gcloud compute routes list and gcloud compute routers get-status, which shows what BGP actually exchanged.
One set of outputs tells you what the internet sees. The other tells you where your traffic goes. Neither substitutes for the other.