yahoo-eng-team team mailing list archive

[Launchpad Bug Tracker <1889454@xxxxxxxxxxxxxxxxxx>]

[Expired for neutron because there has been no activity for 60 days.]

** Changed in: neutron
       Status: Incomplete => Expired

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

Title:
  br-int has an unpredictable MTU

Status in neutron:
  Expired

Bug description:
  We have an environment where users can plug their VMs both to tenant
  and provider networks on the hypervisor.  This environment does not
  have jumbo frames.  The MTU for VMs plugged directly into provider
  networks is 1500 (physical network) however it is 1450 for tneant
  networks (VXLAN).

  https://github.com/openstack/neutron/blob/2ac52607c266e593700be0784ebadc77789070ff/neutron/agent/common/ovs_lib.py#L299-L319

  The code which creates the br-int bridge does not factor in an MTU,
  which means depending on what gets plugged in first, you could end up
  with 1500 MTU interfaces connected to br-int, which would give things
  like this in the system logs:

  br-int: dropped over-mtu packet: 1500 > 1458

  I'm not sure what the best solution inside Neutron to do.  Should we
  perhaps set br-int to the MTU of the largest physical network
  attachable on the agent?  I'm happy to pick up the work.

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