170

When I run ifconfig -a, I only get lo and enp0s10 interfaces, not the classical eth0

What does enp0s10 mean? Why is there no eth0?

muru
  • 72,889
Nico Rodsevich
  • 2,385
  • 14
    ifconfig is deprecated. Think about moving to ip from iproute2 soon. – solsTiCe Jun 13 '15 at 08:21
  • 1
    As the answer says it's a change in systemd. To get your eth0 back use the kernel option net.ifnames=0 biosdevname=0 (see this thread). Using ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rule in below answer didn't work in Debian 10 (Buster) – MrCalvin Jun 02 '19 at 10:22
  • @MrCalvin : the ln -s ... should be updated, see below – serv-inc Dec 16 '20 at 10:44

5 Answers5

236

Answer on "What does enp0s10 means?" question:

enp0s10:
| | |
v | |
en| |   --> ethernet
  v |
  p0|   --> bus number (0)
    v
    s10 --> slot number (10)

Source: udev-builtin-net_id.c on GitHub

chrki
  • 105
DIG mbl
  • 2,531
  • 24
    Came looking for this. – ffledgling Mar 07 '17 at 08:38
  • 10
    Since there is no ...fN part at the end of the NIC name, we can deduce that the function number is 0. After translating the numbers to hexadecimal (10 = "a" in hex), we know that enp0s10 means PCI device ID 00:0a.0. – telcoM Apr 13 '19 at 06:13
  • 2
    There’s also https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html – user3840170 Dec 08 '20 at 20:21
  • 2
    This explains eno (onboard) enp (pci) and enx (mac.) But it does not explain the name end0. What does the d in end0 stand for? – Bram May 20 '23 at 17:47
118

That's a change in how now udevd assigns names to ethernet devices. Now your devices use the "Predictable Interface Names", which are based on (and quoting the sources):

  1. Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: eno1)
  2. Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: ens1)
  3. Names incorporating physical/geographical location of the connector of the hardware (example: enp2s0)
  4. Names incorporating the interfaces's MAC address (example: enx78e7d1ea46da)
  5. Classic, unpredictable kernel-native ethX naming (example: eth0)

The why's this changed is documented in the systemd freedesktop.org page, along with the method to disable this:

ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules

or if you use older versions:

ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules
Braiam
  • 35,991
  • 20
    Following the freedesktop,org link, the main point is: The classic naming scheme for network interfaces applied by the kernel is to simply assign names beginning with "eth" to all interfaces as they are probed by the drivers. As the driver probing is generally not predictable for modern technology this means that as soon as multiple network interfaces are available the assignment of the names is generally not fixed anymore and it might very well happen that "eth0" on one boot ends up being "eth1" on the next. This can have serious security implications... – lepe Oct 17 '16 at 02:43
  • This also applies to docker images. So trying to setup a network bridge between 2 docker networks caused problems 2 years ago because the network ports could be reversed on next boot. an impossible situation for a bridge device. – U.V. Dec 16 '20 at 12:01
  • 5
    funny enough, the "predictable name" of my ethernet device changed from enp5s0 to enp3s0 after a bios upgrade, rendering all my network configurations worthless... – GaspardP Jan 16 '22 at 21:11
  • @GaspardP I would say that that's a bug in your bios, how the device enumeration order on chip changed?! – Braiam Jan 17 '22 at 13:55
  • Absolutely agree, this should not be common - the bus ids should not change and names should be predictable. I suspect this happened because my hardware was new and the bios was not yet able to detect everything connected. After upgrading, it probably discovered new devices. It might still be worth aliasing devices for some people, especially in the context of restoring a system backup onto different hardware. – GaspardP Jan 17 '22 at 18:46
44

As mentioned above, enp0s10 refers to ethernet (en), prefix 0 (p0), slot 10 (s10).

The bus number, device number, and function number are pulled from the Bus Device Function (BDF) notation for PCI devices to create the prefix, slot, and function portions of the Predictable Network Interface Name (PNIN).

If the function is 0, the f0 portion is sometimes omitted. I changed the prefix from p0 to p4, and the function from f0 to f1, for clarity in this example. BDF uses hex values which get converted to decimal values in the PNIN.

Expanding on the answer posted by DIG mbl:

enp4s10f1                        pci 0000:04:0a.1
| | |  |                                |  |  | |
| | |  |                   domain <- 0000  |  | |
| | |  |                                   |  | |
en| |  |  --> ethernet                     |  | |
  | |  |                                   |  | |
  p4|  |  --> prefix/bus number (4)   <-- 04  | |
    |  |                                      | |
    s10|  --> slot/device number (10) <--    10 |
       |                                        |
       f1 --> function number (1)     <--       1

https://wiki.xen.org/wiki/Bus:Device.Function_(BDF)_Notation https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames

I came across a device with a u7 at the end, for USB port. Some of the different label possibilities are included in this documentation on predictable network interface device names.

A second example for the case where the PCI domain is something other than 0 (P stands for PCI geographical location):

P1enp4s10f1                        pci 0001:04:0a.1
| | | |  |                                |  |  | |
P1| | |  |  --> PCI geo loc/domain <-- 0001  |  | |
  | | |  |                                   |  | |
  en| |  |  --> ethernet                     |  | |
    | |  |                                   |  | |
    p4|  |  --> prefix/bus number (4)   <-- 04  | |
      |  |                                      | |
      s10|  --> slot/device number (10) <--    10 |
         |                                        |
         f1 --> function number (1)     <--       1
mhck
  • 551
7

You can use

net.ifnames=0

in kernel command line arguments and your interface name will be called eth0 again.

AdminBee
  • 22,803
Yonatan Amir
  • 81
2

To quote the full text on disabling linked by @Braiam:

I don't like this, how do I disable this?

You basically have three options:

  1. You disable the assignment of fixed names, so that the unpredictable kernel names are used again. For this, simply mask udev's .link file for the default policy: ln -s /dev/null /etc/systemd/network/99-default.link
  2. You create your own manual naming scheme, for example by naming your interfaces "internet0", "dmz0" or "lan0". For that create your own .link files in /etc/systemd/network/, that choose an explicit name or a better naming scheme for one, some, or all of your interfaces. See systemd.link(5) for more information.
  3. You pass the net.ifnames=0 on the kernel command line

TL;DR: it has been renamed to 99-default.link

serv-inc
  • 650
  • This doesn't work (any more?) in Fedora 39; with method 1 I get "wlan0" back but "eth0" remains a mangled name. Method 3 works, but feels less desirable somehow... – Rhialto supports Monica Dec 28 '23 at 20:29