Hide Forgot
Reproducer ################## service network restart and systemctl restart network doesn't accept domain and dns changes in ifcfg files for bonds. But works without bond. nmcli connection add type bond con-name bond0 mode active-backup ifname bond0 Connection 'bond0' (bd935f3f-c391-4072-8974-d461996e818b) successfully added. [root@rhel7a network-scripts]# ls -la total 248 drwxr-xr-x. 2 root root 4096 Dec 2 14:14 . drwxr-xr-x. 7 root root 4096 Dec 1 11:46 .. -rw-r--r--. 1 root root 357 Dec 2 14:14 ifcfg-bond0 copy the static details from ifcfg-ens3 IPADDR=10.0.0.3 PREFIX=23 DOMAIN=test.com GATEWAY=10.0.0.254 DNS1=10.0.0.2 nmcli connection delete ens3 ### network down here, ensure you have console ## adding the slave to bond0, repeat process for more slave nmcli con add type bond-slave ifname ens3 master bond0 con-name ens3 Connection 'ens3' (0e9981be-c1c2-483a-8b5a-4f5025f6648d) successfully added. vim ifcfg-bond0 added the config # reload the configuration nmcli connection reload # reload the network systemctl restart NetworkManager or service network restart cat /etc/resolv "empty" #### Workaround found ### Make changes to your bond vi ifcfg-bond0 ### reload all config files nmcli connection reload [root@rhel7a network-scripts]# nmcli dev connect bond0 Device 'bond0' successfully activated with 'bd935f3f-c391-4072-8974-d461996e818b'. [root@rhel7a network-scripts]# cat /etc/resolv.conf # Generated by NetworkManager search test.tester.com test2 nameserver 8.8.8.8
When you update a connection that is currently active, eg via nmcli connection load "$IFCFG_NAME" nmcli connection reload or nmcli connection modify "$CON" These commands only modify the connection profile. The changes do not take effect immediately on already activated devices. That is intentional. Note the distinction between - connection (profile) - actual device (networking interface) If you want to apply the changed connection, you need do one of: # reactivate connection, implicitly doing a down+up nmcli connection up "$CON" # reconnect the device, doing a down+up. nmcli device connect $DEV # legacy initscripts invoke `nmcli connection up` ifup $NAME # a more graceful way is reapply, which doesn't do a full down+up cycle and # you don't loose connectivey: nmcli device reapply $DEV On the other hand, if you add a connection (or modify a connection that is currently not active), the connection might start autoconnecting right away, depending on it's connection.autoconnect setting. That leads to a confusing situation that: nmcli connection add type ethernet con-name T iface '*' # at this point, the new connection might already activate on the device # with incomplete configuration. nmcli connection modify T ipv4.dns 8.8.8.8 The solutions for that are: # do all in one step: nmcli connection add type ethernet con-name T iface '*' ipv4.dns 8.8.8.8 # after the last modification, re-activate the connection, see before. nmcli connection modify T ipv4.dns 8.8.8.8 nmcli connection up T # don't use autoconnect initially. nmcli connection add type ethernet con-name T iface '*' autoconnect no nmcli connection modify T ipv4.dns 8.8.8.8 connection.autoconnect yes > # reload the network > systemctl restart NetworkManager > or service network restart these are two very different things. One restart NetworkManager.service, the other restarts legacy network.service. Why are you restarting NetworkManager? See above how to apply changes to a connection. Restarting NetworkManager is almost always the wrong thing to do. Certainly it is wrong to restart NM in order to activate a connection. In fact, it does not. On restart, NM will not change the networking configuration -- contrary to restarting network.target, which calls ifup for each interface. The mentioned "workaround" is the right way to do it.
Hello, thanks for clearing that up: service network restart will restart the network.service (legacy network) systemctl restart NetworkManager will just restart the NM service. Have no play at all with reflecting changes to ifcfg* files, unless the configuration files are in legacy format. Both commands should not be used, instead the 4 commands you have mentioned. I think I'll create a good kcs to reflect that info.