After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 790061 - Please allow reconfigure interfaces without downtime
Please allow reconfigure interfaces without downtime
Status: RESOLVED FIXED
Product: NetworkManager
Classification: Platform
Component: IP and DNS config
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks: nm-review
 
 
Reported: 2017-11-08 13:09 UTC by Ruben Herold
Modified: 2017-12-12 13:30 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
[PATCH 1/2] device: don't force a restart of IP configuration on reapply (1.19 KB, patch)
2017-11-15 20:53 UTC, Beniamino Galvani
none Details | Review
[PATCH 2/2] device: remove 'force_restart' argument from reactivate functions (5.73 KB, patch)
2017-11-15 20:53 UTC, Beniamino Galvani
none Details | Review
[PATCH] platform: improve ipv6 addresses synchronization (4.26 KB, patch)
2017-12-12 12:40 UTC, Beniamino Galvani
none Details | Review

Description Ruben Herold 2017-11-08 13:09:31 UTC
hi,

for complex setups it would be very nice if you can reconfigure interfaces
without interruption if possible. 

Please see:

http://cumulusnetworks.github.io/ifupdown2/

"ifreload is non-disruptive. It will fix running config to match what is configured in the interfaces file without bringing the interface down. There are some cases where on linux an interface config cannot be applied unless the interface is brought down...eg: change of mac address and a few bond attributes. For such attribute changes, it may flap the interface only if the linux kernel requires it to."
Comment 1 Thomas Haller 2017-11-08 13:56:53 UTC
There is the D-Bus method Reapply [1]

That functionality is also used by nmcli, as

  $ nmcli device reapply "$DEVICE"

and

  $ nmcli device modify "$DEVICE" $MODIFY_OPTIONS

what do you want in detail?


[1] https://developer.gnome.org/NetworkManager/stable/gdbus-org.freedesktop.NetworkManager.Device.html#gdbus-method-org-freedesktop-NetworkManager-Device.Reapply
Comment 2 Ruben Herold 2017-11-08 14:50:30 UTC
This is destructive:

I have done it in one of my machines without any change from the
network configuration.

The running ping shows me packet loss.

Many operations like adding an ip address or removing can
be done without interruption of the network traffic.

        
        Ruben
