Optimal route advertisement for Network Connectivity Center

This document applies to topologies with redundant Interconnect connections where the following is true:

  • One connection is to a supported (data transfer enabled) Network Connectivity Center location and is attached to a spoke.
  • One connection is to an unsupported (data transfer disabled) location and cannot be attached to a spoke.

In this scenario, to avoid overlapping address prefix announcements for traffic through a Network Connectivity Center hub and traffic outside of the hub, you must configure your on-premises router according to one of the options in the Configuration options section of this document.

Example topology

Use the following example topology as a reference for the configuration options described in the next section. While this example uses Dedicated Interconnect, the guidance in this document also applies to topologies with Partner Interconnect.

Example topology that has an Interconnect connection in an unsupported location
Example topology that has an Interconnect connection in an unsupported location (click to enlarge)

In this topology, on-premises network A has redundant Interconnect connections to Mumbai and Singapore, including:

  • A VLAN attachment to Mumbai, attached to Spoke A.
  • A VLAN attachment to Singapore, not attached to Spoke A because Singapore is not a supported location for Network Connectivity Center.

On-premises network B has a single connection to Australia. In this example, the connection is an HA VPN that is attached to Spoke B.

Configuration options

Given the previously described example topology, where only one of the redundant Interconnect connections can be attached to a Network Connectivity Center spoke, this section describes how to configure your on-premises router to suit the traffic requirements between your on-premises networks and Google Cloud.

Option 1 is optimal for non-hub traffic, but does not support connectivity through the hub. Option 2 allows for both hub and non-hub traffic, but is sub-optimal for non-hub traffic.

Option 1: Same MED values: does not work for hub traffic

In this configuration, the router for on-premises network A advertises 10.1/16 with a MED of 100 to both Mumbai and Singapore.

In this case, the Cloud Router in Australia sees the advertisement coming from Singapore as the best path. This is because Singapore is geographically closer to Australia and has a lower region-to-region cost. For information about region-to-region cost, see Advertised prefixes and priorities in the Cloud Router documentation.

However, because this is not a path through the Network Connectivity Center hub, Cloud Router does not re-advertise 10.1/16 to on-premises network B for hub traffic. This means that there is no connectivity configured through the hub.

Option 2: Different MED values: optimal for hub traffic, sub-optimal for non-hub traffic

In this configuration, the router for on-premises network A advertises 10.1/16 by using the following:

  • A MED of 100 to Mumbai
  • A MED of 20000 to Singapore

In this case, the Cloud Router in Australia does the following:

  • Sees the advertisement coming from Mumbai as the best path.
  • Programs the path to Mumbai as the data path.
  • Re-advertises 10.1/16 to on-premises network B for both Network Connectivity Center and non-Network Connectivity Center traffic.

This means that Network Connectivity Center traffic travels through Mumbai; however, non-Network Connectivity Center traffic also takes this sub-optimal path.

This scenario depends on configuring the router for on-premises network A to advertise 10.1/16 to Singapore with a sufficiently higher MED value so that the region-to-region cost adjustments don't cause Singapore to appear as a better path. The MED advertised to Singapore must be 10,200 larger than the MED advertised to Mumbai. For more information, see Advertised prefixes and priorities.

What's next