This bug was fixed in the package nplan - 0.23~16.04.1
---------------
nplan (0.23~16.04.1) xenial; urgency=medium
* Backport netplan 0.23 to 16.04. (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).
-- Mathieu Trudel-Lapierre <cypher...@ubuntu.com> Tue, 06 Jun 2017
17:19:10 -0700
** Changed in: nplan (Ubuntu Xenial)
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 Committed
Status in nplan source package in Xenial:
Fix Released
Status in cloud-init source package in Yakkety:
Fix Committed
Status in nplan source package in Yakkety:
Fix Committed
Status in cloud-init source package in Zesty:
Fix Committed
Status in nplan source package in Zesty:
Fix Committed
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
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
