Virtual Network Interface Cards (VNICs)

This topic describes how to manage the virtual network interface cards  (VNICs) in a virtual cloud network (VCN).

Overview of VNICs and Physical NICs

The servers in Oracle Cloud Infrastructure data centers have physical network interface cards (NICs). When you launch an instance on one of these servers, the instance communicates using Networking service virtual NICs (VNICs) associated with the physical NICs. The next sections talk about VNICs and NICs, and how they're related.

About VNICs

A VNIC enables an instance to connect to a VCN and determines how the instance connects with endpoints inside and outside the VCN. Each VNIC resides in a subnet in a VCN and includes these items:

  • One primary private IPv4 address from the subnet the VNIC is in, chosen by either you or Oracle. The primary IP address can be an IPv6 address if an IPv6 prefix is assigned to the subnet.
  • Up to 32 optional secondary private IPv4 addresses from the same subnet the VNIC is in, chosen by either you or Oracle.
  • Up to 32 optional secondary IPv6 addresses. IPv6 addressing is supported for all commercial and government regions. For more information, see IPv6 Addresses and Service Limits.
  • An optional public IPv4 address for each private IP, chosen by Oracle but assigned by you at your discretion.
  • An optional hostname for DNS for each private IP address (see DNS in Your Virtual Cloud Network).
  • A MAC address.
  • A VLAN tag assigned by Oracle and available when attachment of the VNIC to the instance is complete (relevant only for bare metal instances).
  • A flag to enable or disable the source/destination check on the VNIC's network traffic (see Overview of VNICs and Physical NICs).
  • Optional membership in one or more network security groups (NSGs) of your choice. NSGs have security rules that apply only to the VNICs in that NSG.

Each VNIC also has a friendly name you can assign, and an Oracle-assigned OCID (see Resource Identifiers).

Each instance has a primary VNIC that is automatically created and attached during launch. That VNIC resides in the subnet you specify during launch. The primary VNIC cannot be removed from the instance. A secondary VNIC can be removed or detached from an instance, but it is always immediately deleted and can't exist when no longer attached to an instance.

How VNICs and Physical NICs Are Related

This section is relevant to bare metal instances.

The OS on a bare metal instance recognizes two physical network devices and configures them as two physical NICs, 0 and 1. Whether they're both active depends on the underlying hardware. You can determine which NICs are active for a shape by reviewing the network bandwidth specifications for bare metal shapes. If the network bandwidth is listed as "2 x <bandwidth> Gbps," it means that both NIC 0 and NIC 1 are active, and each physical NIC has the indicated amount of bandwidth. If the network bandwidth is listed as "1 x <bandwidth> Gbps," it means that only NIC 0 is active. On current generation Standard and DenseIO shapes, typically both NIC 0 and NIC 1 are active.

NIC 0 is automatically configured with the primary VNIC's IP configuration (the IP addresses, DNS hostname, and so on).

If you add a secondary VNIC to an instance, you must specify which physical NIC the secondary VNIC should use. You must also configure the OS so that the physical NIC has the secondary VNIC's IP configuration. For Linux instances, see Oracle Linux: Configuring the OS for Secondary VNICs. For Windows instances, see Windows: Configuring the OS for Secondary VNICs.

About Secondary VNICs

You can add secondary VNICs to an instance after it's launched. Each secondary VNIC can be in a subnet in the same VCN as the primary VNIC, or in a different subnet that is either in the same VCN or a different one. However, all the VNICs must be in the same availability domain as the instance.

Here are some reasons why you might use secondary VNICs:

  • Use your own hypervisor on a bare metal instance: The virtual machines on the bare metal instance each have their own secondary VNIC, giving direct connectivity to other instances and services in the VNIC's VCN.
  • Connect an instance to subnets in multiple VCNs: For example, you might set up your own firewall to protect traffic between VCNs, so the instance needs to connect to subnets in different VCNs.

Here are more details about secondary VNICs:

  • There's a limit to how many VNICs can be attached to an instance, and it varies by shape. For those limits, see Compute Shapes.
  • They can be added only after the instance is launched.
  • They must always be attached to an instance and cannot be moved. The process of creating a secondary VNIC automatically attaches it to the instance. The process of detaching a secondary VNIC automatically deletes it.
  • They are automatically detached and deleted when you terminate the instance.
  • The instance's bandwidth is fixed regardless of the number of VNICs attached. You can't specify a bandwidth limit for a particular VNIC on an instance.
  • Attaching multiple VNICs from the same subnet CIDR block to an instance can introduce asymmetric routing, especially on instances using a variant of Linux. If you need this type of configuration, Oracle recommends assigning multiple private IP addresses to one VNIC, or using policy-based routing as shown in the script later in this topic.
  • Adding multiple VNICs might route iSCSI  traffic away from the primary VNIC, which breaks the iSCSI volume attachments. To avoid this issue, add specific routes for the new VNICs, and use the primary VNIC router address as the gateway. iSCSI boot volumes use the 169.254.0.2/32 address and block volumes use the 169.254.2.0/24 network.

