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 -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp