Both CCN and Peering Connection can realize cross-region VPC interconnection. Compared with Peering Connection, CCN features linkage interconnection, self-learning of routes, simple configuration, stability and reliability, and lower cost and latency.
This document guides you through plans to migrate the cross-region connection from Peering Connection to CCN.
Access control between subnets is implemented through their own network ACLs. For example, for the network ACL21 of the VPC2 subnet 21, only the IP range of subnet 11 within VPC1 is allowed for communication, so as to realize the traffic access control between subnets.
Migration plan: Use CCN to fully connect VPC1, VPC2, and VPC3. Confirm the ACL rules of each subnet in advance to ensure that only the required subnet IP ranges are allowed.
- The directions are given based on scenario 1.
- In scenario 2, multiple VPCs are fully interconnected. Please add these VPCs to CCN one by one, and check the routing conditions in CCN and VPCs in time. When a route conflict occurs due to overlapping IP ranges, the route becomes invalid. For solutions, see Use Limits and Migrating VPCs with Peering Connection to CCN.
- In scenario 3 and scenario 4, please configure an appropriate ACL policy as instructed in Managing Network ACLs for the subnet in advance according to the communication between the subnets. Then associate the VPCs with CCN one by one, and migrate the routes to CCN. During the period, you can monitor the business situation in real time.
Create a CCN Instance and associate the VPC1 to it.
Click the CCN instance ID and enter the route table tab. You can see the routing policy whose destination is the VPC1 subnet. To add a CCN route, see Route Overview.
Associate VPC2 with the CCN instance as instructed in Associating Network Instances.
Click the CCN instance ID again and re-enter the route table tab. You can see a new routing policy whose destination is the VPC2 subnet. For solutions of CCN routing exceptions, see Use Limits.
Check the route tables associated with the subnets of VPC1 and VPC2 respectively. You can see both VPC1 and VPC2 subnets have added a routing policy with the next hop to CCN. But due to the routing conflict, when the destination IP range overlaps, the routing policy added later is invalid, so the communication between VPC1 and VPC2 is still implemented through the peering connection.
In the VPC1 route tables, enable VPC1 - VPC2 routing policy directed to a CCN instance, and disable the VPC1 - VPC2 routing policy directed to a peering connection instance, as instructed in Managing Routing Policies. At this time, VPC1 communicates with VPC2 via a CCN connection, while VPC2 communicates with VPC1 via a peering connection.
Check the monitoring information as instructed in View Monitoring Information or Viewing Monitoring Data of Network Traffic Over a Cross-region Peering Connection or log in to a CVM instance as instructed in Logging In to Linux Instance (Web Shell).
Ping the network to check whether the traffic is normal. If it is not normal, please submit a ticket.
In the VPC2 route tables, please refer to step 6 to enable the VPC2 - VPC1 routing policy directed to a CCN instance, and disable the VPC2 - VPC1 routing policy directed to a peering connection instance.
Check the monitoring information or check whether the traffic is normal by a
If the traffic is abnormal, please submit a ticket.
If the business traffic is normal within a week, and monitoring reveals that the peering connections have no traffic, you can refer to Managing Routing Policies and Deleting a Peering Connection to delete the routing policies directed to peering connection in the VPC1 and VPC2 route tables and the peering connection instances that you no longer use.