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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1573272
Title:
default gateway route not installed for bond interfaces through reboot
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/vlan/+bug/1573272/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
