Troubleshooting

The troubleshooting guide can help you solve common issues that you might encounter when using Cloud Interconnect:

For answers to common questions about Cloud Interconnect architecture and features, see the Cloud Interconnect FAQ.

General troubleshooting

Can't connect to resources in other regions

By default, Virtual Private Cloud (VPC) networks are regional, meaning that Cloud Router advertises only the subnets in its region. To connect to other regions, set the dynamic routing mode of your VPC network to global so that Cloud Router can advertise all subnets.

For more information, see Dynamic routing mode in the Cloud Router documentation.

Can't ping Cloud Router

If you can't ping Cloud Router, find your product in the following table and perform the troubleshooting steps for that product.

Troubleshooting steps to follow Dedicated Interconnect Partner Interconnect with L3 partner Partner Interconnect with L2 partner
For Partner Interconnect, the Cloud Router might never be pingable as some partners filter traffic to the IP range (169.254.0.0/16) for Cloud Router. For L3 partners, BGP is auto-configured by the partner. Contact your partner if BGP doesn't come up. Not applicable Yes Not applicable
Verify that your local device has learned the correct MAC address for the Google Cloud side of the connection. For more information, see Troubleshooting ARP. Yes Not applicable Not applicable
Verify that your Cloud Router has an interface and a BGP peer. Cloud Router is not pingable unless the interface and BGP peer are fully configured, including the remote ASN.
  • For Dedicated Interconnect, see BGP session not working.
  • For L2 Partner Interconnect, Google has added the interface and BGP peer for Cloud Router automatically, but you must configure the remote ASN.
Yes Not applicable Yes

Troubleshooting ARP

For Dedicated Interconnect, you can find the correct MAC address by entering the following gcloud command:

  gcloud compute interconnects get-diagnostics [INTERCONNECT_NAME]

The googleSystemID contains the MAC address that should be present in your device's ARP table for IP addresses assigned to Cloud Router.

  result:
    links:
    — circuitId: SAMPLE-0
      googleDemarc: sample-local-demarc-0
      lacpStatus:
        googleSystemId: ''
        neighborSystemId: ''
        state: DETACHED
      receivingOpticalPower:
        value: 0.0
      transmittingOpticalPower:
        value: 0.0
    macAddress: 00:00:00:00:00:00

If your device has not learned a MAC address, verify that the correct VLAN ID and IP address are configured on the sub-interface.

If you see the wrong MAC address on your device, verify that you have not bridged the layer two segments of two VLAN attachments. The Google Cloud side of the Interconnect connection is configured with ip proxy-arp, which replies to all ARP requests and can cause your on-premises router to learn incorrect ARP entries.

Can't create VLAN attachment

If you attempt to create a VLAN attachment that violates an organization policy, you see an error message. See the following example error message from running gcloud compute interconnects attachments partner create:

ERROR: (gcloud.compute.interconnects.attachments.partner.create) Could not fetch resource:
- Constraint constraints/compute.restrictPartnerInterconnectUsage violated for projects/example-project. projects/example-project/global/networks/example-network is not allowed to use the Partner Interconnect.

See Restricting Cloud Interconnect usage and contact your organization admistrator for information.

Sharing connections with other projects in my organization

Use Shared VPC to share a connection, such as a VLAN attachment or a Dedicated Interconnect in a host project.

Getting diagnostics

To get current, detailed technical information about the Google Cloud side of a Dedicated Interconnect connection on demand, see Getting diagnostics.

Dedicated Interconnect

Google can't ping you during the Cloud Interconnect provisioning process

  • Check that you're using the correct IP & LACP configuration. During the testing process, Google sends you different test IP configurations for your on-premises router, depending on whether you order a single-link or multiple-link bundle. Don't configure VLAN attachments for either of these tests.
  1. The first set of IP addresses Google sends is for testing connectivity on each individual link. You must configure the test IP addresses on every physical link (without LACP configured), as instructed in the emails that Google sent you. Google must ping all of those IPs successfully before this first test will pass.
  2. For the second test, remove all of the IP addresses from the first test. Configure the port channel with LACP even if your interconnect has only one link. Google pings the port channel address. Don't modify the LACP configuration of your port channel after the interconnect has passed the final test. However, you should remove the test IP address from the port channel interface.
  1. Google sends the final production IP for testing connectivity. You must configure the IP address on the bundle interface (with LACP configured, either active or passive mode), as instructed in the email that Google sent you. Google must ping the bundle interface IP successfully before this test will pass. Configure the port channel with LACP even if your interconnect has only one link.

