This page provides key terminology that applies to Network Connectivity products. Review these terms to better understand how each product works.
Google Cloud terms
The following terminology applies to Google Cloud and its features.
Cloud VPN terms
The following terms apply to Cloud VPN gateways and tunnels and gateways on your peer network.
- Another Cloud VPN gateway
- A VPN gateway hosted by another cloud provider such as AWS or Microsoft Azure
- An on-premises VPN device or VPN service
For an HA VPN gateway interface that connects to an external VPN gateway, the remote peer IP address is the IP address of the interface on the external VPN gateway that is used for the tunnel.
For an HA VPN gateway interface that connects to another HA VPN gateway, the remote peer IP address is the IP address of the other HA VPN gateway's interface that is used for the tunnel.
For Classic VPN, the remote peer IP address is the external IP address of the peer VPN gateway.
vpnGatewayresource at one end, and an
externalVpnGatewayor another Google Cloud
VpnGatewayresource at the peer end. A connection also includes all the
vpnTunnelresources and BGP sessions between the gateway resources.
Cloud Interconnect terms
The following key terminology describes the concepts on which Cloud Interconnect is built. Each section indicates whether a term applies to Dedicated Interconnect, Partner Interconnect, or both.
Cloud Interconnect elements
A specific physical connection between Google and your on-premises network. This connection exists in a colocation facility where your on-premises network and Google's network meet.
A single connection can be a single 10-Gbps link, a single 100-Gbps link, or a link bundle. If you have multiple connections to Google at different locations or to different devices, you must create separate Interconnect connections.
Also known as an interconnect attachment, or
resource in the Compute Engine API, a VLAN (virtual local area network) attachment
is a logical connection between your on-premises network and a single region in
your Virtual Private Cloud (VPC) network.
When you create a VLAN attachment, you associate it with a project, a region, an existing or new Cloud Router, and an existing Interconnect connection. Cloud Router then establishes a Border Gateway Protocol (BGP) session over the attachment to your on-premises router.
- For Dedicated Interconnect, the VLAN attachment uses a dedicated connection that you create to your on-premises router.
- For Partner Interconnect, the attachment uses a connection that your chosen partner sets up and manages.
Although a VLAN attachment used with Dedicated Interconnect or Partner Interconnect is not directly associated with a VPC network, it is indirectly tied to a single network because a Cloud Router can only be associated with a single VPC network. Therefore, the VLAN attachment is tied to the network that its Cloud Router is located in.
For Dedicated Interconnect
A VLAN attachment for Dedicated Interconnect allocates a single 802.1Q VLAN on your Dedicated Interconnect connection and connects it to a specific VPC network. Because each connection for Dedicated Interconnect supports multiple VLAN attachments, you can access multiple VPC networks without creating multiple connections.
Each attachment that you create is associated with a VPC network and a Google Cloud region:
- When you associate an attachment for Dedicated Interconnect with a VPC network, this network must be in a project in the same organization as the project that contains the Interconnect connection.
- The set of valid regions for an attachment depends on the colocation facility used by the Cloud Interconnect.
You can set the capacity of each attachment. For a list of capacities, see the Pricing page. The default attachment capacity is 10 Gbps.
The capacity setting limits the maximum bandwidth that an attachment can use. If you have multiple attachments on a single Interconnect connection, the capacity limitation might be helpful in cases where you want to prevent network congestion on your connection. The maximum bandwidth is approximate, so it's possible for an attachment to use more bandwidth than the selected capacity.
Because the capacity setting only limits the egress bandwidth from Google Cloud to the colocation facility for the Interconnect connection, we recommend that you configure an egress rate limiter on your router for your connection. Configuring this limiter enables you to cap the maximum ingress bandwidth to your VPC network for traffic using that connection.
For Partner Interconnect
To request Partner Interconnect connectivity from a service provider, you create a VLAN attachment in your Google Cloud project. The VLAN attachment generates a unique pairing key that you share with your service provider. The service provider uses the pairing key, along with your requested connection location and capacity, to complete the configuration of your VLAN attachment.
After your service provider configures the attachment, they allocate a specific 802.1q VLAN on your on-premises connection.
Cloud Router uses Border Gateway Protocol (BGP) to dynamically exchange routes between your VPC network and your on-premises network. Before you can create a VLAN attachment, you must create or use an existing Cloud Router in the VPC network that you want to connect to. You then associate the attachment with this Cloud Router. The Cloud Router creates a BGP session that connects to your on-premises (peer) router.
For detailed information about Cloud Router, see the overview.
The BGP configuration of the Cloud Router depends on whether you're using Layer 2 or Layer 3 connectivity. Dedicated Interconnect uses only Layer 2 connectivity. Partner Interconnect can use Layer 2 or Layer 3 connectivity.
- For Layer 2, you establish a BGP session between your Cloud Router and your on-premises router.
- For Layer 3, your service provider establishes a BGP session between your Cloud Router and their edge router. For more information, see Layer 2 versus Layer 3 connectivity.
Cloud Router advertises subnets in its VPC network and propagates learned routes to those subnets. Unless you configure custom route advertisements, Cloud Router advertises the following routes:
- If your VPC network uses regional dynamic routing mode, Cloud Router advertises subnet routes in the region where it is located.
- If your VPC network uses global dynamic routing mode, Cloud Router advertises subnet routes in all regions.
Cloud Router also creates custom dynamic routes in your VPC network for destinations that it learns from your on-premises (peer) router. According to the dynamic routing mode of the VPC network (regional or global), Cloud Router makes those routes available to only the Cloud Router's region or to all regions.
The on-premises router is the networking device that establishes a BGP session with Cloud Router. This connection allows you to exchange data between your on-premises network and your VPC network.
For Dedicated Interconnect, you manage the on-premises router, which is often physically located in the colocation facility where your Interconnect connection is provisioned. However, the device can be physically located in another facility, such as an office location where you manage networking equipment. You establish the BGP sessions between your on-premises router and Cloud Router.
For Partner Interconnect, an on-premises router is a device that either you or the service provider configures BGP sessions with Cloud Router.
- With Layer 2 Partner Interconnect connections, you configure the BGP session between your on-premises router and Cloud Router.
- With Layer 3 Partner Interconnect connections, your service provider manages the BGP session between their on-premises router and Cloud Router.
For more information about different partner connections, see Layer 2 versus Layer 3 connectivity.
For information about configuring on-premises routers, see the following documents:
Cloud Interconnect Dataplane v2 is a new implementation of Cloud Interconnect infrastructure. It is designed to provide increased reliability, performance, and functionality.
Certain Google Cloud networking features that work with Cloud Interconnect, such as Bidirectional Forwarding Detection (BFD) for Cloud Router, require that the VLAN attachments used with the feature run on Dataplane v2.
Google is migrating all existing VLAN attachments to use Dataplane v2 without any action required on your part. If you want to use a product feature that requires Dataplane v2 and need to update the version of an existing VLAN attachment, contact Google Cloud Support.
Cloud Interconnect locations
The colocation facility where a physical Interconnect connection is provisioned. This location is where your on-premises routing equipment meets Google's peering edge.
A colocation facility is where Google has a point of presence (PoP), enabling you to connect your on-premises network with Google's network. In the colocation facility, you work with the facility provider to provision your routing equipment before using Dedicated Interconnect.
Each Interconnect connection location supports a subset of Google Cloud regions.
lga-zone1-16 supports VLAN attachments in the regions
For a list of all locations and their supported regions, see Choosing colocation facility locations.
When using Partner Interconnect, partners have already set up connections to Google's network. The set of locations varies, depending on which partner you choose. When you set up your VLAN attachment, you can select from the partner's available locations. For a list of locations that each service provider supports, see the Service providers page.
Each partner location supports a subset of Google Cloud regions. These supported regions
are where you can connect to your Cloud Routers and associated VLAN attachments.
For example, if you choose the
Ashburn location, you can reach all the
North American regions, such as
For a list of Google Cloud regions, see the
Regions and zones page.
A network service provider for Partner Interconnect. To use Partner Interconnect, you must connect to a supported service provider. The service provider provides connectivity between your on-premises network and your VPC network.
The city where a colocation facility is located.
The metro that you choose depends on the location of your on-premises network and the location of your Compute Engine VM instances (their Google Cloud region). Typically, you might want to pick a metro that's geographically close to your on-premises network to reduce latency. When configuring a redundant connection, you might choose an additional metro that is further away.
Each metro supports a subset of Google Cloud regions. You
can create VLAN attachments only in these supported regions. For example,
if you pick a facility in
Ashburn, you can only create VLAN attachments
in the North American regions. Assuming that your VM instances are also located in these
regions, you can create VLAN attachments in the same regions as your VMs to reduce latency
and egress costs. Otherwise, traffic would have to travel between regions to reach your
VM instances or on-premises network.
For more information, see Choosing colocation facility locations.
An older term for edge availability domain.
Each metropolitan area has at least two zones called edge availability domains. These domains provide isolation during scheduled maintenance, which means that two domains in the same metro are not down for maintenance at the same time. This isolation is important when you're building for redundancy.
Edge availability domains span a single metro, not across metros. To maintain
availability and an SLA,
you must build duplicate Interconnect connections in different edge availability domains
in the same metro. For example, building connections in
dfw-zone2-4 provides redundancy across different edge availability domains, whereas
building them in
does not because they are in the same edge availability domain.
Maintenance windows are not coordinated across metros. For example, the edge
could experience overlapping maintenance events. When connecting to multiple metros for
redundancy, it is important to connect to different edge availability domains in each of those
metros, as described in the
Provisioning and configuration
An LOA-CFA identifies the connection ports that Google has assigned for your Dedicated Interconnect connection, and grants permission for a vendor in a colocation facility to connect to them. LOA-CFA documents are required when you order Dedicated Interconnect connections in a colocation facility.
When you order Dedicated Interconnect connections, Google allocates resources
for your connections and then generates an LOA-CFA document for each one. The LOA-CFA
lists the demarcation points that Google allocated for your connections.
Submit this form to the facility vendor to provision connections between
Google's equipment and your own. After the status of a connection changes
PROVISIONED, the LOA-CFA is no longer valid, necessary, or available
in the Google Cloud console.
For more information about the provisioning flow, see the Dedicated Interconnect Provisioning overview.
A unique identifier that lets service providers identify particular VLAN attachments without anyone sharing potentially sensitive information about their VPC network or Google Cloud project. Pairing keys are used only for Partner Interconnect.
Treat the pairing key as sensitive information until your VLAN attachment is configured. If it's discovered, it's possible for other parties to use it to connect to your network. The key is for one-time use and can't be modified. If you need a new pairing key, delete your VLAN attachment and create a new one.
Pairing keys use the following format:
a pairing key for a VLAN attachment in the
region and edge availability domain
Border Gateway Protocol (BGP) terms
The following terminology applies to the Border Gateway Protocol (BGP), which Cloud VPN and Cloud Interconnect use for dynamic routing.