← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1690388] Re: wrong hwaddr on the vlan bond with nplan and cloud-init

 

This bug was fixed in the package nplan - 0.23~16.10.1

---------------
nplan (0.23~16.10.1) yakkety; urgency=medium

  * Backport netplan 0.23 to 16.10. (LP: #1688632)

nplan (0.23) artful; urgency=medium

  * Do not unbind brcmfmac, interface will be gone. (LP: #1696162)

nplan (0.22) artful; urgency=medium

  * Add support for setting a custom MAC address on all device types.
    (LP: #1690388)
  * Improved MAC/vlan integration tests; thanks for Dimitri John Ledkov for the
    changes.

nplan (0.21) artful; urgency=medium

  [ Ryan Harper ]
  * Add support for setting MTU on a device. (LP: #1668693)

  [ Mathieu Trudel-Lapierre ]
  * Don't rebind Atheros AR9271; it would confuse the driver. (LP: #1672740)
  * debian/control: Add Conflicts: against netplan; the network 'plan' daemon.
    Both ship the same /usr/sbin/netplan. (LP: #1665842)

nplan (0.20) zesty; urgency=medium

  * tests/integration.py: increase timeout for integration tests (networkd and
    NetworkManager "wait-online" checks) to account for longer bring-up times
    when dealing with stacked virtual devices.

nplan (0.19) zesty; urgency=medium

  * Add support for unordered definition of network devices: you can now
    specify a virtual devices before their member devices. (LP: #1670495)
  * Allow setting up the STP state for a bridge. (LP: #1665088)
  * Document bond/bridge parameters support. (LP: #1664702)

nplan (0.18) zesty; urgency=medium

  * debian/tests/integration.py: in some cases 'iw reg get' may qualify the
    reg domain results with 'global'; we must not let that trip up tests when
    they are run on Ubuntu infrastructure vs. local tests.

nplan (0.17) zesty; urgency=medium

  * New release:
    - Add support for configuring bonds.
    - Add support for configuring bridges.

nplan (0.16) zesty; urgency=medium

  [ Martin Pitt ]
  * doc/example-config: Adjust "routes:" example.
    It does not make sense to make "routes:" a global thing, they should be
    tied to an interface so that the route is only set when the corresponding
    interface exists and is up, and the config is not split in two parts.
  * doc/netplan.md: Point out that NM does not support globbing (LP: #1631018)

  [ Mathieu Trudel-Lapierre ]
  * Fix coverage for src/netplan to be 100%, and fail if coverage falls below
    that mark again.
  * Add support for specifying routes.

nplan (0.15) zesty; urgency=medium

  * tests/generate.py: Fix PEP-8 error (newly detected by -proposed
    pycodestyle).

nplan (0.14) zesty; urgency=medium

  * tests/generate.py: Introduce macros for commonly expected networkd output
  * networkd: Use NetworkManager compatible DHCP route metrics (LP: #1639754)
  * doc/netplan.md: Fix wrong wifi reference in "br0" example
  * doc/netplan.md: Clarify introduction
  * tests/integration.py: Fix race condition with waiting for networkd

nplan (0.13) zesty; urgency=medium

  [ Jonathan Cave ]
  * Blacklist mwifiex_pcie from rebinds (work around LP: #1630285)

  [ Martin Pitt ]
  * Add support for nameservers (LP: #1626617)

 -- Mathieu Trudel-Lapierre <cyphermox@xxxxxxxxxx>  Tue, 06 Jun 2017
17:25:57 -0700

** Changed in: nplan (Ubuntu Yakkety)
       Status: Fix Committed => Fix Released

** Changed in: nplan (Ubuntu Zesty)
       Status: Fix Committed => 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/1690388

Title:
  wrong hwaddr on the vlan bond with nplan and cloud-init

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in nplan package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released
Status in nplan source package in Xenial:
  Fix Released
Status in cloud-init source package in Yakkety:
  Fix Released
Status in nplan source package in Yakkety:
  Fix Released
Status in cloud-init source package in Zesty:
  Fix Released
Status in nplan source package in Zesty:
  Fix Released

Bug description:
  === Begin netplan SRU Template ===
  [Impact]
  Virtual devices such as VLANs, bridges and bonds may require the user to set a specific MAC address for proper operation on networks; where the same MAC may be used by default by the systems due to the methods used to create them.

  [Test case]
  /!\ This only works with the networkd renderer; NetworkManager does not currently support setting a MAC on bonds and bridges.

  1) Set a MAC address for a virtual device (bond, bridge or vlan),
  using the following syntax in netplan config:

  macaddress: ##:##:##:##:##:##

  2) Validate that the device gets the MAC address applied.

  [Regression potential]
  Failure to bring up a device configured in netplan or to set the MAC should be looked at as a possible regression. Other issues could include failure to write the configuration for networkd or NetworkManager.
  === End netplan SRU Template ===
  http://pad.lv/1690388
  https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1690388
      
  === Begin cloud-init SRU Template ===
  [Impact] 
  Virtual devices such as VLANs, bridges and bonds may require the user to set a
  specific MAC address for proper operation on networks; where the same MAC may
  be used by default by the systems due to the methods used to create them.

  cloud-init would not render the mac address of the vlan into its
  ifupdown/eni or netplan output.  The result is that the vlan device
  would not get the desired mac address.

  [Test Case]
  The basic idea below is:
   a.) launch an instance with proposed version of cloud-init.
   b.) inside instance, get cloud-init's network rendering tool from trunk
   c.) run the rendering tool against a config that failed before.
   d.) check rendered netplan config to verify it has vlan mac addresses present.

  [Regression Potential] 
  Fairly low chance for regression.  The mac address fields were just
  not being written, and now they will be.

  ## launch an instance.
  $ release=xenial
  $ ref=$release-proposed
  $ lxc-proposed-snapshot --proposed --publish $release $ref
  $ lxc init $ref $name

  ## get render tool
  $ wget https://git.launchpad.net/~cloud-init-dev/cloud-init/plain/tools/net-convert.py -O net-convert.py

  ## write a network config with vlan and mac address.
  $ cat > net-config.yaml <<"EOF"
  version: 1
  config:
      - type: physical
        name: eth0
        mac_address: "fa:35:9c:85:55:00"
        subnets: [{type: dhcp}]
      - type: vlan
        name: eth0.101
        vlan_link: eth0
        vlan_id: 101
        mac_address: fe:35:9c:85:55:ee
        mtu: 1500
        subnets:
          - type: static
            address: 192.168.2.10/24
  EOF

  $ for k in eni netplan; do 
     PYTHONPATH=$PWD python3 ./net-convert.py \
      --network-data=net-config.yaml --kind=yaml \
      --output-kind=$k --mac=eth0,fa:35:9c:85:55:00 \
      --directory=out.d ; done

  $ cat out.d/etc/network/interfaces
  auto lo
  iface lo inet loopback

  auto eth0
  iface eth0 inet dhcp

  auto eth0.101
  iface eth0.101 inet static
      address 192.168.2.10/24
      hwaddress fe:35:9c:85:55:ee
      mtu 1500
      vlan-raw-device eth0
      vlan_id 101

  
  $ cat out.d/etc/netplan/50-cloud-init.yaml
  network:
      version: 2
      ethernets:
          eth0:
              dhcp4: true
              match:
                  macaddress: fe:35:9c:85:55:00
              set-name: eth0
      vlans:
          eth0.101:
              addresses:
              - 192.168.2.10/24
              id: 101
              link: eth0
              macaddress: fe:35:9c:85:55:ee

  
  ## If you're running on a openstack system, you can actually take
  ## this a step further and replace the system networking with the
  ## newly generated config, reboot and see the vlan come up.
  ## You'll need to update the 'mac_address' for eth0 in net-config.yaml
  ## to match your system, then re-run the net-convert and update the
  ## system.
  $ sudo cp out.d/etc/network/interfaces /etc/network/interfaces
  $ sudo cp out.d/etc/udev/rules.d/70-persistent-net.rules /etc/udev/rules.d/70-persistent-net.rules
  ## drop the .rules files and update the initramfs
  $ sudo rm -f /etc/systemd/network/50-cloud-init-*
  $ sudo update-initramfs -u -k all
  $ sudo reboot

  
  [Other Info]
  Upstream commit at
    https://git.launchpad.net/cloud-init/commit/?id=d059d480c3

  === End cloud-init SRU Template ===

  ----

  The expected hwaddresses are as follows:

  4: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
      link/ether a0:36:9f:2d:93:80 brd ff:ff:ff:ff:ff:ff
      inet6 fe80::a236:9fff:fe2d:9380/64 scope link
         valid_lft forever preferred_lft forever
  5: bond0.101@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
      link/ether a0:36:9f:2d:93:80 brd ff:ff:ff:ff:ff:ff
      inet 104.130.20.119/24 brd 104.130.20.255 scope global bond0.101
         valid_lft forever preferred_lft forever
      inet6 fe80::a236:9fff:fe2d:9380/64 scope link
         valid_lft forever preferred_lft forever
  6: bond0.401@bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
      link/ether a0:36:9f:2d:93:81 brd ff:ff:ff:ff:ff:ff
      inet 10.184.7.120/20 brd 10.184.15.255 scope global bond0.401
         valid_lft forever preferred_lft forever
      inet6 fe80::a236:9fff:fe2d:9381/64 scope link
         valid_lft forever preferred_lft forever

  however cloud-init shows:
  May 12 14:33:28 xnox-iad-nr5 cloud-init[1163]: ci-info: ++++++++++++++++++++++++++++++++++++++++Net device info++++++++++++++++++++++++++++++++++++++++
  May 12 14:33:28 xnox-iad-nr5 cloud-init[1163]: ci-info: +-----------+------+------------------------------+---------------+-------+-------------------+
  May 12 14:33:28 xnox-iad-nr5 cloud-init[1163]: ci-info: |   Device  |  Up  |           Address            |      Mask     | Scope |     Hw-Address    |
  May 12 14:33:28 xnox-iad-nr5 cloud-init[1163]: ci-info: +-----------+------+------------------------------+---------------+-------+-------------------+
  May 12 14:33:28 xnox-iad-nr5 cloud-init[1163]: ci-info: |   bond0   | True |              .               |       .       |   .   | a0:36:9f:2d:93:81 |
  May 12 14:33:28 xnox-iad-nr5 cloud-init[1163]: ci-info: |   bond0   | True | fe80::a236:9fff:fe2d:9381/64 |       .       |  link | a0:36:9f:2d:93:81 |
  May 12 14:33:28 xnox-iad-nr5 cloud-init[1163]: ci-info: | bond0.101 | True |        104.130.20.119        | 255.255.255.0 |   .   | a0:36:9f:2d:93:81 |
  May 12 14:33:28 xnox-iad-nr5 cloud-init[1163]: ci-info: | bond0.101 | True | fe80::a236:9fff:fe2d:9381/64 |       .       |  link | a0:36:9f:2d:93:81 |
  May 12 14:33:28 xnox-iad-nr5 cloud-init[1163]: ci-info: |     lo    | True |          127.0.0.1           |   255.0.0.0   |   .   |         .         |
  May 12 14:33:28 xnox-iad-nr5 cloud-init[1163]: ci-info: |     lo    | True |           ::1/128            |       .       |  host |         .         |
  May 12 14:33:28 xnox-iad-nr5 cloud-init[1163]: ci-info: | bond0.401 | True |         10.184.7.120         | 255.255.240.0 |   .   | a0:36:9f:2d:93:81 |
  May 12 14:33:28 xnox-iad-nr5 cloud-init[1163]: ci-info: | bond0.401 | True | fe80::a236:9fff:fe2d:9381/64 |       .       |  link | a0:36:9f:2d:93:81 |
  May 12 14:33:28 xnox-iad-nr5 cloud-init[1163]: ci-info: |   ens9f1  | True |              .               |       .       |   .   | a0:36:9f:2d:93:81 |
  May 12 14:33:28 xnox-iad-nr5 cloud-init[1163]: ci-info: |   ens9f0  | True |              .               |       .       |   .   | a0:36:9f:2d:93:81 |
  May 12 14:33:28 xnox-iad-nr5 cloud-init[1163]: ci-info: +-----------+------+------------------------------+---------------+-------+-------------------+

  Specifically
    bond0   | True | fe80::a236:9fff:fe2d:9381/64 |       .       |  link | a0:36:9f:2d:93:81
  bond0.101 | True |        104.130.20.119        | 255.255.255.0 |   .   | a0:36:9f:2d:93:81

  Instead of expected a0:36:9f:2d:93:80

  The generated netplan.yaml does not set macaddress on the vlans at
  all.

  Where as the network_data.json does explicitely specifies the mac
  address to be in use for those vlans:

  "vlan_mac_address" : "a0:36:9f:2d:93:80"

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