Virtual Private Cloud:Route tables

Route tables

When you create a VPC, the system automatically creates a system route table. This route table is associated with all vSwitches in the VPC by default and controls the traffic within the VPC.

If Elastic Compute Service (ECS) instances in a VPC need to use different paths to access the same destination CIDR block, you can create a custom route table. You can deploy the ECS instances across different vSwitches and associate a custom route table with each vSwitch. This provides fine-grained traffic control.

To protect inbound Internet traffic to your VPC with a self-managed firewall, you can use a gateway route table, which is a custom route table associated with a border gateway. You can associate the gateway route table with an IPv4 or IPv6 gateway to direct inbound Internet traffic to your self-managed firewall. This allows for unified traffic filtering, auditing, and security policy management.

The following describes the differences between the types of route tables:

Comparison	System route table	Custom route table
Attached Object	vSwitch	vSwitch	IPv4/IPv6 gateway
Diagram
Scenarios	Attached to all new vSwitches by default to centrally control vSwitch traffic	Attached to specific vSwitches to control their traffic paths	Attached to an IPv4/IPv6 gateway for secure inbound Internet traffic redirection
Creation	Automatically created when you create a VPC	Manually created. Select the vSwitch type when you create the route table.	Manually created. Select the border gateway type when you create the route table.
Can be deleted	Cannot be deleted.	Can be deleted. Detach it from the vSwitch first.	Can be deleted. Detach it from the IPv4/IPv6 gateway first.
Quota	One system route table per VPC.	By default, you can create nine custom route tables that are attached to vSwitches in a VPC. You can request a quota increase.	You can create only one route table that is attached to an IPv4/IPv6 gateway in a VPC.

Each vSwitch must be associated with only one route table. A route table can be associated with multiple vSwitches.

1. Static routes

Static routes are automatically added by the system or manually added by you. They include two types:

• System routes: Routes with the next hop set to Local. They are automatically added by the system when you create a VPC and a vSwitch. They are used for communication between instances within the VPC or for accessing Alibaba Cloud services.

• Custom routes: Routes that you manually add to customize traffic paths.

As shown in the following figure, two VPCs are connected through a VPC peering connection. The system route table of VPC1 contains the following static routes:

1. After you create a VPC and a vSwitch, the system automatically adds system routes with the next hop set to Local:

   1. Cloud service route: The destination CIDR block is 100.64.0.0/10. This route allows instances in VPC1 to access Alibaba Cloud services.

   2. vSwitch CIDR block route: The destination CIDR block is 10.0.0.0/24. This route allows private communication between vSwitches in VPC1.

2. After you create a VPC peering connection, you must manually add the following custom route:

   The destination CIDR block is 172.16.0.0/16 and the next hop is the peering connection. This route forwards traffic destined for VPC2 to the peering connection.

The routes in the system route table of VPC2 work on the same principle as those in VPC1 and are not described here.

2. Dynamic routes

Dynamic routes are routes propagated to a VPC from other network instances. Unlike static routes, you do not need to manually configure dynamic routes in the VPC route table. They are automatically received and updated from dynamic route sources.

Route priorities

Routes in a VPC route table are prioritized based on the following rules:

• If routes with overlapping destination CIDR blocks exist:

  IPv4 and IPv6 traffic routing are independent of each other. The system uses the longest prefix match rule to select the most specific route that matches the destination IP address. This determines the next hop for traffic forwarding.

  Longest prefix match: When multiple routes have destination CIDR blocks that match the destination IP address of a packet, the system uses the route with the longest subnet mask (the most specific CIDR block). For example, traffic destined for 192.168.1.100 matches the 192.168.1.0/24 route before it matches the 192.168.0.0/16 route.

