[openstack-dev] [neutron] VXLAN with single-NIC compute nodes: Avoiding the MTU pitfalls

Ian Wells ijw.ubuntu at cack.org.uk
Wed Mar 11 18:31:09 UTC 2015


On 11 March 2015 at 04:27, Fredy Neeser <Fredy.Neeser at solnet.ch> wrote:

> 7: br-ex.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state
> UNKNOWN group default
>     link/ether e0:3f:49:b4:7c:a7 brd ff:ff:ff:ff:ff:ff
>     inet 192.168.1.14/24 brd 192.168.1.255 scope global br-ex.1
>        valid_lft forever preferred_lft forever
>
> 8: br-ex.12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1554 qdisc noqueue
> state UNKNOWN group default
>     link/ether e0:3f:49:b4:7c:a7 brd ff:ff:ff:ff:ff:ff
>     inet 192.168.1.14/24 brd 192.168.1.255 scope global br-ex.12
>        valid_lft forever preferred_lft forever
>

I find it hard to believe that you want the same address configured on
*both* of these interfaces - which one do you think will be sending packets?

You may find that configuring a VLAN interface for eth1.12 (not in a
bridge, with a local address suitable for communication with compute nodes,
for VXLAN traffic) and eth1.1 (in br-ex, for external traffic to use) does
better for you.

I'm also not clear what your Openstack API endpoint address or MTU is -
maybe that's why the eth1.1 interface is addressed?  I can tell you that if
you want your API to be on the same address 192.168.1.14 as the VXLAN
tunnel endpoints then it has to be one address on one interface and the two
functions will share the same MTU - almost certainly not what you're
looking for.  If you source VXLAN packets from a different IP address then
you can put it on a different interface and give it a different MTU - which
appears to fit what you want much better.
-- 
Ian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150311/cf65bcd9/attachment.html>


More information about the OpenStack-dev mailing list