Introduction

In this blog series we are going to discuss Oracle Cloud Infrastructure (OCI) networking best practices and provide you with some recommendations and tips to help you design and build your network infrastructure.  This is the first blog in this series and will cover OCI network design, Virtual Cloud Networks (VCN) and subnets.  The topics for this blog series are outlined below:

• Part One - OCI Network Design, VCN, and Subnets Best Practices, Recommendations, and Tips
• Part Two - OCI Network Security Best Practices, Recommendations, and Tips
• Part Three - OCI Network Connectivity Best Practices, Recommendations, and Tips
• Part Four - OCI Network Monitoring, Observability, and Management Best Practices, Recommendations, and Tips
• This blog series has also been adapted and published as a Solution Playbook in the Oracle Architecture Center

Take Advantage of Oracle Provided Services and Learn OCI Networking

Rationale

If you are new to OCI, or specifically OCI networking, Oracle has many options available to you to help you increase your knowledge and skills.  Taking advantage of these will help you, and your organization, when it comes time to designing, provisioning, and supporting your OCI network infrastructure down the road.

Recommendation

• Review the below Oracle online learning options
  • Oracle Learning (Free and Paid)
  • Oracle Learning YouTube Channel (Free)
  • OCI Networking in the Cloud YouTube Series (Free)
• Talk to your Oracle account team about any live Oracle provided OCI network learning sessions.  As an example, my team conducts OCI network training workshops for customers on a regular basis that can be customized for your needs.
• Bookmark and check the Oracle A-Team networking blog often for specific information on products, uses cases, and examples
• Check out Oracle Live Labs for hands on self-paced lab workshops 

Tip: If you are familiar with other Cloud Service Providers (CSP), check out the below links for service comparisons between OCI and other CSPs.  This can help you understand the OCI terms and concepts and how they are comparable to other CSPs.

• OCI for AWS professionals
• OCI for Azure professionals

Perform Your OCI Network Design Early

Rationale

Often we see customers jumping right away to deploying their applications or workloads into OCI without taking the time to properly design the OCI Network.  VCNs, subnets, gateways, etc. are typically built very quickly using default parameters and Classless Inter-Domain Routing (CIDRs) can end up overlapping with on-prem CIDRs causing issues later.  Having the network design completed prior to your deployment forces you to think about and resolve these issues early and prevent any barriers to having a successful deployment later. While it's possible to change some OCI network design elements later, it can be a painful experience and could cause disruption.

Recommendation

• Make sure to add appropriate time and resources in the beginning of your project plan to properly perform the OCI network design.
• You can also work with your Oracle account team to see if Oracle can provide OCI networking specialists to assist you as well.
• Your OCI network design should include, at a minimum, the layout, topology, sizing of the VCNs and subnets, Domain Name Service (DNS), and any external network connectivity to on-premise or other CSPs.

Tip: Investigate if there are any reference architectures for your specific deployment that can be leveraged as a starting point.  For example, Oracle has many reference architectures for common Oracle OCI deployments such as E-Business Suite (EBS), Siebel, and ExaCS in the Oracle Architecture Center.

Tip: OCI diagram templates are located here https://docs.oracle.com/en-us/iaas/Content/General/Reference/graphicsfordiagrams.htm

Use a Standard OCI Network Resource Naming Convention

Rationale

When provisioning the necessary network resources in OCI, such as VCNs, subnets, security lists, Dynamic Routing Gateways (DRG), you will be prompted to input a name for the resource.  Having a standard naming convention for your OCI resources will help you, and other OCI users later, with understanding the purpose, location and how that resource is differentiated from others.  Some of these resource names can be changed later, however some cannot, such as DNS label, and others must be changed via CLI, such as VCN name.  

Recommendation

