Learn About Network Design

OCI network infrastructure components, such as VCNs, subnets, and gateways, that are built without proper planning using the default parameters can lead to problems after deployment that can be difficult to resolve. A well planned network design helps set up a successful implementation and makes it easy for your team and organization to use.

Perform Your Network Design Early

Designing your network completely before deployment allows you to catch issues early and remove barriers to a successful deployment. While it's possible to change some OCI network design elements later, it can require significant effort and can disrupt the business flow temporarily.

Oracle recommends the following for your OCI network design:

1. Plan appropriate time and allocate sufficient resources in your project plan to properly design your OCI network.
2. Minimally include the layout, topology, sizing of VCNs and subnets, Domain Name Service (DNS), and any external network connectivity to on-premises or other CSPs.
3. Consider working with your Oracle account team to see if Oracle can provide OCI networking specialists to assist you.

The following is an example of a network design diagram.

Description of the illustration vcn-network-design-example.png

Tip:

Search for relevant reference architectures for your specific deployment to use as a starting point. For example, Oracle has many reference architectures for common Oracle OCI deployments such as Oracle E-Business Suite, Siebel, and ExaCS on the Oracle Architecture Center.

Consider a Hub-and-Spoke VCN Design

Oracle's 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.

The following are the benefits of a multiple VCN hub-and-spoke design using the DRG:

• Isolate and segment different environments.
• Provide common services inside the hub VCN that all the spoke VCNs can share, such as log server, DNS, file sharing.
• Scale your networking easily as the DRG allows you to connect up to 300 VCNs. Once you have a hub-and-spoke VCN design, it's easy to add additional VCNs.
• Place network security appliances such as firewalls in the hub VCN to inspect traffic destined to or sourced from the spoke VCNs.

The following diagram shows an example of using a hub-and-spoke network architecture:

Description of the illustration hub-and-spoke-topology.png

Oracle recommends the following:

• Decide how and where you might want to segment different network environments and consider putting each into its own VCN. The following are common customer examples for using separate VCNs for environments:
  • Prod and non-prod environments
  • Internal or external customers
• If you have a very simple or small OCI deployment, such as a Proof of Concept (POC), and don't need any of the benefits discussed here, then using a single VCN is a good approach. Even with a single VCN, you can always place an environment into a different VCN in future to take advantage these recommendations.

Use Standard OCI Naming Conventions

When provisioning the necessary network resources in OCI, such as VCNs, subnets, security lists, and Dynamic Routing Gateways (DRGs), you will be prompted to enter a resource name. Using a standard naming convention for your OCI resources helps you and other OCI users to understand the purpose and location of resources, and also indicates how a resource differentiates from others.

Some of these resource names can be changed later, however some can't, such as DNS label. Others such as VCN name must be changed using the command-line interface (CLI).

Oracle recommends the following:

1. Use a descriptive acronym somewhere in the name to describe the purpose of a resource. For example:
   • vcn somewhere in the VCN name (VCN Name: vcn-prod-ashburn)
   • drg somewhere in the DRG name (DRG Name: drg-ashburn)
   • sl somewhere in your Security List name (Security List Name: web-sn-sl)
2. Ensure your OCI network resource naming convention is a part of your overall OCI resource naming convention.
3. Consider using tags to add metadata information to resources.

Design a Hybrid DNS with OCI Private DNS

The default behavior of OCI is limited to performing internal DNS resolution to the VCN using oraclevcn.com as the default domain. This can lead to connectivity problems later because you cannot resolve the DNS names for resources in other VCNs or on-premises environments.

The OCI Private DNS service provides the ability to seamlessly resolve DNS between OCI and on-premises infrastructure:

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

Oracle recommends the following:

• Include DNS as a part of your early network design and involve your DNS administrators.
• Consider all the environments where you want seamless DNS name resolution (to or from on-premises environments, OCI VCNs, other CSPs, and so on) and use OCI private DNS to enable a hybrid DNS solution.
• Consider the caveats early and determine the direction you want to proceed. Decide if you want to use the default oraclevcn.com domain name or a custom domain name.

The following diagram shows an example architecture with custom domain names using a private DNS resolver for resolution of local, internal resources with custom domain names:

Description of the illustration architecture-deploy-private-dns.png

Tip:

When you use a custom OCI domain name, the management of the custom zones and records is manual. The default oraclevcn.com is automatic.

Decide the Subnet Types Before Provisioning

VCN CIDRs must be broken down into one or more subnets to organize resources. The subnets can either be regional or Availability Domain (AD) specific subnets and they can also be either public or private subnets.

Decisions about regional versus AD specific subnets, and public versus private subnets can't be changed later. Ensure they are correct when you provision them initially to minimize disruption and complexity at a later stage.

Oracle recommends the following:

• Determine if you need public or private subnets before you create them. Consider potential traffic flows and where the traffic is sourced or destined to.
• Place resources that have a specific requirement for inbound internet connectivity in public subnets and all other resources in private subnets.
• Provision regional subnets unless you have a specific requirement that requires using AD specific subnets.

Tip:

To make changes later, you must terminate the subnets and then reprovision them. You must also terminate the resources deployed in the subnets and then reprovision the resources in the new subnets.

Design and Size Your Subnets

Design and size your subnets to meet both current and future requirements. Sizing 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

Oracle recommends the following:

• 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.
• Preferably lean towards creating a larger CIDR than too small.
• You can add as many as five CIDRs to a VCN, however, adding more later to accommodate growth may result in non-contiguous CIDRs depending on your IP address allocation.
  • For example, you allocated 10.0.0.0/24 to a VCN to start testing a workload. After successful testing, if you want to expand the workload into more VMs, it needs more IPs and subnets. However, the next IP block 10.0.1.0/24 was allocated in your IP address tool for another purpose. As a result, you 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 the 169.254.0.0/16 IP address space. Many providers, including Oracle, use that same IP space in their network and that 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 Route Tables and Security Lists for Each Subnet

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. Using 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

Oracle recommends the following:

• 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.