ifconfig eth0 mtu 7000 works but 9000 does not

[mustangtyson]

Binary package hint: network-manager

On my 3 systems with 6 network cards every one of them will not go over a MTU of 7000

:~$ sudo ifconfig eth2 mtu 9000
SIOCSIFMTU: Invalid argument
:~$ sudo ifconfig eth2 mtu 8000
SIOCSIFMTU: Invalid argument
:~$ sudo ifconfig eth2 mtu 8500
SIOCSIFMTU: Invalid argument
:~$ sudo ifconfig eth2 mtu 7000

last one works

Also recorded here:
http://ubuntuforums.org/showthread.php?t=1628575

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: network-manager 0.8.4~git.20110319t175609.d14809b-0ubuntu3
ProcVersionSignature: Ubuntu 2.6.38-8.42-generic 2.6.38.2
Uname: Linux 2.6.38-8-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
CRDA: Error: [Errno 2] No such file or directory
Date: Wed May 4 21:04:30 2011
Gconf:

IfupdownConfig:
 auto lo
 iface lo inet loopback
InstallationMedia: Ubuntu 9.10 "Karmic Koala" - Release amd64 (20091027)
IpRoute:
 10.0.50.0/24 dev eth2 proto kernel scope link src 10.0.50.102 metric 1
 169.254.0.0/16 dev eth2 scope link metric 1000
 default via 10.0.50.1 dev eth2 proto static
Keyfiles: Error: [Errno 2] No such file or directory
NetworkManager.state:
 [main]
 NetworkingEnabled=true
 WirelessEnabled=true
 WWANEnabled=true
ProcEnviron:
 LANGUAGE=en_US:en
 LANG=en_US.UTF-8
 SHELL=/bin/bash
RfKill:

SourcePackage: network-manager
UpgradeStatus: Upgraded to natty on 2011-04-25 (10 days ago)

[snek (snekone)]

I am having the exact same problem. Although network speeds are pretty damn good from Ubuntu->Windows 7 x64 (easily over 45MB/s) with default MTU of 1500.

02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03)

[Mathieu Trudel-Lapierre (cyphermox)]

This is not a bug in network-manager. My guess is this fits better as marked against the kernel, so I'm re-assigning this to the linux package (because ifconfig returns SIOCSIFMTU when passed something greater than the allowed value as a parameter).

Note that this is implemented in the driver in all cases. For instance, the e1000 driver allows up to 16128 for MTU (and it's normal since it's a gig-capable NIC). Others, although gigabit-capable, still limit to 1500 (for instance, tg3).

Windows may be accepting higher values but not necessarily taking them; you should capture traffic coming from the host and see if it's really being sent as jumbo frames, with which size, and if the other network equipment will accept it properly. With that done, it's then possible to provide more information to the kernel developers if the driver code needs to be patched.

[randallw (rwayth)]

Hi,
I came across a similar situation with a realtek 8111DL chipset. If you go to the realtek website, it explicitly says for that chipset that jumbo frames up to 9K are supported. For some of the other (cheaper?) chipsets, such as the 8111B, it does not say this. So this may well be a real limitation of the chipset.

The problem I had is that the standard realtek (8139?) driver was loaded for the 8111 by default. I think within this driver the limitation to 7200 bytes is likely to exist and I could not increase the MTU above 7200. Following a post on some other forum, I went to the realtek website and downloaded their 8168 linux driver which supports the 8168/8111DL chips. This is painless and trivial to install and it just compiles a kernel module and overwrites the existing realtek driver. (A bit dodgey, but OK if you are careful about kernel updates.) After this, I could set the MTU to 9000.

Hope this is helpful.

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

[rm (rm)]

Hello,

Please try rebuilding your kernel with the following patch. It should enable usage of MTU up to 9000, from 7200 default limit in the driver. Try it and see if you get any issues, especially on high-speed transfer in the transmit direction.

Thanks

[rm (rm)]

Actually the above patch is not needed, it should be enough to use a more recent kernel, since the proper fix is already in the mainline.