The attachment "enp1s0.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

I ran into this as well. VLAN configuration is broken on Xenial unless you disable predictable network interface names, or you set up systemd .link files to rename your NICs (but, importantly, not vlan or bridge interfaces) to have a name starting with "eth".

Since the upstream bug hasn't seen any activity for seven weeks, can we have an Ubuntu-specific fix? Seems like kind of an important piece of functionality that's broken out-of-the-box in an LTS release.

Caught by this too. I get enp3s0, and have set net.ifnames=0 as a workaround.

I agree with the suggestion that the script should be simplified to match XXXX.N, where X is any alphanumeric. More conservatively: the first X could match a-z only, and the last X could match 0-9 only.

Question is, was there a reason for originally matching only specific patterns like ethM.N, wlanM.N etc? Was it to exclude certain other valid interface names which contain a dot but are not VLAN capable? Or perhaps it was just being overly cautious?

We have also faced such issue while migrating some servers from Ubuntu 14.04.5 to Ubuntu 16.04.3. Are there any plans to get a correct fix so that we can properly plan our migration to Xenial?
Meanwhile, we used the workaround provided by Brian Candler - thanks! - which works well.

With netplan becoming the default in 18.04, it'll be either systemd-networkd or Network Manager that will be configuring the vlans, and not ifupdown. I think this means that while this bug continues to exist, it no longer affects the default VLAN case.