When the system was started for the first time, it saw your quad-port NIC using new-style names (
ens11f[0-3]), saw that no configuration exists for them, and created default configuration files for each, and recorded their MAC addresses and UUIDs into those configuration files.
Then, you added the
net.ifnames=0 biosdevname=0 boot options. After that, the quad-port NIC was visible using old-style names (
eth[0-3]). But because the MAC addresses and UUIDs are still the same, the configuration system is clever enough to notice that these NICs have already been seen before, although with different names.
Blindly creating new configuration files might overlap with something the system administrator may have already set up, so... it's safest to not do anything and let the system administrator decide what needs to be done: maybe they'll want to migrate the existing settings to the new names, or maybe they'll want to start from scratch.
If you deleted the now-useless
ifcfg-ens11f* configuration files, then the system might generate new default configuration files at next boot. Or maybe that happens only when the special
firstboot procedure is run, I don't remember offhand.
If you wish to tie a particular NIC name to a card with a particular hardware MAC address, you could add
HWADDR=<MAC address> to your
ifcfg-eth* files. But because some clustered virtualization platforms won't always allow VMs to have MAC addresses that persist from one boot of a VM to the next, leaving the
HWADDR= field must also be a valid configuration: in that case, NIC names are determined purely by the detection order determined by the NIC driver(s) and their loading order, or by any udev rules that you might have added.
(For paravirtualized NIC drivers within VMs, the driver-detected ordering may work quite well: the paravirtualized driver could communicate with the virtualization host and ensure that the NICs of the VM are always presented with the same order and numbering, both in the virtualization platform management tools and in the VM itself.)
The UUID has no meaning for the network configuration by itself, but if you use DHCP, it can be used as an alternative client identifier by the DHCP server (DHCP option code 61; see RFC2132 and RFC4361 if you need further details). If you have a host-specific UUID assigned to each DHCP client host and wish each host to keep using the same DHCP assignments even if a NIC is replaced, you can supply the UUID here.
it's like the networkmanager gui is just the tip of the iceberg?
Oh, yes. This rabbit hole is pretty deep.
In the beginning, there was only the
net-tools package of network configuration commands. Each distribution developed their own ways of using them to configure network settings and to store them persistently.
Over time, some standardization happened: distributions descended from RedHat Linux tended to use the
/etc/sysconfig/network-scripts/ifcfg-* files, SuSE and its descendants did something almost but not quite similar, and Debian and its descendants used a single
/etc/network/interfaces file. Other distributions either mimicked one of these, or made their own solutions.
At some point, the development of the
net-tools package stagnated, and a more advanced command-line network configuration toolkit was developed:
iproute2. But not all wanted to migrate away from the familiar
route commands to the new
ip addr and
ip route, even though the new commands enabled new features that just could not be configured using the old
Then came laptops with WiFi, and the proliferation of VPNs, and the need to store WiFi and VPN passwords, which might be personal: even on the same laptop, one user might know the password to a particular WiFi network and another user might not, and this might be a desirable situation (e.g. a parent and a child). NetworkManager was designed to both enable per-user storage of network settings, and to unify the network configuration management between distributions of different descent.
To do that, NetworkManager can have multiple configuration storage back-ends: there is always NetworkManager's "native" configuration storage back-end that uses
/etc/NetworkManager/system-connections/ directory, and can supplement the other configuration back-ends if they cannot handle e.g. the information for a VPN connection. There is usually also a distribution-specific configuration back-end that can at least read (and sometimes also write) the "traditional" configuration files of that distribution. And then there's often a desktop-environment-specific configuration back-end, that manages the storage of per-user configuration settings using whatever secure storage mechanism that desktop environment has, e.g. the GNOME Keyring or KDE Wallet.
NetworkManager also includes a D-Bus interface, which allows an easy separation of the privileged NetworkManager main process and the various user interfaces for it, GUI and otherwise.
systemd suite also included an optional
systemd-networkd component, which I once read was initially intended as mainly a light-weigh network configuration subsystem for embedded systems but seems to have snowballed from there.
You may have seen this XKCD comic:
netplan, a YAML-based network configuration syntax and a set of configuration back-ends to manage both NetworkManager and
This story has not yet ended: it remains to be seen if there will be any convergence, or if each solution will find its niche of optimality.