Networking

4 Networking

Managing VCNs and Subnets

The VCN is the basic networking unit of the Oracle Private Cloud Appliance product. VCNs can be further divided into IP subnets, and individual VCNs can communicate with each other through various types of gateways, each type intended for a particular purpose.

Creating a VCN

The VCN is the basic networking unit of the Oracle Private Cloud Appliance product. VCNs can be further divided into IP subnets. VCNs can communicate with each other through various types of gateways, each type intended for a particular purpose.

Using the Compute Web UI

Open the Navigation Menu. Under Networking, click Virtual Cloud Networks.
Click the Create Virtual Cloud Network button to open the Create Virtual Cloud Network dialog.
Enter the following information:
- Name: Enter a descriptive name for the VCN.
- Compartment: Select the compartment in which to create the VCN.
- CIDR Block: Specify which CIDR range can be used within the VCN.
- DNS: If you check the box to use DNS host names in this VCN, then you can either enter a DNS label or leave the field blank to let the system generate a label for you. The first character of the label must be a letter. Only use letters and numbers. Up to 15 characters are allowed.
Optionally, add one or more tags to this VCN resource.

For more information about tagging, see Working with Resource Tags. If you are not sure whether to apply tags, skip this option (you can apply tags later) or ask your administrator.
Click the Create Virtual Cloud Network button in the dialog. The details page of the new VCN is displayed.

Using the OCI CLI

Gather the information that you need to run the command:
- Compartment OCID (oci iam compartment list --compartment-id-in-subtree true)

Enter the vcn create command using at least the compartment OCID and CIDR block options.

If you want to use DNS host names in the VCN, include the DNS label in the create command. It cannot be added later.

Optionally, set a descriptive name for the VCN.

$ oci network vcn create --compartment-id compartment_OCID \
--cidr-block 10.0.0.0/16 --dns-label vcn1 --display-name VCN1
{
  "data": {
    "cidr-block": "10.0.0.0/16",
    "compartment-id": "ocid1.compartment.unique_ID",
    "default-dhcp-options-id": "ocid1.dhcpoptions.unique_ID",
    "default-route-table-id": "ocid1.routetable.unique_ID",
    "default-security-list-id": "ocid1.security_list.unique_ID",
    "defined-tags": {},
    "display-name": "VCN1",
    "dns-label": "vcn1",
    "freeform-tags": {},
    "id": "ocid1.vcn.unique_ID",
    "ipv6-cidr-block": null,
    "ipv6-private-cidr-block": null,
    "lifecycle-state": "PROVISIONING",
    "time-created": "2022-04-27T04:34:58.722835+00:00",
    "vcn-domain-name": "vcn1.oraclevcn.com"
  },
  "etag": "a555bf2a-0764-4389-8d72-e9a746f63a78"
}

Creating a Subnet

VCNs can be divided into subnets. Although it is possible to have an enormous VCN with a thousand IP addresses, it often makes sense from a performance and fault isolation standpoint to create multiple subnets within a VCN. The subnets can still communicate if configured properly.

IP subnet calculation can be a difficult task, especially when figuring out which IP addresses in the range are reserved. The wide range of allowable CIDR block addresses complicates the issue. Free subnet calculation tools available online can help, such as https://www.calculator.net/ip-subnet-calculator.html.

Using the Compute Web UI

Open the Navigation Menu. Under Networking, click Virtual Cloud Networks.
Click the name of the VCN in which you want to create a new subnet. The VCN details page is displayed.
In the Resources section, click Subnets.
Click the Create Subnet button at the top of the subnets list to open the Create Subnet dialog.
Enter the following information:
- Name: Enter a descriptive name for the subnet.
- Create in Compartment: Select the compartment where you want to create this subnet.
- CIDR Block: Specify which CIDR range can be used within the subnet. It must be within the VCN CIDR block and must not overlap with other subnets.
- Route Table (Optional): Select the route table to associate with this subnet. You might need to change the compartment selection. If you do not select a route table, the VCN default route table is used.
- Private or Public Subnet: If you select Private Subnet, instances in this subnet are not allowed to obtain a public IP address.
- DNS Hostnames (Optional): Check this box if you want to be able to assign a DNS hostname when you launch an instance in this subnet. If you check the box, enter a DNS label that is unique across the system.
- DHCP Options (Optional): Select the set of DHCP options to associate with the subnet. You might need to change the compartment selection. If you do not select a set of options, the VCN default set is used.
- Security Lists (Optional): If you want a security list for this subnet, click the +Add Security List button. Select a security list to associate with the subnet. You might need to change the compartment selection. If you want another security list, click the +Add Security List button and select another security list. If you do not select a security list, the VCN default security list is used.
Optionally, add one or more defined or free-form tags to this subnet as described in Adding Tags at Resource Creation. Tags can also be applied later.
Click the Create Subnet button in the dialog. The details page of the new subnet is displayed.

Using the OCI CLI

Gather the information that you need to run the command:
- Compartment OCID (oci iam compartment list --compartment-id-in-subtree true)
- VCN OCID (oci network vcn list --compartment-id <compartment_OCID>)

Enter the subnet create command using at least the compartment ID, VCN ID and CIDR block options.

If you want to use DNS host names in the subnet, include the DNS label in the create command. It cannot be added later. This option is available only if you provided a DNS label for the VCN during creation.

This example also sets a descriptive name for the subnet. No set of DHCP options is specified, so the subnet will use the VCN default set.

$ oci network subnet create --compartment-id compartment_OCID \
--vcn-id vcn_OCID --cidr-block 10.0.1.0/24 --dns-label subnet1 \
--display-name NoPublicIP
{
  "data": {
    "availability-domain": "ad1",
    "cidr-block": "10.0.1.0/24",
    "compartment-id": "ocid1.compartment.unique_ID",
    "defined-tags": {},
    "dhcp-options-id": "ocid1.dhcpoptions.unique_ID",
    "display-name": "NoPublicIP",
    "dns-label": "subnet1",
    "freeform-tags": {},
    "id": "ocid1.subnet.unique_ID",
    "ipv6-cidr-block": null,
    "ipv6-virtual-router-ip": null,
    "lifecycle-state": "PROVISIONING",
    "prohibit-internet-ingress": null,
    "prohibit-public-ip-on-vnic": true,
    "route-table-id": "ocid1.routetable.unique_ID",
    "security-list-ids": [
      "ocid1.security_list.unique_ID"
    ],
    "subnet-domain-name": "subnet1.vcn1.oraclevcn.com",
    "time-created": "2022-04-27T04:41:54.984856+00:00",
    "vcn-id": "ocid1.vcn.unique_ID",
    "virtual-router-ip": "10.0.1.1",
    "virtual-router-mac": "00:13:97:0e:8f:ff"
  },
  "etag": "30d67d2d-5e11-4b13-9607-1948c52a78f5"
}

Editing a Subnet

You can change the name of the subnet, the route tables and security lists used by the subnet, and DHCP options.

Using the Compute Web UI

Open the Navigation Menu. Under Networking, click Virtual Cloud Networks.
Click the name of the VCN that contains the subnet you want to edit. The VCN details page is displayed.
In the Subnets list in the Resources section, locate the subnet that you want to edit. In the Actions menu, click Edit to open the Edit Subnet window.
Make the changes to the subnet. The following properties can be edited:
- Name: Change the name of the subnet.
- Route Table: Select a different route table for this subnet. You might need to change the compartment selection.
- DHCP Options: Select a different set of DHCP options for this subnet. You might need to change the compartment selection.
- Security Lists: Select different or additional security lists for this subnet. You might need to change the compartment selection.
Optionally, add or delete tags for this subnet.

For more information about tagging, see Working with Resource Tags. If you are not sure whether to apply tags, skip this option (you can apply tags later) or ask your administrator.
Click Save Changes. The subnet properties are updated.

Using the OCI CLI

Gather the information that you need to run the command:
- Compartment OCID (oci iam compartment list --compartment-id-in-subtree true)
- You might also need OCIDs for a route table, DHCP options set, or security lists.

Enter the subnet update command using the subnet OCID and the parameters you want to change.

This example changes the DHCP options and route table for the subnet.

$ oci network subnet update --subnet-id ocid1.subnet.unique_ID \
--dhcp-options-id ocid1.dhcpoptions.unique_ID \
--route-table-id ocid1.routetable.unique_ID
{
  "data": {
    "availability-domain": "ad1",
    "cidr-block": "10.0.1.0/24",
    "compartment-id": "ocid1.compartment.unique_ID,
    "defined-tags": {},
    "dhcp-options-id": "ocid1.dhcpoptions.unique_ID",
    "display-name": "NoPublicIP",
    "dns-label": "subnet1",
    "freeform-tags": {},
    "id": "ocid1.subnet.unique_ID",
    "ipv6-cidr-block": null,
    "ipv6-virtual-router-ip": null,
    "lifecycle-state": "AVAILABLE",
    "prohibit-internet-ingress": null,
    "prohibit-public-ip-on-vnic": true,
    "route-table-id": "ocid1.routetable.unique_ID",
    "security-list-ids": [
      "ocid1.securitylist.unique_ID"
    ],
    "subnet-domain-name": "subnet1.vcn1.oraclevcn.com",
    "time-created": "2022-04-27T04:41:54.984856+00:00",
    "vcn-id": "ocid1.vcn.unique_ID",
    "virtual-router-ip": "10.0.1.1",
    "virtual-router-mac": "00:13:97:0e:8f:ff"
  },
  "etag": "30d67d2d-5e11-4b13-9607-1948c52a78f5"
}

Deleting a Subnet

A subnet can only be deleted if it is empty. Before deleting a subnet, make sure that all compute instances and other resources have been deleted.

Using the Compute Web UI

Open the Navigation Menu. Under Networking, click Virtual Cloud Networks.
Click the name of the VCN that contains the subnet you want to delete. The VCN details page is displayed.
In the Subnets list in the Resources section, locate the subnet to delete. In the Actions menu, click Delete. Confirm the operation when prompted.

Using the OCI CLI

Get the OCID of the subnet you want to delete (oci network subnet list -c compartment_OCID)

Enter the subnet delete command.

$ oci network subnet delete --subnet-id subnet_OCID
Are you sure you want to delete this resource? [y/N]: y

Terminating a VCN

A VCN can only be terminated if it is empty. Before terminating a VCN, make sure that all subnets, route tables, gateways, and other resources have been deleted.

Using the Compute Web UI

Open the Navigation Menu. Under Networking, click Virtual Cloud Networks.
Click the name of the VCN that you want to terminate. The VCN details page is displayed. Check that the Resources list is empty.
Click the Terminate button. Confirm the operation when prompted.

Using the OCI CLI

Get the OCID of the VCN you want to delete (oci network vcn list -c compartment_OCID)

Enter the vcn delete command.

$ oci network vcn delete --vcn-id vcn_OCID
Are you sure you want to delete this resource? [y/N]: y

Configuring VCN Rules and Options

VCNs and their subnets have various rules and options associated with them. The main categories are the use of DHCP, route tables, and security. If you do not configure these rules and options explicitly, the system uses default values.

This section describes the parameters that are available for DHCP options, route tables, and security lists.

Working with DHCP Options

When you create a subnet, you can specify the set of DHCP options for the subnet. A set of DHCP options is a resource with an OCID. If you do not specify a set of DHCP options, the default set for the VCN is used.

A subnet can only be assigned one set of DHCP options. You can edit a set of DHCP options, create a new set, and change which set is assigned to a subnet. The assigned DHCP option set applies to all of the instances in that subnet.

For more information, see "DHCP Options" in the Virtual Networking Overview of the Oracle Private Cloud Appliance Concepts Guide.

Viewing a VCN's DHCP Options Sets

Every VCN has a default set of DHCP options that is named Default DHCP Options for VCN_name. If you create additional sets, then you can choose which set to assign to a subnet.

Using the Compute Web UI

Open the Navigation Menu. Under Networking, click Virtual Cloud Networks.
Click the name of the VCN for which you want to list DHCP Options sets. The VCN details page is displayed.
Under Resources, click DHCP Options. The list of DHCP options sets is displayed.
The DHCP Options sets in the list are not clickable. To see the options that are defined in the set, click the Actions menu for that set and then click Edit.

Using the OCI CLI

Gather the information you need to run the command:
- Compartment OCID (oci iam compartment list)
- VCN OCID (oci network vcn list --compartment-id compartment_OCID)
Run the list command.

Use both the VCN OCID and the compartment OCID to list all DHCP Options sets that belong to the specified VCN and are in the specified compartment.
```
oci network dhcp-options list --compartment-id ocid1.compartment.unique_ID \
--vcn-id ocid1.vcn.unique_ID
```
Use only the compartment OCID to list all DHCP Options sets in that compartment. The DHCP Options sets in a compartment could belong to any VCN. DHCP Options sets do not need to be in the same compartment with the VCN.
```
oci network dhcp-options list --compartment-id ocid1.compartment.unique_ID
```
Use one of the following methods to show just one DHCP Options set.
- Use the list command with the name of the DHCP Options set.
```
oci network dhcp-options list --compartment-id ocid1.compartment.unique_ID \
--display-name CustomDNSservers
```
- Use the get command with the OCID for the DHCP Options set. The DHCP Options set OCID is the value of id property in the DHCP Options set list command output.
```
oci network dhcp-options get --dhcp-id ocid1.dhcpoptions.unique_ID
```

Creating a Set of DHCP Options

Using the Compute Web UI

Open the Navigation Menu. Under Networking, click Virtual Cloud Networks.
Click the name of the VCN for which you want to create a set of DHCP options. The VCN details page is displayed.
Under Resources, click DHCP Options.
Click the Create DHCP Options button.
In the Create DHCP Options dialog, enter the following information:
- Name: A descriptive name for the set of options. The name doesn't have to be unique, and you can change it later.
- Create in Compartment: The compartment where you want to create the set of DHCP options.
- DNS Type: If you want instances in the subnet to resolve internet hostnames and hostnames of instances in the VCN, select Internet and VCN Resolver. To use a DNS server of your choice, select Custom Resolver and then enter the IP address of the DNS server. You can enter up to three DNS server IP addresses. For more information, see "Name Resolution" in the Virtual Networking Overview in the Oracle Private Cloud Appliance Concepts Guide.
- Search Domain: If you want instances in the subnet to append a particular search domain when resolving DNS queries, enter that domain here. Note that the Networking service automatically sets the search domain option in certain situations. For more information, see "DHCP Options" in the Virtual Networking Overview in the Oracle Private Cloud Appliance Concepts Guide.
- Tagging: For more information about tagging, see Working with Resource Tags. If you are not sure whether to apply tags, skip this option (you can apply tags later) or ask your administrator.
Click the Create DHCP Options button in the dialog.

You can specify this set of options when creating or updating a subnet.

Using the OCI CLI

Gather the information you need to run the command:
- The OCID of the compartment where you want to create this set of DHCP options (oci iam compartment list)
- The OCID of the VCN for this set of DHCP options (oci network vcn list --compartment-id compartment_OCID)
Construct an argument for the --options option.

DHCP options are in JSON format. To see how to format the options, use the following command:
```
oci network dhcp-options create --generate-param-json-input options > options_format.json
```
Alternatively, run a list or get of an existing DHCP Options object and copy the value of the options property.

Put the information for these options in the appropriate places in the format, or replace the information in the options that you copied.

The value of the --options option is either a string between single quotation marks or a file specified as file://path_to_file.json.

Run the DHCP options create command.

Syntax:

oci network dhcp-options create --compartment-id <compartment_OCID> \
--vcn-id <vcn_OCID> --options JSON_formatted_values

Example:

$ oci network dhcp-options create \
--compartment-id ocid1.compartment.unique_ID --vcn-id ocid1.vcn.unique_ID \
--display-name CustomDNSservers --options \
'[{"customDnsServers": ["IP_address"], "serverType": "CustomDnsServer","type":"DomainNameServer"},{"searchDomainNames": ["name.example.com"],"type":"SearchDomain"}]'
{
  "data": {
    "compartment-id": "ocid1.compartment.unique_ID",
    "defined-tags": {},
    "display-name": "CustomDNSservers",
    "domain-name-type": null,
    "freeform-tags": {},
    "id": "ocid1.dhcpoptions.unique_ID",
    "lifecycle-state": "PROVISIONING",
    "options": null,
    "time-created": "2022-05-04T19:29:16.763027+00:00",
    "vcn-id": "ocid1.vcn.unique_ID"
  },
  "etag": "cf50eb7e-88ff-4e1f-b129-08e2c25b3aa2"
}

While the new DHCP Options object is still provisioning, the specified options might not be shown. To confirm the options, use the OCID in the id property of the create output to run a get command:

$ oci network dhcp-options get --dhcp-id ocid1.dhcpoptions.unique_ID
{
  "data": {
    "compartment-id": "ocid1.compartment.unique_ID",
    "defined-tags": {},
    "display-name": "CustomDNSservers",
    "domain-name-type": null,
    "freeform-tags": {},
    "id": "ocid1.dhcpoptions.unique_ID",
    "lifecycle-state": "AVAILABLE",
    "options": [
      {
        "custom-dns-servers": [
          "IP_address"
        ],
        "server-type": "CustomDnsServer",
        "type": "DomainNameServer"
      },
      {
        "search-domain-names": [
          "name.example.com"
        ],
        "type": "SearchDomain"
      }
    ],
    "time-created": "2022-05-04T19:29:16.763027+00:00",
    "vcn-id": "ocid1.vcn.unique_ID"
  },
  "etag": "cf50eb7e-88ff-4e1f-b129-08e2c25b3aa2"
}

Updating a Set of DHCP Options

To update the DHCP options for the instances in a subnet, do one of the following:

Update the DHCP Options object that is currently assigned to that subnet as described in this section.
Update the subnet to assign a different DHCP Options object as described in Editing a Subnet.

For information about how to make the changes take effect in your instances, see "DHCP Options" in the Virtual Networking Overview in the Oracle Private Cloud Appliance Concepts Guide.

Using the Compute Web UI

Open the Navigation Menu. Under Networking, click Virtual Cloud Networks.
Click the name of the VCN for the DHCP options that you want to edit. The VCN details page is displayed.
Under Resources, click DHCP Options.

The list of DHCP options sets is displayed.
For the set of options that you want to change, click the Actions menu and then click Edit. See the descriptions of Name, DNS Type, and Search Domain in Creating a Set of DHCP Options.
Click the Save Changes button in the edit dialog.

Using the OCI CLI

Get the OCID of the DHCP Options object that you want to update (oci network dhcp-options list --compartment-id compartment_OCID)
Run the DHCP options update command.

Syntax:
```
oci network dhcp-options update --dhcp-id dhcp_OCID values_to_update
```
You can update the display name, domain name type, and options. Any options JSON object that you provide replaces the entire set of options. If you want to keep any of the existing options, run the get command with this --dhcp-id and copy what you want from the output option property to your options JSON object.

Example:
```
$ oci network dhcp-options update --dhcp-id ocid1.dhcpoptions.unique_ID \
--options file:///home/flast/dhcp_options.json
```
The output from this command is similar to the output from the create, list, and get commands. If you make changes to options and you do not see those changes initially, wait a few seconds and then run the get command.

Deleting a Set of DHCP Options

You cannot delete a set of DHCP options that is assigned to any subnet. To unassign the DHCP options set from a subnet, update the subnet to assign a different set of DHCP options. See Editing a Subnet. You cannot delete a VCN's default set of DHCP options.

Using the Compute Web UI

Open the Navigation Menu. Under Networking, click Virtual Cloud Networks.
Click the name of the VCN for which you want to delete a DHCP Options set. The VCN details page is displayed.
Under Resources, click DHCP Options.
For the set that you want to delete, click the Actions menu and then click Delete.
Confirm when prompted.

Using the OCI CLI

Get the OCID of the DHCP Options object that you want to delete (oci network dhcp-options list --compartment-id compartment_OCID)

Run the DHCP options delete command.

$ oci network dhcp-options delete --dhcp-id ocid1.dhcpoptions.unique_ID
Are you sure you want to delete this resource? [y/N]: y

To suppress this prompt, use the --force option.

Working with Route Tables

When you create a subnet, you specify a route table to associate with the subnet. If you don't, the VCN's default route table is used. You can change route table entries for a subnet at any time, but a subnet can only be assigned one route table at a time. The assigned route table applies to all of the instances in that subnet.

To delete a route table, it must not be associated with a subnet yet. You can't delete a VCN's default route table.

For more information, see "Route Tables" in the Virtual Networking Overview in the Oracle Private Cloud Appliance Concepts Guide.

Viewing a VCN's Route Tables

To see which table is assigned to a particular subnet, view the subnet. See the Route Table on the subnet details page, or see the route-table-id property in the subnet list or get command output.

Using the Compute Web UI

Open the Navigation Menu. Under Networking, click Virtual Cloud Networks.
Click the name of the VCN for which you want to view route tables. The VCN details page is displayed.
Under Resources, click Route Tables. The list of route tables is displayed.
Click the name of the route table to view its route rules.

Using the OCI CLI

