[Bug 1727301] Re: 229-4ubuntu20 added ARP option breaks existing bonding interfaces

[Dimitri John Ledkov]

** Description changed:

  [Impact]
  
-  * Incomplete cherrypick of ARP functionality in networkd resulted in an
- undesired side-effect, specifically NOARP flag started to be applied
- unconditionally, specifically when it should not have, resulting in loss
- of network connectivity.
+  * Setting [Link] MTUBytes= in .network file has a side-effect of
+ overflowing and setting NOARP flag. This is not intended behaviour /
+ regression.
  
- * This is a regression in -updates.
+  * Trying to fix above by setting ARP=on fails to work as tristate is
+ incorrectly acted upon by unconditionally adding NOARP flag
+ 
+  * This is a regression in -updates.
  
  [Test Case]
  
-  * Configure a bond using networkd
-  * Upgrade
-  * Make sure NOARP flag is not set on the interfaces / bond
+  * Configure an ethernet device with a .network file alone
+  * e.g. Match by mac address and perform DHCP
+  * Add [Link] section to the .network file which changes MTUBytes
+  * Device brought up using this configuration should not have NOAPR flag in the output of iproute link output
+ 
+ 
+  * Further add ARP=off to that .network file, the link should have NOARP flag
+  * Further add ARP=on to that .network file, the link should not have NOARP flag
  
  [Regression Potential]
  
-  * This is an upstream fix for this issue.
+  * These are upstream fixes for ARP= key that are part of zesty and up
  
  [Other Info]
-  
-  * Upstream fix
+ 
+  * Upstream fixes
+ https://github.com/systemd/systemd/commit/b8b40317d0355bc70bb23a6240a36f3630c4952b.patch
  https://github.com/systemd/systemd/commit/1ed1f50f8277df07918e13cba3331a114eaa6fe3.patch
-  
-  * Original bug report
+ 
+  * Original bug report
  
  this breaks existing configurations with bonding on upgrading from
  229-4ubuntu19 to 229-4ubuntu20 on xenial
  
  as bond interfaces are now by default configured without ARP. Hence you
  suddenly lose network connectivity on upgrade. Very bad for a SRU.
  
  Plus adding "ARP=yes" to the Link section of a .network file does not
  work.
  
  Before this update, bond interfaces (specifically 802.3ad) were
  defaulting to ARP enabled. After the upgrade, they are created with
  NOARP set on the link.
  
  pre-upgrade:
  
  eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP>
  eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP>
  bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP>
  
  post-upgrade:
  eth0: <BROADCAST,MULTICAST,NOARP,SLAVE,UP,LOWER_UP>
  eth1: <BROADCAST,MULTICAST,NOARP,SLAVE,UP,LOWER_UP>
  bond0: <BROADCAST,MULTICAST,NOARP,MASTER,UP,LOWER_UP>
  
  Linux cnode11 4.4.0-97-generic #120-Ubuntu SMP Tue Sep 19 17:28:18 UTC
  2017 x86_64 x86_64 x86_64 GNU/Linux

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1727301

Title:
  229-4ubuntu20 added ARP option breaks existing bonding interfaces

Status in systemd:
  Fix Released
Status in systemd package in Ubuntu:
  Invalid
Status in systemd source package in Xenial:
  In Progress
Status in systemd source package in Zesty:
  Invalid
Status in systemd source package in Artful:
  Invalid
Status in systemd source package in Bionic:
  Invalid

Bug description:
  [Impact]

   * Setting [Link] MTUBytes= in .network file has a side-effect of
  overflowing and setting NOARP flag. This is not intended behaviour /
  regression.

   * Trying to fix above by setting ARP=on fails to work as tristate is
  incorrectly acted upon by unconditionally adding NOARP flag

   * This is a regression in -updates.

  [Test Case]

   * Configure an ethernet device with a .network file alone
   * e.g. Match by mac address and perform DHCP
   * Add [Link] section to the .network file which changes MTUBytes
   * Device brought up using this configuration should not have NOAPR flag in the output of iproute link output

  
   * Further add ARP=off to that .network file, the link should have NOARP flag
   * Further add ARP=on to that .network file, the link should not have NOARP flag

  [Regression Potential]

   * These are upstream fixes for ARP= key that are part of zesty and up

  [Other Info]

   * Upstream fixes
  https://github.com/systemd/systemd/commit/b8b40317d0355bc70bb23a6240a36f3630c4952b.patch
  https://github.com/systemd/systemd/commit/1ed1f50f8277df07918e13cba3331a114eaa6fe3.patch

   * Original bug report

  this breaks existing configurations with bonding on upgrading from
  229-4ubuntu19 to 229-4ubuntu20 on xenial

  as bond interfaces are now by default configured without ARP. Hence
  you suddenly lose network connectivity on upgrade. Very bad for a SRU.

  Plus adding "ARP=yes" to the Link section of a .network file does not
  work.

  Before this update, bond interfaces (specifically 802.3ad) were
  defaulting to ARP enabled. After the upgrade, they are created with
  NOARP set on the link.

  pre-upgrade:

  eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP>
  eth1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP>
  bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP>

  post-upgrade:
  eth0: <BROADCAST,MULTICAST,NOARP,SLAVE,UP,LOWER_UP>
  eth1: <BROADCAST,MULTICAST,NOARP,SLAVE,UP,LOWER_UP>
  bond0: <BROADCAST,MULTICAST,NOARP,MASTER,UP,LOWER_UP>

  Linux cnode11 4.4.0-97-generic #120-Ubuntu SMP Tue Sep 19 17:28:18 UTC
  2017 x86_64 x86_64 x86_64 GNU/Linux

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1727301/+subscriptions