GCP Routing and BGP Configuration

For Layer 3 Partner Interconnect, the EBGP session per VLAN attachment runs between the Tata Communications MPLS PE (ASN 4755) and Google (ASN 16550). The service is built as an L3VPN so your remote sites reach the VPC across the Tata Communications network; you do not run a BGP session from your on-premises CPE to Google on the default Layer 3 delivery. (On Layer 2, BGP is yours to manage directly with Google – see GCP L2VPN Services)

Google uses ASN 16550; Tata Communications uses ASN 4755. MD5 is optional and customer-supplied. Google offers private peering only and assigns the BGP peering addresses from its link-local range. Google also assigns the VLAN ID; there is no addressing for you to key in. Where two attachments are used, Tata Communications applies BGP path control to make one primary and the other secondary.

BGP parameters

Parameter	Value
Google ASN	16550 (default for Partner Interconnect)
Tata Communications ASN	4755 (fixed)
BGP sessions	One per VLAN attachment; a pair (Zone 1 + Zone 2) for redundancy
MD5 authentication	Optional; provided by the customer and shared on both sides if used
BGP peering addresses	Assigned by Google from its link-local range
VLAN ID	Assigned by Google on the attachment
Peering type	Private peering only

Private peering and the VRF-Lite model

Google Cloud Partner Interconnect offers private peering only – there is no public-peering option. The service is delivered as a Layer-3 Option-A NNI configured as VRF-Lite with a dedicated router ID, and built using L3VPN topologies (hub-and-spoke or full mesh) so your remote sites can reach the VPC. Google assigns the BGP peering addresses from its link-local range when the attachment is created.

Path control and redundancy

A redundant deployment uses two VLAN attachments – a Zone 1 attachment (pairing key ending /1) on Tata Communications’ primary router port and a Zone 2 attachment (/2) on the secondary, terminated on diversified PE routers. Google presents the redundant attachments as active/active; Tata Communications applies BGP Local Preference and AS-PATH prepending so one attachment is primary and the other secondary, giving predictable traffic flow with automatic failover. The specific path-control values are set by Tata Communications during provisioning.

Prefix policy

Outbound (to Google): advertise only the on-premises prefixes Google needs to reach. Sending a default route to Google is rarely correct.
Inbound (from Google): accept the VPC subnet prefixes advertised by the Cloud Router.

Quality of service

Google does not honour QoS markings on Partner Interconnect. On the Tata Communications backbone, a single class of service is applied to the circuit; you can select the class that suits your application, but only one class applies per circuit.

Multicast

Multicast is not supported on Google Cloud Partner Interconnect VLAN attachments.