Comment 3 Thomas Haller 2017-11-08 15:09:14 UTC
(In reply to Ruben Herold from comment #2)
> This is destructive:

it's supposed not to be, so that is a bug.


Can you describe what you did (in detail)? What seemingly happened, and what you think what should rather happen.

Logfiles might be helpful. See https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/contrib/fedora/rpm/NetworkManager.conf
Comment 4 Ruben Herold 2017-11-09 09:21:54 UTC
What I did was:

nmcli device reapply lacp01


On centos 7 ended up in an 5-10 seconds downtime.

The config:

/etc/sysconfig/network-scripts/ifcfg-lacp01

DEVICE=lacp01
BONDING_OPTS="resend_igmp=1 updelay=0 use_carrier=1 miimon=100 arp_all_targets=any lp_interval=1 min_links=0 downdelay=0 xmit_hash_policy=layer2 primary_reselect=always fail_over_mac=none ad_actor_sys_prio=65535 mode=802.3ad ad_user_port_key=0 lacp_rate=slow all_slaves_active=0 ad_select=stable num_unsol_na=1 num_grat_arp=1"
TYPE=Bond
BONDING_MASTER=yes
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=none
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=no
IPV6FORWARDING=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=lacp01
UUID=fb52b31f-901c-46c4-9ace-9b51ce86c43c
ONBOOT=yes
IPV6ADDR=XXXX:XXXX:X:X::X/64
DNS1=XXXX:XXXX:X::XX
DNS2=XXXX:XXXX:X:X::XX
DOMAIN=test.local
IPADDR=XXX.XX.XXX.XX
PREFIX=28
IPADDR1=XXX.XX.XXX.XX
PREFIX1=32

/sbin/ifup-local:

 /bin/bash
if [ "$1" = lo ]; then
    exit 0;
fi
if [ -n "$1" ]; then
    ethtool -k $1|grep large-receive-offload >/dev/null
    if [ $? = 0 ] ; then
        ethtool -K $1 lro off
    fi
    ethtool -k $1|grep generic-receive-offload >/dev/null
    if [ $? = 0 ] ; then
        ethtool -K $1 gro off
    fi
fi



On the system is an active bird routing daemon for ipv6 and ipv4 to get the routes via ospf.

I have changed nothing I only startet the reapply

Logfile shows:

Nov 09 09:56:46 dus2-lx003.via.de NetworkManager[831]: <info>  [1510217806.4058] audit: op="device-reapply" interface="lacp01" ifindex=19210 pid=3509 uid=0 result="success"
Nov 09 09:56:51 dus2-lx003.via.de NetworkManager[831]: <info>  [1510217811.5098] policy: set 'lacp01' (lacp01) as default for IPv4 routing and DNS
Nov 09 09:56:59 dus2-lx003.via.de NetworkManager[831]: <info>  [1510217819.3367] policy: set 'lacp01' (lacp01) as default for IPv6 routing and DNS
Comment 5 Beniamino Galvani 2017-11-15 20:53:18 UTC
Created attachment 363762 [details] [review]
[PATCH 1/2] device: don't force a restart of IP configuration on reapply
Comment 6 Beniamino Galvani 2017-11-15 20:53:43 UTC
Created attachment 363763 [details] [review]
[PATCH 2/2] device: remove 'force_restart' argument from reactivate functions
Comment 7 Thomas Haller 2017-11-16 11:16:30 UTC
looks not wrong, but this essentially reverts https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=6466b5da6aca2ba29adeaf1ae1641cd6083d878c

How to handle that?
Comment 8 Beniamino Galvani 2017-11-17 16:03:11 UTC
(In reply to Thomas Haller from comment #7)
> looks not wrong, but this essentially reverts
> https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/
> ?id=6466b5da6aca2ba29adeaf1ae1641cd6083d878c
> 
> How to handle that?

Conceptually, how about something like bg/device-reapply-no-restart-bgo790061? i.e. we could keep a copy of the DHCP configuration - untouched by the external changes - and restore it on reapply.
Comment 9 Thomas Haller 2017-11-27 12:05:14 UTC
(In reply to Beniamino Galvani from comment #8)
> (In reply to Thomas Haller from comment #7)
> > looks not wrong, but this essentially reverts
> > https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/
> > ?id=6466b5da6aca2ba29adeaf1ae1641cd6083d878c
> > 
> > How to handle that?
> 
> Conceptually, how about something like
> bg/device-reapply-no-restart-bgo790061? i.e. we could keep a copy of the
> DHCP configuration - untouched by the external changes - and restore it on
> reapply.

I like the idea in general, but I find the implementation confusing. Can you not keep a separate instance (the original, un-temperated version) and a current configuration (after intersect/subtract)? Similar to ext_ip6_config vs. ext_ip6_config_captured.

an in update_ext_ip_config() something like:

  if (!priv->dev_ip4_config)
      priv->dev_ip4_config = nm_ip4_config_clone (priv->dev_ip4_config_orig);
  ...

and in merge-and-appley use "priv->dev_ip4_config ?: priv->dev_ip4_config_orig".
Comment 10 Beniamino Galvani 2017-12-05 08:00:11 UTC
Updated branch bg/device-reapply-no-restart-bgo790061.
Comment 11 Thomas Haller 2017-12-05 09:49:16 UTC
(In reply to Beniamino Galvani from comment #10)
> Updated branch bg/device-reapply-no-restart-bgo790061.

The approach looks very good to me.

I pushed several fixups for consideration.
Comment 12 Beniamino Galvani 2017-12-06 09:13:14 UTC
Squashed all the fixups and merged to master:

https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=b0de9cd2099ef19814237e6d00cde1ffbc622116
Comment 13 Beniamino Galvani 2017-12-12 12:40:10 UTC
Created attachment 365424 [details] [review]
[PATCH] platform: improve ipv6 addresses synchronization

This patch fixes the failure of @ipv6_honor_ip_order CI test caused by previous patches. Previously we would remove all addresses on reapply and add them in the right order. Now we have to detect which addresses must be removed in order to get the order right. Please review.
Comment 14 Thomas Haller 2017-12-12 13:30:42 UTC
(In reply to Beniamino Galvani from comment #13)
> Created attachment 365424 [details] [review] [review]
> [PATCH] platform: improve ipv6 addresses synchronization

lgtm