Ask Your Question
0

MTU size of VXLAN Tunnel in OpenStack Mitaka

asked 2016-09-13 06:03:38 -0500

ThomasHammann gravatar image 
Dear support,
I am using OpenStack Mitaka running on Ubuntu 14.04 LTS Server. As core plugin ML2 is used together with mechanism driver for Open vSwitch. Installation was done as described in "http://docs.openstack.org/mitaka/install-guide-ubuntu/". ML2 is configured as Core Plugin, using Open vSwitch and L2Population as Mechnism Driver.

In the ML2 configuration file the mtu size values are configured as follows:
patch_mtu = 1554
segment_mtu = 1554
physical_network_mtus = vlan:1500,external:1500

When creating a physical network type vxlan (neutron net-create....) Neutron calculates the MTU size as a minimum between patch_mtu and segment MTU and finally substracting 50 bytes. The 50 bytes are based by the overhead of the Outer Ethernet Header (14 Byte), Outer IP Header (20 Byte), UDP Header (8 Byte) and VXLAN Header (8 Byte). 

Explanation in ML2 configuration file:
# Maximum size of an IP packet (MTU) that can traverse the underlying physical
# network infrastructure without fragmentation when using an overlay/tunnel
# protocol. Either set this to the same value as the global_physnet_mtu value
# or use it to explicitly specify a physical network MTU value that differs
# from the default global_physnet_mtu value. (integer value)
patch_mtu = 1554

Questions: 

1.) Why does Neutron not use the configured 1554 Byte MTU size in ML2 configuration file, but substracts 50 Byte, resulting in a insufficient MTU size for VXLAN Networks (in my case of 1504 Bytes)? Why is it not mentioned in the ML2 configuration file, that Neutron substracts 50 byte from the configured patch_mtu/segment_mtu value to inform users about that this important aspect? What’s the idea to reduce the patch_mtu value with 50 Bytes? 

2.) In case of updating the patch_mtu and segment mtu size in the ML2 configuartion file, tests show, that the new values do not have not any effect to already created networks, but are only effective in case of creating new networks.  
I tried to update the already created network, but MTU size is not offered as an option. Is there any procedure, how to update the new patch_mtu/segment_mtu size from the ML2 configuration into already created networks? Restarting the cluster or any process restart does not help. Is it  really required to delete and re-create phsical network to adapt an already created network tot he new values from the ml2 configuration? 
Thanks a lot for support
Thomas
edit retag flag offensive close merge delete

Comments

where did you find this patch_mtu option? I don't see it in the source code.

darragh-oreilly gravatar imagedarragh-oreilly ( 2016-09-14 04:19:27 -0500 )edit
add a comment

3 answers

Sort by » oldest newest most voted
2

answered 2016-09-13 11:47:32 -0500

dbaxps gravatar image

updated 2016-09-13 11:50:17 -0500

Neutron-dhcp-agent should be configured to set MTU 1400 for any newly created tenant's subnet

   root@overcloud-controller-0 neutron]# cat dhcp_agent.ini | grep -v ^$|grep -v ^#
    [DEFAULT]
    ovs_use_veth = False
    interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver
    resync_interval = 30
    dhcp_driver = neutron.agent.linux.dhcp.Dnsmasq
    enable_isolated_metadata = False
    enable_metadata_network = False
    dnsmasq_config_file =/etc/neutron/dnsmasq-neutron.conf
    root_helper=sudo neutron-rootwrap /etc/neutron/rootwrap.conf
    state_path=/var/lib/neutron

Next

$cat etc/neutron/dnsmasq-neutron.conf
log-facility = /var/log/neutron/dnsmasq_conf.log
log-dhcp
dhcp-option=26,1400

For private tenant's networks already created I would recreate them.

edit flag offensive delete link more
add a comment
0

answered 2016-09-13 14:13:34 -0500

fifi gravatar image

updated 2016-09-14 14:37:57 -0500

