Network Setup for Exadata Cloud Infrastructure Instances
This topic describes the recommended configuration for the VCN and several related requirements for the Exadata Cloud Infrastructure instance.
Before you set up an Exadata Cloud Infrastructure instance, you must set up a virtual cloud network (VCN) and other Networking service components.
- VCN and Subnets
To launch an Exadata Cloud Infrastructure instance, you must have a Virtual Cloud Network and at least two subnets: - Node Access to Object Storage: Static Route
To be able to back up databases, and patch and update cloud tools on an Exadata Cloud Infrastructure instance, you must configure access to Oracle Cloud Infrastructure Object Storage. - Service Gateway for the VCN
Your VCN needs access to both Object Storage for backups and Oracle YUM repos for OS updates. - Security Rules for the Oracle Exadata Database Service on Dedicated Infrastructure
This section lists the security rules to use with Exadata Cloud Infrastructure. - Ways to Implement the Security Rules
Learn how to implement security rules within your VCN using the networking service. - Network Requirements for Oracle Database Autonomous Recovery Service
Oracle Database Autonomous Recovery Service requires a registered Recovery Service subnet dedicated to backup and recovery operations in your database virtual cloud network (VCN).
Parent topic: Preparing for Exadata Cloud Infrastructure
VCN and Subnets
To launch an Exadata Cloud Infrastructure instance, you must have a Virtual Cloud Network and at least two subnets:
To launch an Exadata Cloud Infrastructure instance, you must have a Virtual Cloud Network, at least two subnets and select the type of DNS resolver you will use:
- A VCN in the region where you want the Exadata Cloud Infrastructure instance
-
At least two subnets in the VCN. The two subnets are:
- Client subnet
- Backup subnet
- Choose which method of DNS name resolution you will use. See Choices for DNS in Your VCN
Note
For Exadata Cloud Infrastructure instances using The New Exadata Cloud Infrastructure Resource Model , networking is configured on the cloud VM cluster resource.
In general, Oracle recommends using regional subnets , which span all availability domains in the region. For more information, see Overview of VCNs and Subnets.
You will create custom route tables route tables for each subnet. You will also create security rulessecurity rules to control traffic to and from the client network and backup network of the Exadata compute nodes (for The Cloud VM Cluster Resource, nodes are called virtual machines). More information follows about those items.
- Option 1: Public Client Subnet with Internet Gateway
This option can be useful when doing a proof-of-concept or development work. - Option 2: Private Subnets
Oracle recommends private subnets for a production system. - Requirements for IP Address Space
IP addresses must not overlap, especially when Exadata Cloud Infrastructure VM Clusters (and thus VCNs) are in more than one region. - Configuring a Static Route for Accessing the Object Store
To route backup traffic to the backup interface (BONDETH1), you need to configure a static route on each of the compute nodes in the cluster. - Setting Up DNS for an Exadata Cloud Infrastructure Instance
DNS lets you use host names instead of IP addresses to communicate with an Exadata Cloud Infrastructure instance. - DNS: Short Names for the VCN, Subnets, and Exadata Cloud Infrastructure instance
The Internet and VCN resolver enables hostname assignment to the nodes, and DNS resolution of those hostnames by resources in the VCN. - DNS: Between On-Premises Network and VCN
Oracle recommends using a private DNS resolver to enable the use of hostnames when on-premises hosts and VCN resources communicate with each other. - Configure Private DNS
Prerequisites needed to use Private DNS.
Related Topics
Parent topic: Network Setup for Exadata Cloud Infrastructure Instances
Option 1: Public Client Subnet with Internet Gateway
This option can be useful when doing a proof-of-concept or development work.
You can use this setup in production if you want to use an internet gateway with the VCN, or if you have services that run only on a public network and need access to the database. See the following diagram and description.
![Description of network_exa_public_client.png follows Description of network_exa_public_client.png follows](img/network_exa_public_client.png)
You set up:
-
- Public client subnet (public means that the resources in the subnet can have public IP addresses at your discretion).
- Private backup subnet (private means that the resources in the subnet cannot have public IP addresses and therefore cannot receive incoming connections from the internet).
-
Gateways for the VCN:
- Internet gateway (for use by the client subnet).
- Service gateway (for use by the backup subnet). Also see Option 1: Service Gateway Access to OCI Services .
-
- Custom route table for the public client subnet, with a route for 0.0.0.0/0, and target = the internet gateway.
- Separate custom route table for the private backup subnet, with a route rule for the service CIDR labels (see about CIDR labels under Overview of Service Gateways and Available Sevice CIDR labels, and target = the service gateway. Also see Option 1: Service Gateway Access to OCI Services.
- Security rules to enable the desired traffic to and from the Exadata virtual machines compute nodes. See Security Rules for the Oracle Exadata Database Service on Dedicated Infrastructure.
- Node Access to Object Storage: Static Route on the Exadata Cloud Service instance's compute nodes (to enable access to OCI services by way of the backup subnet).
Important See this known issue for information about configuring route rules with service gateway as the target on route tables associated with public subnets.
Parent topic: VCN and Subnets
Option 2: Private Subnets
Oracle recommends private subnets for a production system.
Both subnets are private and cannot be reached from the internet. See the following diagram and description.
![Description of network_exa_private_client.png follows Description of network_exa_private_client.png follows](img/network_exa_private_client.png)
You set up:
-
- Private client subnet.
- Private backup subnet.
-
Gateways for the VCN:
- Dynamic routing gateway (DRG), with a FastConnect or IPSec VPN to your on-premises network (for use by the client subnet).
- Service gateway For use by the backup and client subnets to reach OCI Services, such as Object Storage for backups, YUM for OS updates, IAM (Identitiy Access Management) and OCI Vault (KMS Integration) Also see Option 2: Service Gateway Access to Both Object Storage and YUM Repos.
- NAT gateway(optional) For use by the client subnet to reach public endpoints not supported by the service gateway.
-
-
Custom route table for the private client subnet, with the following rules:
- A rule for the on-premises network's CIDR, and target = DRG.
- A rule for the service CIDR label called All <region> Services in Oracle Services Network, and target = the service gateway. The Oracle Services Network is a conceptual network in Oracle Cloud Infrastructure that is reserved for Oracle services. The rule enables the client subnet to reach the regional Oracle YUM repository for OS updates. Also see Option 2: Service Gateway Access to Both Object Storage and YUM Repos.
- Optionally, a rule for 0.0.0.0/0, and target = NAT gateway.
- Separate custom route table for the private backup subnet, with one rule:
- The same rule as for the client subnet: for the service CIDR label called All <region> Services in Oracle Services Network, and target = the service gateway. This rule enables the backup subnet to reach the regional Object Storage for backups.
-
- Security rules to enable the desired traffic to and from the Exadata nodes. See Security Rules for the Exadata Cloud Service instance.
- Optionally add a Static route on the compute nodes to other OCI services (for VM clusters, the virtual machines) to enable access, if the services are only reachable on the backup subnet and not via. the client subnet, e.g. when using a NAT Gateway.
Parent topic: VCN and Subnets
Requirements for IP Address Space
IP addresses must not overlap, especially when Exadata Cloud Infrastructure VM Clusters (and thus VCNs) are in more than one region.
If you're setting up Exadata Cloud Infrastructure VM Clusters (and thus VCNs) in more than one region, make sure the IP address space of the VCNs does not overlap. This is important if you want to set up disaster recovery with Oracle Data Guard.
For Exadata X8 and lower, the two subnets you create for the Exadata Cloud Infrastructure VM Clusters must not overlap with 192.168.128.0/20.
For Exadata X8M and X9M, IP addresses (100.106.0.0/16 and 100.107.0.0/16) are used for the interconnect.
The following table lists the minimum required subnet sizes, depending on the Exadata VM Infrastructure for each VM Cluster size. For the client subnet, each node requires four IP addresses, and in addition, three addresses are reserved for Single Client Access Names (SCANs). For the backup subnet, each node requires three addresses.
Rack Size | Client Subnet: # Required IP Addresses | Client Subnet: Minimum Size Note | Backup Subnet: # Required IP Addresses | Backup Subnet: Minimum Size Note |
---|---|---|---|---|
Base System or Quarter Rack per VM Cluster | (4 addresses * 2 nodes) + 3 for SCANs = 11 | /28 (16 IP addresses) | 3 address * 2 nodes = 6 | /28 (16 IP addresses) |
Half Rack per VM Cluster | (4 * 4 nodes) + 3 = 19 | /27 (32 IP addresses) | 3 * 4 nodes = 12 | /28 (16 IP addresses) |
Full Rack per VM Cluster | (4* 8 nodes) + 3 = 35 | /26 (64 IP addresses) | 3 * 8 nodes = 24 | /27 (32 IP addresses) |
Flexible infrastructure systems (X8M and higher) per VM Cluster | 4 addresses per database node (minimum of 2 nodes) + 3 for SCANs | Minimum size determined by total number of IP addresses needed for database nodes | 3 address per database node (minimum of 2 nodes) | Minimum size determined by total number of IP addresses needed for database nodes |
The Networking service reserves three IP addresses in each subnet. Allocating a larger space for the subnet than the minimum required (for example, at least /25 instead of /28) can reduce the relative impact of those reserved addresses on the subnet's available space.
Parent topic: VCN and Subnets
Configuring a Static Route for Accessing the Object Store
For instructions, see Node Access to Object Storage: Static Route.
Parent topic: VCN and Subnets
Setting Up DNS for an Exadata Cloud Infrastructure Instance
DNS lets you use host names instead of IP addresses to communicate with an Exadata Cloud Infrastructure instance.
You can use the Internet and VCN Resolver (the DNS capability built into the VCN) as described in DNS in Your Virtual Cloud Network. Oracle recommends using a VCN Resolver for DNS name resolution for the client subnet. It automatically resolves the Swift endpoints required for backing up databases, patching, and updating the cloud tooling on an Exadata instance.
Parent topic: VCN and Subnets
DNS: Short Names for the VCN, Subnets, and Exadata Cloud Infrastructure instance
The Internet and VCN resolver enables round robin resolution of the database's SCANs. It also enables resolution of important service endpoints required for backing up databases, patching, and updating the cloud tooling on an Exadata Cloud Infrastructure instance. The Internet and VCN Resolver is the VCN's default choice for DNS in the VCN. For more information, see DNS in Your Virtual Cloud Network and also DHCP Options.
When you create the VCN, subnets, and Exadata, you must carefully set the following identifiers, which are related to DNS in the VCN:
- VCN domain label
- Subnet domain label
- Hostname prefix for the Exadata Cloud Infrastructure instance's cloud VM cluster or DB system resource
These values make up the node's fully qualified domain name (FQDN):
<hostname_prefix>-######.<subnet_domain_label>.<vcn_domain_label>.oraclevcn.com
For example:
exacs-abcde1.clientpvtad1.acmevcniad.oraclevcn.com
In this example, you assign exacs
as the hostname prefix
when you create the cloud VM cluster or DB system. The Database service automatically
appends a hyphen and a five-letter string with the node number at the end. For
example:
- Node 1:
exacs-abcde1.clientpvtad1.acmevcniad.oraclevcn.com
- Node 2:
exacs-abcde2.clientpvtad1.acmevcniad.oraclevcn.com
- Node 3:
exacs-abcde3.clientpvtad1.acmevcniad.oraclevcn.com
- And so on
Requirements for the hostname prefix:
- Recommended maximum: 12 characters. For more information, see the example under the following section, "Requirements for the VCN and subnet domain labels".
- Cannot be the string localhost
Requirements for the VCN and subnet domain labels:
- Recommended maximum: 14 characters each. The actual underlying requirement is a total of 28 characters across both domain labels (excluding the period between the labels). For example, both of these are acceptable:
subnetad1.verylongvcnphx
orverylongsubnetad1.vcnphx
. For simplicity, the recommendation is 14 characters each. - No hyphens or underscores.
-
Recommended: include the region name in the VCN's domain label, and include the availability domain name in the subnet's domain label.
-
In general, the FQDN has a maximum total limit of 63 characters. Here is a safe general rule:
<12_chars_max>-######.<14_chars_max>.<14_chars_max>.oraclevcn.com
The preceding maximums are not enforced when you create the VCN and subnets. However, if the labels exceed the maximum, the Exadata deployment fails.
Parent topic: VCN and Subnets
DNS: Between On-Premises Network and VCN
Oracle recommends using a private DNS resolver to enable the use of hostnames when on-premises hosts and VCN resources communicate with each other.
See Private DNS resolvers for information on creating and using private resolvers. For a reference architecture see Use private DNS in your VCN in the Oracle Architecture Center.
Parent topic: VCN and Subnets
Configure Private DNS
Prerequisites needed to use Private DNS.
- Private view and private zone must be created before launching DB system provisioning. For details, see Private DNS resolvers.
- Forwarding to another DNS server should be set up beforehand in the DNS console. This can be done by going to the VCN's resolver, and creating the endpoint and then the rules. For details, see DNS in Your Virtual Cloud Network.
- Private zone's name cannot have more than 4 labels. For example, a.b.c.d is allowed while a.b.c.d.e is not.
- It is also required to add the private view to the resolver of the VCN. For details, see Adding a Private View to a Resolver.
- When provisioning a Exadata VM Cluster using Private DNS feature, Exadata needs to create reverse DNS zones in the compartment of Exadata VM Cluster. If the compartment has defined tags or tag defaults, additional policies related to managing tags are needed. For details, see:
Parent topic: VCN and Subnets
Node Access to Object Storage: Static Route
Caution:
You must configure a static route for Object Storage access on each compute node in an Exadata Cloud Infrastructure instance if you are not creating automatic backups with the Console, APIs, or CLIs. Otherwise, attempts to back up databases, and patch or update tools on the system, can fail.When you enable the first automatic backup for a database the static route configuration will be automatically done on the service.
If you want to patch the service before creating a database, the manual static route is required to be able to patch the GI or DB Home.
The static route may also be required to access other services (IAM, KMS) if these are not reachable via client subnet and only the backup subnet uses the setting to access all servcies within a region.
Parent topic: Network Setup for Exadata Cloud Infrastructure Instances
Object Storage IP allocations
Oracle Cloud Infrastructure Object Storage uses the CIDR block IP range 134.70.0.0/16 for all regions.
As of June 1, 2018, Object Storage no longer supports the following discontinued IP ranges. Oracle recommends that you remove these older IP addresses from your access-control lists, firewall rules, and other rules after you have adopted the new IP ranges.
The discontinued IP ranges are:
- Germany Central (Frankfurt): 130.61.0.0/16
- UK South (London): 132.145.0.0/16
- US East (Ashburn): 129.213.0.0/16
- US West (Phoenix): 129.146.0.0/16
Parent topic: Node Access to Object Storage: Static Route
To configure a static route for Object Storage access
-
SSH to a compute node in the Exadata Cloud Infrastructure instance.
ssh -i <private_key_path> opc@<node_ip_address>
-
Log in as opc and then sudo to the root user. Use
sudo su -
with a hyphen to invoke the root user's profile.login as: opc [opc@dbsys ~]$ sudo su -
-
Identify the gateway configured for the BONDETH1 interface.
[root@dbsys ~]# grep GATEWAY /etc/sysconfig/network-scripts/ifcfg-bondeth1 |awk -F"=" '{print $2}' 10.0.4.1
-
Add the following static rule for BONDETH1 to the
/etc/sysconfig/network-scripts/route-bondeth1
file:10.0.X.0/XX dev bondeth1 table 211 default via <gateway> dev bondeth1 table 211 134.70.0.0/17 via <gateway_from_previous_step> dev bondeth1
-
Restart the interface.
[root@dbsys ~]# ifdown bondeth1; ifup bondeth1;
The file changes from the previous step take effect immediately after the ifdown and ifup commands run.
-
Repeat the preceding steps on each compute node in the Exadata Cloud Infrastructure instance.
Parent topic: Node Access to Object Storage: Static Route
Service Gateway for the VCN
Your VCN needs access to both Object Storage for backups and Oracle YUM repos for OS updates.
Depending on whether you use Option1: Public Client Subnet with Internet Gateway or Option 2: Private Subnets described previously, you use the service gateway in different ways. See the next two sections.
- Option 1: Service Gateway Access to OCI Services
You configure the backup subnet to use the service gateway for access only to Object Storage. - Option 2: Service Gateway Access to Both Object Storage and YUM Repos
You configure both the client subnet and backup subnet to use the service gateway for access to the Oracle Services Network, which includes both Object Storage and the Oracle YUM repos.
Parent topic: Network Setup for Exadata Cloud Infrastructure Instances
Option 1: Service Gateway Access to OCI Services
You configure the backup subnet to use the service gateway for access only to Object Storage.
As a reminder, here's the diagram for option 1:
In general, you must:
- Perform the tasks for setting up a service gateway on a VCN, and specifically enable the service CIDR label called OCI <region> Object Storage.
- In the task for updating routing, add a route rule to the backup subnet's custom route table. For the destination service, use OCI <region> Object Storage and target = the service gateway.
- In the task for updating security rules in the subnet, perform the task on the backup network's network security group (NSG) or custom security list. Set up a security rule with the destination service set to OCI <region> Object Storage. See Rule Required Specifically for the Backup Network Rule Required Specifically for the Backup Network .
Option 2: Service Gateway Access to Both Object Storage and YUM Repos
You configure both the client subnet and backup subnet to use the service gateway for access to the Oracle Services Network, which includes both Object Storage and the Oracle YUM repos.
See this known issues for information about accessing Oracle YUM services through the service gateway.
As a reminder, here's the diagram for option 2:
In general, you must:
- Perform the tasks for setting up a service gateway on a VCN, and specifically enable the service CIDR label called All <region> Services in Oracle Services Network.
- In the task for updating routing in each subnet, add a rule to each subnet's custom route table. For the destination service, use All <region> Services in Oracle Services Network and target = the service gateway.
- In the task for updating security rules for the subnet, perform the task on the backup network's network security group (NSG) or custom security list. Set up a security rule with the destination service set to OCI <region> Object Storage. See Security Rules for the Oracle Exadata Cloud Service Security Rules for the Oracle Exadata Database Service on Dedicated Infrastructure. Note that the client subnet already has a broad egress rule that covers access to the YUM repos.
Here are a few additional details about using the service gateway for option 2:
- Both the client subnet and backup subnet use the service gateway, but to access different services. You cannot enable both the OCI <region> Object Storage service CIDR label and the All <region> Services in Oracle Services Network for the service gateway. To cover the needs of both subnets, you must enable All <region> Services in Oracle Services Network for the service gateway. The VCN can have only a single service gateway.
- Any route rule that targets a given service gateway must use an enabled service CIDR label and not a CIDR block as the destination for the rule. That means for option 2, the route tables for both subnets must use All <region> Services in Oracle Services Network for their service gateway rules.
- Unlike route rules, security rules can use either any service CIDR label (whether the VCN has a service gateway or not) or a CIDR block as the source or destination CIDR for the rule. Therefore, although the backup subnet has a route rule that uses All <region> Services in Oracle Services Network, the subnet can have a security rule that uses OCI <region> Object Storage. See Security Rules for the Exadata Cloud Service instance.
Security Rules for the Oracle Exadata Database Service on Dedicated Infrastructure
This section lists the security rules to use with Exadata Cloud Infrastructure.
Security rules control the types of traffic allowed for the client network and backup network of the Exadata's compute nodes. The rules are divided into three sections.
For X8M and X9M systems, Oracle recommends that all ports on the client subnet need to be open for ingress and egress traffic. This is a requirement for adding additional database servers to the system.
Rules Required for Both the Client Network and Backup Network
This section has several general rules that enable essential connectivity for hosts in the VCN.
If you use security lists to implement your security rules, be aware that the rules that follow are included by default in the default security list. Update or replace the list to meet your particular security needs. The two ICMP rules (general ingress rules 2 and 3) are required for proper functioning of network traffic within the Oracle Cloud Infrastructure environment. Adjust the general ingress rule 1 (the SSH rule) and the general egress rule 1 to allow traffic only to and from hosts that require communication with resources in your VCN.
General ingress rule 1: Allows SSH traffic from anywhere
- Stateless: No (all rules must be stateful)
- Source Type: CIDR
- Source CIDR: 0.0.0.0/0
- IP Protocol: SSH
- Source Port Range: All
- Destination Port Range: 22
General ingress rule 2: Allows Path MTU Discovery fragmentation messages
This rule enables hosts in the VCN to receive Path MTU Discovery fragmentation messages. Without access to these messages, hosts in the VCN can have problems communicating with hosts outside the VCN.
- Stateless: No (all rules must be stateful)
- Source Type: CIDR
- Source CIDR: 0.0.0.0/0
- IP Protocol: ICMP
- Type: 3
- Code: 4
General ingress rule 3: Allows connectivity error messages within the VCN
This rule enables the hosts in the VCN to receive connectivity error messages from each other.
- Stateless: No (all rules must be stateful)
- Source Type: CIDR
- Source CIDR: Your VCN's CIDR
- IP Protocol: ICMP
- Type: 3
- Code: All
General egress rule 1: Allows all egress traffic
- Stateless: No (all rules must be stateful)
- Destination Type: CIDR
- Destination CIDR: 0.0.0.0/0
- IP Protocol: All
Rules Required Specifically for the Client Network
The following security rules are important for the client network.
- Client ingress rules 1 and 2 only cover connections initiated from within the client subnet. If you have a client that resides outside the VCN, Oracle recommends setting up two additional similar rules that instead have the Source CIDR set to the public IP address of the client.
- Client ingress rules 3 and 4 and client egress rules 1 and 2 allow TCP and ICMP traffic inside the client network and enable the nodes to communicate with each other. If TCP connectivity fails across the nodes, the Exadata cloud VM cluster or DB system resource fails to provision.
Client ingress rule 1: Allows ONS and FAN traffic from within the client subnet
The first rule is recommended and enables the Oracle Notification Services (ONS) to communicate about Fast Application Notification (FAN) events.
- Stateless: No (all rules must be stateful)
- Source Type: CIDR
- Source CIDR: Client subnet's CIDR
- IP Protocol: TCP
- Source Port Range: All
- Destination Port Range: 6200
- Description: An optional description of the rule.
Client ingress rule 2: Allows SQL*NET traffic from within the client subnet
This rule is for SQL*NET traffic and is required in these cases:
- If you need to enable client connections to the database
- If you plan to use Oracle Data Guard
- Stateless: No (all rules must be stateful)
- Source Type: CIDR
- Source CIDR: Client subnet's CIDR
- IP Protocol: TCP
- Source Port Range: All
- Destination Port Range: 1521
- Description: An optional description of the rule.
Client egress rule 1: Allows all TCP traffic inside the client subnet
- Stateless: No (all rules must be stateful)
- Destination Type: CIDR
- Destination CIDR: 0.0.0.0/0
- IP Protocol: TCP
- Source Port Range: All
- Destination Port Range: 22
- Description: An optional description of the rule.
Client egress rule 2: Allows all egress traffic (allows connections to the Oracle YUM repos)
Client egress rule 3 is important because it allows connections to the Oracle YUM repos. It is redundant with the general egress rule in this topic (and in the default security list). It is optional but recommended in case the general egress rule (or default security list) is inadvertently changed.
- Stateless: No (all rules must be stateful)
- Destination Type: CIDR
- Destination CIDR: 0.0.0.0/0
- IP Protocol: All
- Description: An optional description of the rule.
Rule Required Specifically for the Backup Network
The following security rule is important for the backup network because it enables the DB system to communicate with Object Storage through the service gateway (and optionally with the Oracle YUM repos if the client network doesn't have access to them). It is redundant with the general egress rule in this topic (and in the default security list). It is optional but recommended in case the general egress rule (or default security list) is inadvertently changed.
Backup egress rule: Allows access to Object Storage
- Stateless: No (all rules must be stateful)
- Destination Type: Service
-
Destination Service:
- The service CIDR label called OCI <region> Object Storage
- If the client network does not have access to the Oracle YUM repos, use the service CIDR label called All <region> Services in Oracle Services Network
- IP Protocol: TCP
- Source Port Range: All
- Destination Port Range: 443 (HTTPS)
- Description: An optional description of the rule.
- Rules Required for Both the Client Network and Backup Network
This topic has several general rules that enable essential connectivity for hosts in the VCN. - Rules Required Specifically for the Client Network
The following security rules are important for the client network. - Rule Required Specifically for the Backup Network
The following security rule is important for the backup network because it enables the DB system to communicate with Object Storage through the service gateway (and optionally with the Oracle YUM repos if the client network doesn't have access to them). - Rules Required for Events Service
The compute instance must have either a public IP address or a service gateway to be able to send compute instance metrics to the Events service. - Rules Required for Monitoring Service
The compute instance must have either a public IP address or a service gateway to be able to send compute instance metrics to the Monitoring service.
Parent topic: Network Setup for Exadata Cloud Infrastructure Instances
Rules Required for Both the Client Network and Backup Network
This topic has several general rules that enable essential connectivity for hosts in the VCN.
If you use security lists to implement your security rules, be aware that the rules that follow are included by default in the default security list. Update or replace the list to meet your particular security needs. The two ICMP rules (general ingress rules 2 and 3) are required for proper functioning of network traffic within the Oracle Cloud Infrastructure environment. Adjust the general ingress rule 1 (the SSH rule) and the general egress rule 1 to allow traffic only to and from hosts that require communication with resources in your VCN.
- General ingress rule 1: Allows SSH traffic from anywhere
- General ingress rule 2: Allows Path MTU Discovery fragmentation messages
- General ingress rule 3: Allows connectivity error messages within the VCN
This rule enables the hosts in the VCN to receive connectivity error messages from each other. - General egress rule 1: Allows all egress traffic
Related Topics
General ingress rule 1: Allows SSH traffic from anywhere
- Stateless: No (all rules must be stateful)
- Source Type: CIDR
- Source CIDR: 0.0.0.0/0
- IP Protocol: SSH
- Source Port Range: All
- Destination Port Range: 22
General ingress rule 2: Allows Path MTU Discovery fragmentation messages
This rule enables hosts in the VCN to receive Path MTU Discovery fragmentation messages. Without access to these messages, hosts in the VCN can have problems communicating with hosts outside the VCN.
- Stateless: No (all rules must be stateful)
- Source Type: CIDR
- Source CIDR: 0.0.0.0/0
- IP Protocol: ICMP
- Type: 3
- Code: 4
General ingress rule 3: Allows connectivity error messages within the VCN
This rule enables the hosts in the VCN to receive connectivity error messages from each other.
- Stateless: No (all rules must be stateful)
- Source Type: CIDR
- Source CIDR: Your VCN's CIDR
- IP Protocol: ICMP
- Type: All
- Code: All
Rules Required Specifically for the Client Network
The following security rules are important for the client network.
- For X8M systems, Oracle recommends that all ports on the client subnet need to be open for ingress and egress traffic. This is a requirement for adding additional database servers to the system.
- Client ingress rules 1 and 2 only cover connections initiated from within the client subnet. If you have a client that resides outside the VCN, Oracle recommends setting up two additional similar rules that instead have the Source CIDR set to the public IP address of the client.
- Client ingress rules 3 and 4 and client egress rules 1 and 2 allow TCP and ICMP traffic inside the client network and enable the nodes to communicate with each other. If TCP connectivity fails across the nodes, the Exadata cloud VM cluster or DB system resource fails to provision.
- Client ingress rule 1: Allows ONS and FAN traffic from within the client subnet
The first rule is recommended and enables the Oracle Notification Services (ONS) to communicate about Fast Application Notification (FAN) events. - Client ingress rule 2: Allows SQL*NET traffic from within the client subnet
This rule is for SQL*NET traffic and is required in these cases: - Client egress rule 1: Allows all TCP traffic inside the client subnet
This rule is for SQL*NET traffic as noted. - Client egress rule 2: Allows all egress traffic (allows connections to the Oracle YUM repos)
Client egress rule 3 is important because it allows connections to the Oracle YUM repos.
Client ingress rule 1: Allows ONS and FAN traffic from within the client subnet
The first rule is recommended and enables the Oracle Notification Services (ONS) to communicate about Fast Application Notification (FAN) events.
- Stateless: No (all rules must be stateful)
- Source Type: CIDR
- Source CIDR: Client subnet's CIDR
- IP Protocol: TCP
- Source Port Range: All
- Destination Port Range: 6200
- Description: An optional description of the rule.
Parent topic: Rules Required Specifically for the Client Network
Client ingress rule 2: Allows SQL*NET traffic from within the client subnet
This rule is for SQL*NET traffic and is required in these cases:
- If you need to enable client connections to the database
- If you plan to use Oracle Data Guard
- Stateless: No (all rules must be stateful)
- Source Type: CIDR
- Source CIDR: Client subnet's CIDR
- IP Protocol: TCP
- Source Port Range: All
- Destination Port Range: 1521
- Description: An optional description of the rule.
Parent topic: Rules Required Specifically for the Client Network
Client egress rule 1: Allows all TCP traffic inside the client subnet
This rule is for SQL*NET traffic as noted.
- Stateless: No (all rules must be stateful)
- Destination Type: CIDR
- Destination CIDR: 0.0.0.0/0
- IP Protocol: TCP
- Source Port Range: All
- Destination Port Range: 22
- Description: An optional description of the rule.
Parent topic: Rules Required Specifically for the Client Network
Client egress rule 2: Allows all egress traffic (allows connections to the Oracle YUM repos)
Client egress rule 3 is important because it allows connections to the Oracle YUM repos.
It is redundant with the general egress rule 1: Allow all egress traffic (and in the default security list). It is optional but recommended in case the general egress rule (or default security list) is inadvertently changed.
- Stateless: No (all rules must be stateful)
- Destination Type: CIDR
- Destination CIDR: 0.0.0.0/0
- IP Protocol: All
- Description: An optional description of the rule.
Related Topics
Parent topic: Rules Required Specifically for the Client Network
Rule Required Specifically for the Backup Network
The following security rule is important for the backup network because it enables the DB system to communicate with Object Storage through the service gateway (and optionally with the Oracle YUM repos if the client network doesn't have access to them).
It is redundant with the general egress rule 1: Allows all egress traffic in (and in the ). It is optional but recommended in case the general egress rule (or default security list) is inadvertently changed.
Backup egress rule: Allows access to Object Storage
- Stateless: No (all rules must be stateful)
- Destination Type: Service
-
Destination Service:
- The service CIDR label called OCI <region> Object Storage
- If the client network does not have access to the Oracle YUM repos, use the service CIDR label called All <region> Services in Oracle Services Network
- IP Protocol: TCP
- Source Port Range: All
- Destination Port Range: 443 (HTTPS)
- Description: An optional description of the rule.
Parent topic: Rule Required Specifically for the Backup Network
Rules Required for Events Service
The compute instance must have either a public IP address or a service gateway to be able to send compute instance metrics to the Events service.
The default egress rules are sufficient to to allow the compute instance to send compute instance metrics to the Events service.
If the instance does not have a public IP address, set up a service gateway on the virtual cloud network (VCN). The service gateway lets the instance send compute instance metrics to the Events service without the traffic going over the internet. Here are special notes for setting up the service gateway to access the Events service:
- When creating the service gateway, enable the service label called All <region> Services in Oracle Services Network. It includes the Events service.
-
When setting up routing for the subnet that contains the instance, set up a route rule with Target Type set to Service Gateway, and the Destination Service set to All <region> Services in Oracle Services Network.
For detailed instructions, see Access to Oracle Services: Service Gateway.
Rules Required for Monitoring Service
The compute instance must have either a public IP address or a service gateway to be able to send compute instance metrics to the Monitoring service.
The default egress rules are sufficient to to allow the compute instance to send compute instance metrics to the Monitoring service.
If the instance does not have a public IP address, set up a service gateway on the virtual cloud network (VCN). The service gateway lets the instance send compute instance metrics to the Monitoring service without the traffic going over the internet. Here are special notes for setting up the service gateway to access the Monitoring service:
- When creating the service gateway, enable the service label called All <region> Services in Oracle Services Network. It includes the Monitoring service.
-
When setting up routing for the subnet that contains the instance, set up a route rule with Target Type set to Service Gateway, and the Destination Service set to All <region> Services in Oracle Services Network.
For detailed instructions, see Access to Oracle Services: Service Gateway.
Ways to Implement the Security Rules
Learn how to implement security rules within your VCN using the networking service.
The Networking service offers two ways to implement security rules within your VCN:
For a comparison of the two methods, see Comaprison of Security Lists and Network Security Groups.
- If you use network security groups
- If you use security lists
If you choose to use security lists, here is the recommended process:
Parent topic: Network Setup for Exadata Cloud Infrastructure Instances
If you use network security groups
If you choose to use network security groups (NSGs), here is the recommended process:
-
Create an NSG for the client network. Add the following security rules to that NSG:
- The rules listed in Rules Required for Both the Client Network and Backup Network
- The rules listed in Rules Required Specifically for the Client Network
-
Create a separate NSG for the backup network. Add the following security rules to that NSG:
- The rules listed in Rules Required for Both the Client Network and Backup Network
- The rules listed in Rules Required Specifically for the Client Network
- When the database administrator is Creating an Exadata Cloud Infrastructure Instance, they must choose several networking components (for example, which VCN and
subnets to use):
- When they choose the client subnet, they can also choose which NSG or NSGs to use. Make sure they choose the client network's NSG.
- When they choose the backup subnet, they can also choose which NSG or NSGs to use. Make sure they choose the backup network's NSG.
You could instead create a separate NSG for the general rules. Then when the database administrator chooses which NSGs to use for the client network, make sure they choose both the general NSG and the client network NSG. Similarly for the backup network, they choose both the general NSG and the backup network NSG.
Parent topic: Ways to Implement the Security Rules
If you use security lists
If you choose to use security lists, here is the recommended process:
If you choose to use security lists, here is the recommended process:
-
Configure the client subnet to use the required security rules:
- Create a custom security list for the client subnet and add the rules listed in Rules Required Specifically for the Client Network.
-
Associate the following two security lists with the client subnet:
- VCN's default security list with all its default rules. This automatically comes with the VCN. By default it contains the rules in Rules Required for Both the Client Network and Backup Network.
- The new custom security list you created for the client subnet.
-
Configure the backup subnet to use the required security rules:
- Create a custom security list for the backup subnet and add the rules listed in Rule Required Specifically for the Backup Network.
-
Associate the following two security lists with the backup subnet:
- VCN's default security list with all its default rules. This automatically comes with the VCN. By default it contains the rules in Rules Required for Both the Client Network and Backup Network.
- The new custom security list you created for the backup subnet.
Later when the database administrator creates the Exadata Cloud Service instance, they must choose several networking components. When they select the client subnet and backup subnet that you've already created and configured, the security rules are automatically enforced for the nodes created in those subnets.
WARNING:
Do not remove the default egress rule from the default security list. If you do, make sure to instead include the following replacement egress rule in the client subnet's security list:
- Stateless: No (all rules must be stateful)
- Destination Type: CIDR
- Destination CIDR: 0.0.0.0/0
- IP Protocol: All
Parent topic: Ways to Implement the Security Rules
Network Requirements for Oracle Database Autonomous Recovery Service
Oracle Database Autonomous Recovery Service requires a registered Recovery Service subnet dedicated to backup and recovery operations in your database virtual cloud network (VCN).
To use Recovery Service for backups, follow the steps outlined in Configuring Recovery Service.
- Create a Service Gateway to Object Storage
In the OCI Console, create a service gateway to Object Storage. The service gateway is required for automation updates and configuration metadata.
Related Topics
Parent topic: Network Setup for Exadata Cloud Infrastructure Instances
Create a Service Gateway to Object Storage
In the OCI Console, create a service gateway to Object Storage. The service gateway is required for automation updates and configuration metadata.
- Open the navigation menu. Click Networking, and then click Virtual Cloud Networks.
- Select the VCN where your database services to be backed up are located.
- On the resulting Virtual Cloud Network Details page, under Resources,click Service Gateways.
- Click Create Service Gateway and provide the following
details.
- Name: A descriptive name for the service gateway. It doesn't have to be unique. Avoid entering confidential information.
- Compartment: The compartment where you want to create the service gateway, if different from the compartment you're currently working in.
- Services: Select the service CIDR Label,
All <region> Services in Oracle Services Network
from the drop-down list. - Tags: (advanced option) If you have permissions to create a resource, then you also have permissions to apply free-form tags to that resource. To apply a defined tag, you must have permissions to use the tag namespace. For more information about tagging, see Resource Tags. If you are not sure whether to apply tags, skip this option (you can apply tags later) or ask your administrator.
-
Click Create Service Gateway.
Wait for the gateway to be created before proceeding to the next step.
-
Under Resources, click Route Tables.
Route Table Association: You can associate a specific VCN route table with this gateway. If you associate a route table, afterward the gateway must always have a route table associated with it. You can modify the rules in the current route table or replace them with another route table.
- Click the Route Table name that is being used by the subnet for Recovery Service.
-
In the resulting Route Table Details page, click Add Route Rules in the Route Rules section.
When you configure a service gateway for a particular service CIDR label, you must also create a route rule that specifies that label as the destination and the target as the service gateway. You do this for each subnet that needs to access the gateway.
- In the resulting Add Route Rules dialog, enter the
following details:
- Target Type: Service Gateway.
- Destination Service: The service CIDR label that is enabled for
the gateway.
All <region> Services in Oracle Services Network
- Target Service Gateway: Select the name that you provided in step 4.
- Description: An optional description of the rule.
- Click Add Route Rules.
Related Topics