yahoo-eng-team team mailing list archive

[iain MacDonnell <1684326@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

Using linuxbridge with VLAN networks with MTU<>1500, the nova instance's
VIF's tap interface's MTU needs to get set to that of the network it's
being plugged into, otherwise the first instance on a compute node gets
a tap interface (and bridge) with MTU 1500, but the VM tries to do MTU
9000, and frames get dropped.

Sequence on first instance launch goes like:

 * os_vif creates bridge (with initial MTU 1500)
 * libvirt creates the domain, which creates the tap interface and adds it to the bridge. The tap interface inherits the bridge's MTU of 1500
 * The L2 agent notices that a new tap interface showed up, and ensures that the VLAN interface gets added to the bridge - the VLAN interface has MTU 9000 (inherited from the physical interface), but the bridge MTU remains at 1500 - the lowest amongs its member ports (i.e. the tap interface)

If that instance is then destroyed, the tap interface goes away, and the
bridge updates its MTU to the lowest amongst its members, which is now
the VLAN interface - i.e. 9000. A second instance launch then picks up
the bridge's MTU of 9000 work works fine.

This was previously solved in the l2 agent under
https://bugs.launchpad.net/networking-cisco/+bug/1443607, but the
solution was reverted in
https://git.openstack.org/cgit/openstack/neutron/commit/?id=d352661c56d5f03713e615b7e0c2c9c8688e0132

Re-implementation should probably get the MTU from the neutron network,
rather than the VLAN interface.

** Affects: neutron
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1684326

Title:
  MTU not set on nova instance's vif_type=bridge tap interface

Status in neutron:
  New

Bug description:
  Using linuxbridge with VLAN networks with MTU<>1500, the nova
  instance's VIF's tap interface's MTU needs to get set to that of the
  network it's being plugged into, otherwise the first instance on a
  compute node gets a tap interface (and bridge) with MTU 1500, but the
  VM tries to do MTU 9000, and frames get dropped.

  Sequence on first instance launch goes like:

   * os_vif creates bridge (with initial MTU 1500)
   * libvirt creates the domain, which creates the tap interface and adds it to the bridge. The tap interface inherits the bridge's MTU of 1500
   * The L2 agent notices that a new tap interface showed up, and ensures that the VLAN interface gets added to the bridge - the VLAN interface has MTU 9000 (inherited from the physical interface), but the bridge MTU remains at 1500 - the lowest amongs its member ports (i.e. the tap interface)

  If that instance is then destroyed, the tap interface goes away, and
  the bridge updates its MTU to the lowest amongst its members, which is
  now the VLAN interface - i.e. 9000. A second instance launch then
  picks up the bridge's MTU of 9000 work works fine.

  This was previously solved in the l2 agent under
  https://bugs.launchpad.net/networking-cisco/+bug/1443607, but the
  solution was reverted in
  https://git.openstack.org/cgit/openstack/neutron/commit/?id=d352661c56d5f03713e615b7e0c2c9c8688e0132

  Re-implementation should probably get the MTU from the neutron
  network, rather than the VLAN interface.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1684326/+subscriptions