4

This is a fresh install Ubuntu server 20.04.04 system. I'm using networkd and netplan to configure networking. I did not do any custom install steps, just loaded the .iso and installed Ubuntu server through the prompts.

When these machines were shipped from the vendor, Ubuntu was already installed and the network interfaces were named ens1f0 and ens1f1:

root@oldHost2:~# sudo lshw -C network |grep "logical name"
       logical name: ens1f0
       logical name: ens1f1
       logical name: bond0

However after reinstalling the OS (before running netplan) I get....

root@freshHost1:~# sudo lshw -C network |grep "logical name"
       logical name: ens1f0np0
       logical name: ens1f1np1
       logical name: bond0

Across all my sites, we use a netplan config that assumes ens1f0 and ens1f0. I would like all interfaces to match this.

I know you can set the interface name with set-name in netplan (as defined in https://ubuntu.com/server/docs/network-configuration) however you need to already match the interface somehow (using Mac address, etc) which is going to make auto-provisioning a nightmare (if not impossible). A chicken/egg scenario. I have hundreds of machines to provision and I would like to template out my netplan config without knowing the Mac addresses.

I know you can also group together the interfaces in netplan:

  ethernets:
    eports:
      match:
        name: ens*

Which may work for my case, but not all the systems have a simple two NIC setup like this so I'm not sure what the best course of action will be.

My questions to ServerFault...

  • Since this logical name is set before Netplan is even ran, what is deciding on this name? How can I override it during OS install/provision?
  • What does the np0 and np1 mean in the interface names?
Rino Bino
  • 692
  • 13
  • 34

2 Answers2

2

This is determined by systemd based on information about the device. The name can be influenced by several different factors, including BIOS, other devices that might be installed, linux version, and driver version. See https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html for how systemd constructs the names.

For example, slot numbers may or may not be associated with PCIe slots. I think this at least somewhat related to BIOS/ACPI, but there could be other factors. On one of my machines, a NIC installed in one slot enumerates as enpN, and the same NIC when moved to a different slot enumerates as ensN.

I have heard of cases where PCIe bus numbers are assigned differently under certain conditions, such as the presence of a thunderbolt device during boot. Ultimately this is probably the fault of the system BIOS for not reserving PCIe bus numbers correctly for the thunderbolt port.

As far as what you're seeing with np0 and np1, the p0 and p1 are physical port names coming from devlink __devlink_port_phys_port_name_get. Presumably devlink support was added to the NIC driver, which caused the np0/np1 to appear. If you update the older system to the same kernel version, the naming should also change.

alex.forencich
  • 156
1

From RHEL documentation, for RHEL, but a reasonable guide to udev, systemd, networkmanager family enumeration and naming:

According to RHEL networking guide on consistent network device naming (RHEL legal -- CC-BY-SA-3.0).

11.1. Naming Schemes Hierarchy

By default, systemd will name interfaces using the following policy to apply the supported naming schemes:

  • Scheme 1: Names incorporating Firmware or BIOS provided index numbers for on-board devices (example: eno1), are applied if that information from the firmware or BIOS is applicable and available, else falling back to scheme 2.

  • Scheme 2: Names incorporating Firmware or BIOS provided PCI Express hotplug slot index numbers (example: ens1) are applied if that information from the firmware or BIOS is applicable and available, else falling back to scheme 3.

  • Scheme 3: Names incorporating physical location of the connector of the hardware (example: enp2s0), are applied if applicable, else falling directly back to scheme 5 in all other cases.

  • Scheme 4: Names incorporating interface's MAC address (example: enx78e7d1ea46da), is not used by default, but is available if the user chooses.

  • Scheme 5: The traditional unpredictable kernel naming scheme, is used if all other methods fail (example: eth0).

I find this a clearer first overview of network device naming.

"systemd.net-naming-scheme — Network device naming schemes":

mcint
  • 131