Network interface names

Predictable interface names are commonly based on UIDs. Only if unique UIDs are not guaranteed, predictable interface names are based on FIDs. Kernels that support UID-based predictable interface names have a sysfs attribute /sys/bus/pci/devices/<function_address>/uid_is_unique for its PCI functions. In this path, <function_address> is the PCI ID that identifies a PCI function in the PCI stack.

The availability of predictable interface names on a particular distribution depends on whether the distribution supports and adopts these names. For UID-based predictable interface names, UID uniqueness must be enforced in your environment.

UID uniqueness

How UID uniqueness can be enforced depends on your hypervisor environment.

LPAR: The hardware administrator must set the UID uniqueness option in the hardware configuration of the partition.
For more information, see the section about defining partitions in z/OS® HCD User's Guide, SC34-2669.
DPM partition: UID uniqueness is always enforced.
KVM virtual server: UID uniqueness is always enforced.
z/VM® guest virtual machine: UID uniqueness must be enforced in both the partition and in z/VM.; In z/VM, you control UID uniqueness with the UID option of the SET IO_OPT CP command. By default, UID uniqueness is enforced. For more information, see z/VM: CP Commands and Utilities Reference, SC24-6268.; For z/VM in LPAR mode, ensure that UID uniqueness is enforced in the hardware configuration of the LPAR.; Enabled UID uniqueness for z/VM in an LPAR that does not enforce it, results in misleading values of the uid_is_unique attribute and to limitations for your PCI functions.

To confirm that your Linux® instance runs in a partition for which UID uniqueness is enforced, read the uid_is_unique attribute of any PCI device in sysfs. The following example returns the value 1 for a PCI device 0001:00:00.0, which means that UID uniqueness is enforced.

# cat /sys/bus/pci/devices/0001:00:00.0/uid_is_unique
1

z/VM: For z/VM guests, this value can be misleading unless z/VM and the LPAR have matching settings for enforcing or not enforcing UID uniqueness.

Predictable names

Predictable interface names use one of two naming schemes, depending on whether UID uniqueness checking is enabled and whether the virtual functions (VFs) are isolated. Isolated VFs refer to VFs, where the associated physical function (PF) is assigned to another partition or guest. Enable UID uniqueness checking if supported by your environment.

UID uniqueness checking enforced (eno)

PF interface name

For PFs with enforced UID uniqueness checking , interface names depend on the UID, where <UID_in_decimal> is the UID in decimal notation.

eno<UID_in_decimal>n<phys_port_name>

VF interface names

For isolated VFs:

eno<UID_of_VF_in_decimal>

When the PF is present:

eno<UID_of_PF_in_decimal>v<VF_number>

The following table shows network interface names, when UID uniqueness checking is enforced.

PCI network device	Isolated VFs
PF	eno<UID_in_decimal>n<phys_port_name>
VF, isolated	eno<UID_of_VF_in_decimal>
VF, parent PF present	eno<UID_of_PF_in_decimal>v<VF_number>

UID uniqueness not enforced (ens)

PF interface name

For PFs where UID uniqueness checking is not enforced, interface names depend on the FID, where <FID_in_decimal> is the FID in decimal notation.

ens<FID_in_decimal>n<phys_port_name>

VF interface names

For isolated VFs:

ens<FID_of_VF_in_decimal>

When the PF is present:

ens<FID_of_PF_in_decimal>v<VF_number>

The following table shows network interface names, when UID uniqueness checking is not enforced.

PCI network device	Interface name
PF	ens<FID_in_decimal>n<phys_port_name>
VF, isolated	ens<FID_of_VF_in_decimal>
VF, parent PF present	ens<FID_of_PF_in_decimal>v<VF_number>

For isolated VFs: The following table shows some examples for UIDs and FIDs and the resulting network interface names.

UID and FID of the PCI function	With enforced UID uniqueness (preferred)	Without enforced UID uniqueness
UID: 0x0, FID: 0x0	eno0	ens0
UID: 0x5, FID: 0x7	eno5	ens7
UID: 0xa, FID: 0xb	eno10	ens11
UID: 0x10, FID: 0x20	eno16	ens32

The eth`<n>` naming scheme

Distributions that do not adopt predictable interface names might use the earlier eth<n> scheme.

Such distributions typically assure a persistent mapping of PCI functions to interface names through distribution-specific tooling. On other distributions, forcing the eth<n> naming scheme with the net.ifnames=0 can lead to a nonpersistent mapping.

Other naming schemes

Distributions for which the predictable interface naming scheme does not take effect might use one of the following naming schemes:

enP<UID_or_counter>s<FID_in_dec>
enP<UID_or_counter>p0s
enP<UID_or_counter>p0np0
enP<UID_or_counter>p0s0np0
enP<UID_or_counter>p0

This list is not exhaustive, and even the ens<FID_in_dec> pattern might be used.

In these schemes, <UID_or_counter> represents the UID, in decimal notation, in environments where UID uniqueness is enforced. Without UID uniqueness, a hexadecimal counter is used. <FID_in_dec> represents the FID in decimal notation.

For example, the interface name for a PCI function with FID 0x8ca and UID 0x10 could be enP16s2250, enP0s2250, enP1s2250, ... enP7s2250, enP16p0s, enP0p0s, enP1p0s, ... enP16p0np0 ...

The multiple dependencies on the hardware, on the hardware configuration, on the Linux kernel, and on the udev-rules of the distribution makes it difficult and error prone to predict interface names that follow these schemes.

altnames

Distributions might include interface names for multiple naming schemes as altnames. Such altnames can include predictable interface names. Always use the primary interface name for your network configuration. For example, you might not be able to use altnames for persistent configurations.

The output of ip a shows altnames, if present, for your network interfaces.