Google Cloud HA VPN and Cloud Router: BGP Sessions, Priorities and Failover

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

An HA VPN design has two independent routing decisions. The MED your peer sends sets the path from Google Cloud to your site. The base priority on each Cloud Router BGP session sets the path from your site to Google Cloud. Configure both, or each direction can pick a different tunnel.

Failover is not instant. Google documents 40 to 60 seconds of route withdrawal with expected packet loss. Detecting the failure is a separate stage that comes from BGP timers, because BFD, the faster detection protocol, is not supported on HA VPN BGP sessions. Google does not state the total of the two, so measure it.

Commands below come from Google's documentation or were written for this article against its gcloud reference pages. None was run in a lab.

Why it matters

The availability figure depends on the tunnel layout. Google gives 99.99% for most HA VPN topologies and 99.9% for Classic VPN, but one tunnel does not qualify. You need a tunnel from each of the gateway's two interfaces. An HA VPN gateway with one active interface has no availability SLA.

Capacity is the less visible problem. A tunnel carries 250,000 packets per second, ingress and egress combined, which is about 1 to 3 Gbps depending on packet size. Traffic is throttled at the limit. Two tunnels running active-active at 80% each cannot fit on one tunnel after a failure.

How it works

The parts

An HA VPN gateway is a regional resource with two interfaces, each with its own automatically chosen external IP address. It supports only dynamic BGP routing.

Cloud Router is not in the data path. It is BGP tasks plus a dynamic route control plane, and the VPC data plane forwards the packets.

The task split explains later behaviour. Tunnels on different gateway interface numbers use two BGP tasks, so a correctly built pair does not depend on one task.

Fixed values to plan around

Payload MTU is smaller than gateway MTU. On an IPv4 interface it is 1406 bytes with AEAD ciphers (AES-GCM). With non-AEAD ciphers it is 1374 or 1390, depending on the cipher pair, so check Google's table. Active NAT-Traversal costs another 8 bytes. The peer must support prefragmentation.

Priority in each direction

Google Cloud to your site. Your peer advertises its prefixes with a MED on each session. Cloud Router imports them as dynamic routes with those priorities. Identical values give ECMP, and different values mean only the best route carries traffic.

Your site to Google Cloud. Cloud Router advertises your VPC subnets with a MED equal to the session's base priority. In global dynamic routing mode, subnets in other regions carry base priority plus an inter-regional cost. Your peer decides what to do with those values.

Three details change designs:

• A missing MED wins. A route with no MED is treated as MED 0, the highest priority. If you set a MED only on the tunnel you want preferred, the other tunnel wins.
• Keep base priorities at 200 or below. Region-to-region costs are 201 to 9999, and Google recommends base priorities of 0 to 200 among routers in a region. Above that, another region's path can win by accident. A base priority of 10200 or more makes a path a last resort against any prefix advertised with a base of 200 or less.
• Do not use AS-path prepending as the main control in legacy mode. Legacy best-path selection is the default for a new VPC, and Google says not to rely on AS-path length when different BGP tasks handle the same prefix. The two tunnels of a correct HA pair sit on different tasks. Use MED.

Standard mode is closer to RFC 4271 and evaluates AS path across Cloud Routers, but Google recommends legacy unless you need standard's features.

What happens during a failure

The route removal is triggered in two ways, and they differ. An unhealthy tunnel, for example after failed dead peer detection, makes Cloud Router withdraw routes through it. A BGP session failure removes those routes without marking the tunnel unhealthy.

Changing timers does not cover a peer without graceful restart, as the table shows. On a VPN session the detection setting you control on the Cloud Router is the keepalive, and 20 seconds is already its minimum. The negotiated hold time is the lower of the two routers' values, so the peer's setting matters too. Do not lower it to gain speed: Google's guidance for normal task migration calls for an on-premises hold timer of at least 60 seconds.

Building the pair

The order below follows Google's HA VPN creation guide. The example assumes a peer with two public addresses and active-passive priorities. The names, private ASNs and addresses are placeholders written for this article.

gcloud compute vpn-gateways create gw-syd --network=NETWORK --region=REGION

gcloud compute external-vpn-gateways create peer-gw \
  --interfaces 0=PEER_IP_0,1=PEER_IP_1

gcloud compute routers create rt-syd --region=REGION --network=NETWORK --asn=64514

gcloud compute vpn-tunnels create tun-0 --region=REGION --vpn-gateway=gw-syd \
  --interface=0 --peer-external-gateway=peer-gw \
  --peer-external-gateway-interface=0 --ike-version=2 \
  --shared-secret=SHARED_SECRET --router=rt-syd

Repeat the tunnel for interface 1 as tun-1. Then add one router interface and one BGP peer per tunnel:

gcloud compute routers add-interface rt-syd --region=REGION \
  --interface-name=if-0 --vpn-tunnel=tun-0 \
  --ip-address=169.254.10.1 --mask-length=30

gcloud compute routers add-bgp-peer rt-syd --region=REGION \
  --peer-name=bgp-0 --interface=if-0 --peer-asn=65010 \
  --peer-ip-address=169.254.10.2 --advertised-route-priority=100

Use 169.254.11.1, 169.254.11.2 and --advertised-route-priority=200 for the second session. On the peer, send MED 100 on the first session and MED 200 on the second, and honour the MEDs it receives from Cloud Router. The peer's own configuration comes from your device vendor.

Use a strong pre-shared key. --shared-secret places it on the command line, so keep it out of shell history and tickets.

Advertise the same prefixes on all links, possibly with different priorities. Allow the peer's ranges with a VPC firewall rule, because the implied deny ingress rule blocks them. The rule is separate from tunnel traffic itself: UDP 500, UDP 4500 and ESP to the gateway are always allowed.

