* Description

When configuring a network with bonding+vlan and setting the MTU,
occasionally the MTU doesn't get set properly on the vlan interface.

In addition if one checks /var/log/upstart/networking.log whenever there
is a failure the following message is printed:
SIOCSIFMTU: Numerical result out of range

I've tested the latest ifupdown package (0.7.44) and the problem still
exists.
Multi/single CPU settings both exhibit the issue.

* Test Case

# Create a p/q/r/s server vm with two network interfaces
# This is reproducible on real hardware as well

# Install the following
sudo apt-get install vlan ifenslave-2.6 bridge-utils
sudo modprobe bonding 8021q

# Edit the interfaces file
/etc/networking/interfaces:

auto bond0
iface bond0 inet manual
  bond-mode 802.3ad
  bond-miimon 100
  bond-lacp-rate 1
  bond-slaves eth0 eth1
  post-up ifconfig bond0 mtu 9000

auto eth0
iface eth0 inet manual
  bond-master bond0
  post-up ifconfig eth0 mtu 9000

auto eth1
iface eth1 inet manual
  bond-master bond0
  post-up ifconfig eth1 mtu 9000

auto bond0.123
iface bond0.123 inet static
  address 192.168.122.68
  netmask 255.255.255.0
  gateway 192.168.122.1
  post-up ifconfig bond0.123 mtu 9000

# edit rc.local (or another startup script) so we reboot until we hit
the error
/etc/rc.local:

DEVS="eth0 eth1 bond0 bond0.123"
for d in $DEVS; do
        mtu=$(cat /sys/class/net/$d/mtu)
        if [ $mtu != 9000 ]; then
                echo "FAIL"
                exit 1
        fi
done

reboot
exit 0

# Now reboot the machine, within 10m or so you should be at the login prompt
# if you ifconfig | grep MTU you will see some of our interfaces did not get
# the MTU properly set and the test failed.
# Essentially we want to ensure that all MTU's (except lo) were set to 9000

* Workaround

Change the bond0.123 post-up command to:
  post-up sleep 2 && ifconfig bond0.123 mtu 9000

Now when rebooting the interfaces will all be brought up with the proper
MTU.

I believe this is a configuration problem instead of an actual bug.
Please close.

Hi Chris,

Chris J Arges wrote:

Since you request it I am happy to close the bug ticket.  This is
something you can do as well.  Feel free to send an email to the -done
address and it will close the bug ticket.  Just as I have done here.

Bob

This is actually a bug in the vlan package, the problem is if a vlan
has a mtu set that is higher than the vlan raw device mtu, it fails
while being ifup'ed, e.g.:

auto eth1
iface eth1 inet static
  address 1.2.3.4/24
  mtu 9000

auto eth1.10
iface eth1.10 inet static
  address 6.7.8.9/24
  mtu 9000


then 'sudo ifup eth1.10' fails, if eth1 has not been brought up yet.

this debdiff contains a patch to the /etc/network/if-pre-up.d/vlan
script that increases the vlan raw device mtu if it's lower than the
configured vlan mtu.  This fixes the bug by allowing the vlan to come
up correctly.

sorry, there was a problem with the last patch; it didn't work if the
vlan interface already existed, even if the raw device mtu was too
low.  this updated debdiff checks and increases the dev mtu even if
the vlan interface already exists.

I believe the issue relates to if-pre-up.d/vlan - a comparison is performed
to evaluate the actual device MTU against that of the interface being
provisioned however when actioning the change the raw device name is used
in the ip link command:

if [ -n "$IF_MTU" -a -n "$IF_VLAN_RAW_DEVICE" ]; then
    CUR_DEV_MTU=$(cat /sys/class/net/$IF_VLAN_RAW_DEVICE/mtu)
    # increase the vlan raw device mtu if needed
    if [ -n "$CUR_DEV_MTU" ] && [ $CUR_DEV_MTU -lt $IF_MTU ]; then
*        ip link set dev $IF_VLAN_RAW_DEVICE mtu $IF_MTU*
    fi
fi

Shouldn't this be:

if [ -n "$IF_MTU" -a -n "$IF_VLAN_RAW_DEVICE" ]; then
    CUR_DEV_MTU=$(cat /sys/class/net/$IF_VLAN_RAW_DEVICE/mtu)
    # increase the vlan raw device mtu if needed
    if [ -n "$CUR_DEV_MTU" ] && [ $CUR_DEV_MTU -lt $IF_MTU ]; then
*        ip link set dev $IFACE mtu $IF_MTU*
    fi
fi

I would be happy to submit a patch if i knew where