Professional Cloud Network Engineer
Diagnosing Border Gateway Protocol (BGP) session issues in a Google Cloud Router requires verifying underlying transport connectivity, matching protocol parameters, and monitoring session state transitions. The Cloud Router establishes external BGP (eBGP) sessions with on-premises routers, third-party network appliances, or secondary Virtual Private Cloud (VPC) networks to dynamically exchange route prefixes. When a BGP session fails to reach the Established state, the root cause may be at the physical link, Layer 3 configuration, firewall rules, or protocol parameter level.
Underlying Layer 3 reachability and open transport ports are strict prerequisites for BGP session establishment. Cloud Router requires bidirectional communication across TCP port 179 between the Cloud Router interface IP address and the remote peer IP address. Ingress and egress firewall rules in the VPC network or on-premises security appliances must explicitly allow TCP port 179 traffic to prevent connection timeouts during the initial BGP handshake.
IP address allocation mismatches frequently cause BGP session failures across different interconnectivity architectures. Cloud VPN configurations require each BGP peer to use a unique /30 subnet from the link-local 169.254.0.0/16 range, using the first and second host addresses. For Cloud Interconnect VLAN attachments, Google Cloud allocates a /29 CIDR block from the 169.254.0.0/16 range; configuring an on-premises subinterface with a /30 mask instead of a /29 mask prevents the session from establishing. In contrast, Network Connectivity Center (NCC) Router Appliance instances must use RFC 1918 internal IP addresses residing in the same VPC subnet as the Cloud Router interface rather than link-local addresses.
Basic reachability testing must account for Cloud Router architectural boundaries. Network administrators can verify connectivity using ICMPv4 ping across the peer IPv4 link-local addresses. Cloud Router does not respond to ICMPv6 echo requests sent to its BGP IPv6 addresses, so reachability for IPv6 configurations must be validated via IPv4 pings, session state inspection, or Compute Engine virtual machine (VM) data path tests.
Autonomous System Number (ASN) alignment between Cloud Router and the remote peer determines whether BGP open messages are accepted or rejected. The local ASN defined on Cloud Router must match the remote peer ASN configured on the external router, and the peer ASN specified on Cloud Router must match the local ASN configured on the external router. A mismatch in these attributes causes the BGP peering session to stay in an Active or Idle state.
Topology-specific peering parameters also influence session stability. Dedicated Interconnect and Partner Interconnect deployments require multi-hop BGP enabled on the on-premises router with a time-to-live (TTL) of at least 2 hops. When connecting multiple peer routers to a single spoke in NCC, all peer routers within that spoke must share the same ASN. Peer routers should have AS path loop detection enabled; if two distinct NCC spokes use identical peer ASNs, loop detection automatically drops routes exchanged between those spokes to avoid routing loops. The host VPC network must use global dynamic routing mode rather than regional dynamic routing if Cloud Router needs to propagate and receive routes across multiple Google Cloud regions.
Authentication configurations and timer parameters must align between Cloud Router and the peer device to establish and maintain active sessions. Cloud Router supports MD5 authentication using a pre-shared secret key. If MD5 authentication is enabled on one side of the session, the identical secret key must be configured on the peer router; mismatched or missing keys cause the operating system to drop the TCP segments silently.
Timer mechanisms control session liveness detection and failover behavior during maintenance events. The Cloud Router keepalive timer defines how often keepalive messages are exchanged, configurable as an integer between 20 and 60 seconds, with a default of 20 seconds. Cloud Router supports graceful restart with a fixed restart timer of 120 seconds, sending notifications prior to scheduled control plane maintenance so traffic forwarding continues uninterrupted. To prevent early deletion of routes when a session re-initializes after graceful restart, the external router stalepath timer should be configured to match the Cloud Router default of 300 seconds.
Multiprotocol BGP (MP-BGP) allows Cloud Router to exchange IPv4 and IPv6 routes across single or dual BGP sessions. For IPv6 BGP sessions, Cloud Router interfaces require unique local IPv6 addresses (ULA) from the fdff:1::/64 address range. When exchanging IPv6 routes over an IPv4 BGP session, next-hop IPv6 addresses must be assigned from the 2600:2d00:0:2::/63 address range on both Cloud Router and the peer router.
When IPv6 traffic fails to route despite an established IPv4 session, administrators must verify that the underlying VPC subnets and interconnect attachments are configured for the dual-stack IPV4_IPV6 stack type. Cloud Router enforces learned route quotas per VPC network; if learned route limits are exceeded, Cloud Router drops incoming IPv6 prefixes before dropping IPv4 prefixes. Furthermore, route policies or custom prefix-lists must be verified on both ends to ensure that desired subnet CIDRs are not dropped during route export or import processing.
Evaluating and troubleshooting BGP route advertisement and propagation involves diagnosing why routes learned from an on-premises network or another cloud are not correctly exchanged by Cloud Router or are failing to propagate within your Google Cloud VPC network. The process requires checking session parameters, verifying route status, and analyzing potential filtering or quota constraints.
A common issue is when a BGP session is established but fails to exchange IPv4 or IPv6 routes. First, verify the underlying connectivity configuration. For sessions over a VLAN attachment or HA VPN gateway, the attachment must have a stack type of IPV4_IPV6 to support dual-stack routing; an incorrect type will prevent route exchange. Next, inspect the Cloud Router BGP peer configuration using gcloud compute routers describe. Ensure that bgpPeers.enableIpv4 is set to true and that both bgpPeers.ipv4NexthopAddress and bgpPeers.peerIpv4NexthopAddress are populated. Missing these values indicates a misconfiguration that prevents the BGP session from advertising IPv4 prefixes.
When specific on-premises IPv4 or IPv6 prefixes are unreachable, the cause is often related to how routes are processed by Cloud Router. You must check for inactive custom learned routes and filtered learned routes. Use the gcloud compute routers get-status command to retrieve the BGP route table. Examine the routeStatus field for each learned route; a status other than ACTIVE indicates a problem. Routes can be inactive due to misconfiguration on the BGP session, the on-premises router filtering advertisements, or the BGP session being down. Routes can also be filtered if they exceed quotas or if BGP route policies are applied incorrectly, blocking their import into the VPC's routing table.
When learned routes from an on-premises network are not propagated to other peered VPC networks, the issue typically lies in VPC Network Peering or Shared VPC route export settings. For dynamic BGP routes to flow across a VPC peering connection, the Cloud Router's VPC network must have Export custom routes enabled on its side of the peering. Conversely, the receiving VPC network must have Import custom routes enabled. If these settings are not configured, BGP-learned routes will be confined to the original VPC and will not populate the route tables of connected networks, causing connectivity failures.
BGP route policies in Cloud Router are used to filter or modify route advertisements (export policies) and learned routes (import policies). A route policy must exist before it can be applied to a BGP peer. When troubleshooting, verify the policies attached to a peer using gcloud compute routers describe. Remember that updating policies replaces all existing policies of that type for that peer. If routes are missing, check if an import policy is filtering them out. If routes are not being advertised to an on-premises router, check if an export policy is blocking them. You can download and display a policy's configuration in YAML or JSON format to audit its match conditions and actions.
Continuous monitoring is essential for diagnosing BGP advertisement issues. Use Cloud Logging with specific filters to track BGP events. Key log entries to monitor include "Adding learned routes" and "Removing learned routes" to see route lifecycle events, and "Exporting advertised routes" to confirm outbound advertisements. For session health, filter for "BGP peering came up" or "BGP peering went down" messages. Additionally, Cloud Monitoring provides metrics for Cloud Router and per-BGP-session, such as advertised and learned route counts, which can help identify asymmetric routing or silent failures in route propagation.
Assessing and resolving connectivity issues in hybrid and inter-cloud peering involves diagnosing BGP peering problems in Cloud Router configurations, evaluating connectivity across Cloud VPN, Interconnect, or Partner Interconnect links, and implementing corrective measures to restore reliable network operations. When connectivity fails between on-premises networks and Google Cloud, the troubleshooting process must systematically isolate faults related to BGP session state, route propagation, MTU mismatches, underlying transport issues, and multi-hop BGP peering configurations.
When an IPv6 BGP session is established but IPv4 routes are not being exchanged, the issue typically stems from incorrect stack type configuration or missing IPv4 BGP settings on the Cloud Router. First, verify that the VLAN attachment or HA VPN gateway has the required stack type of IPV4_IPV6; if the stack type is incorrect for the VLAN attachment, modify the VLAN attachment, and for an HA VPN gateway, recreate the HA VPN gateway and its tunnels. Then, ensure that the Cloud Router is configured properly by running gcloud compute routers describe ROUTER-NAME and checking that bgpPeers.enableIpv4 is set to true and that bgpPeers.ipv4NexthopAddress and bgpPeers.peerIpv4NexthopAddress are present in the configuration. Only after confirming these settings can IPv4 routes be exchanged over an IPv6-established BGP session.
When traffic loss, ping errors, or other problems occur when attempting to reach on-premises IPv4 or IPv6 destinations within prefixes learned by Cloud Router, the troubleshooting approach must check multiple potential causes. Start by checking for inactive custom learned routes: verify that the route is configured properly on the BGP session, confirm that the BGP session is up, and check that the on-premises router is not filtering some learned routes. Then, check for filtered learned routes by running gcloud compute routers get-status ROUTER_NAME --region=REGION to examine the output for routes where routeStatus is set to active; if a route appears but is not active, the route is being filtered either by the on-premises router or by Cloud Router's import policies. Additionally, verify that quotas and limits have not been exceeded, as Cloud Router has limits on the number of dynamic routes it can store and program.
Learned routes from an on-premises network must propagate correctly to other VPC networks for hybrid connectivity to function. If learned routes are not propagating to other VPC networks, first verify that the VPC Network Peering connection exists between the VPC networks and that custom route export and import are properly configured on each side of the peering connection. The routing VPC must have custom route export enabled, and the workload VPC must have custom route import enabled for routes learned via BGP to flow between them. Also verify that Cloud Router is advertising the correct prefixes by checking the advertisedRoutes field in the router status output. Finally, ensure that no firewall rules are blocking traffic between the VPC networks, as route propagation and firewall rules work together to enable connectivity.
Cloud Router publishes logs and metrics that are essential for ongoing monitoring and troubleshooting of BGP peering issues. The logs capture critical events including BGP peering coming up or going down, BGP peering going down because the link went down on the Google peering edge router (indicated by "LINK_DOWN"), BGP session shutdown due to excessive received routes (indicated by "NOTIFICATION 6/1"), and Cloud Router dynamic route prefix quota exceeded. BFD (Bidirectional Forwarding Detection) events are also logged, including BFD session waiting for peer, BFD session coming up, and BFD session going down due to Rx Timer expiring or peer's state being Down or AdminDown. Cloud Router publishes metrics to Cloud Monitoring that cover both IPv4 and IPv6 traffic, and these metrics can be accessed via the Cloud Monitoring API or by creating custom dashboards in Cloud Monitoring to analyze router and BGP session performance.
The Network Intelligence Center's Network Analyzer provides automated insights that can help identify connectivity issues in hybrid and multi-cloud environments. Network Analyzer generates insights for VPC network issues such as routes with invalid next hops (including VM IP forwarding disabled, VM stopped, VM deleted, ILB misconfigured, or VPN tunnel deleted), as well as hybrid connectivity insights including shadowed dynamic routes. These insights appear as Recommender insight types and Cloud Logging insight types, allowing automated detection of configuration problems that could cause connectivity failures. When troubleshooting, check Network Analyzer insights first to identify known issue patterns before performing deeper diagnostic investigation.
For comprehensive connectivity troubleshooting across hybrid and inter-cloud links, follow a systematic approach that examines each layer of the network path. First, verify that the underlying transport is functioning: for Cloud VPN, check that IPsec tunnels are established; for Interconnect, verify that the VLAN attachment is operational and the physical connection is healthy. Then, verify BGP session state by checking that the BGP peer is in the Established state, which indicates successful BGP session formation. Next, verify route exchange by confirming that routes are being advertised and received on both sides of the BGP session. Then, verify routing tables on both Cloud Router and on-premises routers to ensure proper route selection. Finally, verify firewall rules and MTU settings, as MTU mismatches can cause packet fragmentation and connectivity issues, particularly for traffic traversing IPsec tunnels where the additional overhead can cause packets to be dropped.
Run gcloud compute routers describe ROUTER-NAME and compare the bgpPeers.peerAsn value to the actual local ASN configured on the on-premises router. The local ASN on Cloud Router must match the remote peer ASN on the external router, and the peer ASN on Cloud Router must match the local ASN on the external router. A mismatch keeps the session in an Active or Idle state.
Check the VPC Network Peering configuration on both sides. The VPC network containing the Cloud Router must have "Export custom routes" enabled, and the receiving VPC network must have "Import custom routes" enabled. Without these settings, BGP-learned routes remain confined to the original VPC network.
Use the gcloud compute routers get-status ROUTER_NAME --region=REGION command to retrieve the BGP route table. Examine the routeStatus field for the specific prefix. If the route appears in the output but the routeStatus is not set to active, the route is being filtered either by the on-premises router or by Cloud Router's import policies.
Prepare and test your skills
Prepare and test your skills
StudyCerts
StudyCerts