Gather the information you need to run the command:
- Compartment OCID (oci iam compartment list)
- VCN OCID (oci network vcn list --compartment-id compartment_OCID)
Run the route table list command.

Use both the VCN OCID and the compartment OCID to list all route tables that belong to the specified VCN and are in the specified compartment.
```
oci network route-table list --compartment-id ocid1.compartment.unique_ID \
--vcn-id ocid1.vcn.unique_ID
```
Use only the compartment OCID to list all route tables in that compartment. The route tables in a compartment could belong to any VCN. Route tables do not need to be in the same compartment with the VCN.
```
oci network route-table list --compartment-id ocid1.compartment.unique_ID
```
Use one of the following methods to show just one route table.
- Use the list command with the name of the route table.
```
oci network security-list list --compartment-id ocid1.compartment.unique_ID \
--display-name ExtRoute
```
- Use the get command with the OCID for the route table. The route table OCID is the value of id property in the route table list command output.
```
oci network route-table get --rt-id ocid1.routetable.unique_ID
```

Creating a Route Table

Route rules are required to send traffic outside the VCN. If you do not need to send traffic outside the VCN, you can use the default route table that was created when the VCN was created. The default route table has no rules.

Each route rule specifies a destination CIDR block and the target (the next hop) for any traffic that matches that CIDR. Before you can create a rule, you must create a target. For descriptions of target types, see "Network Gateways" in the Virtual Networking Overview in the Oracle Private Cloud Appliance Concepts Guide, and see Overview of Routing for Your VCN. To create a target, use one of the procedures in Configuring VCN Gateways.

Using the Compute Web UI

Open the Navigation Menu. Under Networking, click Virtual Cloud Networks.
Click the name of the VCN for which you want to create a route table. The VCN details page is displayed.
Under Resources, click Route Tables.
Click the Create Route Table button.
Enter the name and compartment.
- Name: A user-friendly name for the route table. The name doesn't have to be unique, and you can change it later.
- Create in Compartment: The compartment where you want to create the route table. You are not required to create the route table in the same compartment as the VCN.
To add a rule, click +New Rule, and enter the following information:
- Target Type: Select from the list.
- CIDR Block: The destination CIDR block for the traffic. A value of 0.0.0.0/0 means that all non-intra-VCN traffic that is not already covered by other rules in the route table goes to the target specified in this rule.
- Target: The label for this value is the value that you selected for Target Type. Click the arrow and select the target. You might need to change the compartment just above the arrow.
- Description: An optional description of the rule.
Tagging: Optionally add tags, as described in Working with Resource Tags. If you are not sure whether to apply tags, skip this option (you can apply tags later) or ask your administrator.
Click the Create Route Table button in the dialog.

The details page of the new route table is displayed. You can specify this route table when creating or updating a subnet.

Using the OCI CLI

Gather the information you need to run the command:
- The OCID of the compartment where you want to create this route table (oci iam compartment list)
- The OCID of the VCN for this route table (oci network vcn list --compartment-id compartment_OCID)
Construct an argument for the --route-rules option.

Route rules are in JSON format. To see how to format a rule, use the following command:
```
oci network route-table create --generate-param-json-input route-rules > route_rule_format.json
```
Alternatively, if a route table with route rules already exists, you can list or get that route table and copy the value of the route-rules property.

Put the information for this new rule in the appropriate places in the format, or replace the information in the rule that you copied.

The value of the --route-rules option is either a string between single quotation marks or a file specified as file://path_to_file.json.

Run the route table create command.

If you do not specify a display name, a name is provided.

Syntax:

oci network route-table create --compartment-id compartment_OCID \
--vcn-id vcn_OCID --route-rules route_rules_json

Example:

$ oci network route-table create --compartment-id ocid1.compartment.unique_ID \
--vcn-id ocid1.vcn.unique_ID --display-name InternetRoute --route-rules \
'[{"cidrBlock":"0.0.0.0/0","networkEntityId":"ocid1.internetgateway.unique_ID"}]'
{
  "data": {
    "compartment-id": "ocid1.compartment.unique_ID",
    "defined-tags": {},
    "display-name": "InternetRoute",
    "freeform-tags": {},
    "id": "ocid1.routetable.unique_ID",
    "lifecycle-state": "PROVISIONING",
    "route-rules": [
      {          
        "cidr-block": "0.0.0.0/0",
        "description": null,
        "destination": null,
        "destination-type": "CIDR_BLOCK",
        "network-entity-id": "ocid1.internetgateway.unique_ID"
      }
    ],
    "time-created": "2022-04-11T06:00:29.527637+00:00",
    "vcn-id": "ocid1.vcn.unique_ID"
  },
  "etag": "15dcf54f-fa85-40f6-9557-75774e73f1ce" 
}

While the new route table is still provisioning, the route-rules property might be empty. To confirm the options, use the OCID in the id property of the create output to run a get command:

oci network route-table get --rt-id ocid1.routetable.unique_ID

Updating Rules in a Route Table

You can change the name of a route table and add, edit, or delete rules in a route table.

Using the Compute Web UI

Open the Navigation Menu. Under Networking, click Virtual Cloud Networks.
Click the name of the VCN for which you want to update the route table. The VCN details page is displayed.
Under Resources, click Route Tables.
Click the name of the route table that you want to update.
To change the name of the route table, click the Edit button, change the name in the dialog, and click the Save Changes button.
To create a route rule, click Add Route Rules and enter the information described in Creating a Route Table.
To edit an existing rule, click the Actions menu for that rule, and then click Edit.
To delete a rule, click the Actions menu for that rule, and then click Delete.

Using the OCI CLI

Get the OCID of the route table to update (oci network route-table list --compartment-id compartment_OCID)
If you are changing the route rules, create an argument for the --route-rules option. See Creating a Route Table. This argument replaces any existing route rules, so be sure to include any rules that you want to keep. Use the following command to view existing rules in this route table:
```
oci network route-table get --rt-id ocid1.routetable.unique_ID
```

Run this command.

Syntax:

oci network route-table update --rt-id route_table_OCID --route-rules options_to_change

You can change the name (--display-name), the rules (--route-rules), or the tags.

Example:

oci network route-table update --rt-id ocid1.routetable.unique_ID \
--route-rules file:///home/flast/InternetRoute_rules.json
{
  "data": {
    "compartment-id": "ocid1.compartment.unique_ID",
    "defined-tags": {},
    "display-name": "InternetRoute",
    "freeform-tags": {},
    "id": "ocid1.routetable.unique_ID",
    "lifecycle-state": "AVAILABLE",
    "route-rules": [
      {          
        "cidr-block": "0.0.0.0/0",
        "description": "Uses the ExtG8Way",
        "destination": null,
        "destination-type": "CIDR_BLOCK",
        "network-entity-id": "ocid1.internetgateway.unique_ID"
      }
    ],
    "time-created": "2022-04-11T06:00:29.527637+00:00",
    "vcn-id": "ocid1.vcn.unique_ID"
  },
  "etag": "15dcf54f-fa85-40f6-9557-75774e73f1ce" 
}

Deleting a Route Table

You cannot delete a route table that is associated with a subnet. You cannot delete a VCN's default route table.

Using the Compute Web UI

Open the Navigation Menu. Under Networking, click Virtual Cloud Networks.
Click the name of the VCN for which you want to delete a route table. The VCN details page is displayed.
Under Resources, click Route Tables.
For the route table that you want to delete, click the Actions menu and click Delete.
Confirm when prompted.

Using the OCI CLI

Get the OCID of the route table to delete (oci network route-table list --compartment-id compartment_OCID)

Run the route table delete command.

$ oci network route-table delete --rt-id ocid1.routetable.unique_ID
Are you sure you want to delete this resource? [y/N]: y

To suppress this prompt, use the --force option.

Controlling Traffic with Security Lists

Both security lists and network security groups (NSGs) are types of virtual firewalls for your compute instances. Both security lists and NSGs define network security rules that determine which types of traffic are allowed in and out of instances (VNICs).

Security lists provide virtual firewall rules to all the VNICs in a subnet. To provide a set of firewall rules for a set of VNICs of your choice in a VCN, you can create an NSG. See Controlling Traffic with Network Security Groups.

Security lists enable you to define network security rules that apply to all VNICs in a subnet. A default security list is automatically created for each VCN. That default security list is assigned to each subnet in the VCN if you do not assign a different security list. Up to five security lists can be associated with a subnet.

If you use both security lists and NSGs, traffic in or out of a given VNIC is allowed if any rule in any applicable security list or NSG allows the traffic:

Any rule in any security list that is associated with the VNIC's subnet
Any rule in any NSG that the VNIC is in

For general information and a comparison of security lists and NSGs, see "Virtual Firewall" in the Virtual Networking Overview in the Oracle Private Cloud Appliance Concepts Guide.

Viewing a VCN's Security Lists

Using the Compute Web UI

Open the Navigation Menu. Under Networking, click Virtual Cloud Networks.
Click the name of the VCN for which you want to view security lists. The VCN details page is displayed.
Under Resources, click Security Lists. The list of security lists is displayed.
Click the name of the security list to view its ingress and egress rules.

Using the OCI CLI

Gather the information you need to run the command:
- Compartment OCID (oci iam compartment list)
- VCN OCID (oci network vcn list --compartment-id compartment_OCID)
Run the list command.

Use both the VCN OCID and the compartment OCID to list all security lists that belong to the specified VCN and are in the specified compartment.
```
oci network security-list list --compartment-id ocid1.compartment.unique_ID \
--vcn-id ocid1.vcn.unique_ID
```
Use only the compartment OCID to list all security lists in that compartment. The security lists in a compartment could belong to any VCN. Security lists do not need to be in the same compartment with the VCN.
```
oci network security-list list --compartment-id ocid1.compartment.unique_ID
```
Use one of the following methods to show just one security list.
- Use the list command with the name of the security list.
```
oci network security-list list --compartment-id ocid1.compartment.unique_ID \
--display-name "Custom Security List"
```
- Use the get command with the OCID for the security list. The security list OCID is the value of id property in the security list list command output.
```
oci network security-list get --security-list-id ocid1.securitylist.unique_ID
```

Creating a Security List

Before you create a security list, use the following command to see the security rules that are already defined in the default security list and any other security list for this VCN:

$ oci network security-list get --security-list-id ocid1.securitylist.unique_ID

A security list must have at least one rule. A security list is not required to have both ingress and egress rules.

Using the Compute Web UI

Open the Navigation Menu. Under Networking, click Virtual Cloud Networks.
Click the name of the VCN for which you want to create a security list. The VCN details page is displayed.
Under Resources, click Security Lists.
Click the Create Security List button.
In the Create Security List dialog, enter the following information:
- Name: A descriptive name for the security list. The name does not have to be unique. The name cannot be changed later in the Console but can changed with the CLI).
- Create in Compartment: The compartment where you want to create the security list.
Add at least one rule.

To add one or more ingress rules, click +New Rule in the Allow Rules for Ingress box. To add one or more egress rules, click +New Rule in the Allow Rules for Egress box. Enter the following information:
- Stateless: If you want the new rule to be stateless, check this box. By default, security list rules are stateful and apply to both a request and its coordinated response. For more information about stateless and stateful rules, see "Security Lists" in the Virtual Networking Overview in the Oracle Private Cloud Appliance Concepts Guide.
- CIDR: The CIDR block for the ingress or egress traffic.
- IP Protocol: The rule can apply to all IP protocols, or choices such as ICMP, TCP, or UDP. Select the protocol from the drop-down list.
  - Port Range: For some protocols, such as TCP or UDP, you can supply a source port range and destination port range.
  - Parameter Type and Code: For ICMP, you can select a parameter type and corresponding parameter code.
- Description: An optional description of the rule.
Tagging: For more information about tagging, see Working with Resource Tags. If you are not sure whether to apply tags, skip this option (you can apply tags later) or ask your administrator.
Click the Create Security List button in the dialog.

The details page of the new security list is displayed. You can specify this security list when creating or updating a subnet.

Using the OCI CLI

Gather the information you need to run the command:
- The OCID of the compartment where you want to create this security list (oci iam compartment list)
- The OCID of the VCN for this security list (oci network vcn list --compartment-id compartment_OCID)
Construct arguments for the --ingress-security-rules and --egress-security-rules options.

Security rules are in JSON format. To see how to format a rule, use the following command:
```
oci network security-list create --generate-param-json-input ingress-security-rules > ingress.json
```
Use the same command with egress-security-rules.

Ingress and egress security rules are the same except that ingress rules have source and sourceType properties while egress rules have destination and destinationType properties.

The value of the protocol property is all or one of the following numbers: 1 for ICMP, 6 for TCP, or 17 for UDP.

Alternatively, you can list or get the default security list or another security list and copy the values of the egress-security-rules and ingress-security-rules properties.

Put the information for rules for this new security list in the appropriate places in the format, or replace the information in the rules that you copied.

The value of both rules options is either a string between single quotation marks or a file specified as file://path_to_file.json.

Run the security list create command.

Syntax:

At least one of --ingress-security-rules or --egress-security-rules must be specified. Both can be specified.

oci network security-list create --compartment-id compartment_OCID \
--vcn-id vcn_OCID --ingress-security-rules ingress_rules \
--egress-security-rules egress_rules

Example:

$ oci network security-list create --compartment-id ocid1.compartment.unique_ID \
--vcn-id ocid1.vcn.unique_ID --display-name "Limited Port Range" \
--egress-security-rules '[{"destination": "10.0.2.0/24", "protocol": "6", "isStateless": true, \
"tcpOptions": {"destinationPortRange": {"max": 1521, "min": 1521}, \
"sourcePortRange": {"max": 1521, "min": 1521}}}]' \
--ingress-security-rules '[{"source": "10.0.2.0/24", "protocol": "6", "isStateless": true, \
"tcpOptions": {"destinationPortRange": {"max": 1521, "min": 1521}, \
"sourcePortRange": {"max": 1521, "min": 1521}}}]'
{
  "data": {
    "compartment-id": "ocid1.compartment.unique_ID",
    "defined-tags": {},
    "display-name": "Limited Port Range",
    "egress-security-rules": [
      {
        "description": null,
        "destination": "10.0.2.0/24",
        "destination-type": "CIDR_BLOCK",
        "icmp-options": null,
        "is-stateless": true,
        "protocol": "6",
        "tcp-options": {
          "destination-port-range": {
            "max": 1521,
            "min": 1521
          },
          "source-port-range": {
            "max": 1521,
            "min": 1521
          }
        },
        "udp-options": null
      }
    ],
    "freeform-tags": {},
    "id": "ocid1.securitylist.unique_ID",
    "ingress-security-rules": [
      {
        "description": null,
        "icmp-options": null,
        "is-stateless": true,
        "protocol": "6",
        "source": "10.0.2.0/24",
        "source-type": "CIDR_BLOCK",
        "tcp-options": {
          "destination-port-range": {
            "max": 1521,
            "min": 1521
          },
          "source-port-range": {
            "max": 1521,
            "min": 1521
          }
        },
        "udp-options": null
      }
    ],
    "lifecycle-state": "PROVISIONING",
    "time-created": "2022-05-06T02:17:10.965748+00:00",
    "vcn-id": "ocid1.vcn.unique_ID"
  },
  "etag": "30d67d2d-5e11-4b13-9607-1948c52a78f5"
}

Updating a Security List

You can edit the name of the security list and add, edit, or delete rules or tags in any security list, including the default security list.

Using the Compute Web UI

Open the Navigation Menu. Under Networking, click Virtual Cloud Networks.
Click the name of the VCN for which you want to update a security list. The VCN details page is displayed.
Under Resources, click Security Lists.
For the security list that you want to update, do one of the following:
- Click the Actions menu and then click Edit to open the Edit Security List dialog. Update rules in the Allow Rules for Ingress and Allow Rules for Egress sections. To delete a rule, click the trash can icon. To add a rule, click the +New Rule button. You can also update the security list name and tags. Click the Save button on the dialog.
- Click the Actions menu and then click View Details to open the security list details page.
  - Click the Edit button to open the Edit Security List dialog.
  - To edit only the rules, scroll to the Resources section and click either Ingress Rules or Egress Rules. To create a new rule, click the Create Security Rule button. To update a rule, click the Actions menu for that rule and then click Edit. To delete a rule, click the actions menu and then click Delete.

Using the OCI CLI

Get the OCID of the security list that you want to update (oci network vcn list --compartment-id compartment_OCID)
If you want to update rules, construct arguments for the --ingress-security-rules and --egress-security-rules options as described in Creating a Security List. Arguments that you provide to these rules options overwrite any existing rules. If you want to keep some existing rules, use the following command to show the current rules, and then copy the rules that you want to keep into the new option arguments.
```
$ oci network security-list get --security-list-id ocid1.securitylist.unique_ID
```

Run the security list update command.

Example:

oci network security-list update  \
--security-list-id ocid1.securitylist.unique_ID \
--ingress-security-rules file:///home/flast/ingress_rules.json

WARNING: Updates to defined-tags and egress-security-rules and freeform-tags and 
 ingress-security-rules will replace any existing values. 
 Are you sure you want to continue? [y/N]: y

Delete a Security List

You cannot delete a security list that is associated with a subnet. You cannot delete a VCN's default security list.

Using the Compute Web UI

Open the Navigation Menu. Under Networking, click Virtual Cloud Networks.
Click the name of the VCN for which you want to delete a security list. The VCN details page is displayed.
Under Resources, click Security Lists.
For the security list that you want to delete, click the Actions menu and then click Delete.
Confirm the deletion when prompted.

Using the OCI CLI

Get the OCID of the security list that you want to delete (oci network vcn list --compartment-id compartment_OCID)

Run the security list delete command.

$ oci network security-list delete --security-list-id ocid1.securitylist.unique_ID
Are you sure you want to delete this resource? [y/N]: y

To suppress this prompt, use the --force option.

Controlling Traffic with Network Security Groups

Both network security groups (NSGs) and security lists are types of virtual firewalls for your compute instances. Both NSGs and security lists define network security rules that determine which types of traffic are allowed in and out of instances (VNICs).

NSGs provide virtual firewall rules for a set of VNICs of your choice in a VCN. To provide a set of firewall rules for all VNICs in a subnet, you can create a security list. See Controlling Traffic with Security Lists.

NSGs enable you to define network security rules for groups of instances, which can be in different subnets. For example, an NSG can apply to all the database servers, or to all the application servers running a certain application. Instead of applying security to a particular subnet, you create an NSG and then add the appropriate instances (VNICs) to the NSG.

When you create a VCN, a default security list is created. No default NSG is created because you must choose which VNICs to include in the group.

If you use both security lists and NSGs, traffic in or out of a given VNIC is allowed if any rule in any applicable security list or NSG allows the traffic:

Any rule in any security list that is associated with the VNIC's subnet
Any rule in any NSG that the VNIC is in

For general information and a comparison of security lists and NSGs, see "Virtual Firewall" in the Virtual Networking Overview in the Oracle Private Cloud Appliance Concepts Guide.

Creating a Network Security Group

These procedures create an NSG with no rules and no VNICs.

To add security rules to the NSG, see Manage Rules for a Network Security Group.
To add VNICs to the NSG, see Attaching a VNIC to a Network Security Group.

Using the Compute Web UI

Open the Navigation Menu. Under Networking, click Virtual Cloud Networks.
Click the name of the VCN for which you want to create an NSG. The VCN details page is displayed.
Under Resources, click Network Security Groups.
Click the Create Network Security Group button.
In the Create Network Security Group dialog, enter the following information:
- Name: A descriptive name for the NSG. The name does not have to be unique, and it can be changed later.
- Create in Compartment: The compartment where you want to create the NSG.
Tagging: For more information about tagging, see Working with Resource Tags. If you are not sure whether to apply tags, skip this option (you can apply tags later) or ask your administrator.
Click the Create Network Security Group button in the dialog.

The details page for the new NSG is displayed. You can create security rules and select VNICs to add to the group now, or you can do these tasks later. See the procedures referenced at the beginning of this section.

Using the OCI CLI

You can add a display name and defined and free-form tags. Similarly, when you update an NSG (oci network nsg update), you can only update the name and tags. To add rules and VNICs, see the procedures referenced at the beginning of this section.

Gather the information you need to run the command:
- The OCID of the compartment where you want to create this NSG (oci iam compartment list)
- The OCID of the VCN for this NSG (oci network vcn list --compartment-id compartment_OCID)

Run the NSG create command.

Example:

$ oci network nsg create --compartment-id ocid1.compartment.unique_ID \
--vcn-id ocid1.vcn.unique_ID --display-name "Application A"
{
  "data": {
    "compartment-id": "ocid1.compartment.unique_ID",
    "defined-tags": {},
    "display-name": "Application A",
    "freeform-tags": {},
    "id": "ocid1.networksecuritygroup.unique_ID",
    "lifecycle-state": "PROVISIONING",
    "time-created": "2022-05-09T15:48:30.069904+00:00",
    "vcn-id": "ocid1.vcn.unique_ID"
  },
  "etag": "49073741-0cc7-4371-82ee-2abf4667b14d"
}

Viewing a VCN's Network Security Groups

Using the Compute Web UI

