Bug 1387389 - Changing global_physnet_mtu changes mtu of all virtual interfaces but leaves out Tenant network VLAN interface breaking ssh access to guest due to MTU mismatch
Summary: Changing global_physnet_mtu changes mtu of all virtual interfaces but leaves ...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo
Version: 10.0 (Newton)
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: async
: 10.0 (Newton)
Assignee: Brent Eagles
QA Contact: Ofer Blaut
URL:
Whiteboard: PerfScale
Depends On:
Blocks: 1386319
TreeView+ depends on / blocked
 
Reported: 2016-10-20 18:36 UTC by Sai Sindhur Malleni
Modified: 2019-05-09 17:56 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-05-09 17:56:29 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1635278 0 None None None 2016-10-20 18:37:40 UTC

Description Sai Sindhur Malleni 2016-10-20 18:36:29 UTC
Description of problem:
Starting Newton, global_physnet_mtu was supposed to be the single parameter that the user can change to change the mtu of the guest and all the interfaces leading to the guest. However, bumping global_physnet_mtu to 9000 and restarting neutron services changes MTU of all the virtual interfaces including tap, bridge, ports on ovs etc to 8946 but leaves the Tenant network VLAN interface to 1500 causing ping to work but ssh to guest fail. There should be a single parameter than can be changed during deploy/later like OvercloudBaseMTU : 1500 and everything should work from there.


Version-Release number of selected component (if applicable):
RHOP 10

How reproducible:
100%

Steps to Reproduce:
1. Deploy overcloud 
2. Now change global_physnet_mtu to 9000
3. All the virtual interfaces are set to 8946 but tenant vlan interface remains at 1500 breaking ssh access

Actual results:
Cannot SSH to gues

Expected results:
SSH should work and in fact network tests should report greater throughput

Additional info:

Comment 1 Sai Sindhur Malleni 2016-10-20 19:16:24 UTC
ip a on the compute node: http://pastebin.test.redhat.com/423087
ovs-vsctl show on the compute node: http://pastebin.test.redhat.com/423088

You can see how qvo98d4949e-33@qvb98d4949e-33, qvb98d4949e-33@qvo98d4949e-33 and tap98d4949e-33 are all set to 8946 but vlan237 is set to 1500

Comment 2 Assaf Muller 2016-10-20 23:34:24 UTC
From the Launchpad bug:

"Fwiw, manually bumping the tenant network vlan interface to 9000 solves the issue and I'm able to SSH to the guest."

From comment 1 Sai is talking about "vlan237", an OVS internal port created by TripleO. Seems like a straight forward bug, although not a regression, this functionality has simply never worked as far as I know.

Comment 4 Brent Eagles 2018-01-23 20:50:43 UTC
NeutronGlobalPhysnetMtu is neutron specific. This bug is effectively an RFE for a value that configures neutron as well as any interfaces that might be involved with traffic where the neutron global_physnet_mtu holds sway. We will need to file a blueprint u/s for this. While we can target rocky there are other priorities that may take precedent and it may be pushed further out.

Comment 6 Nate Johnston 2019-05-09 17:56:29 UTC
Declaring this WONTFIX with Brent's concurrence.


Note You need to log in before you can comment on or make changes to this bug.