{"id":13994,"date":"2026-04-17T01:01:00","date_gmt":"2026-04-17T05:01:00","guid":{"rendered":"https:\/\/www.both.org\/?p=13994"},"modified":"2026-04-11T15:37:33","modified_gmt":"2026-04-11T19:37:33","slug":"network-interface-card-nic-name-assignments","status":"publish","type":"post","link":"https:\/\/www.both.org\/?p=13994","title":{"rendered":"Network Interface Card (NIC) name assignments"},"content":{"rendered":"
\r\n
\r\n \r\n <\/i>\r\n <\/a>\r\n 2 <\/span>\r\n<\/div><\/div>\n

On each boot, Linux assigns each Network Interface Card (NIC) a name during the kernel initialization process. In the past these NIC names have been simply \u201cethX\u201d where \u201cX\u201d is a number the was essentially the sequence in which the NIC was discovered by the kernel during the boot process.<\/p>\n\n\n\n

This led to some inconsistencies in the way the NIC names were assigned and so it was not possible to predict with certainty whether a specific NIC would have the same name after each boot. And it was a near certainty that NIC names would change after a new NIC was installed in a host that had multiple NICs.<\/p>\n\n\n\n

Of course there never was a problem with naming consistency in a host with only a single NIC.<\/p>\n\n\n\n

Binding to MAC address<\/h1>\n\n\n\n

Early attempts to resolve these issues seem to have revolved around adding the MAC address of the NIC to the \/etc\/sysconfig\/network-scripts\/ifcfg-ethx interface configuration file for each NIC. That line would look like the following.<\/p>\n\n\n\n

HWADDR=00:1C:C0:91:95:F4<\/code><\/p>\n\n\n\n

This was intended to bind the NIC with that MAC address to the configuration file and became a very common entry in the interface configuration files. But this also had problems and was not as consistent as one would hope. And it never really resolved the problem of naming newly installed NICs on a host where one or more NICs were already present.<\/p>\n\n\n\n

Multiple naming schemes<\/h1>\n\n\n\n

Over the years there have been a number of naming schemes and attempts at resolving this NIC naming problem.<\/p>\n\n\n\n

I have always liked the original ethX naming scheme because, once a system was stable with respect to installed NICs, names like eth0 are easy to remember and type. Problems with this were which device is eth0 and which eth1 in a multiple NIC host? Is the built-in motherboard NIC eth1 or eth0? And did it change when a new NIC was added. What happens when I plug in a USB Ethernet Dongle; what is it\u2019s NIC name now and the next time I reboot without removing the dongle?<\/p>\n\n\n\n

Then there was a naming scheme that was intended to make life simpler for folks actually working with the hardware. In this scheme NICs were named things like em1 for \u201cembedded motherboard 1\u201d or p1p2 for \u201cPCI bus device 1 port 2\u201d which I though made a bit of sense. At least I could determine whether a NIC was on the motherboard or an adapter card. However multiple NICs on adapter cards and USB dongles could still confuse things.<\/p>\n\n\n\n

One recent naming scheme is based on the path of the device in the \/sys filesystem. This scheme produces names like, enp2s0f1, enp0s25, and even\u00a0enp0s29f7u1, which can be very long and difficult to type and remember. The last two NIC names are ones I have on my Lenovo laptop; the name enp0s29f7u1 is actually for an Ethernet USB dongle. The names created with this scheme have no obvious relationship between physical and logical devices to make it easier to either identify the port into which an Ethernet cable is to be plugged, or for which to type a command. This scheme seems to be designed by programmers for programmers and not for users or system administrators but it does have the advantage of being very consistent and predictable. This is the default scheme used by Fedora 15 and up, and for RHEL and CentOS 7 and up.<\/p>\n\n\n\n

Lastly, there is a scheme that names NICs based on their MAC address. This one does make some sense as the MAC address for each NIC is available with the dmesg command. This naming scheme is very predictable and provides a bit more of a logical link between the name and the physical device than the other schemes, at least from the system administrator\u2019s standpoint.<\/p>\n\n\n\n

UDEV for naming<\/h1>\n\n\n\n

The udev daemon has superseded all other methods for device naming. It not only names NICs but also all other devices while treating every device on a host as plug and play.<\/p>\n\n\n\n

This Linux Journal UDEV article<\/a> by\u00a0Greg Kroah-Hartman<\/a> contains a more in-depth explanation of udev and what it does. Note that udev has been around for over 20 years as of this writing because the article was published in June of 2004.<\/p>\n\n\n\n

FreeDesktop.org<\/a> has a link,\u00a0Predictable Network Interface Names<\/a> that describes in some detail the problem, past attempts to resolve it, and the current solution. Note that even with udev the kernel still sees NICs as ethX devices. It is udev that renames them. You can use the dmesg command to see this as shown below.<\/p>\n\n\n\n

[    1.991134] e1000e 0000:00:19.0 eth0: (PCI Express:2.5GT\/s:Width x1) 00:24:7e:13:1e:9e
[    1.991137] e1000e 0000:00:19.0 eth0: Intel(R) PRO\/1000 Network Connection
[    1.991163] e1000e 0000:00:19.0 eth0: MAC: 7, PHY: 8, PBA No: 1008FF-0FF
[    2.005092] systemd-udevd[243]: renamed network interface eth0 to enp0s25
[1268141.210554] asix 2-2:1.0 eth0: register \u2018asix\u2019 at usb-0000:00:1d.7-2, ASIX AX88178 USB 2.0 Ethernet, 00:0e:c6:88:9c:8a
[1268141.240334] systemd-udevd[19296]: renamed network interface eth0 to enp0s29f7u1
<\/code><\/pre>\n\n\n\n
The following comments are from the systemd<\/a> code that, along with udev is now responsible for assigning names to NICs.<\/p>\n\n\n\n
\/*\n * Predictable network interface device names based on:\n *  - firmware\/bios-provided index numbers for on-board devices\n *  - firmware-provided pci-express hotplug slot index number\n *  - physical\/geographical location of the hardware\n *  - the interface's MAC address\n *\n * http:\/\/www.freedesktop.org\/wiki\/Software\/systemd\/PredictableNetworkInterfaceNames\n *\n * Two character prefixes based on the type of interface:\n *   en -- ethernet\n *   sl -- serial line IP (slip)\n *   wl -- wlan\n *   ww -- wwan\n *\n * Type of names:\n *   b<number>                             -- BCMA bus core number\n *   ccw<name>                             -- CCW bus group name\n *   o<index>                              -- on-board device index number\n *   s<slot>[f<function>][d<dev_port>]     -- hotplug slot index number\n *   x<MAC>                                -- MAC address\n *   [P<domain>]p<bus>s<slot>[f<function>][d<dev_port>]\n *                                         -- PCI geographical location\n *   [P<domain>]p<bus>s<slot>[f<function>][u<port>][..][c<config>][i<interface>]\n *                                         -- USB port number chain\n *\n * All multi-function PCI devices will carry the [f<function>] number in the\n * device name, including the function 0 device.\n *\n * When using PCI geography, The PCI domain is only prepended when it is not 0.\n *\n * For USB devices the full chain of port numbers of hubs is composed. If the\n * name gets longer than the maximum number of 15 characters, the name is not\n * exported.\n * The usual USB configuration == 1 and interface == 0 values are suppressed.\n *\n * PCI ethernet card with firmware index \"1\":\n *   ID_NET_NAME_ONBOARD=eno1\n *   ID_NET_NAME_ONBOARD_LABEL=Ethernet Port 1\n *\n * PCI ethernet card in hotplug slot with firmware index number:\n *   \/sys\/devices\/pci0000:00\/0000:00:1c.3\/0000:05:00.0\/net\/ens1\n *   ID_NET_NAME_MAC=enx000000000466\n *   ID_NET_NAME_PATH=enp5s0\n *   ID_NET_NAME_SLOT=ens1\n *\n * PCI ethernet multi-function card with 2 ports:\n *   \/sys\/devices\/pci0000:00\/0000:00:1c.0\/0000:02:00.0\/net\/enp2s0f0\n *   ID_NET_NAME_MAC=enx78e7d1ea46da\n *   ID_NET_NAME_PATH=enp2s0f0\n *   \/sys\/devices\/pci0000:00\/0000:00:1c.0\/0000:02:00.1\/net\/enp2s0f1\n *   ID_NET_NAME_MAC=enx78e7d1ea46dc\n *   ID_NET_NAME_PATH=enp2s0f1\n *\n * PCI wlan card:\n *   \/sys\/devices\/pci0000:00\/0000:00:1c.1\/0000:03:00.0\/net\/wlp3s0\n *   ID_NET_NAME_MAC=wlx0024d7e31130\n *   ID_NET_NAME_PATH=wlp3s0\n *\n * USB built-in 3G modem:\n *   \/sys\/devices\/pci0000:00\/0000:00:1d.0\/usb2\/2-1\/2-1.4\/2-1.4:1.6\/net\/wwp0s29u1u4i6\n *   ID_NET_NAME_MAC=wwx028037ec0200\n *   ID_NET_NAME_PATH=wwp0s29u1u4i6\n *\n * USB Android phone:\n *   \/sys\/devices\/pci0000:00\/0000:00:1d.0\/usb2\/2-1\/2-1.2\/2-1.2:1.0\/net\/enp0s29u1u2\n *   ID_NET_NAME_MAC=enxd626b3450fb5\n *   ID_NET_NAME_PATH=enp0s29u1u2\n *\/<\/code><\/pre>\n\n\n\n
And here we have a nice example of why access to the source code is so important in the Open Source Software world. One can look at the code \u2013 ore more accurately in this case, the comments in the code \u2013 and see for one\u2019s self what is actually going on.<\/p>\n\n\n\n
These comments show the various naming conventions available and examples of each.<\/p>\n\n\n\n
Changing naming schemes<\/h1>\n\n\n\n
It’s no longer possible to change which naming scheme is used for network interfaces. Note that some of the file names for network naming rules have changed since the articles were written. The very old article, Predictable Network Interface Names<\/a>, discusses the reasoning behind changing to persistent NIC naming, but most of the files and their locations seem to have changed.<\/p>\n\n\n\n
Conclusion<\/h1>\n\n\n\n
Regardless of the advantages of any of these new NIC naming schemes, I still found it much easier for several years to remember and type the old ethX NIC names when entering commands. But I got over it. The consistency of the default renaming rules is worth it in the long run. That consistency really allows me to relax and not worry that my automation scripts will break when I install a new NIC.<\/p>\n","protected":false},"excerpt":{"rendered":"
2 On each boot, Linux assigns each Network Interface Card (NIC) a name during the kernel initialization process.<\/p>\n","protected":false},"author":2,"featured_media":7668,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_lmt_disableupdate":"","_lmt_disable":"","footnotes":""},"categories":[5,274],"tags":[954,953,955,413],"class_list":["post-13994","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-linux","category-networking","tag-network-interface-card","tag-nic","tag-nic-naming","tag-udev"],"modified_by":"David Both","_links":{"self":[{"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/posts\/13994","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.both.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=13994"}],"version-history":[{"count":10,"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/posts\/13994\/revisions"}],"predecessor-version":[{"id":14012,"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/posts\/13994\/revisions\/14012"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/media\/7668"}],"wp:attachment":[{"href":"https:\/\/www.both.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=13994"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.both.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=13994"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.both.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=13994"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}