• When the destination CIDR block of a new route overlaps with that of an existing route:

  Operation	Existing system route	Existing custom route	Existing dynamic route
  Create a vSwitch	The CIDR block of the vSwitch cannot overlap with an existing system route.	The CIDR block for a vSwitch cannot be any of the following: Be identical to the destination CIDR block of an existing custom route. Contain the destination CIDR block of an existing custom route.	The vSwitch CIDR block does not support the following: Is the same as the destination CIDR block of an existing dynamic route. Contains the destination CIDR block of an existing dynamic route.
  Add a custom route	The destination CIDR block for a new custom route cannot: match the CIDR block of an existing system route. be more specific than an existing system route.	The destination CIDR block of the new custom route cannot be the same as that of an existing custom route. If the Next hop type is router interface (to VBR), you can configure active/standby or equal-cost multi-path (ECMP) routes. For more information, see Route to a router interface.	When you add a custom route, its destination CIDR block cannot be the same as that of an existing dynamic route. If the next hop of the new custom route is a VPN Gateway or a router interface, and there is an existing dynamic route from CEN with the same destination CIDR block, the dynamic route is withdrawn and the custom route takes effect.
  Receive a dynamic route	When a dynamic route is received: It cannot have the same destination CIDR block as an existing system route. If it is more specific than an existing system route, the dynamic route is not propagated.	When dynamic routes are received from an ECR: If a custom route with the same destination CIDR block exists, the custom route takes precedence. The dynamic route is visible in the VPC route table but does not take effect until the custom route is deleted. When dynamic routes are received from a VPN Gateway, Enterprise Edition TR, or Basic Edition TR: If a custom route with the same destination CIDR block exists, the custom route takes precedence. In this case, the dynamic route is not propagated to the VPC route table. It is propagated and takes effect only after the custom route is deleted.	Not supported. The current VPC route table has only one route propagation source.

Create and delete route tables

You must first create a custom route table before you can associate it with a target vSwitch or an IPv4 or IPv6 gateway.

variable "name" {
  default = "terraform-example"
}

resource "alicloud_vpc" "defaultVpc" {
  vpc_name = var.name
}


resource "alicloud_route_table" "default" {
  description      = "test-description"
  vpc_id           = alicloud_vpc.defaultVpc.id
  route_table_name = var.name
  associate_type   = "VSwitch"
}

Attach and detach route tables

A newly created custom route table is not associated with any resource by default. You must associate it with a vSwitch or an IPv4 or IPv6 gateway for the route table to take effect.

variable "name" {
  default = "terraform-example"
}

resource "alicloud_vpc" "foo" {
  cidr_block = "172.16.0.0/12"
  vpc_name   = var.name
}

data "alicloud_zones" "default" {
  available_resource_creation = "VSwitch"
}

resource "alicloud_vswitch" "foo" {
  vpc_id       = alicloud_vpc.foo.id
  cidr_block   = "172.16.0.0/21"
  zone_id      = data.alicloud_zones.default.zones[0].id
  vswitch_name = var.name
}

resource "alicloud_route_table" "foo" {
  vpc_id           = alicloud_vpc.foo.id
  route_table_name = var.name
  description      = "route_table_attachment"
}

resource "alicloud_route_table_attachment" "foo" {
  vswitch_id     = alicloud_vswitch.foo.id
  route_table_id = alicloud_route_table.foo.id
}

resource "alicloud_vpc" "example" {
  cidr_block = "172.16.0.0/12"
  vpc_name   = "terraform-example"
}

resource "alicloud_route_table" "example" {
  vpc_id           = alicloud_vpc.example.id
  route_table_name = "terraform-example"
  description      = "terraform-example"
  associate_type   = "Gateway"
}

resource "alicloud_vpc_ipv4_gateway" "example" {
  ipv4_gateway_name = "terraform-example"
  vpc_id            = alicloud_vpc.example.id
  enabled           = true
}

resource "alicloud_vpc_gateway_route_table_attachment" "example" {
  ipv4_gateway_id = alicloud_vpc_ipv4_gateway.example.id
  route_table_id  = alicloud_route_table.example.id
}

Add and delete routes

You can add custom routes to a route table that is attached to a vSwitch to control the traffic path of the vSwitch.

You cannot add routes to a route table that is attached to an IPv4 or IPv6 gateway. However, you can change the next hop of a route.

