Key terms

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.

Google Cloud
Google Cloud is a suite of public cloud computing services offered by Google. For more information, see Google Cloud products.
project ID
The ID of your Google Cloud project. A project contains networking resources such as networks, subnets, and Cloud VPN gateways as described in the VPC network overview. For a description of the difference between project name, project ID, and project number, see Identifying projects. You can view the project ID in the Google Cloud console.

Cloud VPN terms

The following terms apply to Cloud VPN gateways and tunnels and gateways on your peer network.

Cloud VPN gateway
A virtual VPN gateway running in Google Cloud managed by Google, using a configuration that you specify in your project, and used only by you. Each Cloud VPN gateway is a regional resource that uses one or more regional external IP addresses. A Cloud VPN gateway can connect to a peer VPN gateway.
Classic VPN
The predecessor to HA VPN. For more information, see Types of Cloud VPN: Classic VPN.
HA VPN
Replaces Classic VPN with a gateway that provides a 99.99% availability SLA. For more information, see Types of Cloud VPN: HA VPN.
external VPN gateway
A gateway resource that you configure in Google Cloud for HA VPN that provides information to Google Cloud about your peer VPN gateway or gateways. Depending on the high availability recommendations from your peer VPN gateway vendor, you can create an external VPN gateway resource for the different types of peer VPN gateways described in Cloud VPN topologies.
peer VPN gateway
A gateway that is connected to a Cloud VPN gateway. A peer VPN gateway can be one of the following:
  • 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
remote peer IP address

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.

VPN tunnel
A VPN tunnel connects two VPN gateways and serves as a virtual medium through which encrypted traffic is passed. Two VPN tunnels must be established to create a connection between two VPN gateways: each tunnel defines the connection from the perspective of its gateway, and traffic can only pass after the pair of tunnels is established. A Cloud VPN tunnel is always associated with a specific Cloud VPN gateway resource.
connection
As defined for Google Cloud, a logical link between Cloud VPN and peer VPN locations as identified by a vpnGateway resource at one end, and an externalVpnGateway or another Google Cloud VpnGateway resource at the peer end. A connection also includes all the vpnTunnel resources and BGP sessions between the gateway resources.
Internet Key Exchange (IKE)
IKE is the protocol used for authentication and to negotiate a session key for encrypting traffic.
Cloud VPN gateway MTU
The size in bytes of the largest IP packet—including headers, data, and IPsec overhead—supported by a Cloud VPN tunnel.
Cloud VPN payload MTU
The size in bytes of the largest IP packet—including headers and data—that can be successfully encrypted and sent in a Cloud VPN tunnel without fragmentation. In other words, the original packet size not counting IPsec overhead.
HA VPN over Cloud Interconnect gateway MTU
The size in bytes of the largest IP packet—including headers, data, and IPsec overhead—supported by a HA VPN over Cloud Interconnect tunnel.
HA VPN over Cloud Interconnect payload MTU
The size in bytes of the largest IP packet—including headers and data—that can be successfully encrypted and sent in a HA VPN over Cloud Interconnect tunnel without fragmentation. In other words, the original packet size not counting Cloud Interconnect overhead and IPsec overhead.

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, Cross-Cloud Interconnect, or a combination thereof.

Cloud Interconnect elements

Interconnect connection

Applies to Dedicated Interconnect and Cross-Cloud Interconnect.

For Dedicated Interconnect

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.

For Cross-Cloud Interconnect

A specific physical connection between Google and the network of another cloud service provider (the remote cloud service provider). This connection exists in a single colocation facility or in adjoining facilities, where the networks of Google and the remote cloud service provider meet.

A single connection can be a single 10-Gbps link, a single 100-Gbps link, or, depending on what the remote cloud provider supports, a link bundle.

connection type
The type of Cloud Interconnect connection falls into one of three categories:
  • Dedicated Interconnect
  • Partner Interconnect
  • Cross-Cloud Interconnect
VLAN attachment

Applies to Dedicated Interconnect, Partner Interconnect, and Cross-Cloud Interconnect.

A VLAN (virtual local area network) attachment is a logical connection between an external network and a single region in your Virtual Private Cloud (VPC) network. In the Compute Engine API, the VLAN attachment is known as an interconnectAttachment resource.

When you create a VLAN attachment, you associate it with a project, a region, an existing or new Cloud Router, and an existing Cloud Interconnect connection. Then you configure a Border Gateway Protocol (BGP) session between the Cloud Router and your external router.

  • For Dedicated Interconnect, the VLAN attachment uses a dedicated connection that you create to reach your on-premises router.
  • For Partner Interconnect, the attachment uses a connection that your chosen partner sets up and manages.
  • For Cross-Cloud Interconnect, the attachment uses a connection that Google creates on your behalf between the networks of Google Cloud and your remote cloud service provider.

