Unfortunately, verification for this fails on trusty.

tl;dr:

The patches so far work to fix this on x/y/z/a, but trusty will need an additional patch to unconditionally call 'ip link set up', since the return code of 'ifup' on trusty can't be trusted.  I'll attach that trusty debdiff.


Long explanation:

First, I will explain why the attached patches work, which requires explaining the entire process of device detection to udev processing to ifup processing.

When udev detects a network device, it matches the rule in '/lib/udev/rules.d/NN-vlan-network-interface.rules' (the NN varies by release).  This rule matches the 'add' for all network device, and calls the vlan-package-provided script /lib/udev/vlan-network-interface.  This script then does 'ifquery --list --allow auto' for a listing of all interfaces defined in ifupdown configuration that are set to 'auto' configuration.  If it detects that the net device that udev just detected is defined as a 'vlan-raw-device' (or e.g. 'eth1' is part of the name 'eth1.100' so vlan-raw-device is assumed), then this script, called from udev, actually executes the ifupdown if-pre-up.d/vlan script; without calling ifup!

That pre-up script is what actually creates the vlan interface; then once the vlan interface is created, udev gets an add event for it, and notifies ifup to actually configure it.

So now, we get to why the patches for this bug 'work'.

In the /etc/network/if-pre-up.d/vlan script, the patch makes this change:

     if [ ! -e "/sys/class/net/$IFACE" ]; then
-       	ip link set up dev $IF_VLAN_RAW_DEVICE
+        # Try ifup for the raw device, if it fails then bring it up directly
+        # this is required e.g. there is no configuration for the raw device
+        ifup $IF_VLAN_RAW_DEVICE || ip link set up dev $IF_VLAN_RAW_DEVICE
         vconfig add $IF_VLAN_RAW_DEVICE $VLANID
     fi

This direct call to 'ifup' from the vlan pre-up script works ONLY when the vlan script is called from the udev script /lib/udev/vlan-network-interface.  When the vlan script is later called from ifup itself as a pre-up script, the ifup call is detected as 'recursive locking' and fails (except on trusty...more on that later).  However, since the vlan pre-up script was *already* run from the udev script, nothing it does during the ifup pre-up execution matters; it's all redundant actions.  (Note - it's *only* redundant during a device hotplug, not manual ifup - but more on that later too).  So, it works like this:

1. One of the bond's slaves is hotplugged/enumerated and detected by udev, which then runs ifup for it.  During its ifup, it detects its bond-master configuration, and creates the master bond interface, and then waits in a loop until its master is detected and enslaves itself.

2. When udev detects the bond interface, it runs the vlan-network-interface script for it, and that detects that the bond is the vlan-raw-device for another interface, so it calls the if-pre-up.d/vlan script; this is done *without* the ifupdown device lock, since it's outside of an ifup call for the bond or child vlan interface.

2a. Previously, that if-pre-up.d/vlan script would call 'ip link set up' for the bond interface, and then create the e.g. bond0.200 vlan interface.  It would not actually call ifup for the bond interface though.  This resulted in udev detecting the bond.vlan interface only slightly after the bond interface, and calling ifup for each of them almost simultaneously; this is what caused this bug, by the ifup for the bond.vlan interface running before the ifup for the bond interface.

2b. Now, with the patches for this bug, the if-pre-up.d/vlan script will actually call 'ifup' for the bond interface, which does succeed since it's called directly from the udev script, and not running inside ifup; so the ifup bond call is able to run.  As noted, when the if-pre-up.d/vlan script is called *again* later during the real ifup execution for the vlan interface, the call to ifup does not succeed since it detects a recursive call.

3.  This process works on all releases except trusty, when a vlan is defined for a device that doesn't have any ifup configuration; e.g. if ens7 is not configured in ifupdown, but ens7.100 is configured.  This works in the other releases because the 'ifup ens7' call fails since there is no ens7 configuration, and returns an error, which then causes the 'ip link set up' call to manually bring up ens7.  However in trusty, the 'ifup ens7' call returns success, even though there is no ens7 configuration and the interface isn't actually brought up.  That results in ens7.100 failing to be configured, since its raw device isn't up.