To add an additional network interface to an instance or to remove an interface from your instance perform the steps described below.

Please note: The steps below only provide a basic overview. The exact tasks required will vary depending on your network design and the base image based on which you launch your image. Please refer to the Oracle cloud documentation for details. In particular, adding additional VNICs to a Linux system running on a baremetal OCI instance requires additional steps to enable the operating system to recognize the additional interface. See https://docs.cloud.oracle.com/iaas/Content/Network/Tasks/managingVNICs.htm for details.

When an instance is created, a default Ethernet interface is attached to the system. This is the primary network interface. You can create additional network interfaces and attach them to an instance.

Please note: for Charon emulators to run properly, certain offloading parameters on the Ethernet interfaces they use must be disabled (see the respective product user's guides). In some cases, the configuration on the Charon host level is not correctly reflected in the underlying OCI cloud instance NICs if the default networking type is used. The correct behavior can often be facilitated by selecting the networking type HARDWARE ASSISTED (SR-IOV) NETWORKING when creating the instance. This setting is required for Charon-SSP versions before 4.1.32 (see Setting up an OCI Instance for Charon-SSP in Charon-SSP for OCI Cloud Getting Started Guide of your version).

Adding a New Network Interface to an Instance

The following steps are required to create a new network interface and to add it to an instance:

Step	Details
Open the list of compute instances and select your instance.	Click on Compute > Instances. Click on the instance name to open the instance details screen.
*Select Attached VNICs* in the Resources section on the left.**	The screen shows the already attached VNICs. Click on Create VNIC to continue. This will open the VNIC creation window.
Add the necessary data to configure the VNIC.	In this window, add for example the name of the VNIC, the virtual cloud network and the subnet to which the VNIC is connected (can be created via Compute > Networking > Virtual Cloud Networks), the private IP address of the VNIC (within the CIDR block of the virtual cloud network), unless you choose to have it assigned automatically, whether a public IP address should be assigned to the VNIC. Once you added all the desired information, click on Save Changes.
Verify that the new interface has been attached to the instance.	The instance details section should now show the newly attached VNIC. Example:

Please note: when attaching a new VNIC to a running instance, the dynamically created configuration on the Linux level may differ from the actual configuration after the first restart of the instance. Therefore, it is recommended to restart the instance before changing the configuration of the new NIC on the Linux level.

Removing a VNIC from an Instance

To remove a VNIC from an instance, select the instance in the instance list and display the Attached VNICs in the Resources section.

Then click on the three dots next to the VNIC and select Delete.

Please note: the primary VNIC cannot be deleted.

Address Assignment Information

Each VCN is assigned a block of private IP addresses. This block can be split by the user to form several IP subnets. Routing within one VCN works automatically.

When an OCI instance is launched into a subnet or if a new vNIC is being added,

it is automatically assigned a private IP address from the address range assigned to the subnet (unless the user configured an address from the subnet range manually in the instance configuration),
the user can choose whether to assign a public IP address if the subnet is a public subnet.

Please note:

Public IP addresses are not directly visible to the instance. The instance operating system always works with the private address. For external connections, the private address is mapped to the public IP address via NAT.
Both, private and public IP addresses for a vNIC can be displayed via the vNIC detail view in the OCI GUI (Instance details > Attached VNICs > vNIC name) .
On the Linux level,
- the private IP address assigned to the primary vNIC is configured automatically via DHCP.
- the private IP address assigned to any secondary vNIC must be configured manually (DHCP is not possible). However, this configuration (depending on the base image from which the instance is launched) may be done in the background by utilities installed on the instance, such as cloud-init or ocid.service. If you require the secondary interface for use by the emulator, you may have to disable such configuration utilities to prevent the IP address from being configured on the interface. For more information see Preparing a Secondary Interface for Emulator Use below.

Reserved addresses (important, if manual address assignment is used):

The following address range is reserved, for example, to allow OCI to query meta-data about instance configuration: 169.254.0.0/16. This range is automatically configured on every network interface.

The following addresses are reserved in each subnet and cannot be used for instance VNICs (shown in the example below for network 10.1.1.0/24):

10.1.1.0: the network address
10.1.1.1: reserved by OCI for the default router
10.1.1.255: network broadcast address.

Other special addresses:

169.254.0.0/16: Reserved for OCI use.

Public IP addresses:

There are two types of public IP addresses (only available in public subnets):

Ephemeral addresses:
- maximum one per VNIC,
- assigned by Oracle,
- persistent during the lifetime of the associated private IP address,
- can only be associated with the primary private IP address of a VNIC,
- a user can only delete it but not associate it with a different private IP address.
Reserved addresses:
- maximum 32 per VNIC,
- created and assigned by the user,
- can be re-assigned to a different private IP,
- can be associated with primary and secondary private IP addresses,
- exists until the user deletes it.

Preparing a Secondary Interface for Emulator Use

Background: if a secondary NIC on the emulator instance is to be dedicated to an emulator, the IP address assigned to the interface by the cloud environment must not be configured on the Linux level but in the guest operating system running in the emulator. Therefore, should the interface that is planned for use by the emulator come up with an IP address configured, this address must be removed. As the configuration method may be different based on the image from which the cloud instance was launched, this section tries to provide an overview of the different options. This overview is not comprehensive as the configuration of the base image plays a large role.

Please note:

This description assumes that the network interfaces on Linux are managed by the NetworkManager.
If you use a marketplace image provided by Stromasys to launch your instance, normally, secondary interfaces are active but do not have an IP address on the Linux level. This means, they can be dedicated to an emulator without additional steps. You may want to configure a NetworkManager connection disabling IP to ensure a consistent configuration (see Step 3).
If you use a general Linux marketplace image (e.g., Rocky, RHEL, or Oracle Linux), the secondary interface configuration on the Linux level may vary depending on the utilities installed in the image and running on the Linux system. Therefore, a secondary interface may come up configured with the private IP address assigned to it on OCI. In such cases, the interface must be reconfigured before it can be dedicated to the emulator.
When attaching a new VNIC to a running instance, the dynamically created configuration on the Linux level may differ from the actual configuration after the first restart of the instance. Therefore, it is recommended to restart the instance before changing the configuration of the new NIC on the Linux level.

The following description assumes that the instance was launched from a general RHEL compatible Linux marketplace image, and that the instance was restarted after adding the additional NIC.

Step 1: Check the Interface Status

Please note: if the interface is active and under NetworkManager control, you can define a NetworkManager connection without IP for it to ensure consistent behavior (see Step 3) and then dedicate it to the emulator as described in your emulator product documentation. The other steps in this section are then not required.

Check if an IP address has been assigned to the secondary NIC (eth1):

# ip addr show
....
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
link/ether 02:00:17:16:e4:65 brd ff:ff:ff:ff:ff:ff
altname enp1s0
inet 10.0.10.162/24 scope global eth1
valid_lft forever preferred_lft forever

In the example above, the interface is active and the IP address 10.0.10.162 (defined on the OCI level) has been assigned to it.

Check if the NIC is managed by NetworkManager:

# nmcli dev
DEVICE TYPE STATE CONNECTION
eth0 ethernet connected Wired Connection
lo loopback connected (externally) lo
eth1 ethernet unmanaged --

In this case, eth1 is set to unmanaged. This means, you cannot configure a NetworkManager connection for it.

Check if a file named similar to /etc/NetworkManager/conf.d/02_00_17_16_E4_65.conf exists. The filename reflects the MAC address of the secondary NIC. If the file contains a statement similar to the following, this is the cause of the interface being unmanaged.

[keyfile]
unmanaged-devices+=mac:02:00:17:16:E4:65

If the new NIC is unmanaged in this way, proceed to Step 2 - checking for the ocid service.

Step 2: Checking for the ocid Service

The ocid service is the interface to several Oracle-provided management utilities. Among other things, it can configure network interfaces based on the instance metadata read from the cloud environment.

Check if the ocid service is active:

# systemctl status ocid
● ocid.service - Oracle Cloud Infrastructure utilities daemon
Loaded: loaded (/etc/systemd/system/ocid.service; enabled; preset: enabled)
Active: active (running) since Mon 2025-03-10 16:28:05 UTC; 1h 36min ago
Main PID: 1129 (python3)
Tasks: 3 (limit: 306144)
Memory: 124.1M
CPU: 4.502s
.....

If the service is active, it will by default configure the network interfaces. You can check for ip commands in journalctl to verify its activity (e.g., journalctl --no-pager |grep eth1). Should this service not be active, check for a cloud-init service that could also configure the interface after boot (Step 4).

You can disable this behavior in the ocid configuration (/etc/oci-utils.conf.d/00-oci-utils.conf by default) as shown below:

...
[vnic]
; Automatically configure/deconfigure network interfaces
; Set to false to disable this function of ocid
enabled=false
...

After setting the vnic enable parameter to false,

delete the file in /etc/NetworkManager/conf.d/xx_xx_xx_xx_xx_xx.conf that makes the new NIC unmanaged for the NetworkManager,
and restart the instance.
Check if the secondary interface now comes up without an IP address (NetworkManager will try to configure the interface automatically using DHCP, but this will fail in OCI for the secondary NICs) , and that the unmanaged state (nmcli dev) has been removed. If this is correct, proceed to Step 3 - configuring a NetworkManager connection.

Step 3: Configuring a NetworkManager Connection

Once the interface comes up without an IP address, you can configure a NetworkManager connection to set the interface up correctly for use by an emulator as shown in the example for eth1 below. Alternatively, you can use the nmtui tool.

The example assumes that no NetworkManager connection existed for this interface (check with nmcli con show) and therefore creates a new connection.

# nmcli con add type ethernet con-name eth1 ifname eth1 ipv4.method disable ipv6.method ignore

# nmcli dev
DEVICE TYPE STATE CONNECTION
eth0 ethernet connected Wired Connection
eth1 ethernet connected eth1
lo loopback connected (externally) lo

# nmcli con show
NAME UUID TYPE DEVICE
Wired Connection 64c5b792-eada-4e29-af94-5ef3797796e1 ethernet eth0
eth1 37644791-dfcd-411f-a67f-cf3c06f3623a ethernet eth1
lo 3b4aaee1-40df-4efc-ad95-894eaf91e1a3 loopback lo

# nmcli con show eth1 |grep ipv4
ipv4.method: disabled
....

# ip addr show
...
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 02:00:17:16:e4:65 brd ff:ff:ff:ff:ff:ff
altname enp1s0
inet6 fe80::17ff:fe16:e465/64 scope link 
valid_lft forever preferred_lft forever

Should there be a pre-existing connection, you must modify it instead of creating a new one (check with nmcli con show):

# nmcli con mod con-name <name-of-connection> ipv4.method disable ipv6.method ignore
# nmcli con up <name-of-connection>

Restart the instance to verify that the configuration is stable and then proceed to dedicate the secondary NIC to the emulator as described in your emulator product documentation.

Step 4: Check for cloud-init Service (only if ocid is not active and the secondary NIC has an unwanted IP address)

If the secondary NIC is configured with an IP address that should be removed, but keeps returning after every restart, cloud-init could play a role. Since the ocid service runs after cloud-init, this section is only relevant if the ocid service is not active.

Check if the cloud-init service is active:

# systemctl status cloud-init
● cloud-init.service - Initial cloud-init job (metadata service crawler)
Loaded: loaded (/usr/lib/systemd/system/cloud-init.service; enabled; prese>
Active: active (exited) since Tue 2025-03-11 09:18:24 UTC; 2h 19min ago
...

If the service exists, check if user-data configuration files exist in /etc/cloud/cloud.cfg.d.

Depending on the marketplace image from which your instance was launched the content of this directory could vary.

One possibility is that there could be an OCI-specific configuration file (e.g., 99_oci.cfg).

In such a case, check if the datastore definition in this file contains directives to configure secondary NICs. The following example shows the configure_secondary_nics directive set to false, meaning that secondary NICs will not be configured by cloud-init:

# head /etc/cloud/cloud.cfg.d/99_oci.cfg 

# OCI cloud-init configuration
datasource_list: ['Oracle', 'OpenStack']
datasource:
# Oracle:
configure_secondary_nics: false
OpenStack:
metadata_urls: ['http://169.254.169.254']
timeout: 10
max_wait: 20
configure_secondary_nics: false
...

The value false should be (according to the cloud-init documentation) be the default if the parameter has not been explicitly added. If set to true on an OCI Virtual Machine, cloud-init will fetch networking metadata from Oracle’s IMDS and use it to configure the non-primary network interface controllers in the system.

The other possibility is that the directory /etc/cloud/cloud.cfg.d does not contain an OCI specific configuration file.

In this case, you can add a file to this directory disabling the network configuration by cloud-init. Example:

# cat /etc/cloud/cloud.cfg.d/99_disable-net-config.cfg
network: {config: disabled}

After such changes, restart the instance, then check if the secondary NIC came up without an IP address. If yes, follow Step 3 to configure the appropriate NetworkManager connection before dedicating the interface to the emulator.

Contents

Adding a New Network Interface to an Instance

Removing a VNIC from an Instance

Address Assignment Information

Preparing a Secondary Interface for Emulator Use

Browser not supported