This page describes the migration options from VPC Network Peering and HA VPN to Virtual Private Cloud (VPC) spokes within Network Connectivity Center.
Migrate from VPC Network Peering to Network Connectivity Center star topology
To migrate from VPC Network Peering to a Network Connectivity Center star topology configuration, which is a multipoint topology, you must configure the Network Connectivity Center hub for star topology. If the existing VPC Network Peering topology is in a hub and spoke or full mesh design, you can implement Network Connectivity Center star topology to group Network Connectivity Center VPC spokes into a center group or an edge group.
Choose one of the following two possible scenarios depending on the topology you choose post migration:
- Migrate from VPC Network Peering hub and spoke topology to Network Connectivity Center star topology
- Migrate from VPC Network Peering full mesh topology to Network Connectivity Center star topology
Migrate from VPC Network Peering hub and spoke topology to Network Connectivity Center star topology
If you have a multipoint topology with a routing VPC network with hybrid attachments that is connected to workload VPC networks through VPC Network Peering, follow these migration steps.
- Create a new Network Connectivity Center hub with a star topology configuration. Leave the existing hybrid connectivity and the routing VPC intact.
- Create a new routing VPC network and attach it as a spoke to the Network Connectivity Center hub that you created. Make sure it is mapped to the center group.
- Create a new VLAN attachment from existing Cloud Interconnect connections. You can also create new HA VPN tunnels on a new gateway. Connect the VLAN attachment or tunnel as a hybrid spoke to join the Network Connectivity Center hub that you created in step 1.
- After you have the new routing VPC network connected to your on-premises network using BGP and you're advertising all the dynamic routes to the new star topology hub, you can configure your workload VPC networks that are in your VPC Network Peering topology, as part of the edge group VPC spokes to the star topology hub.
If two workload VPC networks are connected together with VPC Network Peering, they can't be configured as Network Connectivity Center VPC spokes. Configuring the VPC networks as Network Connectivity Center VPC spokes that belong to an edge group, removes any conflicts with VPC Network Peering because Network Connectivity Center doesn't directly connect these VPC networks together. Network Connectivity Center preserves the existing VPC Network Peering connection. The legacy hub VPC network isn't added to Network Connectivity Center; only the workload VPC networks are added to Network Connectivity Center.
When you are ready to cutover, you can steer traffic by changing the MED value being advertised from the on-premise router to steer traffic to the new Network Connectivity Center star topology hub.
To connect additional VPC network to resources in the center group, you can add them as workload VPC spokes to the edge group, which enables further growth using Network Connectivity Center.
Migrate from VPC Network Peering mesh topology to Network Connectivity Center star topology
Suppose that you have two legacy workload VPC networks VPC1
and VPC2
that are connected through VPC Network Peering to each other
and to a routing VPC network, where all three
VPC networks are fully meshed.
Network Connectivity Center star topology edge groups allow existing VPC networks that are connected with VPC peering to join the Network Connectivity Center hub as a VPC spoke.
To migrate the workload VPC networks to Network Connectivity Center star topology, follow these steps:
- Create a new Network Connectivity Center hub configured with star topology configuration. To prevent disruption to production traffic, leave the existing hybrid connectivity and routing VPC network intact.
- Create a new VLAN attachment and connect it to the new routing VPC network that you created. Add this VPC network and VLAN attachment as spokes of the Network Connectivity Center hub.
- Add the legacy workload VPC networks
VPC1
andVPC2
to the edge group. When configured to be part of the center group, new VPC spokes use the data path established by Network Connectivity Center and not VPC Network Peering. - To steer traffic from the legacy routing VPC network to the new Network Connectivity Center connected path, lower the MED values for the legacy VPC network.
- Remove the legacy VPC Network Peering that is connected to your on-premises network.
- Add any new workload VPC networks to the center group. They are
automatically connected to workload
VPC1
andVPC2
.VPC1
andVPC2
remain connected to each other through VPC Network Peering. All of the VPC networks now have full mesh connectivity between each other.
In this scenario, you don't need to disconnect the legacy VPC networks from VPC Network Peering. Existing VPC Network Peering peering between workload VPC networks in production remains intact and not subject to disruption.
However, you can add new VPCs to the center group to enable further growth using Network Connectivity Center.
Migrate from VPC Network Peering to full mesh topology
When your Network Connectivity Center hub is configured to use the default mesh topology and you migrate to VPC spokes, the topology resulting from the migration is also a full mesh topology, which means that every VPC spoke is connected to every other VPC spoke.
For existing brownfield hub-and-spoke network topology deployments with Virtual Private Cloud (VPC) peering, migrating directly to VPC spokes can cause disruption to existing sessions. If you attempt to configure a VPC network pair as spokes, the Network Connectivity Center hub detects the existing VPC peering and generates an error.
You can choose one of the following two migration options:
- Migrate with some downtime of existing VPC peering sessions
- Migrate with zero downtime by using HA VPN
Migrate with downtime of existing VPC peering sessions
If your organization can support a change management window that disrupts VPC-to-VPC communication for a brief window of time, follow these steps.
- Schedule a downtime for the migration process.
- Delete existing VPC peering.
- Configure VPCs as Network Connectivity Center spokes. This enables full mesh connectivity.
Network Connectivity Center ensures that between any pair of VPC networks, there is no existing peering connection.
Migrate with zero downtime by using HA VPN
If your business cannot afford downtime, start your migration by following these steps.
- Configure a new HA VPN
between two peered VPC networks, for example
VPC1
andVPC2
. - Delete the existing VPC Network Peering between
VPC1
andVPC2
. During this time, packets traverse the HA VPN tunnels and inter-VPC connectivity is sustained. - Configure the two VPCs,
VPC1
andVPC2
, as Network Connectivity Center spokes. For detailed instructions about how to create a VPC spoke, see Propose a spoke. This enables full mesh connectivity. - Delete the HA VPN tunnels.
Migrate from HA VPN
If you are an existing customer using HA VPN tunnels to enable inter-VPC communication, there are two migration patterns available that depend on your existing deployment. Start by determining if the Cloud VPN tunnels are configured as Network Connectivity Center hybrid spokes or standalone HA VPN tunnels.
If the existing Cloud VPN tunnels are configured as Network Connectivity Center hybrid spokes and you have an existing Network Connectivity Center hub,
Hub1
, that you want to migrate, follow these steps.- Create a new Network Connectivity Center hub,
Hub2
, to support inter-VPC communication. Delete the existing Network Connectivity Center hub,
Hub1
, where the Cloud VPN tunnels are configured to hybrid spokes.For information about how to delete hubs and spokes, see Work with hubs and spokes.
- Create a new Network Connectivity Center hub,
If the existing HA VPN tunnels are not configured as Cloud VPN hybrid spokes, follow these steps.
What's next
- To create hubs and spokes, see Work with hubs and spokes.
- To view a list of partners whose solutions are integrated with Network Connectivity Center, see Network Connectivity Center partners.
- To find solutions for common issues, see Troubleshooting.
- To get details about API and
gcloud
commands, see APIs and reference.