← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1684326] Re: MTU not set on nova instance's vif_type=bridge tap interface

 

This was fixed with https://review.openstack.org/#/c/458343/ . I put the
wrong bug in the commit message.

** Changed in: neutron
       Status: Confirmed => Fix Released

-- 
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:
  Fix Released

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


References