Segregation & Segmentation

One of the essential design decisions when migrating workloads to OCI is how to implement an optimal degree of segregation and segmentation. Getting this right is important so that the benefits of protection and flexibility are delivered at the outset.

Most organizations will already have policies in place for network segregation and segmentation. If this is the case, then those policies can continue to be applied seamlessly in OCI.

Generally speaking, the principles behind segregation and segmentation need to align with the network topology that is being implemented. As previously highlighted, the recommended network topology for OCI is a hub and spoke design. But what constitutes a spoke? Should it be a business unit, a geography and environment type, a workload, or a technology layer?

The Organizational Structure section of the Cloud Foundation provides further guidance for this topic. This section focuses on how the various network components can be used to implement the structure.

The objective of segregation and segmentation is to;

This is achieved by isolating groups of resources from each other so that network traffic cannot pass between them unless explicitly granted.

Guidance On IP Address Ranges

VCN Size Netmask Subnet Size IPs/Subnet Total Subnets Total IPs
Small /24 /27 29 8 232
Medium /20 /24 253 16 4,048
Large /18 /22 1,021 16 16,336
Extra Large /16 /20 4,093 16 65,488

The first two IP addresses and the last one in each subnet’s CIDR are reserved

Classless inter-domain routing (CIDR) is a set of Internet protocol (IP) standards used to create unique identifiers for networks and individual devices on the network.

We recommend the following Wikipedia page if you wish to get a general understanding of this topic; CIDR on Wikipedia

There are a few things to consider about the CIDR blocks that are used within an OCI network.

Important:

To avoid IP Address conflicts, CIDR blocks, used within a Virtual Cloud Network (VCN), should not overlap with CIDR blocks that exist elsewhere on OCI, on-premises, or third-party clouds. It is important to ensure that the CIDR block used to allocate the IP addresses is unique and with a big enough range to accommodate all of the network resources required.

General Notes on IPv6 Support

IPv6 addressing is supported for all commercial and government regions.

Both FastConnect and Site-to-Site VPN can be configured to support IPv6 traffic between your VCNs and on-premises network. Dual-stack IPv4/IPv6 is supported.

All VCNs support IPv4 by default. You can optionally enable IPv6 during VCN creation. Enabling IPv6 for the VCN also allows you to use IPv6 or IPv4 for any associated subnets. This means that a VCN can have a mix of IPv4-only subnets and IPv6-enabled subnets. Inbound and outbound initiated IPv6 connections are supported between your VCN and your on-premises network (or the internet). Intra-VCN and inter-VCN IPv6 communication is also supported.

For compute instances within an IPv6 enabled subnet, adding an IPv6 address both before and after instantiation is possible.

The following Network Gateways currently support both IPv4 and IPv6 traffic;

Isolation With Virtual Circuits

If an organization requires network traffic isolation that restricts traffic between different organization units, thus can be achieved by implementing multiple virtual circuits over a FastConnect connection. There are no limits to how many virtual circuits there can be. The virtual circuit is attached to a dynamic gateway router (DRG) which has one or more Virtual Cloud Networks (VCN’s) attached to it.

Isolation With VCN’s

For a Virtual Cloud Network (VCN) to be reachable by on-premises resources, it must be attached to a Dynamic Routing Gateway (DRG). This also enables multiple VCN’s attached to the same DRG to communicate with each other. Without a DRG, communication is still possible between VCNs using a Local Peering Gateway, but there is then no way to communicate with on-premises resources. It is generally recommended that a DRG is used to provide both on-premises communication (via FastConnect or VPN) and also to enable local peering of VCN’s

By default, all VCNs connected to a DRG are routable to each other. You can isolate VCNs by setting entries within the DRG and VCN Route Tables.

Isolation with Subnets

Within a VCN, there can be one or more subnets. Subnets can be one of two types; Public or Private. In both cases, each VNIC within the subnet will have a private IP address from the subnets allocated CIDR. In the case of a Public subnet, there is the option also to have a public IP address. This, in the case of IPV4, will be allocated by Oracle (IPV6 can be specified)

