Autogenerated interface name prevents creating a bridge over a VLAN
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Fix Released
|
High
|
Witold Krecicki | ||
2.4 |
Fix Released
|
High
|
John A Meinel | ||
vlan (Ubuntu) |
Won't Fix
|
Low
|
Dan Streetman | ||
Trusty |
Won't Fix
|
Low
|
Dan Streetman | ||
Xenial |
Won't Fix
|
Low
|
Dan Streetman | ||
Bionic |
Won't Fix
|
Low
|
Dan Streetman | ||
Cosmic |
Won't Fix
|
Low
|
Dan Streetman | ||
Disco |
Won't Fix
|
Low
|
Dan Streetman |
Bug Description
Hi,
First of all, thanks for all your work on creating and maintaining Juju and the charms ecosystem!
I believe I have stumbled onto a bug in autogenerating the name for the bridge interface when one needs to be created to grant a container access to a host's network interface. This bug is currently blocking a MAAS/Juju/OpenStack deployment where traffic is separated into VLANs. I have successfully reproduced it on 2.4.6 and 2.5-beta1 installations, although I believe that it has been present ever since at least 2.2.0, if not maybe earlier.
Currently the name of the bridge interface is, if possible, generated by prepending "br-" to the host interface name; however, this is problematic with VLAN interfaces. If the host interface is called e.g. "enp3s0f0.503", this would create a bridge named "br-enp3s0f0.503"; however, if there is *also* a bridge on the "enp3s0f0" interface (without the VLAN ID), this would cause the Debian/Ubuntu ifupdown scripts to consider "br-enp3s0f0.503" to be VLAN 503 on the "br-enp3s0f0" interface and, consequently, fail to bring it up correctly the next time the node is rebooted.
Steps to reproduce:
1. Define a node with an Ethernet interface (let's call it "enp3s0f0") and a network space (let's call it "mgmt")
2. Define a VLAN over that interface (let's call it "enp3s0f0.503") and a network space for the VLAN (let's call it "storage")
3. Deploy a charm on that node so that Juju knows about the enp3s0f0 interface in the mgmt space and the enp3s0f0.503 interface in the storage space
4. Deploy a charm in a container, specitying `--constraints spaces=storage`; this will lead to Juju autogenerating a bridge interface and calling it "br-enp3s0f0.503"
5. Deploy a charm in a container, specifynig `--constraints spaces=mgmt`; this will lead to Juju autogenerating another bridge interface and calling it "br-enp3s0f0"
6. Reboot the server, then log into it
The br-enp3s0f0 bridge may be brought up correctly, but the br-enp3s0f0.503 interface, although it will exist, will have been created as a VLAN interface, not a bridge interface, and so any attempts to add any interfacesd to it will have failed; consequently, the container will also have failed to start up.
A naive fix for newly-bootstrapped environments would be to replace any dots with e.g. dashes in the `BridgeNameForD
Please let me know if there is any more information that I can provide for a hopefully speedy resolution of this problem.
Thanks in advance for your consideration, and keep up the great work!
Best regards,
Peter
Changed in juju: | |
assignee: | John A Meinel (jameinel) → Witold Krecicki (wpk) |
status: | Triaged → In Progress |
Changed in vlan (Ubuntu Cosmic): | |
status: | New → In Progress |
Changed in vlan (Ubuntu Bionic): | |
status: | New → In Progress |
Changed in vlan (Ubuntu Xenial): | |
status: | New → In Progress |
Changed in vlan (Ubuntu Trusty): | |
status: | New → In Progress |
Changed in vlan (Ubuntu Cosmic): | |
importance: | Undecided → Medium |
Changed in vlan (Ubuntu Bionic): | |
importance: | Undecided → Medium |
Changed in vlan (Ubuntu Xenial): | |
importance: | Undecided → Medium |
Changed in vlan (Ubuntu Trusty): | |
importance: | Undecided → Medium |
Changed in vlan (Ubuntu Cosmic): | |
assignee: | nobody → Dan Streetman (ddstreet) |
Changed in vlan (Ubuntu Bionic): | |
assignee: | nobody → Dan Streetman (ddstreet) |
Changed in vlan (Ubuntu Xenial): | |
assignee: | nobody → Dan Streetman (ddstreet) |
Changed in vlan (Ubuntu Trusty): | |
assignee: | nobody → Dan Streetman (ddstreet) |
Changed in juju: | |
milestone: | 2.5.0 → 2.5.1 |
Changed in juju: | |
status: | Fix Committed → Fix Released |
Interesting, I would have thought you'd hit the 15-byte limit on interface names but you didn't at it's 15 bytes exactly.
Looking at a manpage, bridge_ports should prevent this interface from being treated as a VLAN interface: manpages. ubuntu. com/manpages/ xenial/ man5/interfaces .5.html# vlan%20and% 20bridge% 20interfaces
http://
"To ease the configuration of VLAN interfaces, interfaces having . (full stop character) in the name are configured as 802.1q tagged virtual LAN interface. For example, interface eth0.1 is a virtual interface having eth0 as physical link, with VLAN ID 1. For compatibility with bridge-utils package, if bridge_ports option is specified, VLAN interface configuration is not performed."
I would have thought I'd find this code in this file if-pre- up.d/vlan if-pre- up.d/vlan
dpkg -S /etc/network/
vlan: /etc/network/
but I did not because of this commit it seems: /git.launchpad. net/ubuntu/ +source/ vlan/commit/ ?id=4c88eab6154 9ec4c6c8ed65e96 10fca712ed98f4
https:/
I have this in /e/n/i in a test env before reboot:
auto br-enp4s0f0
iface br-enp4s0f0 inet static
address 10.232.6.131/21
dns-nameservers 10.232.0.2
gateway 10.232.0.1
bridge_ports enp4s0f0
auto b-enp4s0f0.2730
iface b-enp4s0f0.2730 inet static
address 10.232.45.226/21
bridge_ports enp4s0f0.2730
auto b-enp4s0f0.2731
iface b-enp4s0f0.2731 inet static
address 10.232.24.3/21
bridge_ports enp4s0f0.2731
brctl show
bridge name bridge id STP enabled interfaces
b-enp4s0f0.2730 8000.78e7d124e458 no enp4s0f0.2730
veth9RV4DA
vethO1TEE1
b-enp4s0f0.2731 8000.78e7d124e458 no enp4s0f0.2731
veth04DDDF
vethV8F3YP
br-enp4s0f0 8000.78e7d124e458 no enp4s0f0
veth52C4IX
veth8L5MG5
veth8XWOE9
vethOGIXIJ
vethXSH47J
Could you paste what you have too?