Oracle Cloud

Networking in Oracle Cloud Infrastructure – Advanced Topics

Oracle Cloud Infrastructure provides highly customizable Virtual Cloud Networks (VCN) and connectivity services offering performance, isolation, security, and high availability.

In this blog post are going to discuss following topics:

Local Peering

Privately connects two VCNs in the same region so that their resources can communicate using private IP addresses without routing the traffic over the internet.

To implement local peering:

  1. Create a Local Peering Gateway (LPG) on each VCN.
  2. From one of the LPGs, click on “Establish Peering Connection” and choose the second LPG.
  3. Define the routing rules in the route tables and security rules in the security lists.

Use cases: it is helpful for separating networks of different environments, departments, or projects, but allowing specific traffic to flow between them. A service provider could also connect it’s networks to the customer’s network in other tenancies to manage their resources.

Good to know:

  • The VCNs can be either in the same or different tenancies (cross-tenancy peering).
  • A given VCN can have a maximum of 10 local peerings at a time.
  • Two VCNs in local peering relationship must not have overlapping CIDRs.
  • If VCN-1 is peered with three other VCNs, those three VCNs can have overlapping CIDRs with each other. You would set up the subnets in VCN-1 to have route rules that direct traffic to the targeted peered VCN.

Remote Peering

Privately connect two VCNs in different regions in the same tenancy using internal backbone, so the traffic never leaves Oracle Network.

To implement remote peering:

  1. Create a Dynamic Routing Gateway (DRG) and attach it to the VCN in each region. DRG is a standalone object and must be attached to the VCN. VCN and DRG have a 1:1 relationship.
  2. Create a Remote Peering Connection (RPC) on each DRG. The RPC acts as a connection point for a remotely peered VCNs.
  3. From one of the RPCs, click on “Establish Connection”, choose the region, and enter the OCID of the second RPC.
  4. Define the routing rules in the route tables and security rules in the security lists.

Use cases for remote peering are to easily migrate and expand your applications to another region and to implement disaster recovery solutions across regions like Oracle Database Data Guard with the primary in the first, and the standby database in the second region.

Good to know:

  • The VCNs must be in the same tenancy.
  • A given VCN can have a maximum of 10 remote peerings at a time.
  • Two VCNs in remote peering relationship must not have overlapping CIDR blocks.
  • Remote peering to 2 other VCNs with overlapping IP address ranges is not possible.
  • A given VCN can use the connected RPCs to reach only VNICs in the other VCN, and not destinations outside of the VCNs (such as the internet or on-prem network). For example, if VCN-1 were to have an internet gateway, the instances in VCN-2 could NOT use it to send traffic to the internet. However, VCN-2 could receive traffic from the internet via VCN-1.

Private & Public Peering

Do not confuse local and remote peering with private and public peering!

Private and public peering are related to connections from on-prem using FastConnect.

  • Private Peering: access you own OCI resources from on-premise network privately.
  • Public Peering: access Oracle public services from on-premise network privately.

Use cases are to extend your on-prem network to Oracle Cloud (Hybrid Cloud) or access Object Storage from on-premise without using the internet.

Transit Routing

What to do if we want to access multiple VCNs in another region without implementing multiple remote connections? The answer is as you might expect: using transit routing.

We connect the VCNs within the same region via local peering while only one VCN is connected to the other region via remote peering. The traffic transits then through this VCN (Hub VCN) to the other locally peered VCNs (Spoke VCNs). Transit routing can also be used to access Oracle services privately via Service Gateway in the remotely connected region.

To implement transit routing:

  1. Implement local peering as described above.
  2. Implement remote peering as described above.
  3. Create a route table and associate it with the DRG object itself (NOT to the subnet!) to route the traffic to the LPG.
  4. Create a route table and associate it with the LPG object itself (NOT to the subnet!) to route the traffic to the DRG.

You can use transit routing while connected from a second OCI region, from your on-premise network using FastConnect, or from Azure Cloud using Interconnect.

Security List (SL) vs. Network Security Group (NSG)

Both SLs and NSGs enables you to create ingress and egress security rules. The difference is, SLs are attached to subnets while NSGs to specific resources (i.e. compute instances) in multiple subnets in the same VCN.

The advantage of NSGs is that they let you separate the VCN’s subnet architecture from the application security requirements. You can use security lists alone, network security groups alone, or both together (set of rules that applies is the union of both).

Access to Autonomous Database on Shared Infrastructure

When creating an Autonomous Database that can be access privately AND via the internet, then we use a Service Gateway for the private connection, so the traffic doesn’t leave Oracle network.

To restrict the access to the database to specific CIDRs or IPs, use Access Control Lists.

As many enterprises have the requirement that the database should not be accessible via the internet, private endpoints were introduced. A private endpoint refers to a network setup that ensures the only access path to the database is via a VCN inside your tenancy. A private endpoint requires a NSG that acts as a virtual firewall for the Autonomous Database.

*** Important ***

The NSG for the Autonomous Database has to allow ingress traffic from your applications subnet (even if in the same subnet). As ingress rule you can specify the CIDR block of the subnet or a specific NSG attached to the compute VNICs.

The application’s subnet has to allow egress traffic to the private endpoint (even if in the same subnet). As egress rule you can specify the IP of the private endpoint or the NSG attached to the private endpoint.

If you are accessing the private endpoint from outside the VCN via local or remote peering or from your on-prem network, then you have to use the IP address of the private endpoint in tnsnames.ora instead of the private endpoint URL (FQDN) or edit the host’s /etc/hosts file for the FQDN to be resolved to the IP of the private endpoint.

Conclusion

Networking in Oracle Cloud provides different kinds of VCN peering to connect multiple VCNs in the same region, across regions, and your own data center with Oracle Cloud. Security lists and network security groups allow you to implement access control by defining security rules as desired.

In all examples we were using statefull security list rules. If you are concerned about high levels of network traffic coming to your VCN, consider using stateless security list rules to limit the level of connection tracking your VCN must perform.

Looking for a networking hands-on lab? What about rebuilding this architecture ? 🙂

Would you like to get notified when the next post is published?