Proving it works

Run these in order. Each one proves a layer before the next depends on it.

1. Redundancy coverage.

gcloud compute vpn-gateways get-status gw-syd --region=REGION

You want CONNECTION_REDUNDANCY_MET. CONNECTION_REDUNDANCY_NOT_MET with INCOMPLETE_TUNNELS_COVERAGE means a tunnel is missing. This checks configuration only, not traffic.

2. Tunnel state.

gcloud compute vpn-tunnels describe tun-0 --region=REGION \
  --format='flattened(status,detailedStatus)'

A working tunnel reports Tunnel is up and running..

3. BGP state and learned routes.

gcloud compute routers get-status rt-syd --region=REGION

Check these fields:

The readings in the numLearnedRoutes and priority rows are editorial, not Google's wording.

Remember the full-mesh behaviour: if one interface receives the same prefix with different MEDs, only the best is imported, and the others are not visible until it is withdrawn.

4. What each session advertises.

gcloud compute routers list-bgp-routes rt-syd --region=REGION \
  --peer=bgp-1 --address-family=IPV4 \
  --route-direction=OUTBOUND --no-policy-applied

The med values should show your backup priority. Run it with --route-direction=INBOUND to see what the peer sent. Add --policy-applied if you use BGP route policies.

5. Capacity. Google recommends alerting at 50% of tunnel capacity, so that one tunnel can take the load after a failure. Its example query for packet rate, for one tunnel, is:

(
  rate({"vpn.googleapis.com/network/sent_packets_count", monitored_resource="vpn_gateway", tunnel_name="TUNNEL_NAME"}[1m]) +
  rate({"vpn.googleapis.com/network/received_packets_count", monitored_resource="vpn_gateway", tunnel_name="TUNNEL_NAME"}[1m])
) > 125000

The packet metrics carry a status label whose values include throttled and exceeds_mtu. A non-zero throttled count means the tunnel has reached its limit. That reading is editorial.

6. Plan a failover rehearsal. Disabling a BGP peer terminates the session and removes its routes. No executable disable command is supplied because this sequence was not lab validated. A qualified network owner should rehearse the exact peer and recovery procedure on an isolated connection before any approved production window.

The plan must confirm both sessions are healthy, name the affected peer, retain independent management access and define how to restore the original routing state. Measure the beginning and end of loss with a continuous test, and verify the traffic path in both directions. Record return to Established and stable traffic before considering the next test case. Cover each session individually.

A BGP-session exercise tests one failure mode only. Tunnel, device and link failures need their own vendor-reviewed scenarios, and the measured end-to-end recovery time must include detection, route changes and application recovery.

Reading common failures

The commands and log strings below come from Google's VPN troubleshooting and BGP session troubleshooting pages. VPN logs use the filter resource.type="vpn_gateway".

Route quota warnings appear at 75% usage in route_quota_events, and when dropping starts, IPv6 prefixes are dropped before IPv4. Alert on the 75% warning.

A destination inside a VPC subnet will never use the tunnel. Cloud Router ignores advertised routes matching or fitting within a subnet range, and traffic to a narrower subnet stays in the VPC.

Learned routes also stay put. Cloud Router does not re-advertise routes learned from one peer to another. For hub-and-spoke designs, Google points to Network Connectivity Center.

What to choose and why

These are editorial recommendations unless a link says otherwise.

Risks and limits

Warning: the Google ASN cannot be changed later, and tunnel ciphers cannot be modified after creation. Google's create guide says the ASN cannot be changed later, but its BGP troubleshooting page says to change the ASN of your device or Cloud Router, and gcloud compute routers update lists an --asn flag. We have not resolved or tested this conflict, and the sources do not say what the flag does to established sessions. Plan on replacing resources, which interrupts that path, unless validation proves otherwise. Any replacement needs a separately reviewed topology and continuity plan; this source-only article does not establish a replacement procedure.

• Stack type. Moving an HA VPN gateway to another stack type means re-creating the gateway and its tunnels. Decide on IPv6 first. HA-to-HA connections need identical stack types.
• Cross-region SLA. HA-to-HA gateways in different regions give 99.9%, not 99.99%.
• Authentication. HA VPN supports pre-shared keys only. Certificates are not an option.
• Peer support. Check the peer vendor's documentation for BGP MED handling, graceful restart and redundancy.
• Costs and SLA terms. Pricing and SLA contract text were not reviewed for this article. Check them directly before committing.
• Not tested here. Nothing in this article was run. Check every flag against the gcloud version you use, and confirm timings in your own failover test.

Sources

Opened 10 November 2026. Sources behind the corrections reopened 10 November 2026.

• Cloud VPN overview
• Cloud VPN topologies
• Cloud VPN best practices
• Create an HA VPN gateway to a peer VPN gateway
• Check VPN status
• MTU considerations
• Order of routes
• Supported IKE ciphers
• Configure firewall rules
• View logs and metrics
• Cloud VPN quotas and limits
• Cloud VPN troubleshooting
• How Cloud Router works
• Learned routes
• Advertised routes
• BFD for Cloud Router
• BGP session states
• Manage BGP timers
• Update the base route priority
• List BGP routes
• Cloud Router quotas and limits
• Troubleshoot BGP sessions
• Troubleshoot BGP peering
• Troubleshoot BGP routes and route selection
• gcloud compute routers update-bgp-peer
• gcloud compute routers add-bgp-peer
• gcloud compute routers add-interface
• gcloud compute vpn-tunnels create

This article was originally published on 10 November 2026.