Description of problem: In investigating an MTU issue, an accounted-for overhead of 4 bytes was discovered. A spurious 802.1q header was discovered using tcpdump when attempting to connect to a guest via floating IP. The tenant network type is VXLAN and the VXLAN endpoints themselves are on a VLAN. This issue effectively breaks communication with guests via floating ip for some system configurations. The test system is configured with a default global_physnet_mtu of 1500 and inspection of the router namespace confirms that the tenant network's router interface has been automatically configured to with an MTU of 1450. Ping was used to test. e.g. ping -M do -s 1422 192.0.2.58 (1422 is the maximum that should fit in the 1450 MTU without fragmentation). Version-Release number of selected component (if applicable): openstack-neutron-9.0.0-0.20160823075219.1b19d06.el7ost.noarch openstack-neutron-ml2-9.0.0-0.20160823075219.1b19d06.el7ost.noarch openstack-neutron-common-9.0.0-0.20160823075219.1b19d06.el7ost.noarch puppet-neutron-9.1.0-0.20160822221647.b20ea67.el7ost.noarch openstack-neutron-metering-agent-9.0.0-0.20160823075219.1b19d06.el7ost.noarch openstack-neutron-openvswitch-9.0.0-0.20160823075219.1b19d06.el7ost.noarch python-neutron-tests-9.0.0-0.20160823075219.1b19d06.el7ost.noarch python-neutron-9.0.0-0.20160823075219.1b19d06.el7ost.noarch python-neutron-lib-0.3.0-0.20160803002107.405f896.el7ost.noarch python-neutronclient-5.0.0-0.20160812094704.ec20f7f.el7ost.noarch How reproducible: 100% Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
I sent a patch upstream for tempest to catch this kind of issues: https://review.openstack.org/#/c/370804/
The fix landed upstream, we don't need documentation as no customers were impacted by it. We also don't need manual QE verification as Brent already did that.