RHEL 7.9, I have a quad port NIC

ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 01:23:45:67:89:ab brd ff:ff:ff:ff:ff:ff
inet brd scope global noprefixroute eth0
   valid_lft forever preferred_lft forever
inet6 fe80::a4:3cef:41fa:73e1/64 scope link noprefixroute
   valid_lft forever preferred_lft forever

3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 01:23:45:67:89:ac brd ff:ff:ff:ff:ff:ff
4: eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 01:23:45:67:89:ad brd ff:ff:ff:ff:ff:ff
5: eth3: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 01:23:45:67:89:ae brd ff:ff:ff:ff:ff:ff

# -----------------------------------------------------------------------------------------

ls -FC /etc/sysconfig/network-scripts

ifcfg-ens11f0  ifdown@       ifdown-isdn@    ifdown-TeamPort*  ifup-ib*     ifup-post*      ifup-tunnel*
ifcfg-ens11f1  ifdown-bnep*  ifdown-post*    ifdown-tunnel*    ifup-ippp*   ifup-ppp*       ifup-wireless*
ifcfg-ens11f2  ifdown-eth*   ifdown-ppp*     ifup@             ifup-ipv6*   ifup-routes*    init.ipv6-global*
ifcfg-ens11f3  ifdown-ib*    ifdown-routes*  ifup-aliases*     ifup-isdn@   ifup-sit*       network-functions
ifcfg-eth0     ifdown-ippp*  ifdown-sit*     ifup-bnep*        ifup-plip*   ifup-Team*      network-functions-ipv6
ifcfg-lo       ifdown-ipv6*  ifdown-Team*    ifup-eth*         ifup-plusb*  ifup-TeamPort*  route-eth0

My interface names started off as ens11f but I have done GRUB_CMDLINE_LINUX = net.ifnames=0 biosdevname=0. How does networking work in linux (RHEL 7 specifically if it matters) regarding network interface names? Can an explanation be given of the files under /etc/sysconfig/network-scripts and is just everything there at this one location that matters?

  • How come I do not see a ifcfg-eth1 and ifcfg-eth2 and ifcfg-eth3 ? This really confuses me.
  • How or where is MAC address mapped to an interface name, because it is not in my ifcfg-eth0 file?
  • does UUID matter in each network config file?
  • I would like to understand how the whole network configuration works in linux. I only dabble with the graphical Network Manager gui and most times I can completely mess everything up using that; it's like the networkmanager gui is just the tip of the iceberg?

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 ifconfig and 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 net-tools.

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.

The 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: Summary: when you have 14 competing standards and set out to develop one to unify them all for everyone, you'll get 15 competing standards.

Ubuntu developed netplan, a YAML-based network configuration syntax and a set of configuration back-ends to manage both NetworkManager and systemd-networkd by netplan.

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.

  • thanks for taking the time to explain all that – ron Feb 24 at 15:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.