-
Notifications
You must be signed in to change notification settings - Fork 104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
who is supposed to set interface MTU? #67
Comments
The problem is that a lot of interfaces reset their PHY on MTU change whether through driver error or a hardware limitation. The downside is that this won't allow jumbo frames. I suppose we could add an option to increase the interface MTU if the procotol MTU is bigger and then reset it back to what it was when the carrier goes down OR dhcpcd exits. This would likely default to off though due the resetting PHY problem. |
First of all, thank you for the reply. It's so hard to find any reliable
information on this - it seems very few people use jumbo frames, even
though in my experience they are supported by most current consumer
NICs.
Quoting Roy Marples (2021-10-29 13:03:47)
The problem is that a lot of interfaces reset their PHY on MTU change whether through driver error or a hardware limitation.
This in turn triggers carrier down/up which isn't exactly desirable.
Right, the Realtek NIC on my desktop machine does that. It's annoying,
but as long as it only happens once per boot it should not be a big
deal.
The other side effect is when different protocols want different MTU values (strikes me as weird, but it's how some setups work).
As such dhcpcd just changes the MTU at the route level as you now see.
The downside is that this won't allow jumbo frames.
There is also the issue where you change network from jumbo frames to non jumbo frames and there's nothing on the new network to say what the MTU size should be, expecting the interface default to just work.
I suppose we could add an option to increase the interface MTU if the procotol MTU is bigger and then reset it back to what it was when the carrier goes down OR dhcpcd exits. This would likely default to off though due the resetting PHY problem.
That sounds reasonable to me. I don't expect this to work automagically,
toggling an option is still a big improvement over manually setting the
exact MTU value everywhere.
…--
Anton Khirnov
|
As we are currently having issues with The DHCP server returns the MTU size for each client/interface (option 26 IIRC) and thus it would be nice to have a way for the local DHCP client to react to that "properly". Even if this was just an opt-in option, we would be very grateful for the addition :) Anything from our side, we can help to get this feature? |
Sorry for the late reply. You can create a hook script to set MTU based on the value returned by
|
I am trying to set up jumbo frames on (some subnets of) my home LAN (in order to reduce the router load for large
transfers) and I'm struggling to understand how to set the interface MTU without manually hardcoding it on every
machine. Apparently dhcpcd used to have a hook that did this, but it was removed in
ca6cdf5, with the replacement code only setting route MTU, which apparently has no
effect if the interface MTU is smaller.
Any hints on how the interface MTU is supposed to be set up properly? Hardcoding it is annoying and error-prone, ideally
something would just pick it up from RAs. Or are there any major disadvantages to that?
The text was updated successfully, but these errors were encountered: