[CentOS] NetworkManager on servers

Mon Feb 10 21:54:14 UTC 2020
Anand Buddhdev <anandb at ripe.net>

On 09/02/2020 23:55, Nicolas Kovacs wrote:

Hi Nicolas,

[snip]

> Maybe there's a reason to make NetworkManager more or less mandatory
> from now on, but I don't see it. So I thought I'd rather ask on this list.

Like you, I read about NetworkManager becoming the default tool for
CentOS 8. So I sat down with a colleague to figure out how we could use
NetworkManager, and convert our existing network configs (on CentOS 6
and 7) to work with NetworkManager.

I'm sad to report that we ran into at least 3 issues (listed below). We
found solutions to the first two, but the last one was a show-stopper,
and we came to the conclusion that for servers, NetworkManager is still
overkill, and for us, actually unusable. So even on CentOS 8, we will
keep using the legacy scripts.

1. When NetworkManager activates interfaces, it does not wait for IPv6
DAD to complete. This makes systemd reach the "network-online" target
before IPv6 is fully initialised, and some daemons fail to start. We
eventually found a work-around, but not before I'd lost some of my hair.

2. NetworkManager doesn't know how to activate dummy interfaces from
ifcfg-dummy* files. You have to create dummy interfaces directly in
NetworkManager. This is not a problem on CentOS 8, but on CentOS 7,
there is a subtle issue with loading the dummy module that makes things
fail at boot. We again found the solution, but it's annoying that none
of it was documented.

3. Some of our servers run full routing daemons (BIRD), and have
multiple route tables. On these, when we start NetworkManager, it
attempts to read the entire route tables into memory using the netlink
API. This makes it log lots of errors. Then, NetworkManager's RAM usage
goes up and up, going to over 3 GB!! Finally, it barfs and dies. And
then systemd starts it again, and it goes and does the same.

We have NOT been able to find any solution to this stupidity of
NetworkManager. And so we have made the choice to abandon it, and remain
with legacy network scripts.

Regards,
Anand