You can't ping Cloud Router

  • Check that you can ping Google's port channel IP address. The IP address is the googleIpAddress value when you view the interconnect details.
  • Check that you have the correct VLAN on your on-premises router's subinterface. The VLAN information should match the information provided by the VLAN attachment.
  • Check that you have the right IP address on your on-premises router's subinterface. When you create a VLAN attachment, it allocates a pair of link local IP addresses. One is for an interface on a Cloud Router (cloudRouterIpAddress) and the other is for a subinterface on your on-premises router's port channel, not the port channel itself (customerRouterIpAddress).
  • If you're testing the performance of your VLAN attachments, don't ping Cloud Router. Instead, create and then use a Compute Engine VM instance in your VPC network. For more information, see Performance testing.

BGP session not working

  • Enable multi-hop BGP on your on-premises router with at least two hops.
  • Check that you have the correct neighbor IP address configured on your on-premises router. Use the BGP peer IP address (cloudRouterIpAddress) that was allocated by the VLAN attachment.
  • Check that the local ASN configuration on your on-premises router matches the peer ASN on the Cloud Router and vice versa.
  • Each attachment is allocated a unique /29 CIDR from 169.254.0.0/16, within your VPC network. One IP address in the /29 CIDR is allocated for the Cloud Router, the other for your on-premises router. Check that the correct IPs are allocated for your on-premise router interface and its BGP neighbor. A common mistake is to configure a /30 on your on-premises router interface, instead of a /29. All other addresses in the /29 CIDR are reserved by Google Cloud. Make sure that you have not allocated any other IPs from this CIDR to the VLAN attachment interface on your router.

Can't reach VMs in your VPC network

  • Check that you can ping the port channel and VLAN attachment.
  • Check that your BGP session is active.
  • Check that routes are being advertised and received by your on-premises router.
  • Set the MTU size to 1440 on your on-premises router.

Performance testing over your VLAN attachments

If you need to test the performance of your VLAN attachments, use a VM in your VPC network. Add the performance tools that you require on the VM. Don't use the Cloud Router link-local IP address to test for latency, such as ICMP ping or path MTU. Using Cloud Router can give unpredictable results.

Partner Interconnect

BGP session not working (layer 2 connections)

  • Check that your on-premises router has been configured with a BGP session to your Cloud Routers.
  • Enable multi-hop BGP on your on-premises router with at least two hops.
  • Check that you have the correct neighbor IP address configured on your on-premises router. Use the BGP peer IP address (cloudRouterIpAddress) that was allocated by the VLAN attachment.
  • Check that the local ASN configuration on your on-premises router matches the peer ASN on the Cloud Router (16550) and vice versa.

BGP session not working (layer 3 connections)

  • Your Cloud Router must be configured with your service provider's ASN. Reach out to your service provider for assistance.

You can't ping Cloud Router (layer 2 connections)

  • Check that you have the correct VLAN attachment on your on-premises router's subinterface. The VLAN attachment information should match the information provided by your service provider.
  • Check that you have the right IP address on your on-premises router's subinterface. After your service provider configures your VLAN attachment, the attachment allocates a pair of link local IP addresses. One is for an interface on the associated Cloud Router (cloudRouterIpAddress) and the other is for a subinterface on your on-premises router's port channel, not the port channel itself (customerRouterIpAddress).
  • If you're testing the performance of your attachments, don't ping Cloud Router Instead, create and then use a VM in your VPC network. For more information, see Performance testing.

You can't send and learn MED values over an L3 Partner Interconnect connection

If you are using a Partner Interconnect connection where a Layer 3 Partner handles BGP for you, then Cloud Router can't learn MED values from your on-premises router or send MED values to that router. This is because MED values can't pass through autonomous systems. This means that, over this type of connection, you can't set priorities for routes advertised by Cloud Router to your on-premises router, and you can't set route priorities for routes advertised by your on-premises router to your VPC network.

All other issues

Reach out to your service provider for additional assistance. If needed, your service provider will reach out to Google to fix issues related to Google's side of the network.