resource "alicloud_route_entry" "foo" {
  route_table_id        = "rt-12345xxxx" # Enter the route table ID. 
  destination_cidrblock = "172.16.1.1/32"
  nexthop_type          = "Instance" # Enter the next hop type. 
  nexthop_id            = "i-12345xxxx" # Enter the next hop instance ID. 
}

Change the next hop of a route

You can change the next hop of a route to alter the traffic path for the destination CIDR block.

• System routes: You can change the next hop of a system route only if it is in a custom route table, which includes a gateway route table. After the change, the route becomes a custom route. If you delete this custom route, the original system route is restored.

• Custom routes: You can change the next hop of a custom route in both system and custom route tables.

For more information about the supported types for Destination CIDR block and Next hop, see System routes vs. custom routes.

resource "alicloud_route_entry" "foo" {
  route_table_id        = "rt-12345xxxx" # Enter the route table ID. 
  destination_cidrblock = "172.16.1.1/32"
  nexthop_type          = "Instance" # Change the next hop type.
  nexthop_id            = "i-12345xxxx" # Enter the next hop instance ID. 
}

Publish and withdraw static routes

Routes from a route table can be propagated to an Express Connect Router (ECR) or a transit router (TR). When combined with the dynamic route receiving feature, this simplifies route configuration.

• Publish static routes to an ECR: After a static route is published to an ECR, it can be dynamically propagated from the ECR to a data center. If there are no route conflicts, all data centers associated with the ECR can learn this route.

  Click to view the working principle, limits, and an example scenario for publishing static routes to an ECR

  How it works

  • After a VPC is associated with an ECR, the system routes of the VPC are published to the ECR by default.

  • After a static route is published to an ECR:

    • The ECR propagates the route to its associated virtual border router (VBR). If BGP is enabled on the VBR, the route is then propagated to the data center.

    • The ECR does not propagate the route to other VPCs associated with it.

  • If a published static route conflicts with an existing route, you can view the route on the Routes tab of the ECR. The status of the route is displayed as Conflicting and the route does not become Active.

  Limits

  • Routes in a custom route table cannot be published to an ECR.

  • Routes whose destination CIDR block is a prefix list cannot be published to an ECR.

  • Active/standby routes and Equal-Cost Multi-Path (ECMP) routes whose next hop is a router interface to a virtual border router (VBR) cannot be published to an ECR. After a VPC route is published to an ECR, you can no longer configure ECMP or active/standby routes for that route.

  • After a VPC route is published to an ECR, if you modify the route, you can set the next hop only to a route type that supports the publish operation, as described in the following table.

  • The following table lists the default publish status of various types of routes in a VPC instance and whether they support publish and withdraw operations.

    Click to view the table

    Route type	Route Entry Instance	Published by default	Publish operation support	Are revoke operations supported?
    VPC system route	VPC	Yes	Yes	Only in Malaysia (Kuala Lumpur)
    Route to an IPv4 gateway	VPC	No	Support	Support
    Route to an IPv6 gateway	VPC	No	Support	Support
    Route to a NAT Gateway	VPC	No	Support	Support
    Route to a VPC peering connection	VPC	No	No	No
    Route to a transit router	VPC	No	No	No
    Route to a VPN Gateway	VPC	No	Support	Support
    Route to an ECS instance	VPC	No	Support	Support
    Route to an ENI	VPC	No	Support	Support
    Route to a high-availability virtual IP address	VPC	No	Support	Support
    Route to a router interface (to VBR)	VPC	No	No	No
    Route to a router interface (to VPC)	VPC	No	No	No
    Route to an Express Connect Router	VPC	No	No	No
    Route to a Gateway Load Balancer endpoint	VPC	No	Support	Support

  Example Scenario

  An enterprise has a data center and a VPC in the China (Hangzhou) region. The enterprise wants to establish stable communication between the VPC and the data center, and ensure that services deployed in the data center can access the Internet.

  The enterprise can connect the VPC and a VBR to an ECR, create an Internet NAT gateway with an EIP attached, and then publish routes to the ECR. If there are no route conflicts, the data center can learn the route to the NAT Gateway through BGP. This allows the data center to access the Internet.

  

