Comment 6 for bug 1242534

Hi,
it's a bit trick to know exactly where to mention the necessity of this flag. It's a flag that has to be activated in neutron.conf when ML2 plugin use LinuxBridge agent and vxlan technologie. May be here :
http://docs.openstack.org/havana/config-reference/content/networking-plugin-ml2_vxlan.html

-----Message d'origine-----
De : <email address hidden> [mailto:<email address hidden>] De la part de Édouard Thuleau
Envoyé : mercredi 30 octobre 2013 17:33
À : ROHON Mathieu IMT/OLPS
Objet : [Bug 1242534] Re: Linux Bridge MTU bug when the VXLAN tunneling is used

It's not about the flag 'network_device_mtu'.

It's in case we use VLXAN overlay technology with LinuxBridge agents without any MTU customization.
In that case, flows passing through a virtual router will have some strange behavior (cannot make curl from server behind a router or execute command with verbose output in SSH through a floating IP (SSH connection works)...).

This could be corrected by customizing the physical device MTU (by
increasing it by 50 octets) or by decreasing the MTU of interfaces
created by Neutron agents with flag 'network_device_mtu'.

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/1242534

Title:
  Linux Bridge MTU bug when the VXLAN tunneling is used

Status in OpenStack Manuals:
  Incomplete

Bug description:
  I made some tests with the ML2 plugin and the Linux Bridge agent with
  VXLAN tunneling.

  By default, physical interface (used for VXLAN tunneling) has an MTU
  of 1500 octets. And when LB agent creates a VXLAN interface, the MTU
  is automatically 50 octets less than the physical interface (so 1450
  octets) [1]. Therefore, the bridge use to plug tap of VM, veth from
  network namespaces (l3 or dhcp) and VXLAN interface has an MTU of 1450
  octets (Linux bridges take minimum of all the underlying ports [2]).

  So the bridge could only forward packets of length smaller than 1450
  octets to VXLAN interface [3].

  But the veth interfaces used to link network namespaces and bridges
  are spawn by l3 and dhcp agents (and perhaps other agents) with an MTU
  of 1500 octets. So, packets which arriving from them are dropped if
  they need to be forwarded to the VXLAN interface.

  A simple workaround is to increase by 50 at least the MTU of the
  physical interface to harmonize MTU between interfaces. But by default
  (without MTU customizing), the LB/VXLAN mode have strange behavior
  (cannot make curl from server behind a router or execute command with
  verbose output in SSH through a floating IP (SSH connection works)...)

  [1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/vxlan.c#n2437
  [2] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/net/bridge/br_if.c#n402
  [3] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/net/bridge/br_forward.c#n74

To manage notifications about this bug go to:
https://bugs.launchpad.net/openstack-manuals/+bug/1242534/+subscriptions

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.