Source/Destination Check

By default, every VNIC performs the source/destination check on its network traffic. The 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 it needs to perform Network Address Translation (NAT)), you must disable the source/destination check on the VNIC. For instructions, see To update an existing VNIC. For information about the general scenario, see Using a Private IP as a Route Target.

VNIC Information in the Instance Metadata

The instance metadata service (IMDS) includes information about the VNICs at these URLs:

  • IMDS version 2:

    http://169.254.169.254/opc/v2/vnics/
  • Legacy IMDS version 1:

    http://169.254.169.254/opc/v1/vnics/

Here's an example response that shows the VNICs that are attached to an instance:

[ {
  "vnicId" : "ocid1.vnic.oc1.phx.exampleuniqueID",
  "privateIp" : "10.0.3.6",
  "vlanTag" : 11,
  "macAddr" : "00:00:00:00:00:01",
  "virtualRouterIp" : "10.0.3.1",
  "subnetCidrBlock" : "10.0.3.0/24",
  "nicIndex" : 0
}, {
  "vnicId" : "ocid1.vnic.oc1.phx.exampleuniqueID",
  "privateIp" : "10.0.4.3",
  "vlanTag" : 12,
  "macAddr" : "00:00:00:00:00:02",
  "virtualRouterIp" : "10.0.4.1",
  "subnetCidrBlock" : "10.0.4.0/24",
  "nicIndex" : 0
} ]

Required IAM Policy

To use Oracle Cloud Infrastructure, you must be granted security access in a policy  by an administrator. This access is required whether you're using the Console or the REST API with an SDK, CLI, or other tool. If you get a message that you don't have permission or are unauthorized, verify with your administrator what type of access you have and which compartment  to work in.

VNICs reside in a subnet but attach to an instance. The VNIC's attachment to the instance is a separate object from the VNIC or the instance itself. Be aware that the VNIC and subnet always exist together in the same compartment, but the VNIC's attachment to the instance always exists in the instance's compartment. This distinction isn't important if you have a simple access control scenario where all the cloud resources are in the same compartment (for example, for a proof-of-concept). When you move to a production implementation, you might decide to have network administrators manage the network, and other personnel administer instances. That means you might put instances in a different compartment than the subnet.

For administrators: see IAM Policies for Networking.

Monitoring VNICs

You can monitor the health, capacity, and performance of your Oracle Cloud Infrastructure resources by using metrics, alarms, and notifications. For more information, see Monitoring and Notifications.

For information about monitoring the traffic coming in and out of VNICs, see VNIC Metrics.

Using the Console

To view an instance's VNICs
  1. Confirm you're viewing the compartment that contains the instance you're interested in.
  2. Open the navigation menu and click Compute. Under Compute, click Instances.
  3. Click the instance to view its details.
  4. Under Resources, click Attached VNICs.

    The primary VNIC and any secondary VNICs attached to the instance are displayed. If the instance has two active physical NICs, the VNICs are grouped by NIC 0 and NIC 1.

