On Fri, Jan 22, 2021 at 10:48:56PM -0000, David Ames wrote:
> I am not sure I have any definitivie answers but here are my thoughts.
>
> Compare a VLAN device created with `ip link add`
>
> ip link add link enp6s0 name enp6s0.100 type vlan id 100
>
> cat /sys/class/net/enp6s0.100/uevent
> DEVTYPE=vlan
> INTERFACE=enp6s0.100
> IFINDEX=3
>
>
> To an OVS VLAN interface created with ovs-vsctl:
>
> ovs-vsctl add-port br-ex vlan100 tag=200 -- set Interface vlan100
> type=internal
>
> cat /sys/class/net/br-ex.100/uevent
> INTERFACE=br-ex.100
> IFINDEX=7
Thanks for isolating how these devices are created!
> I suspect this is down to the tooling. OVS is creating virtual devices
> so it may not be what `ip link` would create.
I don't believe that cloud-init has changed anything in this area, so I
would still like confirmation that this is a case that cloud-init
definitely needs to workaround. (Rather than it being the case that
there's an underlying bug which, being involved in networking early in
boot, we are the first to encounter.)
> Could the `is_vlan` function check for the '.' followed by an integer
> which is the indication of a VLAN in all cases?
Using device names is generally not reliable. In this specific case,
with this config passed to a LXD VM:
(While you (and I) can certainly question the wisdom of naming a non-VLAN
like this, cloud-init's code cannot assume that there aren't users out
there doing this, for whatever reason.)
On Fri, Jan 22, 2021 at 10:48:56PM -0000, David Ames wrote: net/enp6s0. 100/uevent enp6s0. 100 net/br- ex.100/ uevent
> I am not sure I have any definitivie answers but here are my thoughts.
>
> Compare a VLAN device created with `ip link add`
>
> ip link add link enp6s0 name enp6s0.100 type vlan id 100
>
> cat /sys/class/
> DEVTYPE=vlan
> INTERFACE=
> IFINDEX=3
>
>
> To an OVS VLAN interface created with ovs-vsctl:
>
> ovs-vsctl add-port br-ex vlan100 tag=200 -- set Interface vlan100
> type=internal
>
> cat /sys/class/
> INTERFACE=br-ex.100
> IFINDEX=7
Thanks for isolating how these devices are created!
> I suspect this is down to the tooling. OVS is creating virtual devices
> so it may not be what `ip link` would create.
I don't believe that cloud-init has changed anything in this area, so I
would still like confirmation that this is a case that cloud-init
definitely needs to workaround. (Rather than it being the case that
there's an underlying bug which, being involved in networking early in
boot, we are the first to encounter.)
> Could the `is_vlan` function check for the '.' followed by an integer
> which is the indication of a VLAN in all cases?
Using device names is generally not reliable. In this specific case,
with this config passed to a LXD VM:
bridges:
interfaces :
macaddress : 52:54:00:d9:08:1c
br.100:
dhcp4: true
- enp5s0
mtu: 1500
ethernets:
enp5s0:
mtu: 1500
version: 2
it comes up with working networking and I see:
# cat /sys/class/ net/br. 100/uevent
DEVTYPE=bridge
INTERFACE=br.100
IFINDEX=3
(While you (and I) can certainly question the wisdom of naming a non-VLAN
like this, cloud-init's code cannot assume that there aren't users out
there doing this, for whatever reason.)