A VLAN attachment is not directly associated with a VPC network. However, it's indirectly tied to a single VPC network because a Cloud Router can be associated with only one network. Therefore, the VLAN attachment is tied to the network where the Cloud Router is located.

To fully use the bandwidth of a given Cloud Interconnect connection, you might need to create multiple VLAN attachments. Creating VLAN attachments with a combined bandwidth greater than the Cloud Interconnect connection doesn't give you more than the stated bandwidth of the connection. For example, consider the following:

  • To fully use the bandwidth of 2 x 10-Gbps Cloud Interconnect connections, you need a 20-Gbps VLAN attachment.
  • To fully use the bandwidth of 5 x 10-Gbps Cloud Interconnect connections, you need a 50-Gbps VLAN attachment.

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 Dedicated 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 Dedicated 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 data transfer bandwidth from Google Cloud to the colocation facility for the Interconnect connection, we recommend that you configure a data transfer rate limiter on your router for your connection. Configuring this limiter enables you to cap the maximum inbound data transfer 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.

For Cross-Cloud Interconnect

A VLAN attachment for Cross-Cloud Interconnect allocates a single 802.1Q VLAN on your Cross-Cloud Interconnect connection. The VLAN attachment and the associated Cloud Router link your connection to a specific VPC network. Because each Cross-Cloud Interconnect connection can support multiple VLAN attachments, you can access multiple VPC networks without creating multiple connections.

The following requirements apply:

  • When you associate a Cloud Router with your VLAN attachment, you associate the attachment with a VPC network. That network must be in the same project as the Cross-Cloud Interconnect connection.
  • The set of valid regions for an attachment depends on the locations supported by Google Cloud and by your remote cloud service provider.

You can select a capacity for each attachment. For a list of capacities, see the Pricing page. The default capacity is 10 Gbps. This setting affects the maximum bandwidth that the attachment can use. If you have multiple VLAN attachments, we recommend setting a capacity for each of them. Doing so can prevent any single attachment from using the entire bandwidth of the connection, which can cause packets to be dropped. The maximum bandwidth is approximate, so it's possible for an attachment to use more bandwidth than the selected capacity.

The capacity setting limits only the outbound data transfer bandwidth from Google Cloud to the colocation facility for the Cross-Cloud Interconnect connection. For this reason, we recommend that you configure an outbound data transfer rate limiter on the virtual router in your remote cloud. Configuring this limiter enables you to cap the maximum inbound data transfer bandwidth to your VPC network for traffic using that connection.

Cloud Router

Applies to Dedicated Interconnect, Partner Interconnect, and Cross-Cloud Interconnect.

Cloud Router uses Border Gateway Protocol (BGP) to dynamically exchange routes between your VPC network and your external network. Before you can create a VLAN attachment, you must create or select an existing Cloud Router in the VPC network that you want to connect to. You then use the Cloud Router to configure a BGP session with your external router.

For detailed information about Cloud Router, see the Cloud Router overview.

The BGP configuration of the Cloud Router depends on whether you're using Layer 2 or Layer 3 connectivity. Dedicated Interconnect and Cross-Cloud Interconnect use 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 external 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 advertised routes, 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's located.
  • If your VPC network uses global dynamic routing mode, Cloud Router advertises subnet routes in all regions.

Cloud Router also creates dynamic routes in your VPC network for destinations that it learns from your external router. If your VPC network uses regional dynamic routing mode, Cloud Router makes those routes available to only the region where it's located. If your network uses global dynamic routing mode, Cloud Router makes those routes available to all regions.

on-premises router

Applies to Dedicated Interconnect and Partner Interconnect.

The on-premises router is an external router that establishes a BGP session with Cloud Router. This connection lets you 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 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 uses to configure 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 Interconnect connections, see Layer 2 versus Layer 3 connectivity.

For information about configuring on-premises routers, see the following documents:

external router

Applies to Dedicated Interconnect, Partner Interconnect, and Cross-Cloud Interconnect.

An external router is a networking device that provides access to the network that you want to peer with. The external router can be one of the following:

Dataplane v1

Applies to Dedicated Interconnect, Partner Interconnect, and Cross-Cloud Interconnect.

The legacy version of Cloud Interconnect infrastructure. Dataplane v1 is being replaced by Dataplane v2. While the migration is occurring, however, some VLAN attachments might still operate on Dataplane v1.