To create and attach a secondary VNIC
  1. Confirm you're viewing the compartment that contains the instance you're interested in.
  2. Open the navigation menu and click Compute. Under Compute, click Instances.
  3. Click the instance to view its details.
  4. Under Resources, click Attached VNICs.

    The primary VNIC and any secondary VNICs attached to the instance are displayed.

  5. Click Create VNIC.
  6. In the Create VNIC dialog box, you specify which VCN and subnet to put the VNIC in. By default, the VNIC will be created in the current compartment. You can choose a VCN and subnet from the same compartment or a different compartment.

    Enter the following:

    • Name: A friendly name for the secondary VNIC. The name doesn't have to be unique, and you can change it later. Avoid entering confidential information.
    • Virtual cloud network: The VCN that contains the subnet of interest.
    • Network: Select Normal Setup: Subnet.
    • Subnet: The subnet of interest. The secondary VNIC must be in the same availability domain as the instance's primary VNIC, so the subnet list includes any regional subnets or AD-specific subnets in the primary VNIC's availability domain.
    • Physical NIC: Only relevant if this is a bare metal instance with two active physical NICs. Select which one you want the secondary VNIC to use. When you later view the instance's details and the list of VNICs attached to the instance, they'll be grouped by NIC 0 and NIC 1.
    • Use network security groups to control traffic: Select this check box to add the secondary VNIC to at least one network security group (NSG) of your choice. NSGs have security rules that apply only to the VNICs in that NSG.
    • Skip source/destination check: By default, this check box is NOT selected, which means the VNIC performs the source/destination check. Only select this check box if you want the VNIC to be able to forward traffic. See Overview of VNICs and Physical NICs.
    • Private IPv4 address: Optional. An available private IPv4 address of your choice from the subnet's CIDR (otherwise the private IP address is automatically assigned).
    • Public IPv4 address: Whether to assign a public IPv4 address to the VNIC's primary private IP. Available only if the subnet is public. Choose this option to specify an existing reserved public IP address by name, or to create a new reserved IP address by assigning a name and selecting a source IP pool for the address. If you don't select an IP pool you've created, the default Oracle IP pool is used.
    • (IPv6-enabled subnets only) Assign IPv6 address from subnet: Choose one of the following:
      • Automatically assign IPv6 addresses from prefix: Choose this option to let the console select an available IPv6 address from an IPv6 prefix assigned to this subnet. A subnet can have more than one IPv6 prefix.
      • Manually assign IPv6 addresses from prefix: Choose this option to select a specific address from an IPv6 prefix assigned to this subnet. Example: 0000:0000:1a1a:1a2b.

      If you click + Another subnet prefix you can assign additional IPv6 addresses to the instance VNIC. You can assign one and only one IPv6 address to the VNIC from each IPv6 prefix (there can be several IPv6 prefixes assigned to a subnet). If this VNIC is being attached to an existing instance after its launch, keep in mind that your instance OS needs specific configuration to use IPv6 addressing.

    • DNS record: Whether to assign the VNIC a private IPv4 DNS record. For more information, see DNS in Your Virtual Cloud Network.
    • Hostname: Optional. A hostname to be used for IPv4 DNS within the cloud network. Available only if the VCN and subnet both have DNS labels, and the option to assign a private DNS record is selected.
    • Show tagging options: If you have permissions to create a resource, then you also have permissions to apply free-form tags to that resource. To apply a defined tag, you must have permissions to use the tag namespace. For more information about tagging, see Resource Tags. If you're not sure whether to apply tags, skip this option or ask an administrator. You can apply tags later.
  7. Click Save Changes. The secondary VNIC is created and then displayed on the Attached VNICs page for the instance. It can take several seconds before the secondary VNIC appears on the page.
  8. Configure the OS to use the VNIC. See Oracle Linux: Configuring the OS for Secondary VNICs or Windows: Configuring the OS for Secondary VNICs.
To update an existing VNIC

You can update the VNIC's friendly name or hostname, or whether the VNIC performs the source/destination check.

You can also add a secondary private IP address or add an IPv6 address to a VNIC.

  1. Confirm you're viewing the compartment that contains the instance you're interested in.
  2. Open the navigation menu and click Compute. Under Compute, click Instances.
  3. Click the instance to view its details.
  4. Under Resources, click Attached VNICs.

    The primary VNIC and any secondary VNICs attached to the instance are displayed.

  5. For the VNIC you want to edit, click the Actions menu (Actions Menu), and then click Edit VNIC.

  6. Make your changes. Avoid entering confidential information. Then, click Save Changes.
To add or remove a VNIC from a network security group

You can change which network security groups (NSGs) a VNIC belongs to, or remove a VNIC from all NSGs.

  1. Confirm you're viewing the compartment that contains the instance you're interested in.
  2. Open the navigation menu and click Compute. Under Compute, click Instances.
  3. Click the instance to view its details.
  4. Under Resources, click Attached VNICs.

    The primary VNIC and any secondary VNICs attached to the instance are displayed.

  5. Click the VNIC you're interested in.

    Each VNIC's details page includes a list of the NSGs that the VNIC belongs to (if any).

  6. Next to Network Security Groups, click Edit.

  7. Make your changes and click Save Changes.
To detach and delete a secondary VNIC
Caution

If the VNIC has a private IP that is the target of a route rule, deleting the VNIC causes the route rule to blackhole and traffic will be dropped.

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

  1. Confirm you're viewing the compartment that contains the instance you're interested in.
  2. Open the navigation menu and click Compute. Under Compute, click Instances.
  3. Click the instance to view its details.
  4. Under Resources, click Attached VNICs.

    The primary VNIC and any secondary VNICs attached to the instance are displayed.

  5. For the VNIC you want to delete, click the Actions menu (Actions Menu), and then click Delete VNIC.

  6. Confirm when prompted.

It takes typically a few seconds before the VNIC is deleted.

If the secondary VNIC is on a Linux instance: If you then run the provided script in Oracle Linux: Configuring the OS for Secondary VNICs, it removes the secondary VNIC from the OS configuration.

