Routing control and packet delivery need separate evidence
BGP exchanges routing information between peers. A Cloud Router session can fail before routes are learned, or a session can be established while the required prefix is absent. Neither a green session nor a list of routes alone demonstrates that an application request reaches its destination and returns.
Google's troubleshooting guidance begins with the underlying connection and peer settings. For a VPN-backed relationship, an unavailable tunnel is a different starting point from an established tunnel whose BGP session is failing. Keep transport, peer negotiation, route exchange and host traffic as distinct stages in the incident timeline.
Prepare the routing relationship
- Record the Cloud Router, peer owner, connection design, peer addresses and autonomous-system settings. Maintain an approved list of prefixes that should be advertised and learned.
- Define routing scope and any intentional filters or policy. Identify who may approve a new advertised prefix and who checks its effect on the peer network.
- Rehearse the intended route and a deliberately out-of-scope route in an approved test design. Keep a known-good configuration and a shared test flow for both teams.
For beginners, BGP is a control-plane relationship. It tells routers about reachability but does not grant application firewall access. An established session should therefore be followed by route inspection and a host-level application test.
Illustrative incident: a new subnet is not advertised
A platform adds an application subnet but does not include the intended prefix in its approved advertisement configuration. The existing BGP session remains established, and older subnets work. This is an illustrative scenario. Restarting the peer session cannot substitute for reviewing whether the new prefix is meant to be advertised.
Compare the expected and observed routing contract
First inspect transport and session status, then the relevant learned and advertised routes. Compare both sides at the same time, including any recent network change. Use sanitized prefix and resource evidence without copying authentication material into an incident record.
| Observation | Evidence | Investigation |
|---|---|---|
| Transport is unavailable | Tunnel or underlying connection status | Transport owner |
| Transport works, BGP does not establish | Peer settings and router logs | BGP relationship |
| Session established, required prefix absent | Advertised and learned route comparison | Route configuration |
| Prefix present, application fails | Host path, firewall and return route | Data-plane connectivity |
Avoid a broad default-route advertisement as a diagnostic shortcut. It can redirect unrelated traffic and change failure behavior across the hybrid environment. Establish the exact intended route before considering a change.
Repair the intended prefix and prove the host flow
For the illustrative subnet addition, have both network owners approve the narrow advertisement correction. Retain the previous configuration and review competing routes before applying it. Confirm the peer learns the intended prefix and unrelated routing remains as designed.
Test the actual application protocol from a representative host, including its return path. Repeat the previously working flow as a regression test. Rehearse controlled session interruption outside production where feasible, recording convergence and application behavior rather than promising recovery from the BGP status alone.
Operating objective and BGP SOP
Measure accepted application connectivity and route convergence separately. An illustrative internal gate could require a prefix change to pass expected-route, unexpected-route and application-flow checks before closure. This is a change-acceptance rule, not a Cloud Router SLA or a universal convergence-time guarantee.
The SOP should retain router, peer, transport, expected prefix, observed route, configuration diff and reversal trigger. Escalate ambiguous competing routes to both owners. Keep the prefix inventory current after subnet changes so the next incident begins with an explicit routing contract rather than assumptions about what a green BGP session means.
See Clouvenix engineering support for scope based on documented requirements and acceptance evidence.
Technical reference
Google Cloud: troubleshoot BGP sessions. Reviewed 19 October 2026; check prerequisites against the product configuration and software version in use.