• Publish static routes to a transit router (TR): After a static route is published to a TR, if there are no route conflicts and route synchronization is enabled for the TR, all network instances connected to the TR can learn this route.

If your VPC is connected to both an ECR and a TR, the actions of publishing VPC routes to the ECR and to the TR are independent and do not affect each other.

Enable or disable dynamic route receiving

By default, all route tables are configured to receive dynamic routes. If you require a purely static routing configuration, you can disable dynamic route receiving for a route table. This lets you plan your route tables and manage route configurations as needed.

1. You can disable dynamic route receiving in the following cases: The source of dynamic routes is Route Propagation-Type ECR, or no dynamic routes are propagated to the VPC. If no dynamic routes are propagated to the VPC, the Dynamic Route Source parameter is not displayed on the Route Entry List > Dynamic Route tab of the route table details page.

   You cannot disable dynamic route receiving in the following cases: The VPC is connected to a Basic Edition TR. The VPC is connected to an Enterprise Edition TR and route synchronization is enabled for the VPC on the TR. The VPC is associated with a VPN Gateway and automatic BGP route propagation is enabled for the VPN Gateway.

2. Shutdown impact:

   • The VPC route table no longer receives routes propagated from other network instances. If dynamic routes already exist in the route table, they are all deleted. Proceed with caution.

   • The VPC cannot be connected to a Basic Edition TR. A TR connected to this VPC cannot enable route synchronization for the VPC. A VPN Gateway associated with this VPC cannot enable automatic BGP route propagation.

3. Impact of Shutdown and Restart:

   The dynamic routes in the VPC route table are updated based on the routes that are currently propagated from the dynamic route source.

   For example, assume that an ECR has four dynamic routes. If you disable this feature, the dynamic routes are cleared from the VPC route table. If two more routes are added to the ECR and then you re-enable this feature, the VPC route table receives six dynamic routes from the ECR.

variable "name" {
  default = "terraform-example"
}

resource "alicloud_vpc" "defaultVpc" {
  vpc_name = var.name
}

resource "alicloud_route_table" "default" {
  description      = "test-description"
  vpc_id           = alicloud_vpc.defaultVpc.id
  route_table_name = var.name
  associate_type   = "VSwitch"
  route_propagation_enable = true # Modify this parameter to enable or disable dynamic route receiving. 
}

Use a self-managed firewall

You can set up a self-managed firewall on an ECS instance in a VPC and use a gateway route table to redirect inbound VPC traffic to the firewall for filtering.

GWLB high availability architecture

You can use a Gateway Load Balancer (GWLB) to distribute traffic among different security devices. This improves the security and availability of your applications.

Route to an IPv4 gateway

You can use an IPv4 gateway as a unified ingress and egress point for traffic between your VPC and the internet. When used with a custom route table, an IPv4 gateway allows for centralized control of internet access traffic. This helps you implement unified security policies and auditing, and reduces security risks from scattered access points.

Route to an IPv6 gateway

After you enable IPv6 for a VPC, the system automatically adds a route to the system route table:

• The destination CIDR block is ::/0, and the next hop is the IPv6 gateway.

This route directs default IPv6 traffic to the IPv6 gateway. After you enable IPv6 Internet bandwidth for an IPv6 address, vSwitches attached to the system route table can communicate with the internet.

For a vSwitch with IPv6 enabled that is attached to a custom route table, you must manually add the preceding route to the custom route table to enable IPv6 internet access.

For a custom route whose next hop is an IPv6 gateway instance, the destination CIDR block can only be set to ::/0.

Route to a NAT Gateway

If you have many servers that need to access the internet and require many public IP resources, you can use the SNAT feature of an Internet NAT gateway. This allows multiple ECS instances in a VPC to share EIPs for internet access, which saves public IP resources. Additionally, these ECS instances can access the internet without exposing their private IP addresses, which reduces security risks.

