GCP Partner Interconnect Troubleshooting

Google Cloud Partner Interconnect issues can originate on the Tata Communications side, on the Google Cloud side, or sit ambiguously between the two. Use the triage below to place the symptom, then follow the diagnostic steps. For ambiguous issues, start with Tata Communications support.

Triage

Symptom points to	Examples
Tata Communications side – raise a TC^x service request	Attachment not provisioning after the pairing key is shared; BGP peering address unreachable
Google Cloud side – handle in your console	VLAN attachment or Cloud Router errors; VPC route or firewall issues
Ambiguous – start with us	BGP up but no routes received; intermittent loss; asymmetric routing

Tata Communications-side issues

Attachment not provisioning

The VLAN attachment stays pending after you shared the pairing key.

Diagnostic steps: Confirm you shared the correct pairing key with Tata Communications via the TC^x Portal (the key activates the attachment); confirm the pairing key zone matches your intended port (Zone 1 key /1 for the primary, Zone 2 key /2 for the secondary); confirm the region is supported.

Resolution: Raise a TC^x service request with the pairing key and order details.

BGP peering address unreachable

This applies where you run the CPE session (Layer 2). On the default Layer 3 delivery Google assigns the peering IPs and Tata Communications runs the session.

You cannot reach the Google peering IP from your CPE.

Diagnostic steps: Confirm the VLAN ID matches what Google assigned on the attachment; confirm you are using the peering addresses Google allocated from its link-local range; confirm no customer-side ACL is blocking them.

Resolution: If VLAN and IPs are correct, raise a TC^x service request.

BGP session not establishing

Session in Idle or Active, never Established.

Diagnostic steps: On the default Layer 3 delivery the EBGP runs between Tata Communications (ASN 4755) and Google (ASN 16550) and is brought up by Tata Communications; if peering does not come up, confirm the VLAN attachment is activated and the pairing key was shared, then raise a TC^x service request. On Layer 2, verify the remote ASN is 16550 and your local ASN matches your Cloud Router; verify MD5 if used.

Resolution: If ASN and MD5 are correct, raise a TC^x service request with your sanitised BGP configuration excerpt.

Intermittent packet loss

Connection up but periodic loss.

Diagnostic steps: Check whether utilisation is at or near the attachment’s bandwidth (Tata Communications can confirm), keeping Google’s oversubscription guidance (up to 3×) in mind; check interface errors on your CPE.

Resolution: If utilisation is consistently high, request a bandwidth change; otherwise raise a TC^x service request.

Google Cloud-side issues

Symptom	Where to look
VLAN attachment errors	Attachment state and Cloud Router association in the Google Cloud console
Routes received but traffic doesn’t reach resources	VPC routes, firewall rules, route advertisement on the Cloud Router
Cloud Router not advertising expected subnets	Cloud Router custom route advertisements

Ambiguous issues – start with Tata Communications support

For symptoms that could be on either side – BGP established but no routes received, one-way (asymmetric) traffic, MTU-related drops, or intermittent reachability – Raise a TC^x service request with:

The pairing key and region
Timestamps when the issue began
Your CPE BGP session state (sanitised of MD5 keys)
A description of the affected traffic flow.

Need more help?

If this guide doesn’t resolve the issue or you’re unsure which side it’s on, contact Tata Communications support – we will engage Google where the diagnosis points to the Google Cloud side.