Dataplane v2

Applies to Dedicated Interconnect, Partner Interconnect, and Cross-Cloud Interconnect.

Cloud Interconnect Dataplane v2 is an improved implementation of the 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.

All new VLAN attachments that you create in regions available to Cloud Interconnect are automatically provisioned on Dataplane v2.

To see which regions are available for Cloud Interconnect, see the locations table for Dedicated Interconnect or see the list of service providers for Partner Interconnect.

To check the Dataplane version of an existing VLAN attachment, see one of the following documents:

Cloud Interconnect locations

connection location or colocation facility

Applies to Dedicated Interconnect, with notes for Partner Interconnect and Cross-Cloud Interconnect.

The colocation facility where a physical Cloud 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 connection location supports a subset of Google Cloud regions. For example, lga-zone1-16 supports VLAN attachments in the regions northamerica-northeast1, northamerica-northeast2, us-central1, us-east1, us-east4, us-east5, us-south1, us-west1, us-west2, us-west3, and us-west4.

For a list of all locations and their supported regions, see All colocation facilities.

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.

When using Cross-Cloud Interconnect, you must choose a location that your remote cloud service provider supports:

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 us-east1 and us-west1. For a list of Google Cloud regions, see the Regions and zones page.

service provider

Applies to Partner Interconnect.

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.

metropolitan area (metro)

Applies to Dedicated Interconnect, Partner Interconnect, and Cross-Cloud Interconnect.

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 outbound data transfer costs. Otherwise, traffic would have to travel between regions to reach your VM instances or on-premises network.

For more information for Dedicated Interconnect, see All colocation facilities.

metro availability zone

Applies to Dedicated Interconnect, Partner Interconnect, and Cross-Cloud Interconnect.

An older term for edge availability domain.

edge availability domain

Applies to Dedicated Interconnect, Partner Interconnect, and Cross-Cloud Interconnect.

Each metropolitan area has two independent failure domains called edge availability domains. The two edge availability domains are named zone1 and zone2. 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 whole metro, and do not cross metros. To maintain availability and an SLA, you must build duplicate Cloud Interconnect connections by picking two connection locations in the same metro that are in different edge availability domains. Some metros offer more than two locations, but there are still only two edge availability domains in the metro. For example, building connections in locations dfw-zone1-4 and dfw-zone1-505 does not provide redundancy because both locations are in the zone1 edge availability domain. Building them in dfw-zone1-4 and dfw-zone2-4 provides redundancy because the locations are in different edge availability domains.

Maintenance windows are not coordinated across metros. For example, the edge availability domains dfw-zone1-4 and ord-zone1-7 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 production topology.

Provisioning and configuration

Letter of Authorization and Connecting Facility Assignment (LOA-CFA)

Applies to Dedicated Interconnect.

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 to PROVISIONED, the LOA-CFA is no longer valid, necessary, or available in the Google Cloud console.

For more information about the provisioning flow, see Dedicated Interconnect provisioning overview.

pairing key

Applies to Partner Interconnect.

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:
<random>/<vlan-attachment-region>/<edge-availability-domain>.

For example, 7e51371e-72a3-40b5-b844-2e3efefaee59/us-central1/2 is a pairing key for a VLAN attachment in the us-central1 region and edge availability domain 2.

remote cloud service provider

Applies to Cross-Cloud Interconnect.

Another cloud service provider, in addition to Google Cloud, where you might have networking resources.

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.

Border Gateway Protocol (BGP)
An exterior gateway routing protocol standardized by the Internet Engineering Task Force (IETF) in RFC 1722. BGP automatically exchanges routing and reachability information among autonomous systems on the internet. Your device is BGP-capable if it can perform BGP routing, which means that you can enable the BGP protocol on it and assign it a BGP IP address and an autonomous system number. To determine if your device supports BGP, see the vendor information for your device or contact your device's vendor.
autonomous system (AS)
A collection of connected IP routing prefixes under the control of a single administrative entity or domain that presents a common routing policy to the internet, such as an internet service provider (ISP), a large company, or a university.
autonomous system number (ASN)
A unique identifier allocated to each autonomous system that uses BGP routing. For more information, see RFC 7300.
MD5 authentication
A method of BGP peer authentication that uses the MD5 message-digest algorithm. When you use this approach, BGP peers must use the same authentication key, or a connection cannot be established between them. Later, every segment routed between the peers is verified. For more information about MD5 authentication, see RFC 2385. To find out whether your device supports MD5 authentication, see the vendor information for the device or contact the vendor. To get support with using Cloud Router MD5 authentication, see Support.