When you use a NAT Gateway, you must add a route to the VPC route table that points to the Internet NAT gateway to enable internet access.

• If the vSwitch to which the ECS instance belongs is attached to a custom route table, you must manually add a route where the Destination CIDR Block is set to 0.0.0.0/0 and the Next Hop is set to the Internet NAT gateway.

• If the vSwitch to which the ECS instance belongs is attached to the system route table:

  • If no route with the destination CIDR block 0.0.0.0/0 exists in the system route table, the system automatically adds a route that points to the Internet NAT gateway.

  • If a route with the destination CIDR block 0.0.0.0/0 already exists in the system route table, you must delete the existing route and then add a route that points to the Internet NAT gateway.

Route to a VPC peering connection

VPCs are isolated from each other. However, you can use a VPC peering connection to enable private communication between two VPCs, regardless of whether they are in the same account or region. After you establish a peering connection between two VPCs, Alibaba Cloud resources in these VPCs can access each other using private IPv4 or IPv6 addresses.

Route to a transit router

When you use Cloud Enterprise Network (CEN) to connect VPCs, you must add routes that point to the transit router to the VPC route tables. You can do this in one of the following ways:

• When you create a VPC connection, select Automatically Create Route That Points to Transit Router and Add to All Route Tables of Current VPC.

  After you enable this feature, the system automatically adds three routes to all route tables of the VPC. The destination CIDR blocks of these routes are 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. The next hop for these routes is the VPC connection, which directs IPv4 traffic from the VPC to the transit router.

• After you enable route learning in the transit router, you can either enable route synchronization for each VPC or manually add a route in each VPC route table that points to the peer VPC.

The following figure shows an example in which route learning is enabled in the transit router. A route is manually added to the VPC route table. The destination CIDR block of the route is set to the CIDR block of the peer VPC, and the next hop is set to the transit router.

Route to a VPN Gateway

You can establish an encrypted tunnel through a VPN Gateway to create a secure and reliable network connection between your on-premises data center and your VPC.

When you use a VPN Gateway, you must add a route to the VPC. In this route, set the Destination CIDR Block to the CIDR block of the on-premises data center and set the Next Hop to the VPN Gateway. This allows the VPC to access the on-premises data center through an IPsec-VPN connection.

Route to an ECS instance or an ENI

When two vSwitches in a VPC need to communicate, you can adjust the route tables to insert a third-party security device, such as a firewall or WAF, into the traffic path for traffic inspection, analysis, and protection.

To configure this, you can attach each of the communicating vSwitches to a separate custom route table. Then, you can change the next hop of the system route for the corresponding CIDR block to the firewall's ECS instance or ENI.

Route to a router interface

The VBR-to-VPC connection feature of Express Connect lets you connect your on-premises data center to your VPC.

When you use this feature, you must add a route to the VPC. In this route, set the destination CIDR block to the CIDR block of the on-premises data center and set the next hop type to router interface (to VBR). This allows the VPC to access the on-premises data center through the VBR. This next hop type supports ECMP and active/standby modes. You must use these modes with health checks:

The following figure shows the active/standby mode:

Route to an Express Connect Router

You can use an Express Connect Router (ECR) with Express Connect to connect your on-premises data center to your VPC.

• By default, a VPC accepts dynamic routes from an Express Connect Router (ECR). These routes enable communication with an on-premises data center by specifying the data center's CIDR block as the destination CIDR block and the ECR as the next hop.

• If dynamic route receiving is disabled for the VPC route table, you must manually add a route to the VPC route table. In this route, set the Destination CIDR Block to the CIDR block of the on-premises data center and set the Next Hop to the Express Connect Router. This enables communication between the VPC and the on-premises data center.

Route to a Gateway Load Balancer endpoint

The Gateway Load Balancer endpoint next hop type is supported only in these regions. For specific use cases, see Use a gateway route table - GWLB high availability architecture.

Quotas

Limits

Billing

The VPC route table feature is free of charge.