Open the Navigation Menu. Under Networking, click Virtual Cloud Networks.
Click the name of the VCN for which you want to view Network Security Groups. The VCN details page is displayed.
Under Resources, click Network Security Groups. The list of NSGs is displayed.
Click the name of the NSG to view its details, including security rules and attached VNICs.

Using the OCI CLI

Gather the information you need to run the command:
- Compartment OCID (oci iam compartment list)
- VLAN OCID (oci network vlan list --compartment-id compartment_OCID)
Run the NSG list command.

Specify the compartment OCID to list all the NSGs in that compartment.
```
oci network nsg list --compartment-id ocid1.compartment.unique_ID
```
Specify the VLAN OCID to list all the NSGs in that VLAN.
```
oci network nsg list \
--vlan-id ocid1.networksecuritygroup.unique_ID
```
Use one of the following methods to show just one NSG.
- Use the list command with the name of the NSG.
```
oci network nsg list --compartment-id ocid1.compartment.unique_ID \
--display-name "Custom NSG"
```
- Use the get command with the OCID for the NSG. The NSG OCID is the value of id property in the NSG list command output.
```
oci network nsg get --nsg-id ocid1.networksecuritygroup.unique_ID
```
The NSG security rules are not shown in the list or get command output. Use the following command to show the NSG security rules.
```
oci network nsg rules list --nsg-id ocid1.networksecuritygroup.unique_ID
```

Manage Rules for a Network Security Group

These procedures describe how to add, update, and remove rules that are applied by an NSG.

Using the Compute Web UI

Open the Navigation Menu. Under Networking, click Virtual Cloud Networks.
Click the name of the VCN for which you want to manage rules in an NSG. The VCN details page is displayed.
Under Resources, click Network Security Groups.
In the list of NSGs, click the name of the NSG for which you want to manage rules. The NSG details page is displayed.
Under Resources, click Security Rules.
You can add new rules, and edit and delete existing rules.

To add a rule, click the Create Security Rules button. To add one or more ingress rules, click +New Rule in the Allow Rules for Ingress box. To add one or more egress rules, click +New Rule in the Allow Rules for Egress box. Enter the following information:
- Stateless: If you want the new rule to be stateless, check this box. By default, security list rules are stateful and apply to both a request and its coordinated response. For more information about stateless and stateful rules, see "Security Lists" in the Virtual Networking Overview in the Oracle Private Cloud Appliance Concepts Guide.
- CIDR: The CIDR block for the ingress or egress traffic.
- IP Protocol: The rule can apply to all IP protocols, or choices such as ICMP, TCP, or UDP. Select the protocol from the drop-down list.
  - Port Range: For some protocols, such as TCP or UDP, you can supply a source port range and destination port range.
  - Parameter Type and Code: For ICMP, you can select a parameter type and corresponding parameter code.
- Description: An optional description of the rule.
To edit a rule, click the Actions menu for the Egress or Ingress rule, click Edit, make the necessary changes, and then click Update.

To delete a rule, click the Actions menu for the Egress or Ingress rule, click Remove, and then click Confirm. While you are editing a rule, click the trash can icon to delete the rule.

Using the OCI CLI

Get the OCID of the NSG for which you want to manage rules (oci network nsg list --compartment-id <compartment_OCID>).
Construct an argument for the --security-rules option. Security rules are in JSON format. To see how to format a rule, use the following command:
```
oci network nsg rules add --generate-param-json-input security-rules > nsg_rules.json
```
The --security-rules option argument is exactly the same for the oci network nsg rules update command.

Alternatively, you can list and copy the rules of an existing NSG.
```
oci network nsg rules list --nsg-id ocid1.networksecuritygroup.unique_ID
```
Put the information for the rules for this new or updated NSG in the appropriate places in the format output by --generate-param-json-input, or change the information in the rules that you copied.

The value of the rules option is either a string between single quotation marks or a file specified as file://path_to_file.json.
Run the NSG rules add or update command.

Add:

The specified security_rules are added to any existing rules.
```
oci network nsg rules add --nsg-id nsg_OCID \
--security-rules security_rules
```
Update:

The specified security_rules replace any existing rules.
```
oci network nsg rules update --nsg-id nsg_OCID \
--security-rules security_rules
```

To delete one or more rules, construct a list of rule OCIDs.

Use the following command to find the OCIDs of the rules that you want to delete:

oci network nsg rules list --nsg-id ocid1.networksecuritygroup.unique_ID

Run the NSG rules remove command.

oci network nsg rules add --nsg-id ocid1.networksecuritygroup.unique_ID \
--security-rule-ids '{[ocid1.security_rule.unique_ID1,ocid1.security_rule.unique_ID2]}'

Attaching a VNIC to a Network Security Group

An NSG has one or more VNICs. You can attach a VNIC to an NSG when you create an instance or when you create or update the VNIC. See the following procedures:

Do one of the following to view the list of NSGs that a VNIC is attached to:

View the VNIC details.
1. On the instance details page, scroll to the resources section, and click Attached VNICs.
2. In the list, click the name of the VNIC.
3. On the VNIC details page, scroll to the resources section, and click Network Security Groups.

Run the following command:

$ oci network vnic get --vnic-id ocid1.vnic.unique_ID

Do one of the following to view the list of VNICs that are attached to an NSG:

View the NSG details.
1. On the VCN details page, scroll to the resources section, and click Network Security Groups.
2. In the list, click the name of the NSG.
3. On the NSG details page, scroll to the resources section, and click VNICs.

Run the following command:

$ oci network nsg vnics list --nsg-id ocid1.networksecuritygroup.unique_ID

To change the list of NSGs that a VNIC is attached to, update the VNIC.

Deleting a Network Security Group

Using the Compute Web UI

Open the Navigation Menu. Under Networking, click Virtual Cloud Networks.
Click the name of the VCN for which you want to delete an NSG. The VCN details page is displayed.
Under Resources, click Network Security Groups.
For the NSG that you want to delete, click the Actions menu and then click Delete.
Confirm the deletion when prompted.

Using the OCI CLI

Get the OCID of the NSG that you want to delete (oci network nsg list --compartment-id compartment_OCID)

Run the NSG delete command..

$ oci network nsg delete --nsg-id ocid1.networksecuritygroup.unique_ID
Are you sure you want to delete this resource? [y/N]: y

To suppress this prompt, use the --force option.

Configuring VCN Gateways

Virtual processes communicate with other processes in a variety of ways. If two instances are in the same subnet, meaning the network portions of their IP addresses match, there is no special configuration needed to allow them to communicate. A logical switch connects source and destination at the MAC address level. Also, communication between instances in the same VCN but different subnets requires no routing configuration. Routing is only needed for traffic that is going to a destination or coming from a source external to a VCN.

When communication between two virtual processes is needed and the source and destination are in two different VCNs, then configuration of one of five different types of gateway is necessary in the source VCN. In this context, a gateway is a special type of router, connecting two different IP networks by following rules set up in a route table. (A router can be thought of as a multiport gateway, and a gateway can be thought of as a two-port router.)

When you first create a VCN, various resources are listed in the UI and available for listing with a CLI command. Some of the resources are listed automatically when you create a subnet, and others must be configured explicitly.

Subnets. This resource gives the number of subnets created under the VCN. All other resources also display counts for the VCN.
Route Tables. This resource gives the number of route tables. Subnets can share route tables, especially default route tables, so this count is not necessarily the same as the count of subnets, especially if there is more than one subnet for the VCN.
Internet Gateways. This resource gives the number of internet gateways configured . Initially, there are none.
Local Peering Gateway. This resource gives the number of local peering gateways configured. Initially, there are none.
DHCP Options. This resource gives the number of DHCP option lists. There is at least one for the VCN by default, but more can be created.
Security Lists. This resource gives the number of Security Lists. There is at least one set of ingress and egress rules for the VCN by default, but more can be created.
NAT Gateways. This resource gives the number of NAT gateways configured. Initially, there are none.
Network Security Groups. This resource gives the number of Network Security Groups configured . Initially, there are none, but you can gather existing Security Lists into Network Security Groups, where all security rules are applied at once, as needed.
Service Gateways. This resource gives the number of service gateways configured. Initially, there are none.
Dynamic Routing Gateways. This resource gives the number of dynamic routing gateways (DRGs) configured. Initially, there are none. Note that these gateways are not configured without the VCN, but attached to the VCN.
Dynamic Routing Gateway Attachments. This resource gives the number of dynamic routing gateways attachments that have been configured. You must have a DRG configured to have attachments listed.

The various types of gateways are configured for very specific reasons.

NAT Gateway. A NAT gateway is used to translate IP addresses as traffic passes from one part of an IP network to another. When used between a VCN and the on-premises data center network. the NAT address becomes the source address for traffic sent on to the data center network. A NAT gateway allows egress to the on-premises network from a VCN. It does not allow connections to be initiated to the instances in the VCN. Although essentially one-way, return traffic is allowed for connections initiated in the VCN. Contrast NAT Gateway with the Internet Gateway, which allows connections into and out of the VCN, the NAT Gateway allows instances with public IP addresses to be reachable from outside the PCA network.

Note:

A VCN connected to the on-premises network with a Dynamic Routing Gateway cannot overlap with any on-premises CIDR, or other VCN CIDRs connected with a Dynamic Routing Gateway. In other words, the IP addresses used must be exclusive to the VCN.
Internet Gateway (IGW). An IGW provides the VCN with outside access through the on-premises data center network. The source and destination must have routable, public IP addresses, and a VCN can have only one IGW.
Local Peering Gateway (LPG). A Local Peering Gateway (LPG) is a way to connect VCNs so that elements in each VCN can communicate, even using private IP address. Peered VCNs can be in different tenancies.
Dynamic Routing Gateway (DRG). A DRG is used to connect a VCN to the data center's IP address space. That is, outside the Oracle Private Cloud Appliance rack in the data center. The data center network can, if configured that way, pass Oracle Private Cloud Appliance traffic on to other destinations.
Service Gateway (SG). Some services are isolated on their own network for security and performance reasons. The service gateway (SG) allows a VCN with no external access to privately access Service Network services (such as object storage) in a private subnet.

Enabling Public Connections through a NAT Gateway

A NAT gateway is used to translate IP addresses as traffic passes from one part of an IP network to another. This prevents sources and destinations from having identical IP addresses, and allows RFC 1918 private addresses used in Oracle Private Cloud Appliance traffic to communicate with on-premises data center networks. A NAT gateway is attached to a VCN at the subnet level, allowing finer control of the address translations. The NAT gateway is configured separately from the VCNs, and is not required to be in the same compartment as the VCN (but can be). However, the NAT gateway is within the VCN, and only one NAT per VCN is allowed. The NAT address becomes the source address for traffic sent on to the data center network.

Using the Compute Web UI

In the navigation menu, under Networking, click Virtual Cloud Networks. A list of previously configured VCNs in compartments appears. If the compartment you are creating the NAT gateway in is not in the title bar, then use the drop-down tab to select the correct compartment.
Click on the VCN that you are creating the NAT gateway in.
In the Resources menu for that VCN, click on NAT Gateways (the number of configured NAT gateways in parentheses does not matter).
Click on Create NAT Gateway
Fill in the required NAT gateway information:
- Name: Provide a name or description for the NAT gateway. Avoid using any of the organization's confidential information.
- Create in Compartment: Select the compartment in which to create the NAT Gateway.
- Block Traffic Choose whether to block traffic to this NAT Gateway.
  - (Yes: Traffic Not Blocked): By default, the VCN uses the NAT gateway even if it is not completely configured.
  - (No: Traffic Blocked): You can set the NAT gateway not see traffic until it is explicitly enabled to do so.
  For more information on NAT gateways, refer to "NAT Gateways" in the Virtual Networking Overview chapter of the Oracle Private Cloud Appliance Concepts Guide.
- Tagging: Optionally, add one or more tags to this resource. For more information about tagging, see Working with 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 NAT Gateway.

The NAT Gateway is now ready for the addition of route rules or security settings.

Using the OCI CLI

Gather the information that you need to run the command:
- Compartment OCID (oci iam compartment list --compartment-id-in-subtree true)
- VCN OCID (oci network vcn list --compartment-id <compartment_OCID>)

Run the oci network nat-gateway create command.

Note:

This procedure shows the minimum required parameters for this command. For information about optional parameters, run the command with the --help option.

Syntax (entered on a single line):

oci network nat-gateway create \
--compartment-id <compartment_OCID> \
--vcn-id <vcn_OCID>

Example:

oci network nat-gateway create \
 --compartment-id ocid1.compartment.….….….uniqueID \
 –-vcn-id ocid1.vcn.….….….uniqueID
 
{
  "data": {
    "block-traffic": true,
    "compartment-id": "ocid1.compartment.….….….uniqueID",
    "defined-tags": {},
    "display-name": "natgateway20210827215953",
    "freeform-tags": {},
    "id": "ocid1.vcn.….….….uniqueID",
    "lifecycle-state": "PROVISIONING",
    "nat-ip": "10.133.80.3",
    "public-ip-id": "ocid1.publicip.AK00661530.scasg01..….….….uniqueID",
    "time-created": "2021-08-27T21:59:53.858329+00:00",
    "vcn-id": "ocid1.vcn.AK00661530.scasg01..….….….uniqueID"
  },
  "etag": "c98377e4-ae89-46cf-9c61-52aea68a3476"
}

The NAT Gateway is now ready for the addition of route rules or security settings. Note that the name of the gateway (natgateway20210827215953) is assigned automatically and not by a parameter, and that the IP address of the device (10.133.80.3) is also assigned automatically.

Providing Public Access through an Internet Gateway

An Internet Gateway (IGW) provides the VCN with outside access through the on-premises data center network. The IGW is configured within the VCN, so the IGW is automatically attached to the VCN in which it is configured. The source and destination must have routable, public IP addresses, and a VCN can have only one IGW. Any traffic using public IP addresses goes through the IGW. The IGW is not required to be in the same compartment as the VCN. A subnet's route table determines which public subnets can use the IGW, and the subnet security list defines the types of traffic that can use the IGW. Like a physical router, the IGW can be disabled, severing internet access no matter what permissions are established.

Using the Compute Web UI

In the navigation menu, under Networking, click Virtual Cloud Networks. A list of previously configured VCNs in compartments appears. If the compartment you are creating the internet gateway in is not in the title bar, then use the drop-down tab to select the correct compartment.
Click on the VCN that you are creating the internet gateway in.
In the Resources menu for that VCN, click on Internet Gateways (the number of configured internet gateways in parentheses does not matter).
Click on Create Internet Gateway
Fill in the required internet gateway information:
- Name: Provide a name or description for the internet gateway. Avoid using any of the organization's confidential information.
- Create in Compartment: Select the compartment in which to create the Internet Gateway.
  
  For more information on internet gateways, refer to the "Internet Gateways" in the Virtual Networking Overview in the Oracle Private Cloud Appliance Concepts Guide.
