BGP session authentication secures the connection between a Cloud Router and an on-premises or partner router using an MD5 shared key. This prevents unauthorized routers from establishing a BGP session and injecting false routes into your network. To enable authentication, you must configure the same MD5 key on both the Cloud Router's BGP peer settings and the peer router. For example, when setting up a Cross-Cloud Interconnect with AWS or Oracle Cloud Infrastructure, you provide this key in the virtual circuit configuration. If the keys do not match, the BGP session will fail to establish, which protects the network boundary from unauthorized access.
Link-local addresses are private IP addresses that Google Cloud automatically assigns to each end of a VLAN attachment's point-to-point connection. These addresses come from the 169.254.0.0/16 range and are used only for BGP peering over the interconnect; they are not routable on the public internet. You retrieve these addresses—the cloudRouterIpAddress for Google's side and the customerRouterIpAddress for your side—when describing a VLAN attachment. You then configure your on-premises router with the matching customer-side address. Using non-routable addresses provides natural isolation for the control plane traffic that runs the BGP session.
BGP attributes are values that routers exchange to influence routing decisions. The ASN (Autonomous System Number) identifies your Google Cloud network as a separate autonomous system, and you configure the local ASN when creating a Cloud Router. The Peer ASN identifies the remote autonomous system and is set on the BGP peer configuration. The MED (Multi-Exit Discriminator) attribute can be advertised to influence which path an external peer uses to enter your network when multiple paths exist; a lower MED value is preferred. These attributes travel with routing updates and help routers choose the best path across your hybrid network boundary.
Cloud Router is a software-defined networking component that exchanges routing information with remote routers rather than acting as a physical data path. It establishes external BGP (eBGP) sessions with peer routers to install dynamic routes into your VPC network. Each BGP session on a Cloud Router binds to a single connectivity resource, meaning one BGP session cannot be shared across different VLAN attachments, VPN tunnels, or Router appliance instances. To maintain high availability, administrators deploy redundant connectivity resources such as dual HA VPN tunnels or paired VLAN attachments in separate Edge Availability Domains, each with its own BGP peering session.
Autonomous System Numbers identify distinct routing domains, and a single Cloud Router must use the same local ASN across all its BGP sessions. When using Partner Interconnect, Cloud Router requires the fixed Google ASN of 16550, which limits that router to managing BGP sessions only for Partner Interconnect or compatible Dedicated Interconnect attachments. In Network Connectivity Center deployments, non-Google peering routers connected to the same hybrid spoke must use an identical ASN when advertising prefixes to Cloud Router, while distinct spokes connected to the same hub must use unique ASNs to avoid routing conflicts.
Creating a BGP session follows a two-step order on Cloud Router: first create a router interface, then bind a BGP peer to that interface. An administrator creates the router interface by allocating an IP address from a /30 link-local CIDR block such as 169.254.21.0/30 and associating it with a specific VPN tunnel or VLAN attachment. Next, the administrator adds the BGP peer by defining the remote peer ASN, the remote peer IP address, and any optional parameters. The peering session transitions to an established state once both endpoints successfully exchange open messages and negotiate capabilities over TCP port 179.
Multiprotocol BGP (MP-BGP) allows a single IPv4 BGP control session to advertise both IPv4 and IPv6 network layer reachability information. When configuring IPv6 over HA VPN tunnels, administrators define explicit IPv6 next-hop addresses alongside the IPv4 peering interface for proper routing in dual-stack architectures. Network path selection uses the base advertised route priority, which defaults to 100 for all BGP sessions. Setting identical route priority values across redundant BGP sessions enables active-active routing where traffic balances equally across all healthy paths. Setting a lower route priority on the primary session and a higher value on the secondary session enables active-standby routing where traffic uses the preferred primary link and the secondary link serves as backup.
The Multi-Exit Discriminator (MED) attribute tells neighboring autonomous systems which entry point they should prefer when sending traffic toward your network. A lower MED value indicates a more preferred path, so you can set different MED values on multiple BGP sessions to control which connection carries inbound traffic. In Google Cloud, you configure MED values through Cloud Router's custom route advertisement settings when establishing BGP sessions with Cloud VPN or Cloud Interconnect attachments. When connecting to Google Cloud through multiple hybrid connections, you can send some traffic over one connection and the rest over another by adjusting MED values appropriately.
The Local Preference attribute controls how your network chooses which path to use when sending traffic out to external destinations. Unlike MED, which influences neighbors' decisions about sending traffic to you, Local Preference affects your own network's outbound routing choices. A higher Local Preference value indicates a more preferred path, and this attribute is meaningful only within your own autonomous system. Cloud Router lets you set Local Preference values on advertised routes to direct which Cloud Router or BGP session handles outbound traffic to specific destination prefixes. This is useful when you have multiple Cloud Interconnect attachments or Cloud VPN tunnels and want certain traffic flows through specific egress points based on performance or cost requirements.
Community strings are BGP attributes that tag routes with metadata, enabling automated policy application across complex network topologies. You can mark routes for specific handling, such as preferring certain paths for particular traffic types or controlling which routes get advertised to which peers. In Google Cloud, community strings work with Cloud Router to tag routes advertised to on-premises networks, and on-premises BGP routers can then use these tags to make routing decisions. This approach centralizes route classification at the Google Cloud side and lets downstream routers react automatically, simplifying routing policy management across hybrid and multicloud environments.
Cloud Router establishes BGP sessions over Cloud VPN tunnels and Cloud Interconnect VLAN attachments to exchange routing information between on-premises networks and Google Cloud VPC networks. Each Cloud Router maintains BGP sessions that learn routes from on-premises networks and advertise Google Cloud routes outward, using ASN to identify each side of the BGP relationship. Cloud Router supports both dynamic routing with BGP route propagation and custom route advertisements that precisely control which prefixes get advertised. To enable routes to your on-premises network, you modify Cloud Routers with a custom advertisement pointing to the CIDR range of the on-premises subnet, and use firewall rules to control access accordingly.
When implementing traffic engineering across hybrid and multicloud environments, you can use multiple connection options including Cloud VPN, Dedicated Interconnect, and Partner Interconnect to create redundant paths with different routing characteristics. You can provision several endpoints in the same VPC network and control different network paths using Cloud Router and VPC firewall rules to direct traffic based on your engineering requirements. For regional high availability failover, global dynamic routing must be enabled on Cloud Router, which affects how routes are learned and advertised across regions. The combination of MED, Local Preference, and community strings gives you fine-grained control over both inbound and outbound traffic flows, enabling optimization for performance, cost, or reliability based on your specific network topology and business requirements.
MED influences inbound traffic flow by telling neighboring autonomous systems which entry point to prefer, while Local Preference controls outbound traffic flow by telling your own network which exit path to prefer. MED is advertised to external peers, whereas Local Preference is used only within your own autonomous system.
Link-local addresses are automatically assigned by Google Cloud to each end of a VLAN attachment's point-to-point link and are required for BGP peering over Cloud Interconnect. You must configure your on-premises router with the matching customer-side address retrieved from the VLAN attachment configuration.
Set a lower base route priority value on the primary BGP session and a higher base route priority value on the secondary session. The default route priority is 100 for all BGP sessions. Traffic will use the primary link with the lower priority value and fall back to the secondary link only when the primary fails.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills
StudyCerts
StudyCerts