As businesses expand, the networking needs become more complex, requiring more intelligent traffic management solutions. In this blog, we dive into a real-world scenario where a customer had to optimize their OCI route tables to align with security and compliance requirements.
Setup Overview:
The customer scenario involved five instances within a public subnet:
• Three instances needed access to the Internet.
• Two instances needed access to the Service Gateway to connect to an Autonomous Database (ADB) in the Oracle Services Network (OSN).
The initial approach of using a single route table for the subnet created challenges, especially because OCI does not support having both an Internet Gateway (IGW) and Service Gateway (SGW) route rule together in the same table without causing potential asymmetric routing issues.
Understanding the Routing Conflict:
Traditionally, when a subnet’s route table includes both:
1. A default route (0.0.0.0/0) pointing to the Internet Gateway, and
2. A route to All <region> Services in Oracle Services Network pointing to the Service Gateway,
it can lead to routing conflicts. Specifically:
Oracle services trying to initiate a connection to the public instances may experience asymmetric routing, where responses do not follow the same path back.
As a result, OCI disables this configuration at the API and Console level to prevent misconfigurations.
This safeguard ensures predictable and secure traffic flow but requires a more refined network setup when different traffic patterns are needed within the same subnet.
Solution: Leveraging Per-Resource Routing
OCI introduced a powerful feature called per-resource routing that addresses exactly this kind of requirement.
What is Per-Resource Routing?
•It allows you to associate different route tables not just with entire subnets, but with individual VNICs (Virtual Network Interface Cards) or even specific VNIC IP addresses.
•This provides granular routing control inside a single subnet.
Implementation Steps:
In the customer’s use case, the solution involved:
1.Creating Two Separate Route Tables:
Route Table 1: For instances needing Internet access.
Route: 0.0.0.0/0 → Internet Gateway
Route Table 2: For instances needing Service Gateway access.
Route: All <region> Services → Service Gateway
2.Assigning Route Tables to Instances:
•The three instances needing Internet access were associated with Route Table 1.
•The two instances connecting privately to the Oracle Service Network were associated with Route Table 2.
Using per-resource routing, the network remained clean, secure, and compliant — without needing to move instances to separate subnets.
Related Links:
Associating a Route Table with a VNIC or VNIC IP address: https://docs.oracle.com/en-us/iaas/Content/Network/Tasks/managingroutetables.htm#Overview_of_Routing_for_Your_VCN__source_routing
Routing control using customer route tables: https://www.ateam-oracle.com/post/granular-routing-control-with-custom-route-tables-in-oci
Known Issues with OCI Networking: https://docs.public.content.oci.oraclecloud.com/en-us/iaas/Content/Network/Reference/known_issues_for_networking.htm#sgw-route-rule-conflict
Conclusion:
Associating route tables with individual VNICs or VNIC IP addresses represents a key enhancement in OCI networking, enabling source-based routing at the network interface level. This capability allows for precise traffic engineering, supporting advanced routing use cases while maintaining adherence to stringent security and compliance policies.