Resources and traffic within and across subnets can be managed using specific Route Tables, Network Security Groups and Security Lists.

Tip:

You can achieve an optimal level of segregation and separation by combining each of these isolation techniques across virtual circuits, VCNs and subnets.

Planning The Network

Each VCN can have a maximum of 4093 subnets and 64,000 IPV4 addresses. Deciding how to split the network (VCN) up will determine the maximum number of subnets and IP addresses for your configuration. This has a knock-on effect on the segregation and separation of resources and implications for how routing is specified and maintained.

The network design must take into account many considerations, including security, access privileges and growth. At its simplest, you could have one extensive network across your organization with many subnets.

However, this may be problematic as you may need to address more than 64,000 network resources. You may also want greater control over the access and privileges of different types of OCI based administrators.

In addition, the larger the surface area of attack, the greater the potential damage and loss that can be caused by unauthorized access and activity.

How Many VCN’s?

Each VCN can be in one, and only one, compartment.

Policies provide the means to grant privileges to administrators (via groups). These policies are defined for a resource family (e.g. virtual networks) or a resource type (e.g. subnets) within a compartment. There is no way of allocating privileges specifically to an instance of a resource type (one particular subnet, for example).

Therefore, having one extensive network with multiple subnets means that all network administrators would have privileges against all subnets. This would be true regardless of whether the subnet belongs to a specific business unit, is production or non-production, or is a database, application, or web tier.

Such an open set of access and privileges may be undesirable for your organization. For more detailed information and guidance on this topic, please refer to the Control & Governance section of the Cloud Foundation.

Having multiple VCN’s will allow an organization to address more network resources. However, if each VCN is in the same compartment, the same “open access” problem for administrators still occurs. It may be preferable to put each VCN into its own unique compartment or, more optimally, to group VCNs that the same administrative group can manage into the same compartment.

For example, for a set of production applications, you might choose to put all associated resources into a “Production” Compartment. You may decide to have one VCN for all applications, one VCN per related group of applications, or even one VCN per application within that compartment.

We will discuss these options further in more depth later in this section.

All of the non-production resources casn now be put into a “Non-Production” Compartment with the same VCN structure as production. In this way, we ensure that we grant administrative privileges at a level that supports the integrity of the organization’s structure.

Grouping Workloads into VCN’s

Within each VCN you may choose to group applications.

Grouping different applications within the same VCN makes sense when they frequently communicate with others in the group through frequent or multiple integrations.

When doing this, it is also good practice to keep different application tiers within a dedicated subnet. Being inside dedicated subnets within the same VCN reduces traffic passing through the router (DRG) and simplifies the configuration of the routing tables. This is because, by default, subnets within the same VCN are routable.

This allows us to use Security Lists to control which ports and traffic types are enabled between the different application tiers. These may need to be different for each application.

Dedicated VCN’s per application

You may decide to give each application/workload its own dedicated VCN.

If so, we still recommend having separate subnets for each application tier.

The principle benefit of dedicated VCN’s is enhanced logical separation of traffic, whereas the cost is likely to be in maintaining routing tables between the various VCN’s for integration purposes.

Dedicated VCN’s per application also allows the multiple re-use of CIDR ranges for different applications.

Ideally, CIDR blocks for a VCN should not overlap with other CIDR blocks in OCI (or on-premise). However, it may sometimes be needed so that an on-premises deployment can be replicated in OCI.

Summary

There are many ways to configure OCI networks to deliver separation and segregation. The approach you take is a balance between the need for administrative and traffic separation and the operational cost of maintaining routing tables for cross-application integrations.

Important:

Your organizational structure, and Compartment design, will play a critical role in helping you achieve this balance. The decisions taken in designing the Compartment structure and Network topology will have far-reaching consequences for the administration of other resources in OCI, and not just the network. For more details on this, please visit the Control & Governance section of the Cloud Foundation.