• Consider using a descriptive acronym in the name somewhere to help you and other OCI users know what that resource is.  For example:
• Place 'vcn' somewhere in the VCN name (VCN Name: vcn-prod-ashburn)
• Place 'drg' somewhere in the DRG name (DRG Name: drg-ashburn)
• Place 'sl' somewhere in your Security List name (Security List Name: web-sn-sl)
• Your OCI network resource naming convention should be one piece of your overall OCI resource naming convention

Tip: Consider using OCI tags to add metadata information to the resources.  See https://docs.oracle.com/en-us/iaas/Content/Tagging/Concepts/taggingoverview.htm

Tip: Take a look at the naming convention recommendations from the Oracle Cloud Foundation 

Design and Implement Hybrid DNS With OCI Private DNS

Rationale

The OCI Private DNS service provides the ability to:

• Create and maintain custom DNS domains and records within your VCNs (such as oci.customer.com)
• Integrate DNS resolution across VCNs, with on-premise, and other environments like CSPs or trusted partners

This gives customers the ability to do seamless DNS resolution between OCI and on-premise infrastructure.  Without this, the default behavior of OCI is limited to performing DNS resolution internal to the VCN using the default domain of oraclevcn.com and you may find yourself troubleshooting connectivity problems later because you cannot resolve the DNS names for resources in other VCNs or on-premise.

More info on OCI Private DNS:

• https://blogs.oracle.com/cloud-infrastructure/post/announcing-oracle-cloud-infrastructure-private-dns
• https://www.ateam-oracle.com/post/oci-private-dns---common-scenarios
• https://www.ateam-oracle.com/post/private-dns-implementation

Recommendation

• Make DNS a part of your network design early and involve your DNS administrators
• Think about all the environments where you want seamless DNS name resolution (to/from on-premise, OCI VCNs, other CSP, etc.) and use OCI Private DNS to enable a hybrid DNS solution
• Decide early whether the default oraclevcn.com domain name or a custom domain name is the direction you want to go.  

Tip: Try out this Private DNS lab from Oracle Live Labs to see it in action!

Tip: Keep in mind that when you use a custom domain name in OCI, the management of the custom zones and records is manual whereas the default oraclevcn.com is automatic.

Consider a Hub-And-Spoke VCN Design

Rationale

Oracle best practice and recommendation for most OCI deployments is to use a multiple VCN design in a hub-and-spoke topology utilizing the DRG for connectivity.

For more information on this design, see https://docs.oracle.com/en/solutions/hub-spoke-network-drg/index.html

Benefits of a multiple VCN hub-and-spoke design using the DRG:

• Isolation and segmentation of different environments
• Provide common services inside the hub VCN that all the spoke VCNs can share, such as log server, DNS, file sharing
• Scalability as the DRG allows you to connect up to 300 VCNs.  Once you have a hub-and-spoke VCN design, it's very simple to add additional VCNs in the future as you grow
• Network security appliances such as firewalls can be placed in the hub VCN to inspect traffic destined to or sourced from the spoke VCNs

Recommendation

• Think about how and where you might want to segment your different network environments and consider putting each into its own VCN.  Common customer examples:
  • Placing Prod and Non-Prod into separate VCNs to segment the different environments from each other
  • Placing different internal or external customers in different VCNs to separate them 
• If you have a very simple or small OCI deployment, such as a Proof of Concept (POC), and you are not needing any of the benefits outlined above, then a single VCN solution may be a good approach.

Tip: Take a look at the hub and spoke section of the Oracle Cloud Foundation

Know What Type of Subnets You Need Before Provisioning

Rationale

VCN CIDRs need to be broken down into one or more subnets where resources can be placed.  Those subnets can either be regional or Availability Domain (AD) specific subnets and they can also be either public or private subnets.  Regional vs. AD specific and public vs. private cannot be changed later so making sure they are correct when you provision them will help minimize disruption and complexity later.  In addition to the subnets needing to be terminated and then re-provisioned correctly, the resources already deployed in those subnets will also need to be terminated and then re-provisioned in the new subnets.   

Recommendation

