Procedure for Using Enterprise Router and Central Network to Migrate the Network Set up Through a Cloud Connection

Step 1: Create Enterprise Routers and VPC Attachments

1. Create an enterprise router in the region of each service VPC.

   When creating each enterprise router, enable Default Route Table Association and Default Route Table Propagation. For details, see Table 5.

   For details, see Creating an Enterprise Router.

2. Attach each service VPC to the corresponding enterprise router.

   Do not enable Auto Add Routes and manually add routes with destinations set to the large CIDR block in the VPC route table.

   For details, see Creating VPC Attachments for the Enterprise Router.

3. In each enterprise router route table, check the route that points to the VPC attachment.

   In this example, Default Route Table Association and Default Route Table Propagation are enabled for the enterprise router, and routes with destinations set to VPC CIDR blocks are automatically added when you attach the VPCs to the enterprise router.

   For enterprise router route details, see Table 1 and Table 3.

   To view enterprise routes, see Viewing Routes.

4. In the VPC route tables, add routes destined for the large CIDR block with each enterprise router as the next hop.

   For VPC route details, see Table 1 and Table 2.

   In this example, the large CIDR block is 192.168.0.0/14, and the next hop is each enterprise router.

   For details, see Adding Routes to VPC Route Tables.

Step 2: Create a Central Network to Connect All Enterprise Routers

1. Create a central network and add the enterprise routers to the central network as attachments.

   For details about central network resources, see Table 5.

   For details, see Creating a Central Network.

2. On the Enterprise Router console, view the peering connection attachments.

   For details, see Viewing Details About an Attachment.

   If the status of the peering connection attachments is Normal, the attachments are available.

   When creating each enterprise router, enable Default Route Table Association and Default Route Table Propagation. In this way, after the central network policy is configured and all peering connections are established, the routes destined for the peer enterprise router will be automatically added.

Step 3: Assign Cross-Site Connection Bandwidths on the Central Network

To allow cross-region VPC communications, you need to assign cross-region connection bandwidths on the central network based on service requirements by referring to Table 5.

By default, Cloud Connect allocates 10 kbit/s of bandwidth for testing connectivity between regions. After peering connection attachments are created, you can verify the network connectivity.

To ensure your workloads run normally, you need to purchase global connection bandwidths and assign cross-site connection bandwidths.

1. Assign bandwidth from the purchased global connection bandwidth for the communications between region A and region B.

   For details, see Assigning a Cross-Site Connection Bandwidth.

2. Assign bandwidth from the purchased global connection bandwidth for the communications between region A and region C.
3. Assign bandwidth from the purchased global connection bandwidth for the communications between region B and region B.

Step 4: Verify the Communications Between VPCs

1. In each VPC route table, add a route whose destination is the IP address of an ECS in the peer VPC to check whether VPCs can communicate with each other through the enterprise routers and central network.

   For VPC route details, see Table 2.

   For details, see Adding Routes to VPC Route Tables.

2. Create an ECS in each VPC for verifying communications.

   For ECS resource details, see Table 5.

   For details, see Overview.

3. Log in to each ECS and take the following steps to verify the network connectivity:

   Multiple methods are available for logging in to an ECS. For details, see Logging In to an ECS.

   ping Private IP address of an ECS in a VPC

   For example, the private IP address of ECS-A is 192.169.0.148 (ensure that the private IP address of each ECS is added to the VPC route tables). To verify the communications between VPC-A and VPC-B, log in to ECS-A and run the following command:

   ping 192.169.0.148

   If information similar to the following is displayed, VPC-A can communicate with VPC-B through the central network and enterprise routers.

   [root@ecs-A ~]# ping 192.169.0.148
   PING 192.169.0.148 (192.169.0.148) 56(84) bytes of data.
   64 bytes from 192.169.0.148: icmp_seq=1 ttl=64 time=0.849 ms
   64 bytes from 192.169.0.148: icmp_seq=2 ttl=64 time=0.455 ms
   64 bytes from 192.169.0.148: icmp_seq=3 ttl=64 time=0.385 ms
   64 bytes from 192.169.0.148: icmp_seq=4 ttl=64 time=0.372 ms
   ...
   --- 192.169.0.148 ping statistics ---

4. Delete the routes for verifying communications from the VPC route tables.

   To delete a route, refer to Deleting a Route.

Step 5: Perform the Migration and Delete the Cloud Connection

1. Remove the VPCs from the cloud connection one by one.

   For details, see Removing a VPC.

2. After a VPC is removed, verify the communications between the VPC and other VPCs by referring to 3.

   After the verification is successful, remove the next VPC.

3. After all VPCs are removed and services are running normally for a period of time, delete the cloud connection and the ECSs for verifying communications.
   1. Delete the cloud connection.

      For details, see Deleting a Cloud Connection.

   2. Delete the ECSs for verifying communications.

      To delete an ECS, refer to How Can I Delete or Restart an ECS?