- Enabled: Use the toggle to determine if the gateway is enabled at creation or not. The default is to enable the gateway.
  - (Yes: Gateway Enabled: By default, the VCN uses the gateway when created.(No: Gateway Disabled): You can set the gateway not see traffic until it is explicitly enabled to do so.
- Tagging: Optionally, add one or more tags to this resource.
  
  For more information about tagging, see Working with 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 Internet Gateway.

The Internet Gateway is now ready for the addition of route rules or security settings.

Using the OCI CLI

Gather the information that you need to run the command:
- Compartment OCID (oci iam compartment list --compartment-id-in-subtree true)
- VCN OCID (oci network vcn list --compartment-id <compartment_OCID>)

Run the oci network internet-gateway create command.

Note:

This procedure shows the minimum required parameters for this command. For information about optional parameters, run the command with the --help option.

Syntax (entered on a single line):

oci network internet-gateway create
--compartment-id <compartment_OCID>
--is-enabled <boolean: true | false>
--vcn-id <vcn_OCID>

Example:

oci network internet-gateway create \
 --compartment-id ocid1.compartment.….….….uniqueID
 –-is-enabled true 
 –-vcn-id ocid1.vcn.….….….uniqueID
 
{
  "data": {
    "compartment-id": "ocid1.compartment.….….….uniqueID",
    "defined-tags": {},
    "display-name": "internetgateway20210830165014",
    "freeform-tags": {},
    "id": "ocid1.internetgateway.AK00661530.scasg01..….….….uniqueID",
    "is-enabled": true,
    "lifecycle-state": "PROVISIONING",
    "time-created": "2021-08-30T16:50:14.634466+00:00",
    "vcn-id": "ocid1.vcn.….….….uniqueID",
  },
  "etag": "c98377e4-ae89-46cf-9c61-52aea68a3476"
}

The Internet Gateway is now ready for the addition of route rules or security settings. The IGW is not reachable unless there is at least one route rule for the gateway in the route table. For more information about configuring route rules, see Working with Route Tables.

Disable or Enable an Internet Gateway

You can enable or disable the IGW using the Compute Web UI or the OCI CLI.

Using the Compute Web UI

Open the Navigation Menu. Under Networking, click Virtual Cloud Networks.
Click the name of the VCN that contains the IGW you want to enable or disable. The VCN details page is displayed.
In the Internet Gateway list in the Resources section, locate the IGW to enable or disable. The configuration details show whether the IGW is enabled or not (Yes or No).
Access the Edit dialog from the Actions menu, or click Edit in the upper right of the details box.
Change the status of the Enabled toggle to Yes or No. Click Update to change the status of the IGW.

Using the OCI CLI

Get the IGW OCID of the IGW you want to enable or disable (oci network internet-gateway list -c compartment_OCID)
Enter the internet-gateway update --is-enabled command with the True or False boolean value.
```
$ oci network internet-gateway update --ig-id internetgateway_OCID --is-enabled boolean
```
Use the --force option to override the confirmation step.

Delete an Internet Gateway

If you have previously configured an IGW, you can delete it.

Using the Compute Web UI

Open the Navigation Menu. Under Networking, click Virtual Cloud Networks.
Click the name of the VCN that contains the IGW you want to delete. The VCN details page is displayed.
In the Internet Gateway list in the Resources section, locate the IGW to delete. In the Actions menu, click Delete. Confirm the operation when prompted.

Using the OCI CLI

Get the IGW OCID of the IGW you want to delete (oci network internet-gateway list -c compartment_OCID)

Enter the internet-gateway delete command.

$ oci network internet-gateway delete --ig-id internet-gateway_OCID
Are you sure you want to delete this resource? [y/N]: y

Use the --force option to override the confirmation step.

Connecting VCNs through a Local Peering Gateway

A Local Peering Gateway (LPG) is a way to connect VCNs so that elements in each VCN can communicate, even using private IP address. Peered VCNs can be in different tenancies. There are several other requirements for LPG configuration:

The CIDRs for the VCNs linked by the LPG cannot overlap.
Each peered VCN must have an LPG configured correctly, and the LPGs must be connected.
VCN route rules must be properly configured to steer VCN subnet traffic to and from the LPGs.
Security rules must be properly configured to allow or deny certain types VCN subnet traffic use the LPGs

Using the Compute Web UI

In the navigation menu, under Networking, click Virtual Cloud Networks. A list of previously configured VCNs in compartments appears. If the compartment you are creating the local peering gateway in is not in the title bar, then use the drop-down tab to select the correct compartment.
Click on the VCN that you are creating the local peering gateway in.
In the Resources menu for that VCN, click on Local Peering Gateways (the number of configured local peering gateways in parentheses does not matter).
Click on Create Local Peering Gateway
Fill in the required Local Peering gateway information:
- Name: Provide a name or description for the local peering gateway. Avoid using any of the organization's confidential information.
- Create in Compartment: Select the compartment in which to create the Local Peering Gateway.
- Route Table Association (Optional) Optionally, you can associate a route table with the Local Peering Gateway. A list of configured route tables for the selected compartment is in a drop-down list. You can change the compartment by clicking (change) next to the compartment name.
  
  For more information on local peering gateways, refer to "Local Peering Gateways" in the Virtual Networking Overview chapter of the Oracle Private Cloud Appliance Concepts Guide.
- Tagging: Optionally, add one or more tags to this resource.
  
  For more information about tagging, see Working with 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 Local Peering Gateway.

The Local Peering Gateway is now ready for connecting VCNs with Establish Peering Connection, and the addition of route rules or security settings.

Using the OCI CLI

Gather the information that you need to run the command:
- Compartment OCID (oci iam compartment list --compartment-id-in-subtree true)
- VCN OCID (oci network vcn list --compartment-id <compartment_OCID>)

Run the oci network local-peering-gateway create command.

Note:

This procedure shows the minimum required parameters for this command. For information about optional parameters, run the command with the --help option.

Syntax (entered on a single line):

oci network local-peering-gateway create \
--compartment-id <compartment_OCID> \
--vcn-id <vcn_OCID>

Example:

oci network local-peering-gateway create \
 --compartment-id ocid1.compartment.….….….uniqueID \
 –-vcn-id ocid1.vcn.….….….uniqueID
 
{
  "data": {
    "compartment-id": "ocid1.compartment.….….….uniqueID",
    "defined-tags": {},
    "display-name": "localpeeringgateway20210830174050",
    "freeform-tags": {},
    "id": "ocid1.lpg.AK00661530.scasg01..….….….uniqueID",
    "is-cross-tenancy-peering": false,
    "lifecycle-state": "AVAILABLE",
    "peer-advertised-cidr": null,
    "peer-advertised-cidr-details": null,
    "peering-status": "NEW",
    "peering-status-details": null,
    "route-table-id": null,
    "time-created": "2021-08-30T17:40:50.876023+00:00",
    "vcn-id": "ocid1.vcn.….….….uniqueID"
  },
  "etag": "c98377e4-ae89-46cf-9c61-52aea68a3476"
}

Connecting to the On-Premises Network through a Dynamic Routing Gateway

Dynamic Routing Gateway (DRG). A DRG is the Oracle Private Cloud Appliance equivalent of a general purpose router. A DRG is used to connect a VCN to the data center's IP address space. The router is configured separately from the VCNs, at the compartment level and is not required to be in the same compartment as the VCN (but it typically is). Once configured, the DRG can be attached to more than one VCN and, like a physical router, can be attached and detached at any time, although perhaps with traffic loss. Also like a physical router, even when attached to a VCN, the DRG must have route table rules to steer traffic to the on-premises data center network's IP address space.

Create a Dynamic Routing Gateway

Using the Compute Web UI

In the navigation menu, under Networking, click Dynamic Routing Gateways (DRGs). A list of previously configured DRGs in compartments appears. If the compartment you are creating the dynamic routing gateway in is not in the title bar, then use the drop-down tab to select the correct compartment.
Click on Create Dynamic Routing Gateway
Fill in the required dynamic routing gateway information:
- Name: Provide a name or description for the dynamic routing gateway. Avoid using any of the organization's confidential information.
- Create in Compartment: Select the compartment in which to create the dynamic routing Gateway.
  
  For more information on dynamic routing gateways, refer to "Dynamic Routing Gateways" in the Virtual Networking Overview in the Oracle Private Cloud Appliance Concepts Guide.
- Tagging: Optionally, add one or more tags to this resource. For more information about tagging, see Working with 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 Dynamic Routing Gateway.

The Dynamic Routing Gateway is now ready for the addition of DRG attachments.

Using the OCI CLI

Gather the information that you need to run the command:
- Compartment OCID (oci iam compartment list --compartment-id-in-subtree true)

Run the oci network drg create command.

Note:

This procedure shows the minimum required parameters for this command. For information about optional parameters, run the command with the --help option.

Syntax (entered on a single line):

oci network drg create
--compartment-id <compartment_OCID>

Example:

oci network drg create \
 --compartment-id ocid1.compartment.….….….uniqueID 
 
{
  "data": {
    "compartment-id": "ocid1.compartment.….….….uniqueID",
    "defined-tags": {},
    "display-name": "drg20210830204524",
    "freeform-tags": {},
    "id": "ocid1.drg..….….….uniqueID",
    "lifecycle-state": "AVAILABLE",
    "time-created": "2021-08-30T20:45:24.236954+00:00"
  },
  "etag": "c98377e4-ae89-46cf-9c61-52aea68a3476"
}

Attach VCNs to a Dynamic Routing Gateway

You can connect many VCNs to a DRG, but each VCN can have only one DRG attached. You must still make sure the route tables and security lists allow communication.

Using the Compute Web UI

In the navigation menu, under Networking, click on Dynamic Routing Gateways. A list of previously configured DRGs in compartments appears. If the compartment you are attaching the dynamic routing gateway to is not in the title bar, then use the drop-down tab to select the correct compartment.
Click on Dynamic Routing Gateway name in the list of DRGs for that compartment.
Click on Attach to Virtual Cloud Network.
Click on the VCN to attach the DRG to from the list of VCNs in the drop down list. If the correct compartment you are is not in the title bar, then use the drop-down tab to select the correct compartment.
Click on Attach to DRG.
Repeat the process to attach the other VCNs to the DRG and connect the VCNs.

The Dynamic Routing Gateway is attached to the selected VCN.

You can connect up to 10 VCNs to a DRG, but each VCN can have only one DRG attached. You must still make sure the route tables and security lists allow communication.

Using the OCI CLI

Gather the information that you need to run the command:
- Compartment OCID (oci iam compartment list --compartment-id-in-subtree true)
- VCN OCID (oci network vcn list --compartment-id <compartment_OCID>)
- Dynamic Routing Gateway OCID (oci network drg-attachment --compartment-id <compartment_OCID>)

Run the oci network drg-attachment create command.

Note:

This procedure shows the minimum required parameters for this command. For information about optional parameters, run the command with the --help option.

Syntax (entered on a single line):

oci network drg-attachment create \
--drg-id <drg_OCID> \
--vcn-id <vcn_OCID>

Example:

oci network drg-attachment create \
 --drg-id ocid1.drg.….….….uniqueID \
 --vcn-id ocid1.vcn.….….….uniqueID 
 
{
 "data": {
 "compartment-id": "ocid1.compartment.….….….uniqueID",
 "display-name": "drgattachment20210902221928",
 "drg-id": "ocid1.drg.….….….uniqueID",
 "id": "ocid1.drgattachment.AK00661530.scasg01..….….….uniqueID",
 "lifecycle-state": "ATTACHING",
 "route-table-id": null,
 "time-created": "2021-09-02T22:19:28.642402+00:00",
 "vcn-id": "ocid1.vcn.….….….uniqueID
 },
 "etag": "c98377e4-ae89-46cf-9c61-52aea68a3476"
}

Accessing Oracle Services through a Service Gateway

Some services are isolated on their own network for security and performance reasons. The service gateway (SG) allows a VCN with no external access to privately access Service Network services (such as object storage) in a private subnet. These services are reached at the infrastructure level through the management node cluster.

The feature is non-functional and implemented for compatibility purposes.

A VCN can have only one service gateway. The service gateway is automatically attached to the VCN it is created in. Services use CIDR labels, and are allowed by default.

For each enabled Service, you need a route rule with the Service object’s cidrBlock as the rule destination and the service gateway as the rule target.

Using the Compute Web UI

In the navigation menu, under Networking, click Virtual Cloud Networks. A list of previously configured VCNs in compartments appears. If the compartment you are creating the service gateway in is not in the title bar, then use the drop-down tab to select the correct compartment.
Click on the VCN that you are creating the service gateway in.
In the Resources menu for that VCN, click on Service Gateways (If you are creating a service gateway for a particular VCN< the number of configured service gateways in parentheses should be zero (0)).
Click on Create Service Gateway
Fill in the required service gateway information:
- Name: Provide a name or description for the service gateway. Avoid using any of the organization's confidential information.
- Create in Compartment: Select the compartment in which to create the service Gateway.
- Services: Select the service from the list.
- Route Table Association (Optional): Optionally, you can associate a route table with the Service Gateway. A list of configured route tables for the selected compartment is in a drop-down list. You can change the compartment by clicking (change) next to the compartment name.
  
  For more information on service gateways, refer to "Service Gateways" in the Virtual Networking Overview chapter of the Oracle Private Cloud Appliance Concepts Guide.
- Tagging: Optionally, add one or more tags to this resource.
  
  For more information about tagging, see Working with 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.

The Service Gateway is now ready for the addition of route rules or security settings.

Using the OCI CLI

Gather the information that you need to run the command:
- Compartment OCID (oci iam compartment list --compartment-id-in-subtree true)
- VCN OCID (oci network vcn list --compartment-id <compartment_OCID>)
Run the oci network service-gateway create command.

Complex data types are usually handled by using the --generate-full-command-json-input option, or, in this case, oci network service-gateway create --generate-param-json-input services. This generates a sample json file to be used with this command option. The key names are pre-populated and match the command option names (converted to camelCase format, e.g. compartment-id becomes compartmentId).

The values of the keys are edited by the user before the sample file can be used as an input to this command.

For any command option that accepts multiple values, the value of the key can be a JSON array.

Options can still be provided on the command line. If an option exists in both the JSON document and the command line then the command line specified value will be used.
```
oci network service-gateway create 
--compartment-id ocid1.compartment..….….….uniqueID
--vcn-id ocid1.vcn..….….….uniqueID 
--services '[{"serviceId":"grafana"}]'

{
 "data": {
  "displayName": "servicegateway20210830204524",
  "freeform-tags": {},
  "id": "ocid1.servicegateway..….….….uniqueID",
  "maxWaitSeconds": 0,
  "routeTableId": NULL,
  "services": [
   {
   "serviceId": "grafana"
   }
   ],
  "vcnId": ""ocid1.vcn.….….….uniqueID",
  "waitForState": "PROVISIONING",
  "waitIntervalSeconds": 0
  },
 "etag": "c98377e4-ae89-46cf-9c61-52aea68a3476"
}
```

Configuring VNICs and IP Addressing

The compute nodes in the Oracle Private Cloud Appliance have physical network interface cards (NICs). When you launch a compute instance, the Networking service creates a virtual NIC (VNIC) on top of a NIC so that the instance can communicate over the network. Each instance gets a primary VNIC, and that primary VNIC gets a primary private IP address. Neither the primary VNIC nor the primary private IP address can be removed from the instance.

You can optionally attach a public IP address to the private IP address if the subnet allows a public IP address. A private IP address enables the instance to communicate with other instances on the VCN. A public IP address enables the instance to communicate with hosts outside of the VCN, on your data center network. Internet access depends on what your data center network allows. See "Public Network in Private Cloud " and "IP Addressing" in the Virtual Networking Overview in the Oracle Private Cloud Appliance Concepts Guide.

You can add secondary VNICs to an instance after instance launch. Each secondary VNIC also gets a private IP address, and you can optionally attach a public IP address to the private IP address if the subnet allows a public IP address. See "Virtual Network Interface Cards (VNICs) " in the Virtual Networking Overview in the Oracle Private Cloud Appliance Concepts Guide.

You can add secondary private IP addresses to a VNIC, and you can optionally attach a public IP address to any secondary private IP address. For information about how secondary IP addresses are used, see "About Secondary Private IPs" in the Virtual Networking Overview in the Oracle Private Cloud Appliance Concepts Guide.

Managing VNICs

For information about how primary and secondary VNICs are used on Private Cloud Appliance, see "Virtual Network Interface Cards (VNICs)" in the Virtual Networking Overview in the Oracle Private Cloud Appliance Concepts Guide.

Viewing VNIC Attachments

Using the Compute Web UI, you can only view VNIC attachments for a particular instance. Using the OCI CLI, you can view all VNIC attachments in a compartment, and you can filter the list by instance or VNIC.

Using the Compute Web UI

On the Dashboard, click the Compute/View Instances button.
Click the name of the instance for which you want to view VNIC attachments. You might need to change the compartment to find the instance you want.
In the Resources box on the instance details page, click Attached VNICs.

The list of attached VNICs for that instance is displayed.

Using the OCI CLI

Get the information you need to run the command.
- To list all VNIC attachments in a compartment, get the OCID of the compartment: oci iam compartment list
- To list VNIC attachments only for a specific instance, get the OCID of that instance: oci compute instance list
- To list VNIC attachments only for a specific VNIC, get the OCID of that VNIC: oci compute instance list-vnics

Run the VNIC attachment list command.

Syntax:

oci compute vnic-attachment list --compartment-id compartment_OCID

Examples:

The following example lists all VNIC attachments for all instances in the specified compartment:

$ oci compute vnic-attachment list --compartment-id ocid1.compartment.uniqueID
{
  "data": [
    {
      "availability-domain": "ad1",
      "compartment-id": "ocid1.compartment.uniqueID",
      "display-name": "Ainstance",
      "id": "ocid1.vnicattachment.uniqueID",
      "instance-id": "ocid1.instance.uniqueID",
      "lifecycle-state": "ATTACHED",
      "nic-index": 0,
      "subnet-id": "ocid1.subnet.uniqueID",
      "time-created": "2022-05-09T15:17:39.398551+00:00",
      "vlan-id": null,
      "vlan-tag": 0,
      "vnic-id": "ocid1.vnic.uniqueID"
    },
...
  ]
}

The following example lists VNIC attachments for the specified instance:

$ oci compute vnic-attachment list --compartment-id ocid1.compartment.uniqueID \
--instance-id ocid1.instance.uniqueID

The following example lists the VNIC attachment of the specified VNIC:

$ oci compute vnic-attachment list --compartment-id ocid1.compartment.uniqueID \
--vnic-id ocid1.vnic.uniqueID

Viewing VNICs

Use these procedures to show details of a VNIC such as resource tags, hostname label, MAC address, NSGs, private and public IP addresses, whether this VNIC is a primary or secondary VNIC, and whether source/destination checks are being skipped.

Using the Compute Web UI

On the Dashboard, click the Compute/View Instances button.
Click the name of the instance for which you want to view VNIC attachments. You might need to change the compartment to find the instance you want.
On the instance details page, scroll to the Resources section and click Attached VNICs.

The list of attached VNICs for this instance is displayed.
Click the name of an attached VNIC to view the details page for the VNIC.

Using the OCI CLI

Get the information you need to run the command.
- To list all VNICs in a compartment, get the OCID of the compartment: oci iam compartment list
- To list all VNICs that are attached to a specific instance, get the OCID of that instance: oci compute instance list

Run the VNIC list command.

Syntax:

oci compute instance list-vnics \
{--compartment-id compartment_OCID | --instance-id instance_OCID}

Example:

The following example lists all VNICs for all instances in the specified compartment:

oci compute instance list-vnics --compartment-id ocid1.compartment.uniqueID

{
  "data": [
    {
      "availability-domain": "ad1",
      "compartment-id": "ocid1.compartment.uniqueID",
      "defined-tags": {
        "Oracle-Tags": {
          "CreatedBy": "flast",
          "CreatedOn": "2022-06-07T16:09:47.05Z"
        }
      },
      "display-name": "Ainstance",
      "freeform-tags": {},
      "hostname-label": "ainstance",
      "id": "ocid1.vnic.uniqueID",
      "is-primary": true,
      "lifecycle-state": "AVAILABLE",
      "mac-address": "MACaddress",
      "nsg-ids": [
        "ocid1.networksecuritygroup.uniqueID"
      ],
      "private-ip": "privateIP",
      "public-ip": "publicIP",
      "skip-source-dest-check": false,
      "subnet-id": "ocid1.subnet.uniqueID",
      "time-created": "2022-06-07T16:09:59.813530+00:00",
      "vlan-id": null
    },
...
  ]
}

The following example lists VNICs for the specified instance:

$ oci compute instance list-vnics --instance-id ocid1.instance.uniqueID

To view the details for a specific VNIC, use the VNIC get command.

Use the list-vnics command to get the VNIC OCID.
```
$ oci network vnic get --vnic-id ocid1.vnic.uniqueID
```

Creating and Attaching a Secondary VNIC

The number of secondary VNICs that you can add to an instance depends on the shape of the instance, as shown in "Compute Shapes" in Compute Instance Concepts in the Oracle Private Cloud Appliance Concepts Guide.

After you perform the following Private Cloud Appliance procedure, log onto the instance to configure the instance OS to use the new interface. See Configuring the Instance OS for a Secondary VNIC.

Using the Compute Web UI

On the Dashboard, click the Compute/View Instances button.
Click the name of the instance to which you want to add a secondary VNIC. You might need to change the compartment to find the instance you want.
In the Resources box on the instance details page, click Attached VNICs.

The primary VNIC and any secondary VNICs attached to the instance are displayed.
Click the Create VNIC Attachment button.
In the Subnet section of the Create VNIC Attachment dialog box, specify the subnet to use for the VNIC. You might need to select a different compartment to find the VCN and subnet that you want.

Specifying the same subnet for this VNIC that is specified for another VNIC for this instance can introduce asymmetric routing as described in "Virtual Network Interface Cards (VNICs)" in the Virtual Networking Overview in the Oracle Private Cloud Appliance Concepts Guide.

Instead of creating a VNIC in the same subnet as an existing VNIC for this instance, consider creating a secondary private IP address for the existing VNIC that is in this subnet. See Assigning a Secondary Private IP Address.
Specify whether to disable source/destination checks.

By default, a VNIC looks at the source and destination listed in the header of each network packet. If the VNIC is not the source or destination, then the packet is dropped.

If the VNIC needs to forward traffic (for example, if the VNIC needs to perform Network Address Translation), check the box to disable this source/destination check.
If you selected a public subnet, you can specify whether to automatically assign a public IPv4 address object to the VNIC's private IP address object.
(Optional) Specify the following private IP information.
- Private IP Address. An address that is within the CIDR block range assigned to the subnet and not already in use. If you do not enter an address, an IP address is automatically assigned.
- Hostname. A hostname to be used for DNS within the cloud network. This option is available only if the VCN and subnet both have DNS labels. The hostname can be up to 63 letters, numbers, and hyphens. No spaces are allowed.
(Optional) Add this VNIC to an NSG.

By default, the new VNIC is not attached to any NSG. Check the box labeled Enable Network Security Groups to add this VNIC to one or more NSGs.
1. Select an NSG from the dropdown list. You might need to change the compartment to find the NSG you want.
2. Click the Add Another NSG button if you want to attach to another NSG.
3. To remove an NSG from the list, click the trash can to the right of that NSG. To remove the last NSG or all NSGs, uncheck the Enable Network Security Groups box.
See Controlling Traffic with Network Security Groups for information about NSGs.
Click the Create Attachment button in the dialog. The secondary VNIC is created and then displayed on the Attached VNICs list for the instance.
Configure the instance OS to use the secondary VNIC. See Configuring the Instance OS for a Secondary VNIC.

Using the OCI CLI

Get the information you need to run the command:
- Instance OCID: oci compute instance list
- Subnet OCID: oci network subnet list
  
  Specifying the same subnet for this VNIC that is specified for another VNIC for this instance can introduce asymmetric routing as described in "Virtual Network Interface Cards (VNICs)" in the Virtual Networking Overview in the Oracle Private Cloud Appliance Concepts Guide.
  
  Instead of creating a VNIC in the same subnet as an existing VNIC for this instance, consider creating a secondary private IP address for the existing VNIC that is in this subnet. See Assigning a Secondary Private IP Address.
Review the list of optional parameters to disable source/destination checks, explicitly specify a private IP address, assign a public IP address, specify a host name, attach to network security groups, or assign a display name.
```
oci compute instance attach-vnic -h
```
Use the following command to show the JSON format to use to specify a list of attached NSGs:
```
oci compute instance attach-vnic --generate-param-json-input nsg-ids
```

Run the VNIC attach command.

Syntax:

oci compute instance attach-vnic --instance-id instance_OCID \
--subnet-id subnet_OCID

Example:

In this example, the newly attached VNIC gets a public IP address and a display name, and is attached to one or more NSGs.

$ oci compute instance attach-vnic --instance-id ocid1.instance.unique_ID \
--subnet-id ocid1.subnet.unique_ID --assign-public-ip true \
--nsg-ids file://./InstABC-nsgs.json --vnic-display-name "InstABC-Secondary-VNIC"

When successful, the attach-vnic command has no output. To confirm that the secondary VNIC attached, list VNICs for the instance. The new attached secondary VNIC is a non-primary VNIC (the value of the is-primary property is false).

$ oci compute instance list-vnics --instance-id ocid1.instance.unique_ID
{
  "data": [
    {
      ...
      "display-name": "InstABC-VNIC",
      ...
      "id": "ocid1.vnic.unique_ID",
      "is-primary": true,
      ...
      "time-created": "2022-06-22T22:24:31.853538+00:00",
      ...
    },
    {
      ...
      "display-name": "InstABC-Secondary-VNIC",
      ...
      "id": "ocid1.vnic.unique_ID",
      "is-primary": false,
      ...
      "nsg-ids": [
        "ocid1.networksecuritygroup.unique_ID"
      ],
      ...
      "public-ip": "publicIP",
      ...
      "time-created": "2022-06-29T18:28:44.355805+00:00",
      ...
    }
  ]
}

Configure the instance OS to use the secondary VNIC. See Configuring the Instance OS for a Secondary VNIC.

Configuring the Instance OS for a Secondary VNIC

After you create a secondary VNIC as described in Creating and Attaching a Secondary VNIC, log in to the instance to configure the instance OS to use the new VNIC.

For Linux and Microsoft Windows, you can use scripts that are provided by Oracle. The Oracle scripts use information from the instance metadata. See Retrieving Instance Metadata from Within the Instance for instructions about how to view that data on the instance OS, including how to show the VNIC data.

Linux Instance OS Configuration

Configuring the Instance OS Manually

Use the ifdown and ifup commands for the physical NIC. To persist this configuration across reboots, create a configuration file in /etc/sysconfig/network-scripts.

To add a VNIC, add a configuration file and use ifup.

To delete a VNIC, use ifdown and delete the configuration file.

Using the Oracle Script

You can download the Oracle script from https://docs.oracle.com/en-us/iaas/Content/Resources/Assets/secondary_vnic_all_configure.sh. Note that the script configures policy-based routing: two default routes in two separate route tables on the instance OS. Policy-based routing enables you to use all primary private IP addresses from anywhere without having asymmetric routing problems, if the packets are sourced from the primary IP address of the secondary VNIC. Applications can communicate through the secondary VNIC with hosts outside the VNIC's subnet. You might not need such a configuration. For example, if the secondary VNIC is used only to communicate with devices in the directly attached subnet of the VNIC, then you can use the /etc/sysconfig/network-scripts method described in the preceding procedure to add an IP and routes to the secondary VNIC.

The configuration performed by the script is not persistent across reboots. Run the script every time you add or delete a VNIC or reboot the instance.

The following are the most commonly used options of this script:

-c Using the instance metadata, add IP configuration for VNICs that are not configured and delete configuration for VNICs that are no longer provisioned.
-s Show information about all provisioning and interface configuration. This is the default behavior if you do not specify any option.
-h Show information about how to use the script.

If the secondary VNIC that you are configuring already has secondary private IP addresses, use this Oracle script with the -e option to configure the secondary IP addresses. The instance metadata does not include information about secondary IP addresses. You must provide the IP address and VNIC OCID on the command line. See also Configuring the Instance OS for a Secondary IP Address.

Oracle Solaris Instance OS Configuration

Use the ipadm command to configure network interfaces persistently.

Microsoft Windows Instance OS Configuration

Configuring the Instance OS Manually

Open Settings and then open Network Adapters.

Using the Oracle Script

You can download the Oracle-provided PowerShell script from https://docs.oracle.com/en-us/iaas/Content/Resources/Assets/secondary_vnic_windows_configure.ps1.

When you run the script, you can optionally provide the OCID of the secondary VNIC that you want to configure. See Retrieving Instance Metadata from Within the Instance for instructions about how to get the VNIC OCID from the instance metadata.

.\secondary_vnic_windows_configure.ps1 "ocid1.vnic.unique_ID"

If you do not enter the OCID of a VNIC that you want to configure, the script shows a list of the secondary VNICs on the instance and asks you to select the one you want to configure.

The script does the following:

Checks whether the network interface has an IP address and a default route.
To enable the OS to use the secondary VNIC, the script overwrites the IP address and default route with static settings. These actions effectively disable DHCP. The script prompts you to either overwrite with the static settings or exit.

Updating a VNIC

You can update the VNIC name, the host name, and whether to disable source/destination checks. You can add the VNIC to an NSG and remove the VNIC from an NSG.

Using the Compute Web UI Edit Option

If you only want to add or remove NSGs, see Using the Compute Web UI to Update NSGs Only.

On the Dashboard, click the Compute/View Instances button.
Click the name of the instance for which you want to update a VNIC. You might need to change the compartment to find the instance you want.
In the Resources box on the instance details page, click Attached VNICs.

The list of attached VNICs for that instance is displayed.
For the VNIC that you want to update, click the Actions menu and then click Edit.
In the Update VNIC dialog, update the VNIC name, the host name, whether to disable source/destination checks, or whether to attach this VNIC to an NSG or detach this VNIC from an NSG.

See Creating and Attaching a Secondary VNIC for information about the Skip Source/Destination Check selection.

If you change the Enable Network Security Groups box from unchecked to checked, then you must select an NSG from the dropdown list. You might need to change the compartment to find the NSG you want.

If the Enable Network Security Groups box is already checked, then you can click the Add Another NSG button to attach to another NSG.

If more than one NSG is already listed, you can click the trash can next to an existing NSG to detach this VNIC from that NSG. To detach the last NSG or all NSGs, uncheck the Enable Network Security Groups box.

See Controlling Traffic with Network Security Groups for information about NSGs.
Click the Update VNIC button in the dialog.

Using the Compute Web UI to Update NSGs Only

Follow the steps in the preceding procedure to display the list of attached VNICs for the instance.

Click the name of the VNIC for which you want to change the NSGs.
On the VNIC details page, scroll to the resources section, and click Network Security Groups.
Click the Update Network Security Groups button.
In the Update Network Security Groups for VNIC dialog, attach this VNIC to an NSG or detach this VNIC from an NSG.

If you change the Enable Network Security Groups box from unchecked to checked, then you must select an NSG from the dropdown list. You might need to change the compartment to find the NSG you want.

If the Enable Network Security Groups box is already checked, then you can click the Add Another NSG button to attach to another NSG.

If more than one NSG is already listed, you can click the trash can to the right of an existing NSG to detach this VNIC from that NSG. To detach the last NSG or all NSGs, uncheck the Enable Network Security Groups box.
Click the Update Network Security Groups for VNIC button in the dialog.
An alternative way to detach a VNIC from an NSG is to use the Detach menu option.
1. On the VNIC details page, scroll to the resources section, and click Network Security Groups.
2. In the Network Security Groups list, for the NSG that you want to detach, click the Actions menu and click Detach.

Using the OCI CLI

Use one of the following commands to get the OCID of the VNIC that you want to update:
```
oci compute instance list-vnics
oci compute vnic-attachment list
```
Review the list of optional parameters to use to update the VNIC name or the host name label, change whether to disable source/destination checks, or attach or detach NSGs.
```
oci network vnic update -h
```
Use the following command to show the JSON format to use to replace the list of attached NSGs:
```
oci network vnic update --generate-param-json-input nsg-ids
```

Run the VNIC update command.

Syntax:

oci network vnic update --vnic-id vnic_OCID

Example:

In this example, source/destination checks are disabled, and the list of attached NSGs is replaced.

$ oci network vnic update --vnic-id ocid1.vnic.unique_ID \
--nsg-ids '["ocid1.networksecuritygroup.unique_ID"]' \
--skip-source-dest-check true
{
  "data": {
    "availability-domain": "ad1",
    "compartment-id": "ocid1.compartment.unique_ID",
    "defined-tags": {
      "Oracle-Tags": {
        "CreatedBy": "flast",
        "CreatedOn": "2022-06-28T23:08:55.06Z"
      }
    },
    "display-name": "A2instance",
    "freeform-tags": {},
    "hostname-label": "a2instance",
    "id": "ocid1.vnic.unique_ID",
    "is-primary": false,
    "lifecycle-state": "AVAILABLE",
    "mac-address": "MACaddress",
    "nsg-ids": [
      "ocid1.networksecuritygroup.unique_ID"
    ],
    "private-ip": "privateIP",
    "public-ip": "publicIP",
    "skip-source-dest-check": true,
    "subnet-id": "ocid1.subnet.unique_ID",
    "time-created": "2022-06-28T23:08:55.960950+00:00",
    "vlan-id": null
  },
  "etag": "67fe1002-e72f-4cd5-9200-ea4b5721db39"
}

The initial command output might not show NSG updates. If your updates are not shown, use the network vnic get command to re-check the VNIC configuration.

Deleting a Secondary VNIC

This operation detaches and deletes the specified secondary VNIC. You cannot delete an instance's primary VNIC. When you terminate an instance, all attached VNICs (primary and secondary) are automatically detached and deleted.

Using the Compute Web UI

On the Dashboard, click the Compute/View Instances button.
Click the name of the instance for which you want to delete a VNIC. You might need to change the compartment to find the instance you want.
In the Resources box on the instance details page, click Attached VNICs.

The list of attached VNICs for that instance is displayed.
For the VNIC that you want to delete, click the Actions menu, and then click Delete.
Click the Confirm button on the dialog.

The VNIC state changes to Detached. After a few seconds, the VNIC is removed from the list.
Log onto the instance and delete the configuration for the IP address from the instance OS.

Undo the configuration you did when you added the VNIC. See Configuring the Instance OS for a Secondary VNIC.

Using the OCI CLI

Gather the information you need to run the command:
- Compartment OCID: oci iam compartment list
- VNIC OCID: oci compute vnic-attachment list

Run the instance detach VNIC command.

$ oci compute instance detach-vnic \
--compartment-id ocid1.compartment.unique_ID \
--vnic-id ocid1.vnic.unique_ID
Are you sure you want to delete this resource? [y/N]: y

You can suppress the confirmation by using the --force option.

Log onto the instance and delete the configuration for the IP address from the instance OS.

Undo the configuration you did when you added the VNIC. See Configuring the Instance OS for a Secondary VNIC.

Managing IP Addresses

A private IP address enables communication with resources on the VCN. Along with route rules, security rules, and gateways, a public IP address enables communication outside the VCN, including to the data center network.

All of the following are required for an instance to communicate outside the VCN:

The instance must be in a public subnet, which is configured when the subnet is created. Private subnets cannot have a public IP address assigned to instances in the subnet.
The instance must have a public IP address.
The instance's VCN must have an internet gateway configured.
The public subnet must have route table and security list entries that enable communications outside the VCN.

For information about route rules, security rules, and gateways, see Configuring VCN Rules and Options and Configuring VCN Gateways. For conceptual information, see "IP Addressing" in the Virtual Networking Overview in the Oracle Private Cloud Appliance Concepts Guide.

Viewing Private IP Addresses

The Compute Web UI enables you to view private and public IP addresses for a specific instance.

The OCI CLI enables you to list all private IP address objects in the tenancy or in the specified subnet or VNIC. You can also list a single private IP address object by specifying the IP address.

Using the Compute Web UI

On the Dashboard, click the Compute/View Instances button.
Click the name of the instance for which you want to view the private IP address. You might need to change the compartment to find the instance you want.
On the instance details page, view networking information or VNIC information.
- Click the Networking tab. The primary private IP address and any attached public IP address are shown in the Instance Access column.
- Scroll to the Resources section and click Attached VNICs. Click the name of the VNIC for which you want to view IP addresses.
  
  On the VNIC details page, scroll to the Resources section and click IP Addresses. The primary private IP address and any secondary private IP addresses, as well as any attached public IP addresses, are shown in the table.

Using the OCI CLI

Get the information you need to run the command:
- Subnet OCID: oci network subnet list
- VNIC OCID: oci compute instance list-vnics

Run the command to list private IP address objects.

Syntax:

oci network private-ip list

Examples:

List all private IP address objects in the tenancy:

$ oci network private-ip list
{
  "data": [
    {
      "availability-domain": "ad1",
      "compartment-id": "ocid1.compartment.unique_ID",
      "defined-tags": {},
      "display-name": "privateip20220705090302",
      "freeform-tags": {},
      "hostname-label": "ol8instance",
      "id": "ocid1.privateip.unique_ID",
      "ip-address": "IPaddress",
      "is-primary": true,
      "subnet-id": "ocid1.subnet.unique_ID",
      "time-created": "2022-07-05T09:03:02.025808+00:00",
      "vlan-id": null,
      "vnic-id": "ocid1.vnic.unique_ID"
    },
...
  ]
}

List all private IP address objects in the specified subnet:

$ oci network private-ip list --subnet-id ocid1.subnet.unique_ID

List all private IP address objects in the specified VNIC:

$ oci network private-ip list --vnic-id ocid1.vnic.unique_ID

List the private IP address object with the specified IP address:

$ oci network private-ip list --ip-address IPaddress

The output of the preceding list command is the same as the output from the following get command:

$ oci network private-ip get --private-ip-id ocid1.privateip.unique_ID

Similar to the Compute Web UI instance information, the instance list-vnics command shows each private and public IP address in each VNIC. This command does not show OCIDs or any other information about the IP address objects. See Viewing VNICs.

Assigning a Secondary Private IP Address

When you create an instance, the instance automatically gets a VNIC, and the VNIC automatically gets a primary private IP address. You can add secondary private IP addresses to a VNIC. A VNIC can have up to 32 private IP addresses: one primary private IP address, and up to 31 secondary private IP addresses.

Creating a VNIC in the same subnet as another VNIC for the same instance can introduce asymmetric routing as described in "Virtual Network Interface Cards (VNICs)" in the Virtual Networking Overview in the Oracle Private Cloud Appliance Concepts Guide. Instead, you can create a secondary private IP address for the existing VNIC that is in the subnet that you want.

See information about secondary private IP addresses, including use cases, in "IP Addressing" in the Virtual Networking Overview in the Oracle Private Cloud Appliance Concepts Guide.

After you perform the following Private Cloud Appliance procedure to assign a secondary private IP address, log onto the instance to configure the instance OS to use the new IP address. See Configuring the Instance OS for a Secondary IP Address.

Moving a Secondary IP Address

In addition to adding a secondary private IP address, you can use this procedure to reassign (move) a currently assigned secondary private IP address to a different VNIC. Because the VNIC must be in the same subnet as the VNIC where the secondary private IP address is currently assigned, the new VNIC probably is attached to a different instance; as mentioned above, having two VNICs in the same subnet in the same instance can introduce asymmetric routing.

To move a secondary private IP address, see the Unassign if assigned or --unassign-if-already-assigned options in the following procedures.

You cannot move a VNIC's primary private IP address.

If a public IP address object is assigned to a secondary private IP address object, and you move that secondary private IP address object to another VNIC, the public IP address object moves with it.

Using the Compute Web UI

On the Dashboard, click the Compute/View Instances button.
Click the name of the instance to which you want to add a secondary private IP address. You might need to change the compartment to find the instance you want.
On the instance details page, scroll to the Resources section and click Attached VNICs.

The primary VNIC and any secondary VNICs attached to the instance are displayed.
Click the name of the attached VNIC to which you want to add a secondary private IP address.
On the VNIC details page, scroll to the Resources section and click IP Addresses.
Click the Assign Secondary Private IP Address button.
In the Attach Private IP dialog, all input fields are optional.
- IP Address: If you do not enter an address, an IP address from the subnet CIDR is automatically assigned.
  
  If you enter an address, the IP address must be within the CIDR block for the subnet. You can enter a secondary private IP address that is already assigned to another VNIC in the subnet. You cannot enter a primary private IP address.
  
  If you enter an IP address that is already assigned, see the following option.
- Unassign if assigned: In the previous option, if you entered a secondary private IP address that is already assigned, check this button to move that private IP address. The address will be unassigned from the VNIC where it is currently assigned and reassigned to this VNIC.
  
  If you entered an IP address that is already assigned and you do not check this button, this secondary private IP assignment operation fails.
- Hostname: Enter the hostname to be used for DNS within the cloud network. This option is available only if the VCN and subnet both have DNS labels.
Click the Attach IP Address button in the dialog.

The new secondary private IP address is shown in the table.
Configure the new secondary private IP address in the instance. See Configuring the Instance OS for a Secondary IP Address

Using the OCI CLI

Get the OCID of the VNIC where you want to assign this secondary private IP address: oci compute instance list-vnics

Run the assign private IP command.

Syntax:

oci network vnic assign-private-ip --vnic-id vnic_OCID

Examples:

$ oci network vnic assign-private-ip --vnic-id ocid1.vnic.unique_ID
{
  "data": {
    "availability-domain": "ad1",
    "compartment-id": "ocid1.compartment.unique_ID",
    "defined-tags": {},
    "display-name": "privateip20220707213054",
    "freeform-tags": {},
    "hostname-label": null,
    "id": "ocid1.privateip.unique_ID",
    "ip-address": "IPaddress",
    "is-primary": false,
    "subnet-id": "ocid1.subnet.unique_ID",
    "time-created": "2022-07-07T21:30:54.305936+00:00",
    "vlan-id": null,
    "vnic-id": "ocid1.vnic.unique_ID"
  },
  "etag": "756b973a-c76e-4151-92ad-24fa265c8289"
}

In the following example, an existing private IP address is moved to a different VNIC:

$ oci network vnic assign-private-ip --vnic-id ocid1.vnic.unique_ID \
--ip-address IPaddress --unassign-if-already-assigned

Configure the new secondary private IP address in the instance. See Configuring the Instance OS for a Secondary IP Address.

Configuring the Instance OS for a Secondary IP Address

After you create a secondary private IP address on a VNIC as described in Assigning a Secondary Private IP Address, log in to the instance to configure the instance OS to use the new IP address.

Linux Instance OS Configuration

Configuring the Instance OS Manually

This configuration permits use of an IP address subnet, netmask, gateway, and DNS service that are entirely independent from the existing NIC. This configuration is persistent across reboots.

Create a new network interface configuration file to create a sub-interface on the existing NIC. In this example, ens03 is the name of the existing NIC and ifcfg-ens3:0 is the name of the new configuration file.

Create the network configuration file ifcfg-ens3:0 in the /etc/sysconfig/network-scripts/ directory to create the first sub-interface (:0) on the existing ens3 NIC.

Include the following entries in ifcfg-ens3:0:
```
TYPE=Ethernet
BOOTPROTO=none
IPADDR=a.b.c.d
PREFIX=24
GATEWAY=
DNS=
NAME=ens3:0
DEVICE=ens3:0
```
Include the appropriate IPADDR, PREFIX, GATEWAY, and DNS entries for this new sub-interface.
Run the following command to start the new interface:
```
# ifup ens3:0
```
Run the following command to confirm that the new interface is operational:
```
# ifconfig -a
```

Using the Oracle Script

The Oracle script can only configure a secondary IP address on a secondary VNIC. To configure a secondary IP address on the primary VNIC, use the /etc/sysconfig/network-scripts/ method described in the preceding procedure. You can download the Oracle script from https://docs.oracle.com/en-us/iaas/Content/Resources/Assets/secondary_vnic_all_configure.sh.

To use this script to configure a secondary private IP address on a secondary VNIC, use the -e option as shown below. The instance metadata does not include information about secondary IP addresses. You must provide the IP address and VNIC OCID on the command line.

$ secondary_vnic_all_configure.sh -e IP_address VNIC_OCID

The configuration performed by the script is not persistent across reboots. Run the script every time you add a new secondary private IP address or reboot the instance. If you have several secondary IP addresses, consider creating a configuration file as described in the manual procedure above.

Oracle Solaris Instance OS Configuration

Use the ipadm command to configure network interfaces persistently.

Microsoft Windows Instance OS Configuration

See Windows: Details about Secondary IP Addresses for information about how to either:

Create a PowerShell script.
Use the Network and Sharing Center UI.

Updating a Secondary Private IP Address

You cannot update a VNIC's primary private IP address.

You can update the host name of a secondary private IP address object. To change the IP address, delete the secondary private IP address object as described in Deleting a Secondary Private IP Address, and create a new one as described in Assigning a Secondary Private IP Address, explicitly specifying the IP address that you want to use.

To update the host name for the primary private IP on a VNIC, update the VNIC. See Updating a VNIC.

Using the Compute Web UI

On the Dashboard, click the Compute/View Instances button.
Click the name of the instance that has the secondary private IP address object that you want to update. You might need to change the compartment to find the instance you want.
On the instance details page, scroll to the Resources section and click Attached VNICs.

The primary VNIC and any secondary VNICs attached to the instance are displayed.
Click the name of the attached VNIC that has the secondary private IP address object that you want to update.
On the VNIC details page, scroll to the Resources section and click IP Addresses.
For the secondary private IP address object that you want to update, click the Actions menu and click Edit.
In the Attach Private IP dialog, update the host name.
Click the Attach IP Address button in the dialog.

Using the OCI CLI

Get the OCID of the secondary private IP address object that you want to update: oci network private-ip list
Run the private IP address update command.

Syntax:
```
oci network private-ip update --private-ip-id private_ip_OCID \
--hostname-label newhostname
```
The output is the same as the output of the private-ip get command.

Deleting a Secondary Private IP Address

You cannot delete a VNIC's primary private IP address.

On successful delete, the private IP address is returned to the pool of available addresses in the subnet. Any attached public IP address is again available for assignment.

Using the Compute Web UI

On the Dashboard, click the Compute/View Instances button.
Click the name of the instance for which you want to delete a secondary private IP address. You might need to change the compartment to find the instance you want.
On the instance details page, scroll to the Resources section and click Attached VNICs.

The primary VNIC and any secondary VNICs attached to the instance are displayed.
Click the name of the attached VNIC for which you want to delete a secondary private IP address.
On the VNIC details page, scroll to the Resources section and click IP Addresses.
For the secondary private IP address that you want to delete, click the Actions menu and click Delete.

Confirm the deletion.
Log onto the instance and delete the configuration for the IP address from the instance OS.

Undo the configuration you did when you added the IP address. See Configuring the Instance OS for a Secondary IP Address.

Using the OCI CLI

Gather the information you need to run the command:
- Private IP address: oci network private-ip list
- VNIC OCID: oci compute instance list-vnics
Run the unassign private IP command.

Syntax:
```
oci network vnic unassign-private-ip --ip-address IPaddress --vnic-id VNIC_OCID
```
Confirm the deletion, or use the --force option.

The secondary private IP address object is unassigned and then deleted.
Log onto the instance and delete the configuration for the IP address from the instance OS.

Undo the configuration you did when you added the IP address. See Configuring the Instance OS for a Secondary IP Address.

Viewing Public IP Addresses

The Compute Web UI enables you to view private and public IP addresses for a specific instance. See "Using the Compute Web UI" in Viewing Private IP Addresses.

The OCI CLI enables you to list public IP address objects in a specified compartment.

Using the OCI CLI

Get the OCID of the compartment where the instance is located: oci iam compartment list

Run the public IP list command.

Syntax:

oci network public-ip list --compartment-id compartment_OCID \
--scope {region | availability_domain}

Examples:

List reserved public IP address objects:

$ oci network public-ip list --compartment-id ocid1.compartment.unique_ID \
--scope region --lifetime reserved
{
  "data": [
    {
      "assigned-entity-id": null,
      "assigned-entity-type": "PRIVATE_IP",
      "availability-domain": null,
      "compartment-id": "ocid1.compartment.unique_ID",
      "defined-tags": {},
      "display-name": "apublicIP",
      "freeform-tags": {},
      "id": "ocid1.publicip.unique_ID",
      "ip-address": "IPaddress",
      "lifecycle-state": "AVAILABLE",
      "lifetime": "RESERVED",
      "private-ip-id": null,
      "public-ip-pool-id": null,
      "scope": "REGION",
      "time-created": "2022-07-06T16:36:56.860931+00:00"
    }
  ]
}

List the ephemeral public IP address objects that are assigned to a regional entity such as a NAT gateway:

$ oci network public-ip list --compartment-id ocid1.compartment.unique_ID \
--scope region --lifetime ephemeral

List the ephemeral public IP address objects that are assigned to primary private IP address objects:

$ oci network public-ip list --compartment-id ocid1.compartment.unique_ID \
--scope availability_domain --availability-domain ad1 --lifetime ephemeral

Assigning an Ephemeral Public IP Address to an Instance

To assign a public IP address to an instance, you assign the public IP address object to a private IP address object.

An ephemeral public IP address is created and assigned in the same step.

An ephemeral public IP address can only be assigned to a primary private IP address: The value of the is-primary property of the private IP address object must be true. Every VNIC has one primary private IP address.

For secondary private IP addresses (the value of the is-primary property of the private IP address object is false), assign reserved public IP addresses. See Assigning a Reserved Public IP Address to an Instance.

An ephemeral public IP address cannot be unassigned and cannot be moved to a different private IP address.

An ephemeral public IP address object is deleted in the following cases:

Its private IP address object is deleted.
Its VNIC is detached or terminated.
Its instance is terminated.

Using the Compute Web UI

On the Dashboard, click the Compute/View Instances button.
Click the name of the instance for which you want to assign a public IP address. You might need to change the compartment to find the instance you want.
On the instance details page, scroll to the Resources section and click Attached VNICs. Click the name of the VNIC for which you want to assign a public IP address.
On the VNIC details page, scroll to the Resources section and click IP Addresses. The primary private IP address and any secondary private IP addresses, as well as any attached public IP addresses, are shown in the table.
If the primary private IP address does not already have a public IP address assigned, click the Actions menu for the primary private IP address, and then click Edit Public IP,
In the dialog, click Ephemeral Public IP.
(Optional) Give the ephemeral public IP address a name.
Click the Reserve Public IP button in the dialog.

You might have to refresh the page to see the new public IP address. The new public IP address shows in the IP Addresses table in Resources, in the Primary IP Information column for the VNIC, and in the Instance Access column of the Networking tab of the instance.

Using the OCI CLI

Get the information you need to run the command:
- Compartment OCID: oci iam compartment list
- Private IP OCID: oci network private-ip list
- Public IP OCID: oci network public-ip list

Run the public IP create command.

This command creates a new ephemeral public IP address object and assigns it to the specified private IP address object.

$ oci network public-ip create --compartment-id ocid1.compartment.unique_ID \
--lifetime ephemeral --private-ip-id ocid1.privateip.unique_ID
  "data": {
    "assigned-entity-id": "ocid1.privateip.unique_ID",
    "assigned-entity-type": "PRIVATE_IP",
    "availability-domain": "ad1",
    "compartment-id": "ocid1.compartment.unique_ID",
    "defined-tags": {},
    "display-name": "publicip20220708231248",
    "freeform-tags": {},
    "id": "ocid1.publicip.unique_ID",
    "ip-address": "IPaddress",
    "lifecycle-state": "ASSIGNING",
    "lifetime": "EPHEMERAL",
    "private-ip-id": "ocid1.privateip.unique_ID",
    "public-ip-pool-id": null,
    "scope": "AVAILABILITY_DOMAIN",
    "time-created": "2022-07-08T23:12:48.610545+00:00"
  },
  "etag": "dcb8dafe-bbe4-42ff-b86a-9e1ebaf4d94c"
}