To manage tags for a VNIC
  1. Confirm you're viewing the compartment that contains the instance you're interested in.
  2. Open the navigation menu and click Compute. Under Compute, click Instances.
  3. Click the instance to view its details.
  4. Under Resources, click Attached VNICs.

    The primary VNIC and any secondary VNICs attached to the instance are displayed.

  5. Click the VNIC that you're interested in.

  6. Click the Tags tab to view or edit the existing tags. Or click Add Tags to add new ones.

For more information, see Resource Tags.

Using the API

For information about using the API and signing requests, see REST API documentation and Security Credentials. For information about SDKs, see SDKs and the CLI.

To manage VNICs on an instance, use these operations:

Oracle Linux: Configuring the OS for Secondary VNICs

Use the oci-network-config utility to perform the OS configuration required for secondary VNICs on instances that run Oracle Linux.

Windows: Configuring the OS for Secondary VNICs

Secondary VNICs are supported on VM and bare metal instances (except for instances that use previous generation Standard1 and StandardB1 shapes). For bare metal instances, secondary VNICs are supported only on the second physical NIC.

Tip

The first physical NIC is NIC 0, and the second is NIC 1.

You must configure the secondary VNIC within the OS. Oracle suggests you write a PowerShell script to perform the configuration. When running the script, you can optionally provide the secondary VNIC's OCID (which you can get from the instance's VNIC metadata).

Otherwise, the script should show a list of the secondary VNICs on the instance and ask you to choose the one you want to configure. Here's generally what the script needs to do:

  1. Check if the network interface has an IP address and a default route.
  2. Enable the OS to recognize the secondary VNIC, the script must overwrite the IP address and default route with static settings (which effectively disables DHCP). The script should prompt you with a choice: to overwrite with the static settings, or exit.

The overall process for configuration will vary slightly depending on the type of instance (VM or bare metal) and how many secondary VNICs you add to the instance.

Windows VM instances

Here's the overall process:

  1. Add one or more secondary VNICs to the instance. Keep each VNIC's OCID handy so you can provide it later when you run the configuration script. You can also get the OCID from the instance's VNIC metadata.
  2. Connect to the instance with Remote Desktop.
  3. Run your script as an administrator. Repeat as needed for any of the additional secondary VNICs.
Windows bare metal instances: adding the first secondary VNIC

If you're adding only a single secondary VNIC to the bare metal instance, here's the overall process:

  1. Add the secondary VNIC to your instance. Keep the VNIC's OCID handy so you can provide it when later running your configuration script. You can also get the OCID from the instance's VNIC metadata.
  2. Connect to the instance with Remote Desktop.
  3. Enable the second physical NIC on the instance:
    1. Open the Device Manager, and then click Network adapters.
    2. Right-click the adapter that corresponds to the instance's second physical NIC, and click Enable.
  4. Run your PowerShell script as an administrator.
Windows bare metal instances: adding additional secondary VNICs

If you have one secondary VNIC on the second physical NIC of a bare metal instance, and you want to one or more additional VNICs, here's the overall process. It includes a task for setting up NIC teaming, which is required if the instance has more than one VNIC on the second physical NIC.

Note

If you increase the number of secondary VNICs on the second physical NIC from one to two or more, you must enable NIC teaming for the second physical NIC (see instructions that follow). In your NIC "team," you create a separate interface for each secondary VNIC on that physical NIC, including the initial one. This means that the original interface for that first secondary VNIC will no longer work, and any subsequent configuration you want to do for that VNIC must be done instead on the VNIC's new interface that's part of the "team".
  1. Add one or more additional secondary VNICs to your instance. Keep each VNIC's OCID and VLAN tag handy so you can provide them when later running the configuration script. You can also get the values from the instance's VNIC metadata.
  2. Connect to the instance with Remote Desktop.
  3. Set up NIC teaming on the instance:
    1. Open the Server manager, and then click Local Server.
    2. In the list of properties, locate NIC Teaming, and then click Disabled to enable and set up NIC teaming.
    3. In the Teams section on the lower-left side of the screen, click Tasks, and then click New Team.
    4. Enter a name for the team, select the check box for the second physical NIC on the instance, and click OK.

      The new team is created and appears in the list of teams in the Teams section.

    5. Click the new team so it's selected, and then in the Adapters and Interfaces section on the right side of the screen, click the Team Interfaces tab.
    6. Click Tasks, and then click Add Interface (you will create a separate interface for each secondary VNIC on the second physical NIC).
    7. Click the radio button for Specific VLAN, and then enter the Oracle-assigned VLAN tag number for the VLAN (for example, 1). You can get the VLAN tag from the Console or the instance's VNIC metadata.
    8. Click OK.
    9. Repeat the four preceding steps (e-h) for each of the other secondary VNICs. You create a separate interface for each secondary VNIC.

  4. Run your script as an administrator. Repeat as needed for any of the additional secondary VNICs.