Bug 1750280

Summary:	Propagate MTU to slave interface
Product:	Red Hat Enterprise Linux 8	Reporter:	Ales Musil <amusil>
Component:	NetworkManager	Assignee:	Beniamino Galvani <bgalvani>
Status:	CLOSED NOTABUG	QA Contact:	Desktop QE <desktop-qa-list>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	8.1	CC:	atragler, bgalvani, dholler, edwardh, fgiudici, lrintel, mburman, rkhan, sukulkar, thaller, vbenes
Target Milestone:	rc
Target Release:	8.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-12-03 12:20:19 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:
Embargoed:

Description Ales Musil 2019-09-09 08:33:30 UTC

Description of problem:

The MTU propagation tree should be handled by NetworkManager. For definitions of any interface relation either master/slave (bridge, bond) or vlan. 

Example expected results: 

Vlan:

dummy_Zf42B: <BROADCAST,NOARP,UP,LOWER_UP> mtu 2000 
dummy_Zf42B.10@dummy_Zf42B: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1600 
dummy_Zf42B.20@dummy_Zf42B: <BROADCAST,NOARP,UP,LOWER_UP> mtu 2000 


Bridge:

dummy_9eLco: <BROADCAST,NOARP,UP,LOWER_UP> mtu 2000
test-network: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2000



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

NetworkManager-1.20.0-3.el8.x86_64

How reproducible:

100%

Steps to Reproduce:
1. Create bridge over nic
2. Set the MTU of bridge to non-default value e.g. 2000
3. Check the MTU of bridge and slave

Actual results:

Bridge has MTU 2000
Interface has MTU 1500

Expected results:

Both bridge and interface should have MTU 2000 

Additional info:

The propagation should apply to any kind of those relations (bond, bridge, vlan).

Comment 2 Beniamino Galvani 2019-10-02 16:35:25 UTC

Let's look at how kernel handles MTU assignment when there are master
or parent relationships:

 - the MTU of a VLAN is initially set to same value as master, and it
   is not updated when the master changes (except to avoid that the
   VLAN MTU doesn't exceed master's).

 - for bonds, the slaves' MTU is automatically set to match the bond
   MTU upon enslavement and it is also updated when the bond MTU
   changes. It is also reset to the previous value when the slave is
   released. The slaves' MTU can be explicitly set by user to a
   different value, but this is going to break things for modes other
   than active-backup.

 - teams are handled in the same way as bonds: the kernel propagates
   the MTU from master to slaves.

 - for bridges, unless overridden by user, the bridge MTU is
   automatically updated when a port is added/removed to match the
   minimum of slaves' MTU. So ports can have different MTUs and if the
   destination port of a frame has a MTU lower than the frame size the
   frame gets dropped.

Now the NM side:

 - NM already keeps the MTU of VLANs aligned to master (unless
   explicitly overridden by user).

 - for bonds and teams no action seems necessary because kernel
   already takes care of propagating the MTU to slaves

 - currently it doesn't propagate the MTU to bridge slaves.

The only part missing seems to be bridges. Maybe we should implement a
propagation mechanism to slaves, but only when the MTU is explicitly
set on the bridge connection, not when the kernel changes the bridge
MTU after adding/removing a port because it seems wrong to propagate
one of the slaves' MTU to others.

There are also open questions about the implementation... if a vlan is
enslaved to a bridge, should it get the MTU from the parent or from
the bridge?

Anyway, I consider this a nice-to-have but not strictly a necessary
feature since without any configuration the bridge will get the right
MTU from slaves. If users care about setting a different value, they
can also set the slaves MTU to the needed value that I guess can be
also a different value than master's in particular scenarios.

What do others think?

Comment 3 Edward Haas 2019-11-12 11:52:33 UTC

(In reply to Beniamino Galvani from comment #2)
> The only part missing seems to be bridges. Maybe we should implement a
> propagation mechanism to slaves, but only when the MTU is explicitly
> set on the bridge connection, not when the kernel changes the bridge
> MTU after adding/removing a port because it seems wrong to propagate
> one of the slaves' MTU to others.

Everything sounds right to me so far.
We have encountered bridges in a few incidents now, and it seems their MTU
affects only the management interface but not the forwarding. Therefore,
changing a bridge MTU should not have side effects.

Ales, based on this info, do you have an example of something that you
still think is relevant to this request? If not, I guess we can close it.

Comment 4 Ales Musil 2019-12-03 12:20:19 UTC

(In reply to Edward Haas from comment #3)
> (In reply to Beniamino Galvani from comment #2)
> > The only part missing seems to be bridges. Maybe we should implement a
> > propagation mechanism to slaves, but only when the MTU is explicitly
> > set on the bridge connection, not when the kernel changes the bridge
> > MTU after adding/removing a port because it seems wrong to propagate
> > one of the slaves' MTU to others.
> 
> Everything sounds right to me so far.
> We have encountered bridges in a few incidents now, and it seems their MTU
> affects only the management interface but not the forwarding. Therefore,
> changing a bridge MTU should not have side effects.
> 
> Ales, based on this info, do you have an example of something that you
> still think is relevant to this request? If not, I guess we can close it.

Seems reasonable enough. Closing as not a bug.