[Bug 1224007] Re: mtu not always set properly on bond/vlan interface

Bryan Quigley bryan.quigley at canonical.com
Wed Oct 5 18:29:08 UTC 2016


Added two possible regressions potentials.

** Description changed:

  * 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.
  
  * Versions
  This affects latest ifupdown and ubuntu p/q/r/s.
  
  * 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
+   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
+   bond-master bond0
+   post-up ifconfig eth0 mtu 9000
  
  auto eth1
  iface eth1 inet manual
-   bond-master bond0
-   post-up ifconfig eth1 mtu 9000
+   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
+   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
+         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 
+ # 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
+ 
+ * Regression Potential
+ 
+ - The biggest regression potential would be around an unknown other corner case between MTU and VLANs which could cause that interface to fail to come up (by this fix trying to start it in a different order). 
+ -  It might also be possible that some users really don't want the raw MTU increased while the vlan should be.  
+ 
  
  * Workaround
  
  Change the bond0.123 post-up command to:
-   post-up sleep 2 && ifconfig bond0.123 mtu 9000
+   post-up sleep 2 && ifconfig bond0.123 mtu 9000
  
  Now when rebooting the interfaces will all be brought up with the proper
  MTU.

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1224007

Title:
  mtu not always set properly on bond/vlan interface

Status in vlan package in Ubuntu:
  Fix Released
Status in vlan source package in Precise:
  Triaged
Status in vlan source package in Trusty:
  Triaged
Status in vlan source package in Xenial:
  Triaged
Status in vlan package in Debian:
  New

Bug description:
  * 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.

  * Versions
  This affects latest ifupdown and ubuntu p/q/r/s.

  * 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

  * Regression Potential

  - The biggest regression potential would be around an unknown other corner case between MTU and VLANs which could cause that interface to fail to come up (by this fix trying to start it in a different order). 
  -  It might also be possible that some users really don't want the raw MTU increased while the vlan should be.  

  
  * 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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/vlan/+bug/1224007/+subscriptions



More information about the Ubuntu-sponsors mailing list