Reserving a Public IP Address

Use the Compute Web UI procedure in Updating a Public IP Address to create and assign a reserved public IP address in one step.

Use the following OCI CLI procedure to create a reserved public IP address that is available to assign to a private IP address object at a later time.

Using the OCI CLI

Get the OCID of the compartment where you want to create the IP address object: oci iam compartment list

Run the public IP create command.

Syntax:

oci network public-ip create --compartment-id compartment_OCID \
--lifetime reserved

Example:

$ oci network public-ip create --compartment-id ocid1.compartment.unique_ID \
--lifetime reserved --display-name apublicIP
{
  "data": {
    "assigned-entity-id": null,
    "assigned-entity-type": "PRIVATE_IP",
    "availability-domain": null,
    "compartment-id": "ocid1.compartment.unique_ID",
    "defined-tags": {},
    "display-name": "apublicIP",
    "freeform-tags": {},
    "id": "ocid1.publicip.unique_ID",
    "ip-address": "IPaddress",
    "lifecycle-state": "PROVISIONING",
    "lifetime": "RESERVED",
    "private-ip-id": null,
    "public-ip-pool-id": null,
    "scope": "REGION",
    "time-created": "2022-07-06T16:36:56.860931+00:00"
  },
  "etag": "dcb8dafe-bbe4-42ff-b86a-9e1ebaf4d94c"
}

