Open Stack

I had a look for fix that and I don't found a simple way.

The minimal MTU can be deducted by the LB agent with the value found on the
bridge and the LB agent can set it on veth interface connect to that bridge.
But there no easy way to set it on the other side of the veth in the
namespace. LB agent doesn't know the name of the other side of the veth and
it doesn't know the name of the namespace. Furthermore, I'm not sure it's a
good way to modify network in a namespace doesn't manage by the LB agent.

Another simple solution, is to set a global config flag to define the
minimal MTU and all agents which create veth use it to set interfaces MTU.

I opened a bug to discuss: https://bugs.launchpad.net/neutron/+bug/1242534

Regards,
Édouard.


On Sun, Oct 20, 2013 at 5:29 PM, Salvatore Orlando <sorlando at nicira.com>wrote:

> It might be worth both documenting this limitation on the admin guide and
> provide a fix which we should backport to havana too.
> It sounds like the fix should not be too extensive, so the backport should
> be easily feasible.
>
> Regards,
> Salvatore
>
>
> On 18 October 2013 21:50, Édouard Thuleau <thuleau at gmail.com> wrote:
>
>> Hi all,
>>
>> 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)...)
>>
>> So my question is, do you think we need to open a bug and find a fix for
>> that ? Or do we need to put warning in docs (and logs perhaps)?
>>
>> [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
>>
>> Édouard.
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131021/cf751d2b/attachment.html>