Bug 1387389

Summary:	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
Product:	Red Hat OpenStack	Reporter:	Sai Sindhur Malleni <smalleni>
Component:	openstack-tripleo	Assignee:	Brent Eagles <beagles>
Status:	CLOSED WONTFIX	QA Contact:	Ofer Blaut <oblaut>
Severity:	high	Docs Contact:
Priority:	high
Version:	10.0 (Newton)	CC:	amuller, mburns, mcornea, njohnston, racedoro, rhel-osp-director-maint
Target Milestone:	async	Keywords:	Triaged, ZStream
Target Release:	10.0 (Newton)
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	PerfScale
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-05-09 17:56:29 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Bug Depends On:
Bug Blocks:	1386319

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.