Assigning a Reserved Public IP Address to an Instance

To assign a public IP address to an instance, you assign the public IP address object to a private IP address object.

An ephemeral public IP address can be assigned only to the primary private IP address of a VNIC. See Assigning an Ephemeral Public IP Address to an Instance. A reserved public IP address can be assigned to any private IP address.

See Reserving a Public IP Address to create a reserved public IP address that is available to assign to a private IP address object at a later time.

Use the procedures in Updating a Public IP Address to assign an existing reserved public IP address object to the specified private IP address object or to create and assign a reserved public IP address in one step.

A reserved public IP address object remains available for reassignment when its private IP address object is deleted, its VNIC is detached or terminated, or its instance is terminated.

Updating a Public IP Address

You can use the public IP update command to do any of the following:

Assign an existing reserved public IP address object to a private IP address object.
Create and assign a reserved public IP address object in one step.
Move a reserved public IP address object to a different private IP address object.
Unassign a reserved public IP address object from a private IP address object.
Change the display name or tags for a public IP address object.

Using the Compute Web UI

On the Dashboard, click the Compute/View Instances button.
Click the name of the instance for which you want to assign a public IP address. You might need to change the compartment to find the instance you want.
On the instance details page, scroll to the Resources section and click Attached VNICs. Click the name of the VNIC for which you want to assign a public IP address.
On the VNIC details page, scroll to the Resources section and click IP Addresses. The primary private IP address and any secondary private IP addresses, as well as any attached public IP addresses, are shown in the table.
For the private IP address for which you want to add or update a public IP address, click the Actions menu and then click Edit Public IP.
In the Reserve Public IP dialog, click one of the following choices:
- No public IP
  
  Click the Reserve Public IP button in the dialog to unassign this public IP address from this private IP address. You might have to refresh the page to see that the public IP address is no longer assigned.
- Reserve public IP
  
  Click one of the following choices:
  - Reserve existing public IP
    1. Select an existing public IP address. You might need to change the compartment.
    2. Click the Reserve Public IP button in the dialog.
      If the specified public IP address object is already assigned to a different private IP address object, the public IP address object will be unassigned (moved) from the current private IP address object and reassigned to the specified private IP address object.
  - Create public IP
    
    Create and assign a reserved public IP address in one step.
    1. (Optional) Provide a name for the new reserved public IP address object.
    2. Select the compartment where the new reserved public IP address object will be created.
    3. Select the IP Address Source.
    4. Click the Reserve Public IP button in the dialog.
The new reserved public IP address shows in the IP Addresses table in Resources. You might need to refresh the page to see the new public IP address.

Using the OCI CLI

Get the OCID of the public IP object that you want to update. See Viewing Public IP Addresses.

If you want to assign or move the public IP object to a private IP object, get the OCID of the private IP object. See Viewing Private IP Addresses.

Run the public IP update command.

Syntax:

oci network public-ip update --public-ip-id public_ip_OCID

Example:

The following example updates an existing reserved public IP address object and assigns it to the specified private IP address object. If the specified public IP address object is already assigned to a different private IP address object, the public IP address object will be unassigned (moved) from the current private IP address object and reassigned to the specified private IP address object.

$ oci network public-ip update --public-ip-id ocid1.publicip.unique_ID \
--private-ip-id ocid1.privateip.unique_ID
{
  "data": {
    "assigned-entity-id": null,
    "assigned-entity-type": "PRIVATE_IP",
    "availability-domain": null,
    "compartment-id": "ocid1.compartment.unique_ID",
    "defined-tags": {},
    "display-name": "apublicIP",
    "freeform-tags": {},
    "id": "ocid1.publicip.unique_ID",
    "ip-address": "IPaddress",
    "lifecycle-state": "ASSIGNING",
    "lifetime": "RESERVED",
    "private-ip-id": null,
    "public-ip-pool-id": null,
    "scope": "REGION",
    "time-created": "2022-07-06T16:36:56.860931+00:00"
  },
  "etag": "dcb8dafe-bbe4-42ff-b86a-9e1ebaf4d94c"
}

The following example unassigns the specified reserved public IP address object and makes it available for future reassignment.

$ oci network public-ip update --public-ip-id ocid1.publicip.unique_ID \
--private-ip-id ""

Deleting a Public IP Address

An ephemeral public IP address object cannot be unassigned and cannot be directly deleted. An ephemeral public IP address object is deleted in the following cases:

Its private IP address object is deleted.
Its VNIC is detached or terminated.
Its instance is terminated.

A reserved public IP address object is unassigned but remains available for reassignment when its private IP address object is deleted, its VNIC is detached or terminated, or its instance is terminated.

Use the following procedure to delete a reserved public IP address object.

Using the OCI CLI

Gather the information you need to run the command:
- Compartment OCID: oci iam compartment list
- Public IP address OCID: oci network public-ip list

Run the public IP delete command.

Syntax:

oci network public-ip delete --public-ip-id public_ip_OCID

Example:

oci network public-ip delete --public-ip-id ocid1.publicip.unique_ID --force

Managing Public DNS Zones

In its most basic form, DNS returns an IP address (if known) when given a string in the DNS name space for that zone. However, DNS is also the way that an IP host client application knows where to get its own configuration information using DHCP (DHCID records), go to send or receive email (MX records), and more. Without DNS, client devices would have to know the proper IP addresses not only for local servers, but for every server or application they interacted with, no matter where in the world they were located. With DNS, clients can always find the correct location of www.oracle.com or any other application.

Once you create a DNS zone inside a compartment, you cannot move the zone to another compartment.

Creating a Public DNS Zone

DNS zones are created in a compartment to associate IP addresses with portions of the DNS name space. Zones are created in a compartment using the DNS service.

Using the Compute Web UI

In the navigation menu, under DNS, click Zones. A list of previously configured zones in compartments appears. If the compartment you are creating the DNS zone in is not in the title bar, then use the drop-down tab to select the correct compartment.
Click Create Zone.
Fill in the required zone information:
- Zone Name: Provide a name or description for the DNS zone. Avoid using any of the organization's confidential information.
- Compartment: Select the compartment in which to create the DNS zone.
- Zone Type: Choose the type of DNS zone you are creating.
  - Primary: A primary DNS zone is the original authoritative DNS zone of a portion of the DNS name space. When a DNS server hosts a primary zone, that DNS server is the Authoritative DNS Server and is considered the primary source of information in that zone.
  - Secondary: A secondary DNS zone is a read-only copy of a primary DNS zone or another secondary DNS zone. A secondary DNS zone is kept on a Secondary DNS Server and reduces the load on the primary DNS zone and eliminated a single point of failure risk to name resolution inside the zone.
  For more information on DNS Zones, refer to "Name Resolution" in the Virtual Networking Overview in the Oracle Private Cloud Appliance Concepts Guide.
- Tagging: Optionally, add one or more tags to this resource.
  
  For more information about tagging, see Working with 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 Zone.

The zone is now ready for the addition of zone records or for the configuration of TSIG Keys or Steering Policies.

Using the OCI CLI

Gather the information that you need to run the command:
- Compartment OCID (oci iam compartment list --compartment-id-in-subtree true)

Run the oci dns zone create command.

Syntax (entered on a single line):

oci dns zone create \
--compartment-id <compartment_OCID> \
--name <dns_zone_OCID> \
--zone-type <PRIMARY | SECONDARY>

Example:

oci dns zone create \
 --compartment-id ocid1.compartment.….….….uniqueID \ 
 –-name test-dns-zone \
 --zone-type PRIMARY 

{
  "data": {
    "compartment-id": "ocid1.compartment.….….….uniqueID",
    "defined-tags": {},
    "external-masters": null,
    "freeform-tags": {},
    "id": "ocid1.dns-zone.….….….uniqueID",
    "is-protected": null,
    "lifecycle-state": "ACTIVE",
    "name": "test_dns_zone",
    "nameservers": [
      {
        "hostname": "ns1.example.com"
      }
    ],
    "scope": null,
    "self-uri": "https://20180115/zones/test_dns_zone",
    "serial": 1,
    "time-created": "2021-08-17T18:08:00.059867+00:00",
    "version": 1,
    "view-id": null,
    "zone-type": "PRIMARY"
  },
  "etag": "3e389cab-b3fd-4783-91c1-ede81bc132d5"
}

Working with Zone Records

Creating a DNS zone is only the beginning of working with DNS. The zone is essentially empty when created, except for a basic Start of Authority (SOA) and Name Server (NS) record The SOA record provides a kind of history of this DNS zone and holds information such as when it was last updated and things like that. The NS record contains the fully-qualified name of the DNS server for the zone. The NS record is very important and therefore has a high TTL, usually 24 hours (86400 seconds).

To make the name server truly useful, the zone must be rounded out and filled with the DNS records that form the basis of responses to the kinds of queries that clients make. These queries include IP addresses for parts of the domain name space, email server details, and so on.

Creating a Zone Record

The RDATA field is where the content of the zone record is entered. The format of the information varies according to the type of record you are creating. However, the data must be in one of the formats that DNS understands. For example, an A-type zone record RDATA is an IP address, and an MX record contains information on how to route email. Because of the authoritative nature of the zone records within a zone, RDATA is not editable. If DNS information in a zone changes, then the old record must be deleted and a new record created.

Using the Compute Web UI

In the navigation menu, under DNS, click Zones. A list of previously configured zones in compartments appears. If the compartment you are adding zone records to is not in the title bar, then use the drop-down tab to select the correct compartment.
Click on the name of the zone. The information screen contains general zone information such as type and compartment, OCID (which you can show in full or copy to the clipboard), and the date and time that the zone was created. The zone records that exist are also displayed, and initially there are only SOA and NS records.
Fill in the required zone record information:
- Zone Record:Select the type of zone record you are creating from the drop-down list.
  - A - IPv4 Address: A host record, which is used to point a hostname to an IPv4 address. This is the most basic DNS record type.
  - You can add many other types of zone records: any types in the drop down list.
    
    For more information on DNS Zones, refer to "Name Resolution" in the Virtual Networking Overview in the Oracle Private Cloud Appliance Concepts Guide.
- Domain (Optional): Type the name of the zone subdomain if used (this value is already filled in based on the zone itself: the initial dot (".") is used for adding the zone subdomain).
- TTL: Check this box to set your own value for the TTL of that particular record type. If you do not check this box, the default TTL value for that record type is used (for example, 300 for SOA, 86400 for NS). The valid range is from 1 to 129540 seconds (from 1 second to about a day and a half).
- Edit RDATA: Check this box if you wish to edit the RDATA information, such as the IP address or Target established by the zone record type. This box is only displayed for some zone record types.
- (RDATA): This unlabeled field varies based on the type of zone record created. For example, you enter the 32-bit IP address that corresponds to the A-type DNS record, or Flags for a DNSKEY zone record, if that is what you are creating.
  - A - IPv4 Address: If you are creating an A type zone record, then the data is a properly formatted IPv4 address. This is the most basic DNS record, but there are many others.
  - The RDATA field reflects the correct information for the type of zone record selected.
Click Create Record.

The zone record is now added to the zone. If you click the optional box to Add another record, then the screen stays at the Create DNS Zone Record state to make record entry more efficient.

Using the OCI CLI

There is no "create dns zone record" command in the CLI. Instead, the command "oci dns zone record update" command replaces records in the specified zone with the records specified in the request body of the command. If a specified record does not exist, then it will be created. Also, if a current record is not in the records list, it will be deleted. Care is needed, because if the record exists, then it will be updated with the record information in the body of the request. The command in this section adds an A resource record (IPv4 address and domain name) to a DNS zone named dns-test-zone.

Gather the information that you need to run the command:
- Compartment OCID (oci iam compartment list --compartment-id-in-subtree true)
- DNS zone name (oci dns zone list --compartment_OCID <compartment_OCID>)
Run the oci dns record zone update command.

Note:

This procedure shows the minimum required parameters for this command. For information about optional parameters, run the command with the --help option.

Syntax (entered on a single line):
```
oci dns record zone update \
 --zone-name-or-id <zone_name> or <compartment_OCID> \
 --items <complex type>
```
Note:

DNS resource record types are provided as objects in JSON format. This is a JSON list with items of type RecordDetails. For documentation on RecordDetails please see https://docs.cloud.oracle.com/api/#/en/dns/20180115/datatypes/RecordDetails. This is a complex type whose value must be valid JSON. The value can be provided as a string on the command line or passed in as a file using the file://path/to/file syntax.

The --generate-param-json-input option can be used to generate an example of the JSON which must be provided. We recommend storing this example in a file, modifying it as needed and then passing it back in via the file:// syntax.

Example:
```
oci dns record zone update
 --zone-name-or-id <zone_name> or <compartment_OCID> 
 --items 
{
    "domain": "test-dns-zone.test-pca-comparment.example.com",
    "isProtected": true,
    "rdata": "10.225.15.10",
    "recordHash": "fkT4md",
    "rrsetVersion": "1",
    "rtype": "1",
    "ttl": 3600
}
```

Editing a Zone Record

There is no "edit record" command. You can update a group of records, and if one of the records in the list is the same except for the rdata for example, in effect you have updated the record.

Deleting a Zone Record

You can delete many, but not all, DNS zone records. The initial SOA and NS records, created by default when the zone is created, cannot be deleted, To delete a zone record:

Using the Compute Web UI

In the navigation menu, under DNS, click Zones. A list of previously configured zones in compartments appears. If the compartment you are adding zone records to is not in the title bar, then use the drop-down tab to select the correct compartment.
Click on the name of the zone. The information screen contains general zone information such as type and compartment, OCID (which you can show in full or copy to the clipboard), and the date and time that the zone was created. The zone records that exist are also displayed.
Click on the Action square with the three dots on the right side of the zone record that you are deleting.
Click Delete.

The zone record is deleted and removed from the list for that DNS zone.

Using the OCI CLI

To delete resource records in a zone with the CLI, use the oci dns record rrset delete command to delete an entire resource record set (for example, all A-type IPv4 address records for a given host name). The resource records are identified by their DNS record type (A, MX, and so on). The command in this section deletes the A resource record (IPv4 address and domain name) in a DNS zone named "dns-test-zone" for a device named "test-device-1."

Gather the information that you need to run the command:
- Compartment OCID (oci iam compartment list --compartment-id-in-subtree true)
- DNS zone name (oci dns zone list --compartment_OCID <compartment_OCID>)

Run the oci dns record rrset delete command.

Syntax: (entered on a single line):

oci dns record rrset delete \
 --domain <domain-name> \
 –-rtype <resource-record-type> \
 --zone-name-or-id <zone_name> or <compartment_OCID>

Example:

oci dns record rrset delete \
 --domain "test-device-1.dns-test-zone.example.com" \
 –-rtype "A" \
 --zone-name-or-id "dns-test-zone"

The record is deleted from the zone.

Editing a Public DNS Zone

You can add resource tags to an existing zone. You can also edit the externalMasters field of a SECONDARY zone.

Working with Transaction Signature Keys

A DNS transaction signature (TSIG) is a network protocol defined in RFC 2845. The main purpose of the TSIG is to allow DNS to authenticate updates to a DNS database, so that malicious users cannot change name resolution records to point to a bogus IP address instead of (for example) the IP address of a bank. TSIG uses one-way hashing and shared secret keys to provide a secure means to authenticate the endpoints of a connection for processing (or responding to) DNS update requests.

The TSIG protocol uses timestamps to prevent replay of recorded responses. Therefore, DNS servers and TSIG clients need accurate clocks to provide the timestamps. A number of extensions to the basic TSIG protocol have been made to extend the types of cryptography and hashing methods that are supported by TSIG.

To use TSIG for a DNS zone, add TSIG keys to the DNS zone. The TSIG key must be base64 encoded.

Using the Compute Web UI

