Professional Cloud Network Engineer
Dynamic routing for hybrid Google Cloud connectivity uses Cloud Router to manage Border Gateway Protocol (BGP) sessions that automatically exchange routes between Virtual Private Cloud (VPC) networks and external peer networks. When running High Availability Cloud VPN (HA VPN) over Cloud Interconnect, Cloud Router maintains dynamic BGP peer sessions over encrypted tunnels to eliminate manual route table management. This dynamic exchange allows traffic to automatically reroute when an individual tunnel or interface fails, providing the foundation for high-availability service level agreements.
An HA VPN gateway is a regional Google Cloud networking resource with two distinct interfaces that connect to external peer VPN gateways. Peer gateway redundancy types are categorized as SINGLE_IP_INTERNALLY_REDUNDANT for a single external IP address, TWO_IPS_REDUNDANCY for two external IP addresses, and FOUR_IPS_REDUNDANCY for four external IP addresses. When configuring the external peer gateway resource, each peer interface is assigned an interface ID (from 0 to 3) and an IP address, allowing Google Cloud to automatically infer the redundancy type. Interface 0 of the HA VPN gateway connects directly to interface 0 of the peer gateway, while interface 1 connects to interface 1, because mismatched interface pairings prevent IPsec tunnels from establishing.
A Cloud Router manages dynamic BGP routing sessions within a specific region and VPC network using a fixed Google Autonomous System Number (ASN) assigned during creation. Supported private ASN ranges include 64512 through 65534 in 16-bit space and 4200000000 through 4294967294 in 32-bit space, provided the chosen number does not collide with the peer network's ASN. Each HA VPN gateway requires a dedicated Cloud Router and cannot share an instance that already manages BGP sessions for Partner Interconnect VLAN attachments. The Cloud Router establishes router interfaces bound to specific VPN tunnels and creates router peers representing on-premises BGP neighbors, where optional advertised route priorities function as Multi-Exit Discriminator (MED) metrics to influence return traffic paths.
Achieving a 99.99% availability service-level agreement (SLA) requires creating at least one VPN tunnel on each of the two HA VPN gateway interfaces to the corresponding peer gateway interfaces. Each tunnel configuration specifies the local HA VPN gateway interface, the matching peer gateway interface, and an identical Internet Key Exchange (IKE) pre-shared key on both sides. Google Cloud recommends IKE version 2 (IKEv2) as the default protocol version, and requires it when transmitting IPv6 traffic across the tunnel. Pre-shared keys act as shared secrets for IPsec authentication and cannot be retrieved after creation, and configured tunnels remain inoperable until corresponding partner tunnels are fully provisioned on the peer gateway.
BGP sessions run inside established IPsec VPN tunnels using link-local IPv4 addresses, typically allocated from the 169.254.0.0/30 subnet range. Each tunnel connects to a dedicated Cloud Router interface and peer configuration, defining the peer ASN, peer link-local IP address, and an optional advertised route priority. BGP computes best paths across active tunnels using standard decision criteria, including Autonomous System (AS) path length, origin type, and MED values. When one tunnel experiences a failure, BGP automatically withdraws the route and directs traffic across the remaining functional tunnels to achieve deterministic failover.
HA VPN over Cloud Interconnect delivers line-rate, IPsec-encrypted data transmission between on-premises environments and Google Cloud VPC networks using dedicated physical circuits. This architecture couples the high throughput and predictable performance of Cloud Interconnect with the cryptographic privacy provided by IPsec encapsulation. Organizations provision HA VPN gateways directly over Dedicated Interconnect or Partner Interconnect VLAN attachments to ensure data in transit is protected across the physical transport layer. Because tunnels terminate on private regional IP addresses rather than public IP addresses, network traffic stays confined entirely within private network boundaries.
Achieving a 99.99% availability SLA requires deploying redundant HA VPN gateways across dual Cloud Router instances and geographically separated Cloud Interconnect connections. The design spans two distinct metropolitan availability domains or Google Cloud edge points of presence (PoPs) to eliminate single points of physical hardware failure. On-premises peer routers establish paired IPsec tunnels connecting to both interfaces of the HA VPN gateway across primary and redundant VLAN attachments. Cloud Router manages dynamic BGP sessions across these redundant paths to automatically divert traffic if a physical connection, tunnel, or edge facility fails.
Configuring HA VPN over Cloud Interconnect requires assigning private regional IP addresses to each HA VPN gateway interface rather than external public IP addresses. Each provisioned HA VPN gateway contains two interfacesâinterface 0 and interface 1âthat bind directly to redundant Dedicated Interconnect or Partner Interconnect VLAN attachments within the same region. On-premises routers configure matching private IP endpoints on their local interconnected interfaces to terminate the corresponding IPsec tunnels. After the underlying Layer 3 connectivity is established across both VLAN attachments, Cloud Router activates BGP sessions inside the IPsec tunnels to advertise and receive internal VPC routes.
Configuring Maximum Transmission Unit (MTU) sizes, cryptographic settings, and tunnel counts ensures high throughput, tunnel stability, and SLA compliance for HA VPN over Cloud Interconnect. These configuration choices prevent packet fragmentation, prevent tunnel disconnects during key rotation, and ensure traffic matches the capacity of underlying interconnect attachments.
The Maximum Transmission Unit (MTU) defines the largest packet size that a network path can transmit without fragmenting the packet into smaller frames. When deploying HA VPN over Cloud Interconnect, engineers must calculate an MTU that accommodates the encapsulation overhead introduced by IPsec headers and 802.1Q VLAN tags. Cloud VPN tunnels use a default MTU of 1460 bytes, though path MTU discovery can identify a lower path MTU when additional encapsulation layers exist. If path MTU discovery detects a value lower than the default, the tunnel MTU must be manually adjusted to match that lower value to avoid performance degradation or packet loss.
Cryptographic parameters for IKE and IPsec Security Associations (SAs) must match precisely between Google Cloud and the on-premises VPN gateway to maintain connection stability. A frequent source of tunnel flapping or unexpected disconnection is a mismatch in SA rekeying behavior, such as when a peer gateway tears down an existing SA before completing rekey negotiation. Administrators must ensure both endpoints agree on the Phase 2 IPsec lifetime and support an identical Diffie-Hellman (DH) group. Cloud VPN diagnostic logs flag parameter mismatches with specific messages such as Peer proposal: DOES NOT HAVE DIFFIE_HELLMAN_GROUP to aid in cipher troubleshooting.
Tunnel optimization requires scaling the number of HA VPN tunnels to match the overall provisioned throughput capacity of the underlying encrypted VLAN attachments. The required tunnel count depends entirely on the capacity allocated to the encrypted VLAN attachments, regardless of whether unencrypted traffic shares the same physical Cloud Interconnect link. Achieving high availability requires deploying tunnels across redundant connections in separate edge availability domains for a 99.9% SLA, or across separate regions for a 99.99% SLA. This multi-path deployment structure ensures seamless traffic failover if an individual link, zone, or regional facility goes offline.
Private regional IP addresses are assigned to the HA VPN gateway interfaces so IPsec tunnels terminate directly on the private Layer 3 transport provided by Cloud Interconnect VLAN attachments. This configuration ensures that all encrypted traffic travels strictly over private enterprise connections without traversing the public internet.
Tunnel drops often happen when the on-premises gateway deletes an active Phase 2 Security Association before successfully negotiating a new one instead of completing the rekey negotiation beforehand. Mismatches in agreed Phase 2 lifetimes or unsupported Diffie-Hellman groups also cause rekeying negotiations to fail.
Cloud Router evaluates standard BGP attributes, including Autonomous System path length, origin type, and Multi-Exit Discriminator values configured via advertised route priorities. If the primary tunnel fails, Cloud Router automatically updates its routing tables to route traffic over the remaining healthy tunnels.
Prepare and test your skills
Prepare and test your skills
StudyCerts
StudyCerts