Routing is a fundamental aspect of networking in any cloud environment. Within Oracle Cloud Infrastructure (OCI), the virtual cloud network (VCN) provides you with a powerful framework to direct traffic between subnets, internet gateways, on-premises networks, and other OCI resources. We’re excited to announce a pivotal update to this core networking feature: per-resource routing.
Unlike traditional routing, which makes decisions solely based on the destination, per-resource routing lets you influence routing based on the source resource, such as a virtual network interface card (VNIC) or an assigned IPv4/IPv6 address. By associating a route table with a VNIC or IP address, you can route traffic differently for workloads in the same subnet. This blog post can help you understand why we’re introducing per-resource routing, how it works, and how you can integrate it seamlessly into your existing network architecture.
Why Do We Need Per-Resource Routing?
As your network routing needs become more diverse, you can find an increasing demand for greater control over traffic routing within your subnets. For example, you might need to direct specific workloads to a monitoring or intrusion prevention system, you might want to set up a hub VCN with network virtual appliances that require distinct routing configurations for each interface, or you might have a Kubernetes environment running on bare metal instances that need multiple addresses assigned to node ports each with discrete routing needs.
In the past, you would have addressed these needs by creating multiple subnets tailored to specific routing requirements. Per-resource routing allows you to simplify your architecture by reducing the number of subnets you need. You can associate specific route tables directly to VNICs or IP addresses, enabling more precise traffic control without added design complexity. Security segmentation remains intact through network security groups (NSGs), so you can streamline your design without compromising security.
Benefits of Per-Resource Routing
VNIC Use Case
A common network architecture within a region consists of a combination of private subnets, public subnets, route tables, and various route targets in the form of gateways, such as internet gateways, NAT gateways, service gateway, and dynamic routing gateways (DRGs). The following graphic shows a simple example topology:
Routing in this topology is based on the route tables associated with subnets, gateways, and DRG attachments. As an example, all instances deployed within the private subnet named PrivSubnet1 are routed based on the associated route table, PrivRouteTable.
Now, let’s introduce a network virtual appliance (NVA), such as a firewall, into the VCN that we want certain applications to traverse before going to the NAT gateway. In this post, we cover only the egress portion of routing traffic through the NVA because the NAT gateway would require modifications to handle the return traffic. For a more comprehensive explanation, including how the ingress routing is configured, see Announcing OCI intra-VCN routing and VCN gateway ingress routing enhancements.
To route traffic through this NVA, you can modify the existing route table, PrivRouteTbl, for our private networks, but what if you want to be selective about what’s routed through this NVA, such as only VM-C? You can create a private subnet with a new route table that includes a default route pointing to the NVA and move or redeploy VM-C into this new subnet. However, with per-resource routing, you can simplify this process further by associating the new route table with the existing VNIC of VM-C and remove the need for a new subnet and changing the instance’s IP address.
With per-resource routing, route lookup follows a hierarchy based on specificity, starting with the IP address, then the VNIC, and finally the subnet. In this example, because a route table is associated with the VM-C VNIC, the subnet-level PrivRouteTbl routes do not apply. As a result, the route table linked to the VM-C VNIC must include all necessary routes, not just the route to the NVA.
IP Address Use Case
Using the example topology from the VNIC use case, let’s explore a different use case, where we have a single instance (VM-B) that we want to have two separate default routes, one to the on-premises network and one to the NAT gateway.
You can achieve this structure by adding a second VNIC to the instance and placing that second VNIC in a separate subnet associated to a discrete route table. You can also follow the example in the previous section and use the same subnet but associate the discrete route table to the second VNIC.
If you attach this second VNIC for the sole purpose of achieving the dual gateway topology, you’re likely adding unnecessary overhead to the instance. The total number of VNICs supported on an instance depends on the shape and OCPUs configured within that Compute shape.
With per-resource routing, you have a more efficient approach. Assign a secondary IP address to the existing VNIC in PrivSubNet1 and associate the discrete route table to that secondary IP.
Conclusion
Per-resource routing brings a significant upgrade to how you manage networking in Oracle Cloud Infrastructure. By enabling routing decisions based on the source resource, you can simplify how routing changes are deployed within the network leading to greater flexibility and simplified operations.
Whether you’re looking to streamline hub-and-spoke designs, integrate network virtual appliances, or direct traffic for specific workloads, per-resource routing gives you a scalable and efficient solution. With this feature, you can build a secure and adaptable cloud environment that evolves with your business needs. For more information on how to implement this feature, see Custom Route Tables for VNICs or VNIC IP addresses.