In the navigation menu, under DNS Zones, click TSIG Keys.
Click Create Key.
Fill in the required TSIG Key information:
- Name: Provide a name or description for the TSIG key. Avoid using any of the organization's confidential information.
- Compartment: Select the compartment in which to create the TSIG key.
- Algorithm: Choose the security algorithm for the TSIG Key you are creating, such as hmac-sha256.
- Secret Key: Provide the base64 string encoding the binary shared secret that corresponds to the key. The maximum is 255 characters. An example key in base64 encoding is shown in RFC3874. You can provide the key in one of two ways:
  - Select the key file: If you provide the TSIG shared secret key this way, you can drag and drop the key file into the space provided.
  - Paste the key: If you provide the TSIG shared secret key this way, you can copy and paste the contents of the key file into the space provided.
- Tagging: Optionally, add one or more tags to this resource. For more information about tagging, see Working with 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 TSIG Key.

The TSIG key now available for use in the DNS zone between TSIG client and DNS server.

Using the OCI CLI

Gather the information that you need to run the command:
- Compartment OCID (oci iam compartment list --all)

Run the oci dns tsig-key create command.

Note:

This procedure shows the minimum required parameters for this command. For information about optional parameters, run the command with the --help option.

Syntax (entered on a single line):

oci dns tsig-key create \
--algorithm <hmac-algorithm> \
--name <tsig-key-name> \
--compartment-id <compartment_OCID> \
--secret <secret-string>

Example:

oci dns tsig-key create --algorithm hmac-sha256 --name new-tsig-key \
--compartment-id ocid1.compartment.….….….uniqueID \
--secret 2o8goaon2168n(secret key string)e6um8lvd2lwdoouq46lsygak0009014
{
  "data": {
    "-self": "https://20180115/tsigKeys/new-tsig-key",
    "algorithm": "hmac-sha256",
    "compartment-id": "ocid1.compartment.….….….uniqueID",
    "defined-tags": {},
    "freeform-tags": {},
    "id": "ocid1.dns-tsig-key..….….….uniqueID",
    "lifecycle-state": "ACTIVE",
    "name": "new-tsig-key",
    "secret": "2o8goaon2168n(secret key string)e6um8lvd2lwdoouq46lsygak0009014",
    "time-created": "2021-10-29T17:50:31.219934+00:00",
    "time-updated": null
  },
  "etag": "81eb0e02-e09c-4b25-9d21-eefa9ab2aacc"
}

The new key appears in the list of TSIG keys for the DNS for this compartment.

Adding a TSIG Key

To add a TSIG key to an existing list of TSIG keys, simply create another key with a unique TSIG key name and a new algorithm or a new key value. To modify fields in an existing TSIG key, use the update command.

A TSIG key is a separate object from a DNS zone. You can have a SECONDARY DNS zone reference a TSIG key as part of its ExternalMaster definition. But creating a new key doesn't do anything for a PRIMARY zone.

Removing a TSIG Key

Using the Compute Web UI

In the navigation menu, under DNS Zones, click TSIG Keys.
Click on the TSIG key that you want to remove from the dropdown list of TSIG keys.
Click Delete from the list of actions under the Action Menu icon (three bars), or click the Delete button at the top of the display window.

The TSIG key is removed from the list.

Using the OCI CLI

Gather the information for these resources:
- Compartment OCID (oci iam compartment list --compartment-id-in-subtree true)
- TSIG OCID (oci dns tsig-key list --compartment-id <compartment_OCID>)

Syntax (entered on a single line):

oci dns tsig-key delete --tsig-key-id <tsig-key_OCID>

Example:

oci dns tsig-key delete --tsig-key-id ocid1.dns.tsig.key.….….….uniqueID \
Are you sure you want to delete this resource? [y/N]: y

The TSIG key is deleted from the list of TSIG keys for DNS in this compartment. Use the --force option to suppress the "Are you sure...?" message.

Deleting a Public DNS Zone

Using the Compute Web UI

In the navigation menu, under DNS Zones, click Zones.
Click on the zone name that you want to remove from the dropdown list of zones.
Click the Delete button at the top of the display window.

The DNS zone is removed from the list.
The DNS zone is deleted from the compartment. Use the --force option to suppress the "Are you sure...?" message.

Using the OCI CLI

Gather the information for these resources:
- Compartment OCID (oci iam compartment list --compartment-id-in-subtree true)
- Zone OCID (oci dns zone list --compartment-id <compartment_OCID>)

Syntax (entered on a single line):

oci dns zone delete --zone-name-or-id zone_OCID-or-zone-name>

Example:

oci dns zone delete --zone-id ocid1.dns.zone.….….….uniqueID \
Are you sure you want to delete this resource? [y/N]: y

Managing Traffic with Steering Policies

DNS can do more than return an IP address (if known) when given a string in the DNS name space for that zone. DNS is also a part of a system of traffic management, where traffic is distributed among multiple servers depending on some criterion, such as location. Steering policies are a way to distribute access to a single full-qualified name across multiple servers.

For example, the same content could be available from multiple source servers, whether it is a streaming video or records from a product database. One server might be in the United States, and the other in Europe. A traffic steering policy could distribute traffic based on IP address or CIDR. Other criteria can be used for this traffic distribution, such as load balancing, which strives to keep the load on multiple servers roughly equal.

Oracle Private Cloud Appliance offers two major types of traffic steering policies based on load balancing and some value of the IP address prefix (network portion of the IP address, such as 192.168.100.0/24).

Creating a Load Balancer Steering Policy

If you have more than one DNS server, you can distribute traffic in a load balancing fashion, based on the weight you assign to each of them.

Using the Compute Web UI

Open the Navigation Menu. Under DNS Zones, click Steering Policies.
Click Create Steering Policy.
Click the Load Balancer button to create a load balancer steering policy.
Enter the required information:
- Name: Enter a name to display for the load balancer steering policy. Do not use confidential information.
- Policy TTL: Enter a TTL in seconds for responses to steering policy requests. The maximum is 604800 seconds (equal to 168 hours or 7 days).
- Answer(s): Supply the answer or answers to the DNS request for FILTER, WEIGHED, and LIMIT rules. You do not have to specify which condition the answers is for: that is all done by the load balancer template.
  - Name: Enter a name for the RData returned, such as Server1.
  - Type: Choose the type of resource record to return for the request from the dropdown list. Choices are items such as A (IPv4 address) or CNAME (canonical name).
  - RData: Enter the resource record RData that is returned that corresponds to the Type selected. For example, for Type = A, the RData would be an IPv4 address.
  - Weight: Enter a weight for this policy to use for load balancing. Values up to 256 are supported. The default is 10. Higher weights mean that policy answer is used more often. For example, if dns-server1 and dns-server2 have equal weights, DNS requests are split evenly between them. If dns-server1 has a weight twice that of dns-server2, then dns-server1 is used twice as often as dns-server2.
Disabled: The steering policy answer is enabled at creation by default. To disable this steering policy answer, click this toggle to change the Disabled value to TRUE.
Optionally, add or delete tags for this subnet resource.

For more information about tagging, see Working with Resource Tags. If you are not sure whether to apply tags, skip this option (you can apply tags later) or ask your administrator.
Click Save Changes. The load balancing steering policy is created.

Using the OCI CLI

Gather the information you need.
- Compartment OCID (oci iam compartment list --compartment-id-in-subtree true)

Run the oci dns steering-policy create command with the LOAD_BALANCE parameter.

Note:

This procedure shows the minimum required parameters for this command. For information about optional parameters, run the command with the --help option. Complex types are long json strings.

Syntax (entered on a single line):<dns_steering_policy_name>

oci dns steering-policy create
--compartment-id <compartment_OCID>
--display-name <dns_steering_policy_name>
--template <LOAD_BALANCE>
--answers <complex type> 
--rules <complex type>

Example:

oci dns steering-policy create 
--compartment-id ocid1.compartment.….….….uniqueID 
--display-name test-lb-policy-1 
--template LOAD_BALANCE 
--answers '[{"name": "server","pool": "server","rdata": "10.25.11.10","rtype": "A"},
{"name": "trial","pool": "trial","rdata": "10.25.11.10","rtype": "A"}]' 
--rules '[{"ruleType": "FILTER","defaultAnswerData": [{"answerCondition": 
"answer.isDisabled != true","shouldKeep": true}]},{"ruleType": "WEIGHTED","defaultAnswerData": 
[{"answerCondition": "answer.name == 'server'","value": 90},{"answerCondition": 
"answer.name == 'trial'","value": 10}]},{"defaultCount": 1,"ruleType": "LIMIT"}]'

{
  "data": {
    "-self": "https://20180115/steeringPolicies/ocid1.dnspolicy..….….….uniqueID",
    "answers": [
      {
        "is-disabled": true,
        "name": "server",
        "pool": "server",
        "rdata": "10.25.11.10",
        "rtype": "A"
      },
      {
        "is-disabled": true,
        "name": "trial",
        "pool": "trial",
        "rdata": "10.25.11.10",
        "rtype": "A"
      }
    ],
    "compartment-id": "ocid1.compartment.….….….uniqueID",
    "defined-tags": {},
    "display-name": "lr-policy",
    "freeform-tags": {},
    "health-check-monitor-id": null,
    "id": "ocid1.dnspolicy..….….….uniqueID",
    "lifecycle-state": "ACTIVE",
    "rules": [
      {
        "cases": null,
        "default-answer-data": [
          {
            "answer-condition": "answer.isDisabled != true",
            "should-keep": true
          }
        ],
        "description": null,
        "rule-type": "FILTER"
      },
      {
        "cases": null,
        "default-answer-data": [
          {
            "answer-condition": "answer.name == 'server'",
            "value": 90
          },
          {
            "answer-condition": "answer.name == 'trial'",
            "value": 10
          }
        ],
        "description": null,
        "rule-type": "WEIGHTED"
      },
      {
        "cases": null,
        "default-count": 1,
        "description": null,
        "rule-type": "LIMIT"
      }
    ],
    "template": "LOAD_BALANCE",
    "time-created": "2021-11-03T23:36:25.392833+00:00",
    "ttl": 30
  },
  "etag": "2c63fca5-f747-487e-b2f3-0ae5d6fe939c"
}

The load balancer steering policy is created and available for attaching to a DNS domain.

Creating an IP Prefix Steering Policy

An IP prefix steering policy dynamically routes DNS request traffic to different servers based on the originating IP prefix (for example, 172.16.1.0/24).

Using the Compute Web UI

Open the Navigation Menu. Under DNS Zones, click Manage DNS.
From the list of DNS resources, click Steering Policies. The steering policies for that compartment are displayed.
Click Create Steering Policy.
Select IP Prefix Steering and supply the following properties:
- Name: The name for the new steering policy.
- Policy TTL:The Time To Live (TTL) for responses from the steering policy, in seconds. The maximum allowed value is 604800 (equal to 168 hours or 7 days).
In the Answer(s) box, supply the following properties:
- Name: The name for response to requests sent to the new steering policy.
- Type: The type of request and response. The choices are A, AAA, or CNAME.
- RData: The zone record data to return for the query. It must match the type expected by the type chosen.
- Pool: Select the IP address pool to use of the policy from the dropdown list.
- +Add Answer: Click this box to add more answers to the requests received by the steering policy.
- Disabled: This toggle determines if the IP prefix answer is enabled at creation or not. The default is enabled.
In the IP Prefix Steering Rules box, supply the following properties:
- +Add Rule: Click this box to add rules to the IP prefix steering policy.
- Order: Use the directional arrows to order the rule in the sequence of configured rules.
- Subnet Address: Enter the IP subnet prefix to apply to this steering policy.
- You can add more rules to this steering policy by clicking +Add Rule.
Tagging: Optionally, you can add tags to the steering policy.

For more information about tagging, see Working with Resource Tags. If you are not sure whether to apply tags, skip this option (you can apply tags later) or ask your administrator.
Click Save Changes. The IP prefix steering policy is created.

Using the OCI CLI

Gather the information you need.
- Compartment OCID (oci iam compartment list --compartment-id-in-subtree true)

Run the oci dns steering-policy create command with the ROUTE_BY_IP parameter.

Note:

This procedure shows the minimum required parameters for this command. For information about optional parameters, run the command with the --help option. Complex types are long json strings.

Syntax (entered on a single line):

oci dns steering-policy create--compartment-id <compartment_OCID>
--display-name <dns_steering_policy_name>
--template <LOAD_BALANCE>
--answers <complex type> 
--rules <complex type>

Example:

oci dns steering-policy create --compartment-id ocid1.compartment..….….….uniqueID
--display-name test-ip-steering-1 
--template ROUTE_BY_IP  
--answers file:///root/users-stuff/ip-steering-answers.json 
--rules file:///root/users-stuff/ip-steering-rules-2.json
{
  "data": {
    "-self": "https://20180115/steeringPolicies/ocid1.dnspolicy..….….….uniqueID",
    "answers": [
      {
        "is-disabled": null,
        "name": "server",
        "pool": "server",
        "rdata": "10.20.10.10",
        "rtype": "A"
      },
      {
        "is-disabled": null,
        "name": "trial",
        "pool": "trial",
        "rdata": "10.20.10.10",
        "rtype": "A"
      }
    ],
    "compartment-id": "ocid1.compartment..….….….uniqueID",
    "defined-tags": {},
    "display-name": "test-ip-steering-1",
    "freeform-tags": {},
    "health-check-monitor-id": null,
    "id": "ocid1.dnspolicy..….….….uniqueID",
    "lifecycle-state": "ACTIVE",
    "rules": [
      {
        "cases": null,
        "default-answer-data": [
          {
            "answer-condition": "answer.isDisabled != true",
            "should-keep": true
          }
        ],
        "description": null,
        "rule-type": "FILTER"
      },
      {
        "cases": [
          {
            "answer-data": [
              {
                "answer-condition": "answer.pool == 'internal'",
                "value": 1
              }
            ],
            "case-condition": "query.client.address in (subnet '10.0.3.0/24')"
          },
          {
            "answer-data": [
              {
                "answer-condition": "answer.pool == 'external'",
                "value": 1
              }
            ],
            "case-condition": null
          }
        ],
        "default-answer-data": null,
        "description": null,
        "rule-type": "PRIORITY"
      },
      {
        "cases": null,
        "default-count": 1,
        "description": null,
        "rule-type": "LIMIT"
      }
    ],
    "template": "ROUTE_BY_IP",
    "time-created": "2021-11-09T16:53:34.963177+00:00",
    "ttl": 30
  },
  "etag": "aad5bbcc-9d89-40cd-ab10-03dcc2e4ee0a"
}

The IP steering policy is created and available to attach to a DNS domain.

Editing a Steering Policy

Using the Compute Web UI

Open the Navigation Menu. Click DNS, and then click Steering Policies.
For the policy that you want to update, click the Actions menu, and click the Edit option.
Make the necessary changes on the Edit Steering Policy dialog.
When you have finished making changes, click the Save Changes button on the dialog.

The details page for this steering policy is displayed with the updated information.

Using the OCI CLI

Get the steering policy OCID.

Use the following command to list all of the steering policies in the specified compartment to get the OCID of the steering policy that you want to update:
```
# oci dns steering-policy list --compartment-id <compartment_OCID>
```
Run the steering policy update command.

Syntax:
```
oci dns steering-policy update --steering-policy-id <steering_policy_OCID> \
<options_with_values_to_update>
```
Example:

This example shows replacing the answers block of the steering policy. You can also change the display name, health check monitor, rules or rules template, TTL, and scope.
```
# oci dns steering-policy update --steering-policy-id ocid1.dnspolicy.unique_ID \
--answers file://answers.json
```
This command returns the same output as the steering-policy get command.

Moving a Steering Policy to a Different Compartment

Using the OCI CLI

Get the following information:
- The OCID of the compartment where the steering policy is currently located, and the OCID of the compartment where you want to move the steering policy.
```
# oci iam compartment list --compartment-id-in-subtree true
```
- The steering policy OCID.
```
# oci dns steering-policy list --compartment-id <current_compartment_OCID>
```
Run the steering policy update command.

Syntax:
```
oci dns steering-policy change-compartment -c <destination_compartment_OCID> \
--steering-policy-id <steering_policy_OCID>
```
This command returns the same output as the steering-policy get command. Verify the new compartment-id.

Attaching a Domain to a Steering Policy

A steering policy must be attached to a domain for the policy to answer DNS queries for that domain. The attachment is automatically placed into the same compartment as the domain's zone.

Using the Compute Web UI

Open the Navigation Menu. Click DNS, and then click Steering Policies.
Click the name of the policy to which you want attach a domain.
Scroll to the Resources section and click Attached Domains.
In the list of attached domains, click the Add Attached Domain button.
In the Add Attached Domain dialog, enter the domain name and select a zone.
Click the Submit button.

The new domain is added to the Attached Domains list for this steering policy.

Using the OCI CLI

Get the following information:
- The steering policy OCID. Use the following command to list all of the steering policies in the specified compartment to get the OCID of the steering policy to which you want to attach a domain:
```
# oci dns steering-policy list --compartment-id <current_compartment_OCID>
```
- The name of the domain that you want to attach to the steering policy.
- The OCID of the attached zone. Use the following command to list all of the zones in the specified compartment to get the OCID of the zone where the domain that you want to attach is located:
```
# oci dns zone list <compartment_OCID>
```
Run the steering policy attachment create command.

Syntax:
```
oci dns steering-policy-attachment create --steering-policy-id <steering_policy_OCID> \
--domain-name <domain-name> --zone-id <zone_OCID>
```
The value of the --domain-name argument is the attached domain within the attached zone specified in the --zone-id argument.

This command returns the same output as the steering-policy-attachment get command.

Editing an Attached Domain

Using the Compute Web UI

Open the Navigation Menu. Click DNS, and then click Steering Policies.
Click the name of the policy for which you want to edit an attached domain.
Scroll to the Resources section and click Attached Domains.
Click the name of the attached domain that you want to edit.
On the top of the details page for the attached domain, click the Edit button.
Make the necessary changes on the Edit Steering Policy Attachment dialog.
When you have finished making changes, click the Save Changes button on the dialog.

The details page for this steering policy attachment is displayed with the updated information.

Using the OCI CLI

Get the steering policy attachment OCID.

Use the following command to list all of the steering policy attachments in the specified compartment to get the OCID of the steering policy attachment that you want to update:
```
# oci dns steering-policy-attachment list --compartment-id <compartment_OCID>
```
Run the steering policy attachment update command.

Syntax:
```
oci dns steering-policy-attachment update \
--steering-policy-attachment-id <steering_policy_attachment_OCID>
```
This command returns the same output as the steering-policy-attachment get command.

Deleting a Steering Policy Attachment

Using the Compute Web UI

Open the Navigation Menu. Click DNS, and then click Steering Policies.
Click the name of the policy for which you want to delete an attachment.
Scroll to the Resources section and click Attached Domains.
For the attached domain that you want to delete, click the Actions menu, click the Delete option, and confirm the deletion.

The steering policy attachment is removed from the Attached Domains list.

Using the OCI CLI

Get the steering policy attachment OCID.

Use the following command to list all of the steering policy attachments in the specified compartment to get the OCID of the steering policy attachment that you want to delete:
```
# oci dns steering-policy-attachment list --compartment-id <compartment_OCID>
```

Run the steering policy attachment delete command.

Syntax:

oci dns steering-policy-attachment delete \
--steering-policy-attachment-id <steering_policy_attachment_OCID>

Deleting a Steering Policy

A policy that is attached to any zones cannot be deleted. To detach a policy from a zone, see Deleting a Steering Policy Attachment.

Using the Compute Web UI

Open the Navigation Menu. Click DNS, and then click Steering Policies.
Click the name of the policy that you want to delete.
Scroll to the Resources section, click Attached Domains, and ensure that this policy has no attached domains.
Click the Delete button at the top of the steering policy details page, and confirm that you want to delete this steering policy.

The steering policies list page is displayed.

Using the OCI CLI

Get the steering policy OCID.

Use the following command to list all of the steering policies in the specified compartment to get the OCID of the steering policy that you want to delete:
```
# oci dns steering-policy list --compartment-id compartment_OCID
```

Run the steering policy delete command.

Syntax:

oci dns steering-policy delete --steering-policy-id steering_policy_OCID

Networking Scenarios

All networking scenarios for a virtualized cloud environment are similar to scenarios for individual IP subnets connected by physical switches, routers, and gateways. In other words, virtual devices still have MAC (hardware) addresses as source and destination addresses in frames and IP addresses as source and destination addresses in packets.

Content delivery works essentially the same way as well. If the network portion of the source and destination IP addresses are in the same defined VCN subnet, delivery is through a logical switch (bridge) based on source and destination MAC frame addresses. If the network portion of the source and destination IP addresses are in different VCN subnets, then delivery is based on source and destination IP packet addresses.

You do not have to configure a logical switch for Oracle Private Cloud Appliance. The MAC addresses are known to all the other entities connected to the logical switch. It is assumed that if you place two or more VMs in the same VCN subnet, it is okay if they communicate. If instance isolation is the goal, then establish separate subnets or VCNs for them.

Logical Routers

Traffic between different VCN subnets is handled by at least one logical router, by definition. Devices that use IP packet addresses to determine forwarding steps, while using different MAC frame addresses on the different subnets they link, are called routers. In the case where the routers attach to the internet, these virtual devices are internet gateways (IGWs).

