- Documentation
Transit Router
Best Practices
Interconnection and isolation across network planes
Best Practices
Interconnection and isolation across network planes
Interconnection and isolation across network planes
This topic describes how to use Cloud Wide Area Network (WAN) plane route sharing to achieve selective and controlled interconnection between specific network planes. This is done on the premise that most business networks remain isolated from each other.
In a multi-plane isolation architecture, different network planes are isolated by default. Examples include Production, Development, and Test network planes. They cannot access each other directly. However, real business often requires selectively connecting some networks. For example: - The test environment needs to access shared services in the production environment. Examples include unified login and configuration center.
- The development and test environments can access each other.
- The development and production environments are fully isolated. They cannot access each other.
Cloud WAN plane route sharing meets this need. One network plane's route table learns another plane's propagated routes. This establishes a reachable path between the two planes. The main features of route sharing are as follows:
- Unidirectional/bidirectional interconnection: Plane B can access Plane A only (unidirectional), or both planes can access each other (bidirectional).
- Dynamic route sharing only: Route sharing passes automatically learned routes. Manually configured static routes are not passed.
- Cross-region auto-publishing: Shared routes learned in one region are automatically synced to other regions of the plane. No repeated configuration is required.
- No impact on other isolation: Only the two planes with route sharing are connected. Other planes remain isolated.
The network topology is shown in the following figure. Production and Test network planes are isolated by default. Configure unidirectional route sharing from Production to Test. Publish Production propagated routes to the Test route table. Test can then access shared services in Production. Other isolation remains unchanged.
- Network plane sharing planning
- Network instance planning
- The basic network configuration for multi-plane isolation is complete. The core network is created. Production and Test interconnected network planes exist in an active version.
- The shared Service Virtual Private Cloud (VPC) in Production and the VPC in Test are attached to their network planes. Their attachment status is Available.
- Service insertion is not configured between the two network planes. Route sharing and service insertion are mutually exclusive on the same pair of planes. They cannot be configured at the same time.
- The current account has permission to edit and execute Cloud WAN configuration versions. If not, contact your root account to grant you the required permissions. For required policies, see Cloud WAN IAM policy types.
Configuration procedure
Step 1: Create route sharing
- In the Global Network instance list, click the name of the target instance.
- In the left navigation pane, select Core network > Configuration version.
- Click Edit to the right of the active configuration, and select any configuration method to complete the action.
Page configuration
JSON configuration
- Click the Network plane behavior > Route sharing tab.
- Click Create route sharing and configure the two route sharing as described in the table below.
- Click OK to complete the action.
In the configuration version content, add the route sharing configuration, as shown in the segment-actions section of the following JSON configuration.
"schema-version": "2026.06",
"region": "cn-shanghai",
"region": "cn-guangzhou",
"isolate-attachments": false,
"region": "cn-guangzhou"
"isolate-attachments": false,
"region": "cn-guangzhou"
"isolate-attachments": false,
"region": "cn-guangzhou"
"attachment-policies": [
"association-target": "segment",
"association-method": "constant",
"association-target": "segment",
"association-method": "constant",
"association-target": "segment",
"association-method": "constant",
"mode": "attachment-route",
Step 2: Generate and execute a configuration version
- After completing Step 1, click Generate version. The latest version is generated. After syntax and dependency validation passes, the version enters the Ready to execute status.
- In the configuration version list, locate the latest version and click Execute. On the execution preview page, confirm the change set includes the new route sharing.
- Click Confirm execution in the upper-right corner. Wait for the version status to change to Executed.
Step 3: View route information
After completing the preceding steps, Development and Test learn each other's propagated routes. Routes are automatically synchronized to other VPC route tables. View the routes to ensure the configuration is correct.
- In the left navigation pane, select Core network > Basic information.
- Select the Route information tab. Select the network planes in order: Development and Test. Select the regions in order: China (Beijing), China (Shanghai), and China (Guangzhou). View the Cloud WAN routes to ensure routes from the corresponding planes have been learned.
- Use the Development plane and China (Beijing) as an example. The route table contains the following routes:
- A route entry whose destination CIDR block is a subnet of the Test VPC in China (Beijing), with the next hop being that VPC attachment.
- A route entry whose destination CIDR block is a subnet of the Test VPC in China (Shanghai), with the next hop being cross-region.
- A route entry whose destination CIDR block is a subnet of the Test VPC in China (Guangzhou), with the next hop being cross-region.
tip
When multiple routes in the Cloud WAN route table have the same destination CIDR block, the route with the shorter AsPath has higher priority. Of the two routes with destination 172.17.0.0/24, the route whose next hop is CrossRegion-cn-shanghai has a shorter AsPath and higher priority, so it takes effect and its status is Available. The same applies to the two routes with destination 172.18.0.0/24.
- Log in to the VPC console. In the top menu bar, select China (Beijing).
- In the VPC list, search for the VPC named vpc-dev-bj and click its name to go to the details page.
- Click the number next to Route Table in the Associated resources section, and then click the route table name to go to its details page.
- Under the Route Entry tab, select the Propagation route tab. Ensure Cloud WAN has synchronized routes shared from Test to this VPC route table.
- Using vpc-dev-bj in the Development plane in China (Beijing) as an example, the routes synchronized from Cloud WAN are:
- A route entry whose destination CIDR block is a subnet of the Test VPC in China (Beijing), with the next hop being the core network cn-enterprise.
- A route entry whose destination CIDR block is a subnet of the Test VPC in China (Shanghai), with the next hop being the core network cn-enterprise.
- A route entry whose destination CIDR block is a subnet of the VPC in China (Guangzhou), with the next hop being the core network cn-enterprise.
- Verify isolation between Production and Development/Test: Log in to an ECS instance in the Production plane in China (Beijing). Run ping to access the IP addresses of ECS instances in the Development and Test planes in China (Beijing), China (Shanghai), and China (Guangzhou). If the ping fails, the networks are isolated.
- Verify connectivity between Development and Test: Log in to an ECS instance in the Development plane in China (Beijing). Run ping to access the IP addresses of ECS instances in the Test plane in China (Beijing), China (Shanghai), and China (Guangzhou). If the ping succeeds, the networks can communicate with each other.
Last updated: 2026.09.28 15:57:52