yahoo-eng-team team mailing list archive

[Kleber Sacilotto de Souza <kleber.souza@xxxxxxxxxxxxx>]

** Changed in: linux (Ubuntu Yakkety)
       Status: New => Fix Released

** Changed in: linux (Ubuntu Zesty)
       Status: New => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1682871

Title:
  attempts to rename vlans / vlans have addr_assign_type of 0 on kernel
  4.4

Status in cloud-init:
  Confirmed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Committed
Status in linux source package in Xenial:
  In Progress
Status in cloud-init source package in Yakkety:
  Fix Committed
Status in linux source package in Yakkety:
  Fix Released
Status in cloud-init source package in Zesty:
  Fix Committed
Status in linux source package in Zesty:
  Fix Released

Bug description:
  [Impact]

   * When vlan interfaces are created, their mac address is copied from
  the underlying interface, but it is not marked by kernel as stolen.

   * When underlying interface MAC address is changed, it does not
  propagate to the vlan interfaces.

  [Test Case]

   * Create vlan interface, check the addr_assign_type sysfs attribute,
  it should be 2, not 0.

   * Update the base interface mac address, the mac address of the vlan
  interface should change too.

   * cloud-init test case

  
      
  wget https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/plain/bin/get-proposed-cloudimg;
  chmod 755 get-proposed-cloudimg;

  for release in xenial yakkety zesty; do
    ./get-proposed-cloudimg $release;
    MODE=vlan ./btest-launch.sh $release-server-cloudimg-amd64-proposed.img <LP_ID>;
    # ubuntu/passw0rd
    python3 -c 'from cloudinit.net import get_interfaces_by_mac; print(get_interfaces_by_mac())'; # results in no runtime error and doesn't report vlan interface name
  done
   


  
  [Regression Potential]

   * Userspace may rely on non-propagating MAC addresses, and the fact
  that vlan mac address type is wrongly stated as non-stolen; however
  this behaviour will be consistent with 4.7+ kernels.

  [Other Info]

   * Please cherrypick 308453aa9156a3b8ee382c0949befb507a32b0c1 into
  v4.4 kernels

  commit 308453aa9156a3b8ee382c0949befb507a32b0c1
  Author: Mike Manning <mmanning@xxxxxxxxxxx>
  Date:   Fri May 27 17:45:07 2016 +0100

      vlan: Propagate MAC address to VLANs

      The MAC address of the physical interface is only copied to the VLAN
      when it is first created, resulting in an inconsistency after MAC
      address changes of only newly created VLANs having an up-to-date MAC.

      The VLANs should continue inheriting the MAC address of the physical
      interface until the VLAN MAC address is explicitly set to any value.
      This allows IPv6 EUI64 addresses for the VLAN to reflect any changes
      to the MAC of the physical interface and thus for DAD to behave as
      expected.

      Signed-off-by: Mike Manning <mmanning@xxxxxxxxxxx>
      Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>

   * Original bug report

  When attempting to verify sru for bug 1669860, I found that vlans
  are not properly filtered out by 'get_interfaces_by_mac'.  That means
  that the bug is still present with vlans.

  The reason for this is that /sys/class/net/<vlan_name>/addr_assign_type
  shows '0' for a vlan on 4.4, but (correctly) shows '2' on 4.8.
  See https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net
  for doc on addr_assign_type.

  Related bugs:
   * bug 1669860: cloud-init attempts to rename bonds

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1682871/+subscriptions