• Make sure and understand if you need public or private subnets before you create them.  Think about potential traffic flows and where the traffic is sourced or destined to.
• Only place resources that have a specific requirement for inbound Internet connectivity in public subnets.  Place all other resources in private subnets.
• Provision regional subnets unless you have a specific requirement that dictates using AD specific subnets

Design and Size Your VCN and Subnets to Meet Both Current and Future Requirements

Rationale

Sizing the VCNs and subnets appropriately during your design will help you:

• Prepare for future growth and expansion
• Simplify your IP allocation by using contiguous and summarizable IP addressing space 

For more information see https://www.ateam-oracle.com/post/vcn-design-and-sizing

Recommendation

• Before you create a VCN, determine the number of CIDR blocks required and the size of each block based on the number of resources and subnets that you plan to deploy in the VCN.
• Make sure to allow for some amount of future growth inside the subnets and the VCNs
• Error on the side of having too large of a CIDR than too small
• Although you can add as many as 5 CIDRs to a VCN, adding more later to accommodate growth may result in non-contiguous CIDRs depending on your IP address allocation
  • For example, customer has allocated 10.0.0.0/24 to a VCN to start testing a workload.  After testing is successful and they want to expand the workload into more VMs they need more IPs and subnets, however the next IP block 10.0.1.0/24 has been allocated in their IP address tool to another purpose.  As a result they are forced to add a non-contiguous CIDR to the VCN.  
• If possible, use CIDR blocks that are within the standard RFC 1918 private IP address space
• Avoid using 169.254.0.0/16 IP address space.  Many providers, including Oracle, use that same IP space in their network and can cause problems.
• Select unique CIDR blocks that don't overlap with any other network (in OCI, your on-premises data centers, or another CSP)
• When you design the subnets, consider your traffic flow and security requirements.  Attach all the resources within a specific tier or role to the same subnet.

Use Custom VCN Route Tables and Security Lists for Each Subnet

Rationale

When provisioning subnets you will be prompted to choose a VCN route table and a security list to use with each subnet.  OCI provides a default route table and a default security list that, if used, is shared with all subnets that are associated with them.  

Using the default options for these is good for a simple deployment or to get you started but not a recommended approach for a production design that includes multiple subnets.  Having VCN route tables and security lists that are specific to each subnet allows you to maintain granular routing and security control to the individual subnets instead of having them share these resources.  
    
    For example:

• You may want a private subnet to have a default route to a NAT gateway and a public subnet have a default route to an internet gateway which would necessitate having separate VCN route tables. 
• You may want to allow a specific traffic flow to one subnet but not another which would necessitate having separate security lists

Recommendation

• Create and associate a unique VCN route table for each subnet 
• Create and associate a unique security list for each subnet 

Tip: Create and associate these unique VCN route tables and security lists when you provision the subnets as it will be more difficult to change from the default ones later.

Enable VCN Flow Logs for Each Subnet

Rationale

VCN flow logs show details about traffic that passes through, is sourced from, or destined to your VCN.  VCN flow logs are not enabled by default when a subnet is created.

For more information see: 

• https://docs.oracle.com/en-us/iaas/Content/Network/Concepts/vcn_flow_logs.htm
• https://blogs.oracle.com/cloud-infrastructure/post/announcing-vcn-flow-logs-general-availability-for-oracle-cloud-infrastructure

Enabling VCN flow logs on all subnets will help you later with auditing traffic and troubleshooting your VCN and security lists.  

Recommendation

• Enable VCN flow logs for each subnet after you create the subnet
• Consider creating a separate log group just for VCN flow logs
• VCN flow logs should be one piece of an overall OCI logging architecture and design

Tip: There is a cost for OCI logging storage above a certain threshold.  Make sure you understand your OCI logging needs and budget and consider only enabling VCN Flow Logs on a temporary and as needed basis for troubleshooting purposes if you want to limit the usage.

Stay tuned for Part Two of this blog series which will focus on OCI Network Security Best Practices, Recommendations, and Tips