Linux – How to increase MTU size on Linux 2.6

linuxmtutcpip

How to increase MTU size on Linux 2.6?

Is such a thing possible? If yes, which files (in /etc or elsewhere) must one edit?

Best Answer

I'd warn you not not to do it unless you are really certain, that this is what you really want (like having two servers directly connected by cross-over cable over Gigabit Ethernet interfaces).

There's already PMTUD algorithm, which is able to deduce MTU size across the path. And when rising MTU above that you'll either experience some packet loss or will make network-administrating guys sad, because their routers and switches will have to fragment your packets using CPU as opposed to fast routing with ASICs.

If that's what you want, then you may want to see http://wiki.archlinux.org/index.php/Jumbo_Frames, which has some nice numbers and hints. The basic command is ip link set mtu 4000 dev eth0 (or ifconfig eth0 mtu 4000 for older ifconfig tool) for 4K packets.

Related Solutions

Linux Bash – How to Sort du -h Output by Size

As of GNU coreutils 7.5 released in August 2009, sort allows a -h parameter, which allows numeric suffixes of the kind produced by du -h:

du -hs * | sort -h

If you are using a sort that does not support -h, you can install GNU Coreutils. E.g. on an older Mac OS X:

brew install coreutils
du -hs * | gsort -h

From sort manual:

-h, --human-numeric-sort compare human readable numbers (e.g., 2K 1G)

Is there such a thing as a “typical” or “de facto” default for MTU size

You should not care about the MTU as the network stack will take care of the necessary optimizations. If you are using TCP, the stack may use methods for the calculation of the Maximum Segment Size (MSS) which in turn ideally is going to result in packets that are smaller than the lowest MTU in the path. One of them is PMTU discovery.

In general, you should not try to outsmart the stack - the layered architecture of TCP/IP employs the abstractions for good reasons. Unless you have better ones, you should leave the functionality of segmentation and fragmentation where it has been designed to be.

As others have written, there is no "safe MTU" to assume aside from the minimum defined MTU for IP packets - which is 68 bytes and thus has rather low practical value due to the enormous overhead.

Typical support issues due to MTU limitations are mainly twofold:

unnecessary fragmentation and thus higher protocol overhead and higher latencies for ping-pong protocols
broken transmissions due to ignorant firewall admins filtering ICMP and thus breaking PMTU discovery along the path

Both factors are nothing you should be dealing with in an application.

Best Answer

Related Solutions

Linux Bash – How to Sort du -h Output by Size

Is there such a thing as a “typical” or “de facto” default for MTU size

Related Topic