Open Stack

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131020/810151be/attachment.html>