Join Log in
Score:3
avatar Server

Windows MTU can no longer be set higher than 1500 Bytes?

cn flag
Timmy Brolin

For some time we have been using jumbo frames on several computers without problems.

But suddenly I am no longer able to increase the MTU on some computers to more than 1500 Bytes.

netsh returns error for any MTU value higher than 1500:

netsh interface ipv4 set subinterface “Local Area Connection 3” mtu=4096 store=persistent

The parameter is incorrect.

Jumbo frames are enabled in the Ethernet driver. The problem is on several computers with many different ethernet interfaces. But it still works on some computers.

On one computer the MTU was set to 4096 and it was working fine for a year or so. Last week I lowered it to 1500, and after that I could not set it back to 4096 again.

All computers run Windows 10 Pro.

Could this problem be related to any recent windows update? Is there anything else which can constrain the MTU setting in windows?

EDIT1

Tested on Ethernet adapters: Intel I219-LM, D-Link USB, QNAP QNA-T310G1T and ASIX AX88179. Same result on all. And at least the Intel and QNAP are known to have worked before on these computers.

Interestingly, it does work on the WMware virtual NICs on the same computer.

EDIT2

The same problem recently reported by another user on elevenforum. No solution other than reinstalling windows: https://www.elevenforum.com/t/setting-jumbo-packets-does-not-change-the-mtu.3505/

496
0 + 0
mtu
mfinni avatar
cn flag
mfinni
Interesting. On my Windows 11 machine (fully patched), I can set MTU=4096 on an interface, but not on a subinterface.
1
Reply
cn flag
Timmy Brolin
Did you use this command: "netsh interface ipv4 set interface "12" mtu=4096 store=persistent"? When I do that I get an "OK" back, but it does not actually change the MTU. Could you check with "netsh interface ipv4 show interfaces" if you were able to actually change the MTU?
0
Reply
mfinni avatar
cn flag
mfinni
Yes, that's what I did, and I didn't check that it actually made the change. I did find that going into the UI for the config on my NIC driver and setting "Jumbo Packets" from "disabled" to "9014" did set the MTU on my interface and subinterface to 8192 - so this might be more a NIC driver issue than a Windows one
0
Reply
cn flag
Timmy Brolin
When I change the NIC driver config to 4088 or 9014, nothing changes in netsh. I have had to explicitly set it on the subinterface in netsh as well. Except that does not work anymore. On multiple computers with different NICs.
0
Reply
cn flag
Timmy Brolin
Still, I think you might be onto something. I'll have to map out exactly which combinations of NICs and computers has the problem. To see if there is a pattern.
1
Reply
cn flag
Timmy Brolin
We see the problem on both "Intel I219-LM" and D-Link USB NICs. But we can activate jumbo frames on WMware virtual NICs on the same computers. Another user has reported the same problem on "Action 10GBE" and "Intel I219-V": https://www.elevenforum.com/t/setting-jumbo-packets-does-not-change-the-mtu.3505/
0
Reply
cn flag
Timmy Brolin
Tested with Ethernet NICs "QNAP QNA-T310G1T" and "ASIX AX88179" as well. Same result.
0
Reply
cyberbrain avatar
tr flag
cyberbrain
did you try to use the network troubleshooter? to me it looks like some internal windows settings are screwed up, since when I do changes in netsh interface or subinterface or the GUI of the driver settings, all changes are reflected in all other places.You might also want to try the network reset function (search for "network reset" in the start menu.
0
Reply
cn flag
Timmy Brolin
The latest clue: It seems to be related to windows updates KB5010342, KB5009543, and KB5008212. The problem occurs if either of these three are installed. On one computer we were able to fix the problem by uninstalling these. But Windows refuses to uninstall KB5010342 on most computers.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.