Systemd starts services.
Services read user choices stored in files and modify kernel's state accordingly. For example, "configure a network interface".
Services may use tools, like ip, ethtool, brctl, and iptables to talk with the kernel.
Only one service may configure a given interface; network.service and NetworkManager.service are mutually exclusive per interface
It is possible to have one interface managed by NM and other by network.service.
The network.service has existed a long time. It has got many features.
Red Hat has evolved the file format that the network.service does use. It is quite human-readable.
The network.service is essentially one-shot scripts that run at boot and shutdown.
NetworkManager.service has shorter history. It has different philosophy than network.service.
It has its own file format, "NM settings", but can also read/write the config files that network.service uses.
Due to shorter history, NM has lacked some "exotic" features that network.service supports. However, NM in CentOS Linux 7
has improved substantially over the lifetime of CentOS Linux 7.
For some reason the list of NM settings (see man nm-settings
) is not 1:1 the command line parameters that one can give to nmcli
The nmcli does modify the config files.
The documentation of NM does show that it does support ethtool options. It most likely calls "ethtool". However, the translation from nmcli parameter, via NM settings, to how NM will call ethtool ... is poorly documented, or the support is incomplete.
For "normal" network NM is sufficient. Why do we tend to stay away from "normal"?