Virtual Network Interface Cards (VNICs)

This topic describes how to manage the virtual network interface cardsA VNIC enables an instance to connect to a VCN and determines how the instance connects with endpoints inside and outside the VCN. Each instance automatically comes with a primary VNIC, and you can add secondary ones. (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.
  • Up to 31 optional secondary private IPv4 addresses from the same subnet the VNIC is in, chosen by either you or Oracle.
  • 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 Source/Destination Check).

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.

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:

  • Oracle X5 servers (also called first-generation): Only NIC 0 is active.
  • Oracle X7 servers (also called second-generation): Both NIC 0 and NIC 1 are active. Each physical NIC has 25 Gbps bandwidth.

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 a second-generation 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 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. The secondary VNIC can be in a subnet in the same VCN as the primary VNIC or a different VCN. However, all the VNICs must be in subnets in the same availability domain as the instance.

Here are a few 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. For more information, see Installing and Configuring KVM on Bare Metal Instances with Multi-VNIC.
  • Connect an instance to multiple subnets in a VCN: For example, you might have a network appliance to monitor traffic between subnets, so the instance needs to connect to multiple subnets in the VCN.
  • Connect an instance to multiple VCNs: For example, you might have resources that need to be shared between two teams that each have their own VCN.

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.

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 includes information about the VNICs at this URL:

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

Here's an example response:

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

Required IAM Policy

To use Oracle Cloud Infrastructure, you must be given the required type of access in a policyA document in the IAM that specifies who has what type of access to your resources. It is used in different ways: to mean an individual statement written in the policy language; to mean a collection of statements in a single, named "policy" document (which has an Oracle Cloud ID (OCID) assigned to it); and to mean the overall body of policies your organization uses to control access to resources. written by an administrator, whether you're using the Console or the REST API with an SDK, CLI, or other tool. If you try to perform an action and get a message that you don’t have permission or are unauthorized, confirm with your administrator the type of access you've been granted and which compartmentA collection of related resources that can be accessed only by certain groups that have been given permission by an administrator in your organization. you should work in.

For administrators: see IAM Policies for Networking.

Tagging Resources

You can apply tags to your resources to help you organize them according to your business needs. You can apply tags at the time you create a resource, or you can update the resource later with the desired tags. For general information about applying tags, see Resource Tags.

Using the Console

Using the API

For information about using the API and signing requests, see REST APIs and Security Credentials. For information about SDKs, see Oracle Cloud Infrastructure SDKs.

To manage VNICs on an instance, use these operations:

Linux: Configuring the OS for Secondary VNICs

This section gives details about OS configuration that is required for secondary VNICs on instances that run a variant of Linux.

At the end of the section is a script that you can use to configure secondary VNICs on either VM instances or bare metal instances.

Linux VM Instances

When you add a secondary VNIC to a Linux VM instance, a new interface (that is, an Ethernet device) is added to the instance and automatically recognized by the OS. However, DHCP is not active for the secondary VNIC, and you must configure the interface with the static IP address and default route. The script provided here handles that configuration for you.

Linux Bare Metal Instances

When you add a secondary VNIC to a Linux bare metal instance, the OS does not automatically recognize the secondary VNIC, so you must configure it in the OS. Depending on your requirements, you can configure it as either:

Configuration Script for Either Linux VM Instances or Linux Bare Metal Instances

The following script works for both VM instances and bare metal instances. It looks at the secondary VNIC information in the instance metadata and configures the OS accordingly. You could run the script periodically to bring the OS configuration up to date with the instance metadata.

For VM instances in particular, the OS automatically recognizes the secondary VNIC's interface, and the script just needs to configure the static IP address and default route.

For bare metal instances in particular, the script creates the interface for the secondary VNIC and configures it with the relevant information. If the instance has two active physical NICs (an X7/second-generation shape with NIC 0 and NIC 1), the script configures the secondary VNIC to use whichever physical NIC you chose when you added the VNIC to the instance. Note that for NIC 1, if a secondary VNIC has VLAN tag 0, it uses the NIC's interface. The script doesn't create an interface for that secondary VNIC.

Here are some additional notes about how the script works for both VM instances and bare metal instances:

  • Default namespace and policy-based routing: By default, this script configures the secondary VNIC in the default namespace and with policy-based routing so applications can communicate through the VNIC with hosts outside the VNIC's subnet. This policy-based routing has effect only if the packets are sourced from the IP address of the secondary VNIC. The ability to bind to a specific source IP address or source interface exists in most tools (such as ssh, ping, and wget) and libraries that initiate connections. For example, the ssh -b option lets you bind to the private IP address of the secondary VNIC:

    ssh -b <secondary_VNIC_IP_address> <destination_IP_address>

    Be aware that if traffic comes in to a service on the instance through a secondary VNIC's interface and the service replies, the reply packets automatically have the VNIC's interface IP address as the source IP address. Policy-based routing is required for that reply to go back out on the same interface and find the correct default gateway.

  • A separate namespace: If you're familiar with namespaces, you can instead configure the secondary VNIC in another namespace of your choice by running the script with the -n option. A separate namespace is required when an instance has secondary VNICs that are attached to subnets in different VCNs, and those subnets have overlapping CIDR blocks.
  • Secondary private IPs: The instance metadata does not include information about any secondary private IPs assigned to the instance. To include that as part of the script's OS configuration, you must provide the secondary private IP address and OCID at the command line when you run the script.
  • Removal of a secondary VNIC: After deleting a secondary VNIC from an instance, running the script removes the VNIC's information from the OS configuration.

The script uses a simple configuration process that does not persist if you reboot the instance. If you use the script, make sure to rerun it after each reboot.

Here are basic examples of how to run the script:

  • <script_name> -c: Configure (adds or deletes) secondary VNIC host IP configuration
  • <script_name> -c -n: Same but uses separate namespaces
  • <script_name> -d: Force removes all secondary VNIC host IP configuration

See the script's help for more information.

View the script that configures a Linux-variant OS for a new secondary VNIC

Windows: Configuring the OS for Secondary VNICs

Secondary VNICs are supported on VM and bare metal instances, but only on X7/second-generation shapes (shapes with "2" in the name, such as VM.Standard2.16 and BM.Standard2.52). For bare metal, secondary VNICs are supported only on the second physical NIC.

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

You must configure the secondary VNIC within the OS. There's an Oracle-provided PowerShell script that performs configuration. When running the script, you can optionally provide the secondary VNIC's OCID (which you can get from the instance's VNIC metadata):

.\secondary_vnic_windows_configure.ps1 "<secondary_VNIC_OCID>"

Otherwise, the script shows a list of the secondary VNICs on the instance and asks you to choose the one you want to configure. Here's generally what the script does:

  1. The script checks if the network interface has an IP address and a default route.
  2. To 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 prompts you with a choice: to overwrite with the static settings, or exit.

View the Powershell script that configures Windows for a new secondary VNIC

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