In cases where the source or destination IP address rules include IP network address translation (NAT), the packets are handled by a NAT gateway of some type (there are several types of NAT gateways). If some form of NAT is used, these are NAT gateways (NATGW or NGW).

In many cases of virtualized cloud networking, routing is very simple and can be handled by a small, static routing table that has a handful of destinations. More complex virtual environments require more complex logical routers, containing dynamic information that is updated periodically.

Logical routers inspect the packet's IP addresses. The IP addresses, source and destination, are looked up in a route table, called the route rule table in the Oracle Private Cloud Appliance, and forwards the packet to the next hop (another router) or destination (for local delivery) if the IP address rule allows this. If the route rules do not apply to the IP addresses, the packet is silently dropped and does not generate an error message (this is a security feature to prevent blocked probes from gathering information). However, this lack of error messages means that the route rules must be configured very carefully.

One IP address is special when it comes to route rules. This is the IPv4 address 0.0.0.0/0, which essentially matches any IP address at all. In some documents, the 0.0.0.0/0 notation is called an IP address CIDR block, but the same universal matching is true no matter what it is called.

For example, the following route rule allows a packet sent from inside the VCN to any IP address at all to reach a gateway to the internet:

Destination                                                          Target
0.0.0.0/0                                          Internet Gateway  vcn-20210714-0910

Route rules do more than determine the destination of a packet. Route rules also form the basis for network firewalls.

Using Firewalls

Internet access is convenient, but brings concerns over vulnerability and security. Firewalls exist to limit the free passage of traffic between network elements and secure the network. A firewall, logical or physical, examines the traffic flow from a particular source to a particular destination and permits or blocks the packets based on the configured security rules in the route rule table.

Firewalls should be configured not only to allow or block traffic from or to external sources, but should also be configured to validate the traffic passing from subnet to subnet within the same VCN. Threats could be coming from external sources, but also from compromised instances within the network.

Use of Network Segmentation

It is tempting to configure a virtual network as one big entity, with everything easily reachable by everything else. But this makes it relatively easy for attackers to compromise the network: once they are in, they are in everywhere. It is much better to use segmentation for the network and group resources and data into the various segments.

In the Oracle Private Cloud Appliance, segments are essentially network security groups.

Typically, you group data and resources based on similarity or data sensitivity. For example, you can establish a group that examines all traffic received from the data center. Based on your security rules, this traffic can then be passed to a group of application servers, and then onto the database servers.

With this approach, firewalls between the groups secure the application and database servers from any compromised components of the data center.

Use of Tunneling

One complication of virtualized cloud networking is that there is no central authority to assign IP addresses to VCN subnets. Nothing stops one hypervisor from assigning, for example, IP address 192.168.1.6 to VM-1 in Subnet-1 of VCN-1, while another hypervisor assigns the same IP address 192.168.1.6 to VM-7 in Subnet-1 of VCN-1. Yet, if various tables are configured correctly, they can still communicate.

In order to effectively hide these network address complications, the Oracle Private Cloud Appliance moves traffic between network components such as logical routers through IP tunnels. However, this use of tunnels, a common IP network practice, does not change the network scenarios. Instances still have IP addresses, and these addresses are still assigned to a particular subnet and the subnets are assigned to virtual network interface cards (VNICs). All traffic from the various running instances under the same a hypervisor is bonded together into an IP tunnel for transport to the next device between source and destination.

Use of Virtual Cloud Networks

It is easy to say that resources are gathered into one or more VCNs, which are private cloud networks running in a tenancy. But there is a lot more to VCNs than declaring a group of resources and creating a boundary for a VCN.

Planning your VCNs is a critical part of any deployment. VCNs serve as a foundation to structure your application servers, databases, and any other services provided. VCNs should take into account any needs such as redundancy, high availability, scalability, security, and more.

This section details the critical parts of a VCN.

IP Address Ranges

When planning VCNs, the first decision to make is which IP address CIDR block to use.

Note:

To help with the calculation of CIDR blocks, a good resource is: IP Address Guide for CIDR

The VCN network address range should be any VLSM between /16 and /30. This covers virtual networks for between 4 available IP addresses (/30) to 65,536 available IP addresses (/16), although the highest and lowest IP address are not useful for endpoint devices.

The size of the CIDR block chosen for the VCN is of critical importance. If the size is too large, then IP addresses are wasted that could be used in other places in the network. If the size is too small, the solution does not scale because there are not enough IP addresses for the VCN. You can always create another VCN and peer them together, but this is a complication that can be avoided through careful planning.

There are some important points about VCN CIDR blocks:

VCNs should use one of the RFC1918 private address ranges: 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16.
VCNs use a contiguous IPv4 CIDR block. IPv6 is not supported.
You cannot change the VCN and subnet sizes (such as 10.100.0.0/21) after their creation. The IP address range must not overlap with any VCN you want to peer with.
Subnets within a VCN must not overlap with each other.
Remember that the highest and lowest IP addresses in a range are reserved for network functions.

IP Subnets

A subnet is a subdivision of a VCN that uses a continuous IP address range as established by CIDR. Subnets group resources by IP address.

From the VCN perspective, subnets can be public or private. In the context of Oracle Private Cloud Appliance, private VCN addresses must be changed using NAT before they can interact with other VCNs that might be using the same private address space. Public VCN addresses allow for connectivity to the data center network and are accessible from outside the rack.

It is, however, possible to have an RFC1918 address space subnetted into both public IP address spaces (which allows external data center connectivity) and private IP address spaces (which connect within the Oracle Private Cloud Appliance rack).

For example, it is possible for a VCN to do this with an IP CIDR block:

Subnet Name                           Subnet Access                               IP CIDR Block

Public_Subnet_01                      Public                                      10.100.0.0/24
Private_Subnet_01                     Private                                     10.100.1.0/24

Public_Subnet_01 has 256 IP addresses, from 10.100.0.0 to 10.100.0.255 (these two addresses are not often used for devices and have special uses in most IP networks). The netmask is 255.255.255.0

Private_Subnet_01 also has 256 IP addresses, from 10.100.1.0 to 10.100.1.255 (again, the low and high addresses are not often useful for devices). The netmask is 255.255.255.0.

Note that the two address ranges do not overlap. (If the public range was 10.100.0.0/23, then 256 devices would overlap with 10.100.1.0/24.)

Route Tables

A VCN uses a route table to hold the rules governing the sending and receiving of traffic by an instance. A VCN could be allowed or prevented form reaching destinations like:

The global public internet
An on-premise network, such as the date center network
A peer VCN

Whenever a VCN is created, a virtual router with a default route table is also created.

For better security, it is preferable to create a dedicated route table for every subnet rather than use the default rules, which might not be adequate for the level of security needed. Dedicated route tables can more effectively manage the route rules that each subnet needs. For example, if the subnet is allowed to send traffic out onto the global public internet, then the route table for that subnet needs a rule for routing traffic to an internet gateway with the "universal destination" 0.0.0.0/0.

Note:

The CIDR block 0.0.0.0/0 matches all addresses in the IPv4 address space. It means "any IPv4 address with any subnet mask."

A subnet not needing global public network access should not include that rule in the route table. In addition:

Traffic with a source and destination within a VCN is not governed by any route table rules.
If rules overlap (usually regarding different CIDR block or subnets), then the more specific rule applies (often seen as "the longest match").
If there is no rule that applies to the traffic flow, then the traffic is silently dropped (no error message sent).

Every rule in the route table has a target. The targets are the functional network nodes for the common components of any network:

Dynamic Routing Gateway (DRG: the route table rules are not statically configured, but use a routing protocol such as BGP to change them).
Internet Gateway (IG) to connect to the global public internet.
NAT gateway (NATG) for IP address translation.
Service Gateway (SG) to reach a variety of services in other subnets.
Local Peering Gateway (LPG) to connect to peer VCNs.
Private IP address, which routes traffic to a specific instance inside the VCN.

As an example, a VCN could contain a route table with the following rules:

Subnet Name                           Route Table                                Target

Public_Subnet_01                      Public_Subnet_01_Route_Table               IG
Private_Subnet_01                     Private_Subnet_01_Route_Table              NAT Gateway

Route tables are the foundation of VCN security.

Security Lists and Network Security Groups

It might seem odd that an on-premises network needs firewall-like security. But security is important in every context, and not all threats come from outside an organization.

Oracle Private Cloud Appliance offers two security networking mechanisms that act like firewalls to control traffic at the packet level:

Security lists, which are used like physical firewalls for subnets.
Network security groups (NSGs), which act as firewalls for groups of instances across subnets.

You use a security list to define the rules that apply to all inbound (ingress) and outbound (egress) traffic of a subnet. You can associate up to five security lists per subnet. In the same way as route tables, there are default security lists and dedicated security lists. For better control and management, you should always use dedicated security lists for each subnet.

In contrast to security lists, NSGs let you build rules for groups of instances, even if the instances are in different subnets. For example, the same NSG can apply to all the database servers, or all the application servers running a certain application. Instead of applying security to a particular subnet, you create an NSG and then add the appropriate instances to the NSG.

There is no requirement to use either security lists or NSGs. You can use security lists without establishing NSGs, or create NSGs without creating any security lists. However, if you use both security lists and NSGs, the rules that apply to a VNIC are the union (both sets) of the rules that are in the security list for the VNIC and the rules specific to that VNIC from the NSG.

When creating a VCN, a default security list with three ingress rules and one egress rule is created. The default rules are stateful, which means that they know what connections are and that a request is followed by a response and that the rules should take this into consideration. In contrast, stateless rules are applied to every packet regardless of situation.

The default ingress and egress security rules look like this if you display them:. First, the ingress rules (for a 10.0.0.0/16 CIDR block):

Stateless Source       Source Type  IP Protocol Source Port Range Destination Port Range  Type and
                                                                                          Code

No        10.0.0.0/16  CIDR Block   ICMP                                                  3
No        0.0.0.0/0    CIDR Block   ICMP                                                  3, 4
No        0.0.0.0/0    CIDR Block   TCP         22 - 22            22 - 22

These rules, line by line, can be read as:

There is a stateful rule that apples to traffic originating from the VCN 10.0.0.0/16 CIDR block using the ICMP protocol Type = 3 message format (Destination Unreachable) and all Codes. In other words, this rule allows devices in the 10.0.0.0/16 CIDR block to pass Destination Unreachable messages with any code (such as Net or Host Unreachable) back to the sender (another instance in the VCN subnet).
There is a stateful rule that apples to traffic originating from any IP address (0.0.0.0/0 CIDR block) using the ICMP protocol Type = 3 message format (Destination Unreachable) and a Code = 4 (message must be fragmented, but the Do Not Fragment (DF) bit is set in the packet: these are Path MTU Discovery messages). In other words, this rule allows devices to notify sources that the DF bit is set on packets that need to be fragmented because the content exceeds the MTU size established for this VCN subnet.
There is a stateful rule that apples to traffic originating from any IP address (0.0.0.0/0 CIDR block) using the connection-oriented TCP protocol and with the Source or Destination Port = 22 (SSH). In other words, this rule allows SSH for this VCN subnet.

This last rule makes allows you to create a new VCN and subnet, launch a Linux instance, and then use SSH to connect to that instance without writing any new security list rules.

Important:

The default ingress security list does not include a rule to allow Remote Desktop Protocol (RDP) access. If you're using Windows images, make sure to add a stateful ingress rule for TCP traffic on destination port 3389 from authorized source IP addresses and any source port. See To enable RDP access for more information.

The single egress rule is very simple:

Stateless Source       Source Type  IP Protocol Source Port Range Destination Port Range  Type and
                                                                                          Code

No        0.0.0.0/0    CIDR Block   All

This can be read as: "There is a stateful rule that allows packets with any source address and for any IP protocol at all to leave the VCN." This basically says that anything can leave the VCN subnet without a problem.

The default security list comes with no stateless rules. However, you can always add or remove rules from the default security list.

To use these default rules in an NSG, let's give the default ingress and egress rules distinctive names, such as Ingress_Security_List_Subnet01 and Egress_Security_List_Subnet01. Before you can add these rules to an NSG, you must first create the NSG. To create an NSG, you must give it a name and assign it to an existing compartment. You can also add tags, but these can be added later.

Network Gateway Example: Internet Gateway

VCNs are the basic networking unit of the Oracle Private Cloud Appliance, and can communicate with other processes through various types of gateways used for a particular purpose.

In this example, access to a VCN from outside the rack is established through an Internet gateway (IGW). All steps to produce a working IGW are detailed.

This example sets up an IGW to allow access to web servers on a public IP subnet running inside an instance. It also adds an ingress rule to the default security list to allow outside access to the web servers on the public subnet. Then this example allows ingress connections for HTTPS connections on TCP port 443, the standard port for HTTP encrypted traffic.

Without this ingress rule, inbound HTTPS connections are not allowed. You should make the new rule stateful, which is the default and allows a reply to an HTTPS request without creating an explicit rule for responses.

Next, this example adds the existing IGW target to the route rules. The route rules are added to the default route table for the VCN, or a new route table created for reaching the IGW specifically. The route rule uses CIDR block 0.0.0.0/0. This means that all traffic not already covered by other rules in the route table goes to the IGW target specified in this new rule.

This example includes steps to enable or disable the IGW, and how to delete it.

Overview

There are three major operations for establishing and using an IGW. Each step has its own set of prerequisites and can usually be configured with the Compute Web UI or the OCI CLI. If both methods are available, both methods are presented.

The three activities used to configure and operate an IGW are:

Set up an IGW
Create or update a route table to include a rule for an IGW
Update the Security List or NSG

Set Up an Internet Gateway

The first thing that needs to be done is to configure the IGW.

Basic Internet Gateway Configuration

There are certain considerations that need to be assessed before setting up and using an IGW:

There are public subnets in the VCN that need internet access. (Only public subnets can use the IGW successfully.)
Because the default condition is to deny access, the types of ingress and egress internet traffic that are allowed must have been determined. These include ingress HTTPS connections, ingress ICMP pings, or other types of traffic. The IGW primarily responds to ingress network protocol requests.

For the basic configuration of an IGW, see Providing Public Access through an Internet Gateway. You must perform this initial configuration before proceeding.

Once the IGW has been created, there are two additional steps needed to make the IGW work properly with route tables and security list for the VCN or instance port Network Security Groups (NSGs). First, route table entries for the subnet must be configured to direct authorized traffic to the proper gateway destination. Second, the VCN containing to IGW must have the correct security rules to prevent unauthorized access and yet allow users to access resources they need.

Establish the Route Table Entries

Each public subnet that needs to use the internet gateway needs to update the subnet's route table entry to include a route to the IGW.

Each route rule specifies a destination CIDR block and the target (the next hop) for any traffic that matches that CIDR. Before you can create a rule, you must create a target for the rule, in this case, an IGW.

This example adds the existing IGW target to the route rules of the default route table for the VCN. You can also create a new route table for reaching the IGW specifically, but that is not done here. The route rule uses CIDR block 0.0.0.0/0 so that all traffic not covered by other rules in the route table goes to the IGW target specified in this new rule.

Using the Compute Web UI

Open the Navigation Menu. Under Networking, click Virtual Cloud Networks.
Click the name of the VCN for which you want to create a route table. The VCN details page is displayed.
Under Resources, click Route Tables.
Go to the details page of the Default Route Table and click the Add Route Rule button.
Click +New Rule, and enter the following information for this example:
- Target Type: Select Internet Gateway from the list.
- CIDR Block: Enter 0.0.0.0/0 as the destination CIDR block for the traffic.
- Target: The target is the IGW. Click the arrow and select the target IGW. You might need to change the compartment just above the arrow.
- Description: An optional description of the rule, such as "New rule for IGW."
Click the Create Route Table Rule button in the dialog.

The details page of the edited default route table is displayed. Because the subnet was set up to use the default route table, the resources in the subnet can now use the internet gateway.

Using the OCI CLI

Gather the information you need to run the command:
- The OCID of the compartment where you want to create this route table (oci iam compartment list)
- The OCID of the VCN for this route table (oci network vcn list --compartment-id compartment_OCID)

Construct an argument for the --route-rules option.

Route rules are in JSON format. To see how to format a rule, use the following command:

oci network route-table update --generate-param-json-input route-rules > route_rule_format.json

Example (put the following content into the IGW_route_rule.json file):

[
  {
    "cidr-block": "0.0.0.0/0",
    "description": null,
    "destination": null,
    "destination-type": "CIDR_BLOCK",
    "network-entity-id": "ocid1.internetgateway.unique_ID"
 }
]

Run the route table update command.

Syntax:

oci network route-table update --compartment-id compartment_OCID \
--vcn-id vcn_OCID --route-rules file:///home/flast/IGW_route_rule.json

While the new route table is still provisioning, the route-rules property might be empty. To confirm the options, use the OCID in the id property of the create output to run a get command:

oci network route-table get --rt-id ocid1.routetable.unique_ID

Once the route table rule has been added, the IGW is now reachable from the subnet and VCN.

Establish the Internet Gateway Security Rules

Once the IGW has been created, the correct security setting must be established to prevent unauthorized access to the gateway. For example, all outside HTTPS access should only be allowed to access port 443 which is the default port of secure web page access. Without this explicit rule, the standard port is not reachable.

This section uses security lists to accomplish this goal, but a similar result can be achieved using security rules in a Network Security Group (NSG), which is what Oracle recommends.

For more information about security lists and NSGs, see the Virtual Networking Overview.

Important:

If you have configured the public subnet to use the default security list, remember that the default includes several rules to enable basic access, such as ingress SSH and egress access to all destinations. Oracle recommends that you become familiar with this basic access set of rules. If you do not use the default security list, make sure that basic access is still provided either in the customized security rules or in an NSG containing those modified rules.

This example adds an ingress rule to the default security list to allow ingress connections for HTTPS connections on TCP port 443, the standard port for HTTP encrypted traffic.

Without this ingress rule, inbound HTTPS connections are not allowed. You should make the new rule stateful, which allows a reply to an HTTPS request without creating an explicit rule for responses.

For information about creating a new security list instead of modifying the default or adding a rule to an existing security list, see Creating a Security List.

Using the Compute Web UI

Open the Navigation Menu. Under Networking, click Virtual Cloud Networks.
Click the name of the VCN for which you want to add the rule to a security list. The VCN details page is displayed.
Under Resources, click Security Lists.
For the security list that you want to add the rule, click the Actions menu and then click Edit to open the Edit Security List dialog. Update rules in the Allow Rules for Ingress and Allow Rules for Egress sections.
To add a new rule, in the Allow Rules sections, click the +New Rule button. You can also update the security list name and tags.
When you are done, click the Save Changes button on the dialog.

For the HTTPS example using TCP port 443 ingress rule, enter the following information:

Stateless: To allow for a response to the incoming HTTPS request, the new rule should be stateful. Make sure that the stateless box is unchecked. For more information about stateless and stateful rules, see "Security Lists" in the Virtual Networking Overview in the Oracle Private Cloud Appliance Concepts Guide.
CIDR: The CIDR block for the example 0.0.0.0/0, which applies the rule to all IP source addresses.
IP Protocol: Select the TCP protocol from the drop-down list.
Port Range:
- Source Port Range: Leave blank.
- Destination Port Range: Enter 443.
Description: An optional description of the rule, such as "Allow stateful traffic for HTTPS on TCP port 443."

Click Save Changes to save your new rule. You can always edit the new rule at any time.

Using the OCI CLI

Get the OCID of the default security list of the VCN that you want to update (oci network vcn list --compartment-id compartment_OCID)

To update rules, construct arguments for the --ingress-security-rules and --egress-security-rules options as described in Creating a Security List. Arguments that you provide to these rules options overwrite any existing rules. If you want to keep some existing rules, use the following command to show the current rules, and then copy the rules that you want to keep into the new option arguments.

$ oci network security-list get --security-list-id ocid1.securitylist.unique_ID

Example (put the following content in the file IGW_ingress_rule.json):

[
  {
    "description": null,
    "icmp-options": null,
    "is-stateless": false,
    "protocol": "6",
    "source": "0.0.0.0/0",
    "source-type": "CIDR_BLOCK",
    "tcp-options": {
      "destination-port-range": {
        "max": 22,
        "min": 22
      },
      "source-port-range": null
    },
    "udp-options": null
  },
  {
    "description": null,
    "icmp-options": null,
    "is-stateless": false,
    "protocol": "6",
    "source": "0.0.0.0/0",
    "source-type": "CIDR_BLOCK",
    "tcp-options": {
      "destination-port-range": {
        "max": 443,
        "min": 443
      },
      "source-port-range": null
    },
    "udp-options": null
  }
]

Run the security list update command to add the rule for HTTPS and TCP port 443 traffic.

Example:

oci network security-list update  \
--security-list-id ocid1.securitylist.unique_ID \
--ingress-security-rules file:///home/flast/IGW_ingress_rule.json

WARNING: Updates to defined-tags and egress-security-rules and freeform-tags and 
 ingress-security-rules will replace any existing values. 
 Are you sure you want to continue? [y/N]: y