The additional headers added to the packets may cause the packet to exceed the maximum transmission unit, or MTU. Encapsulating a packet with VXLAN headers or any other headers related to Openstack virtual network may cause the packet size to exceed the default maximum. Connection issues caused by exceeding the MTU show themselves in strange ways; they can be seen in partial failures in connecting to instances over SSH or in a failure to transfer large payloads between instances. Consider lowering the MTU of interfaces within virtual machine instances to account for the overhead of encapsulation is a good solution to avoid weird connectivity issues. I guess this is why Openstack reduces the MTU automatically.

edit flag offensive delete link more
add a comment
0

answered 2016-09-14 01:12:10 -0500

ThomasHammann gravatar image

Hello together,

thanks a lot for your support. I am not using the option "dnsmasq_config_file =/etc/neutron/dnsmasq-neutron.conf" in the dhcp_agent.ini file, because the value in the "dhcp-option=26,1400" is used during Path MTU discovery protocol, where DHCP Server would like to assign an MTU value to instances, and my instances (cirros) does not consider PMTU.

Be aware, my issue in not any MTU size value on any instance or subnet, but only the MTU size of the physical network created with the neutron command "neutron net-create..........." with admin priviliges.

When I use in the ml2 file the value path_mtu=segment_mtu=1604 bytes, then Neutron reduces from that value 50 bytes, finally resulting in the expected 1554 bytes, which are required for VXLAN based Overlay Networks. Please see output "net-create ..." command executed with admin rights with path_mtu=segment_mtu=1604 bytes:

root@controller01:~# neutron net-create TENANT_NET100 --tenant-id fe55df4eac9a4f7b9460877e5c30a923 --provider:network_type vxlan --provider:segmentation_id 100 Created a new network: +---------------------------+--------------------------------------+ | Field | Value | +---------------------------+--------------------------------------+ | admin_state_up | True | | availability_zone_hints | | | availability_zones | | | created_at | 2016-09-08T14:07:52 | | description | | | id | d2a33db5-c466-4d6e-a22a-eb1e70905007 | | ipv4_address_scope | | | ipv6_address_scope | | | mtu | 1554 | | name | TENANT_NET100 | | port_security_enabled | True | | provider:network_type | vxlan | | provider:physical_network | | | provider:segmentation_id | 100 | | router:external | False | | shared | False | | status | ACTIVE | | subnets | | | tags | | | tenant_id | fe55df4eac9a4f7b9460877e5c30a923 | | updated_at | 2016-09-08T14:07:52 | +---------------------------+--------------------------------------+

When I use instead of 1604 bytes the normal expected value 1554 bytes (path_mtu=segment_mtu=1604 bytes) in ml2 config, then the same output shows 1504 bytes for the physical network, which is unsufficient for VXLAN Overlay Networks:

My question is, why does Neutron when creating pyhsical networks as admin user reduce 50 bytes from the configured path_mtu/segment_mtu? This problem does not happen only Ubuntu OpenStack Mitaka, but also Ubuntu OpenStack Liberty Release.

As workaround of course we just use the value path_mtu=segment_mtu=1604 bytes in the ml2 config file.

Greetings Thomas

edit flag offensive delete link more
add a comment

Get to know Ask OpenStack

Resources for moderators

Question Tools

2 followers

subscribe to rss feed

Stats

Asked: 2016-09-13 04:00:43 -0500

Seen: 3,588 times

Last updated: Sep 14 '16

Related questions

VM's across different compute nodes not able to ping with packet size more than 1500

Launch VM fails on Compute when VXLAN ML2 type driver is used [closed]

Problem connecting external host to vxlan

Combination vxlan/vlan ML2 configuration

lbaas mtu issue

How to remove vxlan tunnels after compute node removal

use l2 population,vxlan can not establish tunnel

Do we effectively still have 4K VLAN limit with VXLAN?

windows 2012 vm stuck in "Getting Ready"

Problem with VXLAN Tunnel