VCN Troubleshooting

Breaking API Changes

If anyone in your organization implements a regional subnet, be aware that you may need to update any client code that works with Networking service subnets and private IPs. There are possible breaking API changes. For more information, see the regional subnet release note.

DNS Resolver Endpoints

Network security groups (NSGs) act as a virtual firewall for your DNS resolver endpoints. An NSG consists of a set of ingress and egress security rules that apply only to the associated DNS resolver endpoints.

Secondary IP Address

If you've assigned a secondary IP to a secondary VNIC, and you're using policy-based routing for the secondary VNIC, make sure to configure the route rules to look up the same route table for the secondary IP address.

DNS in Your VCN

You use the Domain Name Server DHCP option to specify the DNS Type for the associated subnet. If you change the option's value, either restart the DHCP client on the instance or reboot the instance. Otherwise, the change does not get picked up until the DHCP client refreshes the lease (within 24 hours).

By default. the Internet and VCN Resolver does not let instances resolve the hostnames of hosts in your on-premises network connected to your VCN by IPSec VPN connection or FastConnect. That functionality can be achieved either by using a custom resolver or by configuring the VCN's private DNS resolver.

Requirements for DNS Labels and Hostnames

  • VCN and subnet labels: Max 15 alphanumeric characters and must start with a letter. Notice that hyphens and underscores are NOT allowed. The value cannot be changed later.
  • Hostnames: Max 63 characters and must be compliant with RFCs 952 and 1123. The value can be changed later.

Don't confuse the DNS label or hostname with the friendly name you can assign to the object (that is, the display name), which doesn't have to be unique.


Your instances running Oracle-provided Linux images or Windows images also have OS firewall rules that control access to the instance. When troubleshooting access to an instance, make sure that all of the following items are set correctly:

  • The rules in the network security groups that the instance is in
  • The rules in the security lists associated with the instance's subnet
  • The instance's OS firewall rules

For more information, see Oracle-Provided Images.

If your instance is running Oracle Autonomous Linux 7, Oracle Linux 8, or Oracle Linux 7, you need to use firewalld to interact with the iptables rules. For your reference, here are commands for opening a port (1521 in this example):

sudo firewall-cmd --zone=public --permanent --add-port=1521/tcp
sudo firewall-cmd --reload

For instances with an iSCSI boot volume, the preceding --reload command can cause problems. For details and a workaround, see Instances experience system hang after running firewall-cmd --reload.

Subnet or VCN Deletion

This topic covers reasons why deletion of a subnet or VCN might fail.


  • To delete a VCN, it must first be empty and have no related resources or attached gateways (for example: no internet gateway, dynamic routing gateway, and so on).
  • To delete a VCN's subnets, they must first be empty.

Delete All Option

The Console has an easy "Delete all" process that deletes a VCN and its related Networking resources (subnets, route tables, security lists, sets of DHCP options, internet gateway, and so on). If the VCN is attached to a dynamic routing gateway (DRG), the attachment is deleted, but the DRG remains.

The "Delete All" process deletes one resource at a time and takes a minute or two. A progress report is displayed to show you what's been deleted so far.

Before using the "Delete All" process, verify there are no instances, load balancers, DB systems, or orphaned mount targets in any of the subnets. For more information, see Subnet or VCN Deletion.

If there are still resources in any subnet, or if you don't have permission to delete a particular Networking resource, the "Delete All" process stops and an error message is displayed. Any resources deleted up to that point cannot be restored. You might need to contact your tenancy administrator to help you delete any remaining resources.

The Subnet Isn't Empty

The most common reason a subnet (and thus a VCN) can't be deleted is because the subnet contains one or more of these resources:


When you create one of the preceding resources, you specify a VCN and subnet for it. The relevant service creates at least one VNIC in the subnet and attaches the VNIC to the resource. The service manages the VNICs on your behalf, so they are not readily apparent to you in the Console. The VNIC enables the resource to communicate with other resources over the network. Although this documentation commonly talks about the resource itself being in the subnet, it's actually the resource's attached VNIC. This documentation uses the term parent resource to refer to this type of resource.

If the subnet is empty when you try to delete it, its state changes to TERMINATING briefly and then to TERMINATED.

If the subnet is not empty, you instead get an error indicating that there are still resources that you must delete first. The error includes the OCID of a VNIC that is in the subnet (there could be more, but the error returns only a single VNIC's OCID).

You can use the Oracle Cloud Infrastructure command line interface (CLI) or another SDK or client to call the GetVnic operation with the VNIC OCID. The response includes the VNIC's display name. Depending on the type of parent resource, the display name can indicate which parent resource the VNIC belongs to. You can then delete that parent resource, or you can contact your administrator to determine who owns the resource. When the VNIC's parent resource is deleted, the attached VNIC is also deleted from the subnet. If there are remaining VNICs in the subnet, repeat the process of determining and deleting each parent resource until the subnet is empty. Then you can delete the subnet.

For example, if you're using the CLI, use this command to get information about the VNIC.

oci network vnic get --vnic-id <VNIC_OCID>
Load balancer example

Here is an example CLI response for a VNIC that belongs to a load balancer. The display name shows the load balancer's OCID:

  "data": {
    "availability-domain": "fooD:PHX-AD-1", 
    "compartment-id": "ocid1.compartment.oc1..<unique_id_1>", 
    "defined-tags": {}, 
    "display-name": "VNIC for LB ocid1.loadbalancer.oc1.phx.<unique_id_2>", 
    "freeform-tags": {}, 
    "hostname-label": null, 
    "id": "ocid1.vnic.oc1.phx.<unique_id_3>", 
    "is-primary": false, 
    "lifecycle-state": "AVAILABLE", 
    "mac-address": "00:00:17:00:BB:CA", 
    "private-ip": "", 
    "public-ip": null, 
    "skip-source-dest-check": false, 
    "subnet-id": "ocid1.subnet.oc1.phx.<unique_id_4>", 
    "time-created": "2019-05-11T04:28:31.950000+00:00"
  "etag": "5d8213fa"
File Storage example

Here's an example for a VNIC that belongs to a File Storage mount target:

"display-name": "fss-<integer>",

Although the display name does not include an OCID, the fss characters indicate that the resource is for the File Storage service.

Database example

Here's an example of the display name for a VNIC that belongs to a DB system:

"display-name": "ocid1.dbnode.oc1.phx.<unique_id>", 

A Network Security Group Isn't Empty

Another reason a VCN can't be deleted is because it contains a one or more network security groups (NSGs) that are not yet empty. To delete an NSG, it must not contain any VNICs (or parent resources with VNICs). You can determine what parent resources are in an NSG by using either the Console or REST API. For more information, see To delete an NSG.

There Are Resources in Compartments You Don't Have Access To

You might not be able to see all the resources in a subnet or VCN. This is because subnets and VCNs can contain resources in multiple compartments , and you might not have access to all the compartments. For example, the subnet might contain instances that your team manages but also DB systems that another team manages. Another example: The VCN might have security lists or a gateway in a compartment that another team manages. You might need to contact your tenancy administrator to help you determine who owns the resources in the subnet or VCN.