wrong hwaddr on the vlan bond with nplan and cloud-init
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cloud-init |
Fix Released
|
Medium
|
Unassigned | ||
cloud-init (Ubuntu) |
Fix Released
|
Medium
|
Unassigned | ||
Xenial |
Fix Released
|
Medium
|
Unassigned | ||
Yakkety |
Fix Released
|
Medium
|
Unassigned | ||
Zesty |
Fix Released
|
Medium
|
Unassigned | ||
nplan (Ubuntu) |
Fix Released
|
High
|
Mathieu Trudel-Lapierre | ||
Xenial |
Fix Released
|
Medium
|
Unassigned | ||
Yakkety |
Fix Released
|
Medium
|
Unassigned | ||
Zesty |
Fix Released
|
Medium
|
Unassigned |
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://
https:/
=== 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-
$ lxc-proposed-
$ lxc init $ref $name
## get render tool
$ wget https:/
## 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-
--output-
--directory
$ cat out.d/etc/
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/
network:
version: 2
ethernets:
eth0:
dhcp4: true
match:
vlans:
eth0.101:
- 192.168.2.10/24
id: 101
link: eth0
## 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/
$ sudo cp out.d/etc/
## drop the .rules files and update the initramfs
$ sudo rm -f /etc/systemd/
$ sudo update-initramfs -u -k all
$ sudo reboot
[Other Info]
Upstream commit at
https:/
=== End cloud-init SRU Template ===
----
The expected hwaddresses are as follows:
4: bond0: <BROADCAST,
link/ether a0:36:9f:2d:93:80 brd ff:ff:ff:ff:ff:ff
inet6 fe80::a236:
valid_lft forever preferred_lft forever
5: bond0.101@bond0: <BROADCAST,
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:
valid_lft forever preferred_lft forever
6: bond0.401@bond0: <BROADCAST,
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:
valid_lft forever preferred_lft forever
however cloud-init shows:
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: +------
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:
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:
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:
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:
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"
Related branches
- Server Team CI bot: Approve (continuous-integration)
- Scott Moser: Needs Fixing
-
Diff: 43 lines (+6/-1)2 files modifiedcloudinit/net/netplan.py (+3/-1)
tests/unittests/test_net.py (+3/-0)
- Mathieu Trudel-Lapierre (community): Approve
- Martin Pitt (community): Approve
-
Diff: 86 lines (+32/-2)4 files modifiedsrc/networkd.c (+3/-0)
src/parse.c (+1/-0)
tests/generate.py (+7/-2)
tests/integration.py (+21/-0)
Changed in nplan (Ubuntu): | |
status: | New → Invalid |
no longer affects: | nplan (Ubuntu) |
Changed in cloud-init (Ubuntu): | |
status: | New → In Progress |
Changed in cloud-init: | |
status: | New → Fix Committed |
Changed in nplan (Ubuntu): | |
status: | New → In Progress |
importance: | Undecided → High |
assignee: | nobody → Mathieu Trudel-Lapierre (cyphermox) |
milestone: | none → ubuntu-17.05 |
Changed in nplan (Ubuntu): | |
status: | In Progress → Fix Committed |
description: | updated |
Changed in nplan (Ubuntu Xenial): | |
importance: | Undecided → Medium |
Changed in nplan (Ubuntu Yakkety): | |
importance: | Undecided → Medium |
Changed in nplan (Ubuntu Zesty): | |
importance: | Undecided → Medium |
Changed in cloud-init (Ubuntu): | |
importance: | Undecided → Medium |
Changed in cloud-init (Ubuntu Xenial): | |
importance: | Undecided → Medium |
Changed in cloud-init (Ubuntu Yakkety): | |
importance: | Undecided → Medium |
Changed in cloud-init (Ubuntu Zesty): | |
importance: | Undecided → Medium |
Changed in cloud-init: | |
importance: | Undecided → Medium |
description: | updated |
nplan should accept mac addresses for vlans, it currently doesn't.