Policy-based routing

Scenario A: Route traffic by source IP

• Prerequisite: Two subnets in the same vSwitch must send traffic to the same destination IDC at 10.1.0.0/16 but through different Virtual Border Routers (VBRs): VBR-A and VBR-B.

• Configuration: Create two PBR rules. Each rule matches the source CIDR of one subnet and directs its traffic to the route table associated with the corresponding VBR.

• Advanced: When using ECMP over dual private connections, use the AsPathPrepend attribute in a Cloud Enterprise Network (CEN) route policy (RouteMap) to ensure symmetric return paths.

Scenario B: Subnet-level active-standby paths

• Prerequisite: A single VPC contains two subnets. Two private connections, A and B, are connected to a Transit Router (TR). Subnet A must use private connection A as its primary path and B as its standby, while Subnet B must use B as its primary path and A as its standby.

• Configuration: Create two route tables, vtb-a-primary and vtb-b-primary. In each route table, use a RouteMap to lower the priority of the route that points to the opposing VBR. Then, use PBR to direct traffic from each subnet to its respective primary route table.

• Advanced: If the primary link fails, BGP automatically converges to the standby path. Symmetric return traffic depends on bidirectional RouteMaps.

Scenario C: Service insertion for cross-VPC traffic

• Prerequisite: A Cloud Firewall is connected to the TR as an attachment and has its own dedicated route table, vtb-firewall.

• Configuration: On the attachment for the source VPC, bind a policy route table. Create a rule with the match conditions SourceCidr=10.0.1.0/24, DestinationCidr=10.0.0.0/8 and set the target to vtb-firewall. Traffic that does not match this rule follows the default route table.

• Note: Because the firewall is stateful, return traffic must also pass through it. You can achieve this by binding a similar policy route table to the peer attachment or by associating the peer attachment with a route table that directs traffic through the firewall.

Scenario D: Path isolation for multiple tenants

• Prerequisite: Multiple tenants share the same VPC and vSwitch. Each tenant must access their own IDC through a dedicated IPsec tunnel.

• Configuration: Associate each tenant's IPsec attachment with a separate route table. Use PBR to map traffic from each tenant's source network segment to the corresponding route table.

Scenario E: Zonal egress for active-active architectures

• Prerequisite: Subnets in different availability zones (AZs) and their corresponding local private connection egress points are configured as separate attachments. For example, 10.1.1.0/24 → att-vbr-az1 and 10.1.2.0/24 → att-vbr-az2.

• Configuration: Assign a separate route table for each AZ's egress point. Use PBR to map traffic from each AZ's subnet to its corresponding egress route table. This prevents ECMP from load balancing traffic across different AZs.

• Advanced: For failover, you can pre-configure cross-AZ fallback routes in a standby route table. This maintains service availability during an outage, albeit with potentially degraded performance.

Scenario F: Dedicated channel for compliance auditing

• Prerequisite: Outbound traffic from the DMZ subnet 10.2.0.0/24 must be routed through an auditing channel. The auditing appliance is connected as an attachment and is associated with the route table vtb-audit.

• Configuration: Create a PBR rule that matches the source network segment of the DMZ and forwards its traffic to the vtb-audit route table. Traffic from other subnets without a bound policy or a matching rule is forwarded according to the default route table.

• Note: Inline auditing is similar to a stateful firewall and requires symmetric routing. Mirrored (out-of-band) auditing has minimal impact on return traffic.

Scenario G: Traffic coloring for canary releases

• Prerequisite: A canary subnet (10.3.100.0/24) and a production subnet share the same VPC. The backend cluster for the canary environment connects through a separate attachment, which is associated with the route table vtb-gray.

• Configuration: Create a PBR rule: SourceCidr=10.3.100.0/24 → vtb-gray. Set its priority lower than any security or compliance rules.

• Note: The network layer only determines the traffic path. Application-level logic must still manage version switching and rollbacks.

Traffic matching process

When traffic enters an attachment, the system evaluates it against the policy route table before looking up a route table for forwarding:

1. A packet enters an attachment.

2. The system checks if a policy route table is bound to the attachment.

   • If yes, proceed to step 3.

   • If no, skip to step 6.

3. The system evaluates the packet against the rules in the policy route table in order of priority.

4. The system checks if the packet matches a rule.

   • If yes, proceed to step 5.

   • If no, skip to step 6.

5. The system looks up the destination in the target TR route table specified by the rule and then skips to step 7.

6. The system looks up the destination in the TR route table bound by associated forwarding.

7. The packet is forwarded to the next hop.

Key principles:

• Priority-based evaluation: Rules are evaluated in priority order (smaller value = higher priority). The first matching rule is applied, and evaluation stops.

• Decoupled matching and forwarding: A policy route table only determines which route table to use. The selected route table resolves the next hop.

• Ingress control: A policy route table is bound to an attachment and only affects traffic entering the TR through that specific attachment.

Rule matching fields

Each rule contains the following fields:

Follow these three steps:

1. Create a Policy-based Route Table.

   Click the ID of the TR to go to its details page. Switch to the Policy-based Route Table tab and click Create Policy-Based Routing Table.

2. Add Policy-Based Routes.

   1. In the Actions column for the policy route table you just created, click View Rule.

   2. In the Policy-Based Routing Table Details panel, on the Policy-Based Routes tab, click Add Policy Routing Rule.

   3. In the Add Policy Routing Rule dialog box, configure the following settings:

      • Match Condition: Configure as listed in Rule matching fields.

      • Priority: 1 to 100. A lower value indicates higher priority.

      • Forwarding Target Route Table: The route table to use if traffic matches the rule.

   You can add multiple rules to a table.

3. Bind the Policy-based Route Table to an Network Instances:.

   1. In the Actions column for the policy route table, click Manage.

   2. In the Policy-Based Routing Table Details panel, on the Policy-Based Routes tab, click Associate Network Instance Connection to complete the binding.

After you bind the table, the system first evaluates traffic entering the attachment against the Policy-Based Routes:

• If the traffic matches a rule, the system forwards it based on the specified target route table.

• If the traffic does not match any rules, the system forwards it based on the route table configured for associated forwarding.

Quotas and limits

Quotas:

Monitoring metrics

The following CloudMonitor metrics use dimension PolicyBasedRouteId:

FAQ

Why isn't my rule taking effect?

Check these items in order:

① Verify that the policy route table is bound to the ingress attachment. You can check this on the Intra-Region Connections tab of the TR details page, in the Associate with Route Table column for the target attachment.

② Confirm that the rule is configured correctly and that active traffic matches its conditions.

③ Check if a higher-priority rule (one with a smaller priority value) is matching the traffic first.

④ Check the traffic direction. Policy-based routing only applies to traffic flowing into the TR. You can use the PolicyBasedRouteHitCount monitoring metric in CloudMonitor to verify if packets are matching the rule.