Explicitly set MTU on bridge devices. #46849
Conversation
|
Are there any possibly consequences of doing this? I saw your reply on the ticket, and was wondering if there's any reason we took this approach (e.g. "we don't own the bridge, so don't touch it directly"), but looking at existing code, IIUC, we're already modifying things, so guess that's not the case. Also from your other comment;
Does setting the value here limit what range can be set on the veth? Or no effect there either? (sorry if these are silly questions, just trying to see the scope of this change) |
|
Thank you for taking a look - fair questions! ...
Explicitly setting the bridge's MTU stops it from taking the min value of anything that's hooked up to it - it'll just keep the value it was given. The MTU config belongs to the bridge, not the container. So, any 'veth' that's set up for a new container will get the same MTU as bridge. So, I think it's ok. Unless there's any daemon-restart case I'm not aware of? (I tried changing the config and bouncing the daemon with I see I've broken a couple of Windows tests by using netlink in an integration test - I'll sort that out. |
This is purely cosmetic - if a non-default MTU is configured, the bridge will have the default MTU=1500 until a container's 'veth' is connected and an MTU is set on the veth. That's a disconcerting, it looks like the config has been ignored - so, set the bridge's MTU explicitly. Fixes moby#37937 Signed-off-by: Rob Murray <rob.murray@docker.com>
robmry
force-pushed
the
37937_explicit_bridge_mtu
branch
from
17ab32b
to
964ab71
Compare
thaJeztah
added
status/2-code-review
kind/enhancement
|
@akerouanton @corhere PTAL |
|
Let me bring this one in |
|
@robmry Hello, this seems to cause issues setting the MTU above 1500 ? Trying to restart the daemon setting a Tried deleting the |
|
@ivasilyev-mxr thanks for reporting; could you open a ticket for this with details (and steps to reproduce)? It's easy for comments on merged PRs to get lost 😅 |
|
Hi @thaJeztah thanks, I have created an issue: #47308 |
|
Thank you! |
| // Always set the bridge's MTU if specified. This is purely cosmetic; a bridge's | ||
| // MTU is the min MTU of device connected to it, and MTU will be set on each | ||
| // 'veth'. But, for a non-default MTU, the bridge's MTU will look wrong until a | ||
| // container is attached. |
There was a problem hiding this comment.
This is not purely cosmetic: on Linux 4.17 and newer, manually setting the MTU disables MTU auto tuning. torvalds/linux@804b854
There was a problem hiding this comment.
The MTU is defined for the network, and all the endpoints attached to the bridge get that MTU. So, auto tuning would select the network's MTU ... and, I thought, the only effect of setting it explicitly on the bridge would be to have it report that MTU before an endpoint was attached (so, cosmetic in that sense).
I don't have laptop access at the moment (won't be properly back online until Tues) - but if this change is shown to be causing problems, we should just revert it.
There was a problem hiding this comment.
Sorry, I'm speaking in a more general sense that setting the MTU on a Linux Ethernet Bridge is sticky on newer kernels, whereas on older kernels it would get clobbered every time a link is attached to it. Since we control all the links and set the MTU on all of them to the bridge MTU, it's a distinction without a difference to the libnetwork bridge driver unless someone manually changes the MTU of host-side veths. I don't think we need to revert once we patch the bridge driver setupMTU() to ignore -EINVAL.
There was a problem hiding this comment.
Forgive the potential dumb question as I am not well versed in linux networking internals.
What will be end result behavior on older version of linux after patching that function to ignore the EINVAL error response ? Will it be like it was before this MR and the docker0 interface will switch to the desired MTU > 1500 once a container is attached ?
There was a problem hiding this comment.
Will it be like it was before this MR and the
docker0interface will switch to the desired MTU > 1500 once a container is attached ?
Yes, exactly
- What I did
This is purely cosmetic - if a non-default MTU is configured, the bridge will have the default MTU=1500 until a container's 'veth' is connected and an MTU is set on the veth.
That's a disconcerting, it looks like the config has been ignored - so, set the bridge's MTU explicitly.
Closes #37937
- How I did it
When a bridge is created or updated, set its MTU to the configured value.
- How to verify it
Updated integration tests.
- Description for the changelog
Explicitly set MTU on bridge devices.